持续集成 vs. 持续交付 vs. 持续部署

CI 和CD是人们谈论现代开发实践时经常提到的两个缩略语。CI 代表持续集成，这种实践专注于使发布更容易。但CD 可能意味着持续交付或持续部署，虽然这两种实践有很多共同之处，但他们也有显著的差异，可能对业务产生严重的后果。

我们将在本文中看到这三种实践的含义以及使用它们需要什么条件。

持续集成，持续交付和持续部署之间有什么区别？

持续集成

实施持续集成的开发人员会尽可能多地将其更改合并到主分支。通过创建构建并针对构建运行自动化测试来验证开发人员的更改。通过这样做，您可以避免通常在人们等到发布当天将其更改合并到发布分支时发生的集成地狱。

持续集成非常强调测试自动化，以便在新的提交集成到主分支时检查应用程序是否被破坏。

持续交付

持续交付是持续集成的延伸，以确保您可以以可持续的方式快速向客户发布新的更改。这意味着除了自动化测试之外，您还可以自动执行发布过程，并且可以通过单击按钮随时部署应用程序。

从理论上讲，通过持续交付，您可以决定每天、每周、每两周或任何适合您业务需求的发布。但是，如果您真的希望获得持续交付的好处，则应尽早部署到生产中，以确保发布小的分支，在出现问题时容易进行故障排除。

持续部署

持续部署比持续交付更近一步。通过这种做法，每个通过生产管道所有阶段的更改都将发布给您的客户。没有人为干预，只有失败的测试才能阻止将新的更改部署到生产中。

持续部署是加速与客户建立反馈循环的绝佳方式，并且由于没有发布日，因此可以减轻团队压力。开发人员可以专注于构建软件，他们可以看到他们的工作在完成后几分钟就会上线。

这些实践如何相互关联？

简而言之，持续集成是持续交付和持续部署的一部分。持续部署除了自动发布外和持续交付相同。

每种实践有什么好处？

我们已经解释了持续集成，持续交付和持续部署之间的区别，但我们尚未研究您采用它们的原因。实施每项实践都有明显的成本，实际上远远超过了它们的优势。
持续集成

您需要什么成本？

 您的团队需要为每个新功能，改进或bug修复编写自动化测试。
 您需要一个持续集成服务器，它可以监视主仓库并为每个推送的新的提交自动运行测试。
 开发人员需要进可能多地合并他们的更改，至少每天一次。

您获得了什么益处？

 由于采用自动化测试，bug在回归测试中被发现，在生产环境中会有较少的bug。
 由于所有集成问题都已尽早解决，因此构建版本很容易。
 减少上下文切换，因为开发人员一旦打破构建就会收到警报，并且可以在他们转移到另一个任务之前修复它。
 测试成本大幅降低 - 您的CI服务器可以在几秒钟内完成数百次测试。
 您的QA团队花费更少的时间进行测试，并可专注于对质量文化的重大改进。

持续交付

您需要什么成本？

 您需要在持续集成方面拥有坚实的基础，并且您的测试套件需要覆盖足够的代码库。
 部署需要自动化。触发器仍然是手动的，但一旦开始部署，就不需要人为干预。
 您的团队很可能需要使用功能标记，以便不完整的功能不会影响生产环境中的客户。

您获得了什么益处？

 部署软件的复杂性已不存在，您的团队不再需要花费数天时间准备发布。
 您可以更频繁地发布，从而加快与客户的反馈循环。
 对于小变化的决策压力要小得多，因此鼓励更快地迭代。

持续部署

您需要什么成本？

 您的测试文化需要处于最佳状态。测试套件的质量将决定您的版本的质量。
 您的文档需要跟上部署的步伐。
 功能flags成为发布重大更改过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。

您获得了什么益处？

 您可以更快地开发，因为不需要为了发布而暂停开发。每次更改都会自动触发部署管道。
 在部署小批量更改时，如果出现问题，版本风险较小且更易于修复。
 客户每天都能看持续不断的改进和质量改善，而不是每个月、每季度或每年。

与持续集成相关的传统成本之一是CI服务器的安装和维护。但是，通过使用Bitbucket Pipelines 等云服务可以大大降低采用这些实践的成本，并且为每个Bitbucket 仓库增加了自动化功能。只需在仓库的根目录中添加配置文件，您就可以创建一个连续的部署管道，该管道可以执行推送到主分支的每个变更。

从持续集成到持续部署

如果您刚启动没有用户的新项目，可能很容易将每个提交部署到生产环境中。您甚至可以从自动化部署开始，并将您的alpha版本发布到没有客户的生产环境中。然后您将提升您的测试文化，并确保在构建应用程序时增加代码覆盖率。当你准备让用户上线时，您将拥有一个出色的持续部署流程，其中所有新的变更都会在自动发布到生产环境之前进行测试。

但是，如果您现有的应用已经有了客户，您应该减慢速度，并开始持续集成和持续交付。首先实现单元测试的自动化，无需专注于复杂的端到端测试。相反，您应该尽快尝试自动化部署，并进入自动完成部署到临时环境的阶段。原因是通过自动部署，您将能够集中精力改进测试，而不是定期停下来去协调一个版本的发布。

一旦您可以每天发布软件，您就可以调研持续部署了，但也要确保组织的其他部分也已准备就绪， 如文档、技术支持、市场营销等。这些部分需要适应新版本的节奏，重要的是它们不会错过影响客户的重大变更。

作者：Sten Pittet
翻译：毛哥
日期：2019年6月23日
原文：https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment