持续交付原则

CD 是一种组织范围内的包容性方法，包括设计、产品和营销等非工程团队。CD 鼓励开发人员专注于交付最终用户产品，而非 CD 环境可能会激励“翻墙”行为，在这种行为中，QA 团队成为开发人员关注的主要用户体验。下一节将讨论为 CD 工作流程奠定基础的具体原则。

组织流程有自己的开发生命周期。它们通常以手动清单或“剧本”开始，是手动执行的任务列表。稍后，它们可能会使用软件工具和脚本实现自动化。将这些剧本提交到软件脚本中可确保它们是可重复的。如果需要再次运行清单，则团队成员可以执行该脚本。当这些剧本脚本在不同环境之间持续运行时，可靠性就会提高。例如，将代码部署到开发或暂存环境的剧本应尽可能地镜像生产环境。环境和执行之间这种可靠的一致性消除了一整类一致性错误。

自动化是 CD 的关键价值。人类的时间很宝贵，应该花在创造性练习上，而不是花在繁琐的小技巧任务上。手动流程只有在提交到代码并可按需自动执行之后，才能真正实现可重复和可靠。可以将自动化任务组合在一起以进一步提高自动化水平。尽可能实现自动化：测试、发布、配置变更等。

作为 CD 的基础，版本控制是任何严肃的软件项目的绝对必要条件。版本控制使开发人员团队能够在共享的代码库上进行高效协作。Git 是使用最广泛的版本控制系统，也是 CD 的绝佳伴侣。版本控制通过允许回滚到之前的候选版本来启用“撤销”功能。除代码外，配置、脚本、数据库、文档都应进行版本控制，以跟踪整个历史记录中的编辑。

在 CD 中，质量不是 QA 团队事后的想法，质量已融入发布管道的每个步骤。CD 的中央反馈回路是不断重新检查交付给最终用户的质量。新功能是通过一系列自动测试提供的，这些测试可确保新代码没有错误并符合质量预期。新功能发布的项目规划应包括分析、性能监控和自动测试工具任务方面的注意事项。

随着时间的推移，痛苦、耗时或容易出错的任务会变得越来越复杂。应尽快完成痛苦的任务，以防止进一步的能量损失。想象一件痛苦的琐事，需要 20 分钟才能完成，每周要做五次。这相当于每周痛苦 100 分钟，每月痛苦约 400 分钟。想象一下，您可以解决这个琐事并对其进行优化，完全避免痛苦时光。显然，那将是一场胜利。

“先做最难的部分”也是帮助确定组织过程中的弱点的练习。如果某项任务被拖延或主动回避，则表明该任务可能是一个有待改进的领域，应积极推进。团队应定期接触困难的部分，以保持熟悉，并让他们在规划对话时处于最前沿。

整个组织应集中精力并激励他们，确保最终用户交付成果尽可能优质。产品经理在规划时应注意部署和质量保证。安全团队应积极参与发布流程。QA 团队成员应像在生产中一样严格地测试开发和暂存环境，以便在最终发布之前发现任何故障。开发人员应积极规划量产发布。

软件公司的业务是向最终用户提供软件。如果一个应用只能在一个开发人员的计算机上运行，那就没有意义了。“它对我有用”是常见的危险信号，表示对总体业务目标缺乏认识，对最终用户缺乏同理心。CD 完全专注于向最终客户交付软件。此外，“完成”并不意味着团队个人成员的贡献何时完成，而是团队的全部贡献已完成。

希望前面的章节已经开始说明 CD 的高级附加价值。在宏观层面上，CD 可提高执行效率、跨团队沟通、产品市场契合度、敏捷性和整体组织透明度。

在微观层面上，可以通过测量明确的跟踪指标来衡量 CD。一些有价值的 CD 指标可能是：

• 从新功能设计阶段到生产发布的时间。
• 用户遇到了多少生产错误。
• 用户对新功能的参与度。
• 新功能发布的频率

此外，CD 可以用作构建组织绩效指标（如 KPI）的基础。最后，底线业务收入和财务状况是衡量组织实践影响力的好方法。

在了解了 CD 的好处和理念后，接下来就是将其付诸实施。持续集成是一个很好的起点。持续集成或 CI 是 CD 的先导。CI 专注于自动化代码发布的工作流程。它通过使用自动代码测试工具和质量保证任务来做到这一点。CI 建立后，可以在其上构建 CD 进程，向最终用户部署代码，并开发反馈回路来指导未来的版本。