开发流程和程序概述
Last updated: June 19, 2026
本文档将概述 Leading2Lean 的开发流程和程序。本流程描述了 Leading2Lean 在对生产服务和基础设施进行更改时应遵循的职责、政策和程序。所有员工都必须遵守此政策。
Leading2Lean 技术团队负责为我们的客户提供稳定可靠的 IT 基础设施。开发流程旨在最大限度地减少对我们数据中心环境的服务中断，并促进系统的可用性和完整性。首席技术官（CTO）负责根据需要维护和更新开发流程和程序。此流程还受组织控制措施的进一步管辖，这些控制措施是我们 AICPA SOC 2 Type 2 合规计划的一部分。这些控制措施由我们的外部审计师每年进行审计。
开发流程从开发人员审查工单开始，与同事协调架构和设计，编写代码，接收 QA 团队的反馈，最终向客户发布软件。
范围
本文档定义了功能请求和漏洞的生命周期。还描述了用于确保每个版本都进行适当测试和验证的流程和程序。本文档不描述我们变更控制政策概述中定义的变更管理流程。
定义
待办列表：一组尚未开始开发的漏洞和功能。待办列表中存放所有低优先级工单。
漏洞：未按预期运行的功能。漏洞的严重程度可以从不严重到极其严重不等。漏洞列表中存放所有低优先级漏洞。工单会在分类会议期间被放入漏洞列表。工单会从漏洞列表中分配给开发团队成员。
功能或增强：尚未为软件开发的行为。这可以是对现有功能的修改，也可以是创建新功能。
项目或史诗：漏洞和功能的集合。项目在路线图上进行管理。
路线图：项目的集合。路线图是大型项目的规划板。路线图推动新功能（无论大小）的开发。
分类处理：新工单的收集。分类处理列表是所有新工单创建的地方。分类处理团队随后会将工单放入漏洞列表、路线图或待办列表。
概述
每个开发工单主要分为 3 个阶段：1. 规划，2. 开发，以及 3. 质量保证测试。下面将逐一讨论每个阶段。
规划
我们采用多学科的分类处理方法来进行规划。我们的支持、开发和质量团队会定期举行分类处理会议，以评估新问题、功能请求和改进需求。根据严重程度，这些问题可能会触发升级的故障修复响应周期，以便在高优先级项目或服务出现降级时恢复服务。否则，我们会为其设定初始优先级，并将其交给产品团队进行进一步规划、确定优先级和安排。
功能通常是在少数人员的参与下进行规划的。这可能包括产品团队成员、主题专家、客户等。这由我们的产品管理团队推动。
大多数功能请求会在路线图规划会议期间进行讨论。在此会议中，将讨论项目和升级的功能请求。项目将与其他项目进行优先级排序，功能请求则会经过审查并移至待办列表。功能请求可能会关联到路线图中的某个项目。
开发
规划过程完成后，这项工作会分配给开发团队。开发团队拥有自己的一套开发环境，该环境是我们生产环境的镜像。这是我们质量计划的重要组成部分。在开发生命周期的每个步骤（开发、质量保证、暂存和生产）中，我们都会维护独立的基础设施，以确保完成的任何工作在进入生产环境之前都经过适当的测试和验证。
我们采用了一整套行业标准的开发工具，用于版本控制、自动化测试、静态代码分析和代码整洁性检查。这些工具可以及早且频繁地向开发人员提供反馈，以确保尽可能高的代码质量。它们还有助于保持开发分支之间适当的隔离，避免在处理不同项目、任务和代码库元素的开发人员之间发生交叉污染。这些工具为代码同行评审和审批流程提供了标准化方法，以确保任何准备交由质量保证测试的代码都已通过所有自动化测试和验证检查。
当开发人员对如何实现工单有疑问时，他们会直接与支持团队、产品团队或其他开发人员沟通。所有用户界面更改都需要获得产品团队的批准。由于用户界面更改会影响客户，并且可能需要进行培训，因此我们会与客户、支持团队和产品团队合作，确保在设计任何用户界面更改时得到妥善处理，以尽量减少对客户的影响。在质量保证测试阶段，我们的支持团队还会对所有用户界面更改进行审查，以验证功能是否正常，并确保客户获得适当的通知和培训。
开发人员必须按照日常操作流程，在进行任何更改后成功运行我们的自动化测试套件。工单通过这些自动化测试后，即可由开发人员以外的其他人员进行审查。此事件让关键团队成员知道现在是提供反馈的时候，同时也表明该工单距离发布更近了一步。
所有代码在交给质量保证团队之前，都必须由另一名开发人员进行同行评审。这有助于确保不止一个人了解并理解正在进行的更改及其原因。代码评审的目的应是思考更改的总体目标，检查代码是否存在简单错误，扫描代码中是否存在低效之处，在发现问题时要求澄清，并努力保持与编码标准和最佳实践的一致性。 有时，原开发人员会因测试阶段的反馈而重构代码。如果这导致大量代码更改，则会进行额外的评审。 当代码评审共识被记录并归档后，代码即可发布给质量保证团队
质量保证测试
自动化测试套件成功完成且没有错误，并且代码评审成功完成后，质量保证团队即可开始质量保证测试流程。
测试过程涉及的两项主要活动是运行自动化测试脚本和手动测试。L2L 拥有一套 UI 和单元测试用例，可从命令行运行。此外，还有一个针对代码运行的 lint 检查流程，用于检查基本的编码错误。所有开发人员在提交代码进行审查之前，都应运行测试套件和 lint 检查流程。QA 团队会在将代码部署到 QA 测试环境后，自行审查自动化测试套件的结果。这确保我们拥有一个干净的测试环境，以评估代码更新是否能够按照设计以及我们的质量标准正常运行。
QA 团队将协调代码的手动测试，以确保额外的质量保障。QA 团队的反馈将记录到开发工单中。通常，在 QA 批准之前，代码需要进行重构和更新。QA 会通过批准拉取请求来表示代码已准备好合并。QA 会在所有内容获得批准后，将代码合并到主代码库中。这确保开发人员无法将代码合并到我们的主代码库中并绕过 QA 流程。
在质量保证测试阶段，QA 团队还将利用支持团队成员和客户来执行用户验收测试。这些测试对于确保代码更改可用、符合客户需求，并遵守任何行业法规和要求至关重要。
变更控制流程和部署到生产环境
为确保对生产环境的任何更改都遵循标准流程，我们实施了变更管理流程，具体定义于我们的变更控制政策概述中。这确保组织中具备适当的检查和平衡机制，以确保生产环境的质量、安全性和可用性。有关此流程的更多信息，请参阅上述链接。
需要注意的是，作为变更控制流程的一部分，L2L 使用自动化部署脚本，将软件从代码存储库发布到客户服务器。在任何情况下，员工都不会手动更新生产环境。此自动化系统会为每次新版本发布/部署创建审计跟踪，并验证是否已获得适当的批准。完成此操作后，发布脚本才会获准更新生产服务器。此自动化脚本还会提供公司内部的部署通知。部署完成后，此自动化系统还会执行“烟雾测试”，以验证部署是否成功以及生产环境是否正常运行。
回顾会议
如果发布的代码重新引发了旧问题或导致系统发出警报，将召开复盘会议，也称为事后分析会议。会议的目的是收集与不良代码发布相关的事实，讨论防止类似事件将来发生的方法，分配与防止未来事件相关的任务，并向团队介绍该事件。这些会议应在事件发生后的36小时内举行，并应尽可能邀请开发人员和质量保证团队成员参加，以进行根本原因分析和培训。
客户通知
在此过程中，可能会多次向客户发送通知。在规划、开发、质量保证阶段以及代码发布后，通常都会征求客户的意见。将通过以下方式通知客户：
- 个人联系 / 计划会议。 参与特定开发项目的客户可能会受邀参加定期更新会议，以审查计划、设计和项目状态。
- 向客户发送个人电子邮件。所有发起的支持工单都会更新，告知客户更改已发布到生产服务器，并且工单将被关闭。如果未创建支持工单，支持代表可能会直接联系客户。如果更改只影响一位客户，则可能不会使用其他通知方式。
- 变更日志。所有影响客户的更改都将包含变更日志。这包括漏洞修复、次要更新和功能请求。当更改只影响单个客户且影响较小时，如果已直接联系客户，则可能不会添加变更日志。客户可以从应用程序的支持菜单访问变更日志。
- 群发电子邮件。对于应用程序的所有重大更改，将向所有管理员发送电子邮件。群发电子邮件主要用于产品公告和大型用户界面增强，但也可用于其他场景。
- 应用内通知可用于影响较大的更改。