了解持续交付

持续交付 (CD) 建立在持续集成 (CI) 的基础上，自动执行准备将软件发布到生产中所涉及的步骤。

每次将代码更改合并到指定分支时，持续集成流程都会运行一系列检查，包括自动化单元测试，并创建构建。 持续交付扩展了这一流程，自动将每个构建部署到一系列测试和暂存环境并运行进一步自动化测试。

这些测试包括集成测试、UI 测试、性能测试（如负载、浸泡和压力测试）以及端到端测试。 根据您的行业，您还可以使用持续交付运行安全测试、无障碍功能测试以及手动用户验收或探索性测试。 构建成功通过每个阶段后，就可以发布到生产。

与持续集成一样，有效持续交付做法的关键是尽可能自动执行流程。 这包括在每个阶段提供反馈，并在构建未能通过某个阶段时提醒团队，以便您快速解决问题。

持续交付和持续部署都涉及自动将构建部署到环境并运行自动化测试。 因此，这两个词有时会互用。 不过，持续交付和持续部署之间仍有一个明显的区别。

借助持续部署，代码更改每次成功通过所有测试阶段后，就会自动部署到生产中。 持续交付则涉及最后阶段的手动步骤，也就是将软件发布到生产。

虽然持续部署听起来像是软件开发团队的理想目标，但许多团队经过合理考量决定选择持续交付。

详细了解持续交付与持续部署。

CI/CD 流程的最后阶段涉及将代码更改部署到生产。 对于持续交付，虽然发布流程本身是自动化的，但发布到生产的决定还是手动步骤。

某些团队将持续交付作为持续部署的垫脚石。 在完善自动化测试和检查时，手动触发到生产的最终部署可以提供一个安全网。 在这种情况下，您可能会选择先进行几个月的持续交付，然后再将每个成功的代码更改自动部署到生产。

但是，每天或每小时多次部署软件更新并不总是理想的选择。 对于版本化软件（包括移动应用、API、嵌入式软件或桌面产品），通常有必要将更改分组到更大的版本中。 已安装产品的用户不会希望每隔几个小时就更新一次应用，而升级到新的 API 版本可能会对您的客户产生重大影响。 在持续交付和部署之间做出选择，就是要为企业和用户做出正确的决定。

虽然具体的构建步骤、环境和测试取决于您的产品和组织，但以下一般原则还是可以帮助您构建持续交付流程：

• 从 CI 开始：大多数情况下，可以在持续交付之前实现持续集成。 CI 主要影响开发团队，这就提供了一个在涉及外部利益相关者之前熟悉自动执行构建、测试和部署流程的机会。
• 设计您的 CD 流程以获得快速反馈：尽早发现问题可以使您的开发流程更加高效。 某些阶段可以并行运行，例如针对不同平台构建的自动化 UI 测试。 同样，运行时间较长或消耗大量资源的性能测试也可以推迟，直到构建成功通过先前的阶段。
• 与利益相关者互动：DevOps – CI/CD 背后的理念鼓励开发团队打破孤岛，考虑整个软件开发流程。 设计 CD 管道时，从运营和安全到营销和支持，让参与当前发布流程的所有人员加入进来。
• 自动执行测试：自动化测试对于持续交付至关重要，因为它们可以提供快速可靠的验证，确保软件按预期运行。 如果没有自动化测试，则应优先考虑影响最大的领域，并逐步扩大测试覆盖率。
• 重用相同的构建工件：为了避免引入不一致，应将相同的构建工件从 CI 阶段部署到每个预生产环境和生产本身。
• 自动刷新测试环境：理想情况下，应当为 CI/CD 流程中的每个新构建刷新测试环境。 容器和基础架构即代码方式让您可以更轻松地根据需要拆除和启动新环境。
• 考虑利益相关者的需求：上一点的例外是支持、销售或营销团队用来熟悉新功能的暂存环境。 这些团队可能更喜欢根据请求更新环境，以避免中断正在进行的工作。
• 采用 DevSecOps：信息安全或网络安全团队通常被视为频繁发布的障碍，因为安全审核需要大量时间，并且随后需要生成长篇报告。 采用 DevSecOps 方式，从一开始就将安全要求融入管道。
• 考虑手动测试要求：根据您的企业，加入一些手动探索性测试，帮助识别意外故障模式。 与其要求对每次代码更改进行手动测试，不妨考虑设置每周或每月运行的可选步骤或替代管道。
• 自动执行发布：虽然持续交付意味着发布到生产的决定是手动做出，但发布本身应该自动化。 您应当能够使用一个命令将良好的构建部署上线。

