持续集成、持续交付和持续部署 的真正区别(2)

保持 CI 的构建时间短，这是一个折衷方案。在 CI 范围内运行时间更长或几乎没有价值的测试应移至 CD 步骤。是的，那里的故障也需要修复。但是，由于它们不会阻止任何人做他们的事情，因此你可以在完成工作后将这些修补程序作为“下一项任务”。只需在工作时关闭通知并不时检查即可。保持上下文切换到最小。
持续交付和部署是工程问题
让我们来解决一下定义，以解决这个问题。

持续交付是指能够随时部署任何版本的代码。实际上，它是指代码的最新版本。你不会自动部署，通常是因为你不必或不受项目生命周期的限制。但是只要有人愿意，就可以在最短的时间内完成部署。有人可以成为想要在暂存或预生产环境中进行测试的 test/QA 团队。或者实际上可能是时候将代码推向生产了。

持续交付的思想是准备与你要在环境中运行的制品尽可能接近。如果使用 Java，则可以是 jar 或 war 文件，如果使用 .NET，则可以是可执行文件。它们也可以是已转译 JS 代码的文件夹，甚至是 Docker 容器，或者其他使部署变得更短（即，你已尽可能预先构建）。

通过准备制品，我不是要把代码变成制品。这通常是一些脚本和执行时间。准备意味着：

运行所有测试，以确保代码一旦部署便可以正常工作。如果可以自动执行单元测试，集成测试，端到端测试，甚至性能测试。

这样，你可以过滤主分支的哪些版本实际上已准备好生产，哪些尚未准备就绪。理想的测试套件：
确保应用程序关键功能正常工作。理想情况下，所有功能正常
确保没有引入性能破坏因素，因此当您的新版本受到众多用户的欢迎时，它就有机会发生
空运行您的代码需要的任何数据库更新，以免出现意外

它不需要非常快。30分钟或1小时是可以接受的。

持续部署是下一步。你将代码的最新版本和生产就绪版本部署到某些环境。如果你足够信任 CD 测试套件，则是理想的生产方式。

请注意，根据上下文，这并非总是可能或值得付出。持续交付通常足以提高生产力。特别是如果你在封闭的网络中工作并且环境有限，则可以部署到该环境。也可能是软件的发布周期阻止了计划外的部署。

持续交付和持续部署（从现在起将其称为 CD）不是团队问题。他们的目的是在执行时间，维护工作和测试套件的相关性之间找到适当的平衡，以便能够说“此版本应能正常工作”。这是一个平衡。如果你的测试持续 30 个小时，那就有问题了。有关 Oracle 数据库测试套件的例子，请参见这篇史诗般的帖子。如果你花费大量时间使测试与最新代码保持最新，从而阻碍了团队的进步，那也不是一件好事。而且，如果你的测试套件几乎没有任何保证……那基本上是没有用的。

在理想的世界中，我们每次向主分支提交都需要 1 组可部署的制品。你可以看到我们有一个垂直的可扩展性问题：我们从代码转移到制品的速度越快，我们就越准备好部署最新版本的代码。
最大的不同是什么？
持续集成是一个水平可伸缩性问题。你希望开发人员经常合并其代码，因此检查必须快速。理想情况下，几分钟之内就可以避免开发人员始终通过 CI 版本的高度异步反馈来切换上下文。

你拥有的开发人员越多，则在所有活动分支上运行简单检查（构建和测试）所需的计算能力就越高。

良好的 CI 构建：
确保没有将破坏基本内容并阻止其他团队成员工作的代码引入主分支 足够快，可以在几分钟内向开发人员提供反馈，以防止任务之间进行上下文切换
持续交付和部署是垂直可伸缩性问题。你需要执行一个相当复杂的操作。

良好的 CD 构建：
确保尽可能多的功能正常运行
速度越快越好，但这不是速度问题。30 至 60 分钟的构建就可以了

一个常见的误解是将 CD 视为诸如 CI 之类的水平可扩展性问题：从代码移至制品的速度越快，实际处理的提交越多，并且越接近理想的情况。但是我们不需要。尽可能快地为每次提交生产制品通常是过度的。你可以尽最大的努力很好地使用 CD：拥有一个 CD 构建，它将在给定构建完成后立即选择最新提交进行验证。

毫无疑问 CD 真的很难。获得足够的测试信心才能说你的软件已准备好自动部署，通常可以在诸如 API 或简单 UI 之类的底层应用程序上使用。在复杂的 UI 或大型整体系统上很难实现。

原文转自：https://fire.ci/blog/the-difference-between-ci-and-cd/