持续集成、交付与部署
了解这些持续实践之间的区别
Sten Pittet
特约作家
CI 和 CD 是现代开发实践和 DevOps 中经常使用的两个缩略词。CI 代表持续集成，这是一种基本的 DevOps 最佳实践，在这种情况下，开发人员经常将代码变更合并到一个中央存储库中，在此存储库中运行自动构建和测试。但是 CD 可以表示持续交付或持续部署。
持续集成、持续交付和持续部署 (CI/CD) 有什么区别？
持续集成
实践持续集成的开发人员尽可能经常将其变更合并回主分支。开发人员的变更通过创建版本并针对该版本运行自动测试来验证。这样做可以避免在等待发布日将变更合并到发布分支时可能发生的集成难题。
持续集成非常重视测试自动化，以检查每当将新的提交集成到主分支中时，应用是否中断。
持续交付
持续交付是持续集成的延伸，因为它会在构建暂存后自动将所有代码变更部署到测试和/或生产环境中。
这意味着，除了自动测试外，您还有一个自动发布流程，您可以随时通过单击按钮来部署应用。
理论上，通过持续交付，您可以决定每天、每周、每两周或任何适合您业务需求的版本发布。但是，如果您确实想获得持续交付的好处，则应尽早部署到生产环境中，以确保小批量发布在出现问题时能够轻松进行故障排除。
查看解决方案
使用 Open DevOps 构建和操作软件
相关资料
什么是 DevOps 管道？
持续部署
持续部署比持续交付更进一步。通过这种实践，通过生产管道所有阶段的每项变更都会发布给客户。没有人为干预，只有失败的测试才会阻止将新的变更部署到生产环境中。
持续部署是加快客户反馈循环的绝佳方式，也是减轻团队压力的绝佳方式，因为已经没有“发布日”了。开发人员可以专注于构建软件，在工作完成几分钟后，他们就能看到自己的工作上线。
这些实践是如何相互关联的
简而言之，持续集成是持续交付和持续部署的一部分。持续部署就像持续交付，唯一的不同是发布是自动发生的。
每种实践有什么好处？
What are the benefits of each practice?
我们已经解释了持续集成、持续交付和持续部署之间的区别，但我们还没有介绍您采用它们的原因。实施每种做法都有明显的成本，但其好处远远超过了成本。
持续集成
您需要什么（成本）
- 您的团队将需要为每项新功能、改进或错误修复编写自动测试。
- 您需要一台持续集成服务器，它可以监控主存储库，并为推送的每一次新提交自动运行测试。
- 开发人员需要尽可能频繁地合并他们的变更，至少每天一次。
您会得到什么
- 由于自动测试可以及早捕获回归，因此投入生产的错误较少。
- 由于所有集成问题都已尽早解决，因此构建版本很容易。
- 减少上下文切换，因为开发人员在构建中断后会立即收到警报，并且可以在转移到其他任务之前着手修复。
- 测试成本大大降低了——您的 CI 服务器可以在几秒内运行数百次测试。
- 您的 QA 团队花在测试上的时间更少，可以专注于质量文化的重大改进。
持续交付
您需要什么（成本）
- 您需要在持续集成方面打下坚实的基础，并且您的测试套件需要覆盖足够的代码库。
- 部署需要自动化。触发器仍然是手动的，但是一旦开始部署，就不需要人工干预。
- 您的团队很可能需要使用功能标志，这样不完整的功能就不会影响生产中的客户。
您会得到什么
- 部署软件的复杂性已经消失，您的团队不必再花几天时间为发布做准备了。
- 您可以更频繁地发布，从而加快与客户的反馈循环。
- 小变更决策的压力要小得多，因此鼓励更快地迭代。
持续部署
您需要什么（成本）
- 您的测试文化必须处于最佳状态，测试套件的质量将决定版本的质量。
- 您的文档流程需要跟上部署的步伐。
- 功能标志成为发布重大变更流程的固有组成部分，以确保您可以与其他部门（支持、营销、公关...）进行协调。
您会得到什么
- 您可以更快地开发，因为无需暂停版本的开发。每次变更都会自动触发部署管道。
- 在部署小批量变更时，发布的风险较小，并且在出现问题时更容易修复。
- 客户会看到持续的改进，质量每天都在提高，而不是每个月、每个季度或每年。
与持续集成相关的传统成本之一是安装和维护 CI 服务器。但是，您可以通过使用 Bitbucket Pipelines 等云服务来显著降低采用这些做法的成本，该服务可以提高每个 Bitbucket 存储库的自动化程度。只需在存储库的根目录添加一个配置文件，您就可以创建一个持续的部署管道，该管道会在推送到主分支的每个新变更时执行。
从持续集成转向持续部署
如果您刚刚开始一个还没有用户的新项目，那么将每一次提交都部署到生产环境可能很容易。您甚至可以从自动化部署开始，在没有客户的情况下将内测版发布到生产环境中。然后，您可以增强测试文化，并确保在构建应用时增加代码覆盖率。当您准备好加入用户时，您将有一个很好的持续部署流程，在自动发布到生产环境之前，所有新变更都要经过测试。
但是，如果您已经向客户提供了现有应用，则应放慢脚步，从持续集成和持续交付开始。首先实现自动执行的基本单元测试——没必要专注于运行复杂的端到端测试。相反，您应该尝试尽快实现部署自动化，并进入自动完成对暂存环境的部署的阶段。这样做的原因是，如果您有自动部署，您可以将精力集中在改进测试上，而不是定期停下来协调发布。
一旦您可以开始每天发布软件，就可以考虑持续部署。但请确保组织的其他部门也准备就绪：文档、支持、营销等。这些功能需要适应新的发布节奏，重要的是不要错过可能影响客户的重大变更。
分享这篇文章
下一个主题
推荐阅读
将这些资源加入书签，以了解 DevOps 团队的类型，或获取 Atlassian 关于 DevOps 的持续更新。
DevOps 社区
阅读博客文章