持续交付使团队能够更快、更频繁地发布软件，同时减少进入生产的 bug 数量。 为此，关键在于持续测试更改并在发现问题时立即解决，确保代码随时可以发布。

此外，持续交付还提供了多项额外优势：

• 更频繁地发布意味着您可以加快产品上市时间，更快地向用户提供新功能、修正和增强。
• 持续测试流程意味着您可以快速获得工作反馈。 如果最近的更改引入了漏洞，导致应用在某些情况下挂起或者 API 调用失败，相较于传统的发布测试流程，您会更快发现。
• 尽早发现问题会使开发流程更加高效。 您仍然记得更改，而且添加依赖于错误代码的其他代码更改的风险也更小。
• 自动执行重复构建、测试和发布任务可以确保一致执行并降低出错风险，同时让团队成员能够专注于增加价值。
• 投资自动化测试有助于更全面地测试软件。 这可能包括跨多个平台进行一致测试、检查您是否满足无障碍功能要求，或对产品或服务的性能进行基线测试。
• 自动刷新环境和部署构建可以帮助您更有效地使用基础架构，无论是内部服务器还是云托管构建场。
• 自动执行到暂存站点的部署有助于确保产品、营销和支持团队可以预览新功能，无需开发或运营团队进行额外的手动操作。
• 持续交付使发布流程稳健且可重复，同时让您可以精确控制发布时间。 通过 CD 流程，您可以选择每周、每天甚至每小时交付小型改进。

实现持续交付流程可能会遇到一些挑战：

• 跨团队协作：您可能需要组织多个部分的协作，例如运营、基础架构和安全团队。 虽然打破孤岛在短期内可能具有挑战性，但从长远来看，它会带来更好的协作和更高的效率。
• 时间投入：自动执行构建、测试和发布流程需要时间。 不过，采取迭代方式并逐步完善流程可以使这更易于管理。 收集缺陷率和构建时间等指标并将其与手动过程进行比较，是向利益相关者展示投资回报的有效方式。
• 扩缩挑战：在扩缩持续交付流程时，您可能会希望并行运行多个构建和测试。 此时，可用服务器的数量可能成为限制因素。 优化管道性能后，可以考虑迁移到云托管基础架构，以根据需要扩缩构建场。

搭建持续交付流程看似艰巨，但只要方法得当，它可以大幅加快软件发布速度，同时最大限度地减少 bug。

有效实现持续交付的关键是采用 DevOps 思维。 DevOps 倡导协作和从短的迭代周期中快速获取反馈，而不是将软件开发流程视为单向传送带 – 要求、代码和报告从一个团队传递到另一个团队。

改变您对“完成”的定义可以帮助您接受这种心态。 不要在将代码交给测试时就认为任务已经完成，只有您的新功能或代码更改发布上线后才算完成。 如果在管道的任何阶段发现问题，与必须由更改委员审批的冗长报告相比，及时传达反馈并展开协作可以更快地解决问题。 这就是持续交付的意义所在。

如需帮助您开始采用持续交付的更多提示，请阅读我们的 CI/CD 最佳做法指南。

持续交付使发布软件变得更加轻松快捷，您可以更频繁地部署到生产。 更频繁交付的小型更新将取代大型的季度或年度发布。 这不仅意味着用户可以更快获得新功能和 bug 修正，还意味着您可以了解软件的实际使用情况并相应调整计划。

虽然某些组织倾向于对发布流程的最后一步保持控制，但对其他组织来说，CI/CD 管道的逻辑结论是使用一种称为持续部署的做法自动将版本上线。 您可以在我们 CI/CD 指南的下一部分中了解详情。

TeamCity 是一个 CI/CD 平台，广泛支持各种构建工具、测试框架、容器和云基础架构提供商。 无论您是想在现场、云端或两者结合来托管构建机器，TeamCity 都会协调构建任务以实现最高效率。

TeamCity 的可定制管道逻辑意味着您可以选择何时并行运行流程（例如在不同平台上进行测试）以及何时要求成功完成后才能进入下一阶段。 无论您在哪里工作，可配置的通知都能为您提供所需信息，帮助您避免不必要的干扰。 最后，详细的结果有助于确保生产路径保持畅通。