持续集成与持续交付/部署有何关系？

以下是连续积分当前内容的引文：

...经常将开发人员的工作代码副本合并到共享代码库中的过程，以防止或最小化集成问题。

好我知道了 但是接着还有连续交付和 连续部署，这就是我不断迷失的地方：

• 假设通过您沿生产线的某个地方最终将到达目标环境，那么持续集成与持续交付和/或持续部署之间的关系如何。integrationdeliveringdeployed
• 持续交付和持续部署之间有什么区别？

过去，在将DevOps称为DevOps之前，我们使用了术语，可能有助于理解这些新的DevOps术语，例如：

• 推动到（或降级从）一些预先PROD目标，任选地与一些类型的再生过程（编译，结合等）的组合中可执行状的东西封装所有相关组件在一起。那应该类似于/接近连续集成吗？
• 使用FTP之类的工具（如果标准副本无法弥合差距）将其分发到某些目标环境，但尚未在目标中激活它。那应该类似于/接近连续交付吗？
• 在某些目标环境中安装（或激活），并结合诸如绑定，停止/启动操作等内容。这应该类似于/接近于连续部署吗？

通过向流程中添加“生产部署”步骤，持续交付和持续部署都将持续集成进一步向前迈进了一步。连续交付和部署之间的区别在于，交付步骤是手动完成的，而部署则是自动完成的。

持续集成，持续交付和持续部署之间的区别。图片从codeproject.com复制

无论是连续交付还是连续部署，在很大程度上都是实现选择。如果您进行连续部署，则通过验收测试后，将自动部署代码更改。这对于您的产品可能是不希望的。通过连续交付，人们可以选择是否部署特定的代码更改（以及可能在何处确切部署）。

由于连续交付和部署之间的差异很小，并且许多人不知道确切的差异，因此有时可以互换使用这两个术语。

连续交付和连续部署（CD）差不多是同一件事*。每次更改被认为“可行”（经过测试/验证）时，都应立即发布。完成工作后，您每天可以执行多次。

持续集成（CI）仅是指经常将代码合并在一起，以确保功能分支与主“主”分支之间的距离不会太远，而且还可以使您很快就知道代码是否存在问题。集成角度-即您在更改内容时是否破坏了任何功能。

就它们之间的相互关系而言，CI可以极大地帮助验证代码，以便可以快速发布（CD）。您仍然可以在没有CI的情况下获得CD（反之亦然），但是您会发现，这通常使早期集成代码变得更加容易，并且常常可以更快地发现问题，从而使您可以更快地解决上述问题，最后更快地提供您的功能！

*编辑：这是一篇讨论差异的文章。https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff 连续交付并不总是意味着始终在任何时候都实际部署到生产中，而是意味着不断地将其部署到类似生产的环境中，并确信一旦业务准备就绪，这些更改就可以随时投入生产。实际上，大多数人将这些术语混为一谈。

某个版本的软件产品必须先完成其集成阶段，然后才能交付或部署它。

对于连续交付/部署，必须进行持续集成。否则，如果集成完成事件相距太远而无法获得“连续”属性的资格，则可能的交付/部署也是如此（通常只有集成版本的子集才有资格交付/部署）。

更新：我的答案仅强调了CI和CD和CD两者之间的依赖性（关系），THelper的答案很好地涵盖了该术语。

我唯一需要说明的是有关（的超载）使用deployment。非生产环境中的部署是真实的。它们甚至可以经常发生，例如，在连续交付期间作为各种测试阶段的一部分来完成。但这并没有进行这样的部署continuous deployments。连续部署专门指生产环境中的部署。

基本上，持续发布是持续交付和持续部署的一部分，只是发布会自动发生。您也可以将持续交付视为持续集成的逻辑下一步，它适用于所有环境。持续集成还有助于工件验证，因此可以更快地进行部署。尽管没有持续集成就不可能进行连续部署，并且通过持续集成来捕获错误要容易得多。所有这些“连续的事情”最终都与消除开发工作流中不必要的动作有关。最重要的是，CI / CD从技术和业务角度来看都很重要。未能采用这些DevOps原则的公司可能会冒险走上恐龙的道路。在当今快速发展的IT环境中，无论是DevOps或死亡。