有关持续集成（CI）和持续交付（CD）的信息很多。多篇博文试图用技术术语解释这些方法的作用以及它们如何帮助您的组织。不幸的是，在某些情况下，这两种方法通常都与特定工具甚至供应商相关联。公司自助餐厅的一个非常常见的对话可能是：
- 您是否在团队中使用持续集成？
- 是的，当然，我们使用X工具
让我告诉你一个小秘密。持续集成和交付都是开发方法。它们与特定工具或供应商无关。即使有工具和解决方案可以帮助你们（比如Codefresh），实际上，公司可以使用bash脚本和Perl单行来实践CI / CD（不是很实用，但肯定是可行的）。
因此，我们不会使用工具和技术术语来解释CI / CD的常见陷阱，而是使用最重要的内容来解释CI / CD：人们！
关于人的故事 – 软件集成的黑暗时代
认识爱丽丝，鲍勃，查理，大卫和伊丽莎白。它们都适用于SoftwareCo Inc.构建SuperBigProject应用程序。Alice，Bob和Charlie是开发人员。大卫是一名测试工程师。伊丽莎白是该团队的项目经理。
开发应用程序的传统方法如下：
Alice，Bob和Charlie都在他们的工作站上处理三种不同的功能。每个开发人员以单独的方式编写和测试代码。他们使用长期运行的功能分支，在合并到生产环境之前存在数周甚至数月。
在某个时间点，伊丽莎白（PM）收集了整个团队，并宣布：“人们，我们需要创建一个版本。请实现它！“
此时，Alice，Bob和Charlie正在争先恐后地将所有三个功能集成到同一个分支中。这是一个非常紧张的时间，因为这些功能以前从未一起测试过。由于错误的假设或环境问题，许多错误和问题突然出现（请记住，到目前为止，所有功能都只是在每个工作站上进行测试，彼此隔离）。
一旦这个高压力期结束，合并后的结果将传递给David，后者将执行额外的手动和自动测试。这段时间也很耗时，因为他可以批准或阻止发布，具体取决于发现了多少关键错误。所有的目光都落在大卫的身上，因为他的测试可以揭示可能会延迟释放的严重问题。
最后，测试结束了，伊丽莎白高兴地宣布该版本已准备好打包并运送给客户。
那么人们如何在这个虚构（但非常现实）的故事中感受到这种感觉？
- Alice，Bob和Charlie（开发）不满意，因为他们总是在即将发布的版本之前了解集成问题。整合期间感觉就像是同时出现多个问题的消防。
- 大卫（测试）不高兴，因为他的工作确实是不平衡的。在等待开发人员完成功能工作的平静时期。然后是测试阶段，当他被工作淹没，必须处理意外的测试场景，每个人都在看他的肩膀。
- 伊丽莎白（管理层）也不高兴。整合阶段是项目的关键路径。这是一个紧张的时期，因为任何意外的问题都会推迟产品的交付。伊丽莎白一直梦想着软件发布没有任何意外，但实际上这种情况从未发生过。估计项目时间表中的整合阶段始终是一个猜谜游戏。
团队中的每个人都不高兴。（顺便说一句，如果您的公司仍在开发这样的软件，请尝试了解此开发工作流程会损害您团队的士气。）
这里的主要问题是每个产品发布时发生的单一 “集成”阶段。这是工作流程的痛点，它可以防止团队发布无压力版本。
将“连续”添加到集成
现在我们已经看到了“集成”的含义，很容易理解“持续集成”的含义。正如谚语所说，“ 如果事情是痛苦的，那就更经常地做。”持续整合本质上是以高频率重复整合步骤以减轻其痛苦。经常这样做的最明显的方法是在每个功能合并之后进行集成（而不是在宣布正式发布之前等待）。
当团队实施持续集成时……
- 所有功能都直接合并到主分支（主线）。
- 开发人员并非孤立地工作。所有功能都是从主线开发的。
- 如果主线是健康的，则认为功能已完成，而如果主线在其自身的单独工作站上工作则不会。
- 测试在功能级别和主线级别自动进行。
这就是持续集成的要点！当然，还有更多的细节（实际上有关于这个主题的整本书）但主要的一点是，不是只有一个紧张的集成期，一切都在同时合并和测试，“整合”一直在发生以连续的方式。
持续集成是开发软件的更好方法（与“普通”集成相比），因为它：
- 减少合并功能时出现的意外数量。
- 解决“我机器上的工作”问题。
- 将测试时段切换为多个时段，其中每个要素逐渐合并到主线中（而不是一次性合并）。
结果是，使用CI工作的团队不是通过过山车生活（平静的开发时期，然后是压力释放），而是通过逐步的方式更好地了解项目的完成程度。
使用CI进行工作是现代软件开发的支柱之一。该技术已被很好地记录并且在此时已知。如果您今天没有在您的软件项目中练习CI，那么您的组织没有任何借口。
软件交付的黑暗时代
现在我们已经看到了“集成”的历史以及持续集成的工作原理，我们可以通过持续交付将其提升到新的水平。
如果我们回到原始故事，我们可以看到与发布方式类似的模式：
执行发布本质上是一个“大爆炸”事件。在认为软件被测试之后，有人负责打包和部署过程。将软件部署到生产也是一个非常紧张的时期，传统上涉及许多手动步骤（和检查表）。部署很少发生（有些公司每六个月部署到今天一次）。在极端情况下，部署发生在ONCE（瀑布式设计方法）。
仅在最终截止日期到来时提供软件会带来与不频繁集成相同的挑战：
- 通常发现生产环境与最后一分钟需要额外配置的测试环境不同。
- 在测试环境中正常工作的功能在生产中被破坏。
- 在发布时尚未准备好的功能根本不会提供给客户，或者他们甚至会进一步推迟发布日期。
- 发布会在开发人员（想要发布新功能）和操作（他们想要稳定性并且不希望一次部署太多新功能）之间产生紧张关系。
你应该能够在这里看到模式。如果我们通过更频繁地减轻“整合”阶段的痛苦，我们也可以为“交付”阶段做同样的事情。
将“连续”添加到交货
持续交付是指尽可能频繁地打包和准备软件（就像它被发送到生产中一样）的做法。最极端的交付方式是在每个功能合并之后。
因此，CD使CI更进了一步。将每个功能合并到主线分支后，不仅会对应用程序进行正确性测试，还会将其打包并部署到测试环境中（理想情况下与生产相匹配）。所有这些都以完全自动化的方式发生。请注意上图中缺少粘贴图（表示手动步骤）。
另请注意，每个新功能都是推动生产的潜在候选者。并非所有候选人实际上都被发送到生产。根据组织的不同，部署到生产的决策需要人为干预。人类只决定释放是否正在生产（但不准备释放本身）。该版本已在测试环境中打包，测试和部署。
持续交付比持续集成更难采用。这样做的原因是，由于每个候选版本都可能达到生产，因此整个生命周期需要自动化：
- 构建应该是可重复的和确定的。
- 所有发布步骤都应该是自动化的（这比听起来更难）。
- 所有配置和相关文件都应存在于源代码管理中（不仅仅是源代码）。
- 应在其自己的测试环境中测试每个功能/发行版（理想情况下以动态方式创建和销毁）。
- 所有测试套件都应该是自动化的并且相对较快（也比听起来更难）。
虽然云无疑可以满足所有这些要求，但软件团队（开发人员和运营人员）需要一定程度的纪律才能真正实现持续交付。
一旦CD到位，释放变得微不足道，因为只需按一下按钮即可执行。每个人（不仅仅是项目经理）都能看到当前的候选版本。当前版本候选版本可能没有所有请求的功能，或者它可能尚未满足所有要求，但就发布过程而言，这并不重要。重要的是，该版本经过全面测试和打包，随时可以发送到生产（如果需要）。任何项目利益相关者都应该能够开绿灯，并立即将产品发布到生产中。
如果您使用的是CD，则软件生命周期可以总结如下：
每个候选发布者总是提前准备好。人类决定是否也会将候选版本推向生产阶段。如果需要在将来召回，那么未达到生产的候选版本仍会存储为工件。
与持续集成一样，如果您想了解所有细节，还有一本关于持续交付的书籍。
奖金：持续部署
CD中的“D”也可以表示部署。这种开发方法建立在持续交付的基础之上，基本上完全消除了所 任何被发现准备好（并通过所有质量和测试门）的候选版本都会立即投入生产。
不可否认，只有极少数公司能够像这样工作。在没有人的情况下直接投入生产不应该掉以轻心，在撰写本文时，许多公司甚至都没有实施持续交付，更不用说部署了。现在应该清楚的是，每种开发方法都需要先前的基础。
在升级之前，您的组织应确保每个基础都非常扎实。在Codefresh，我们看到许多公司试图通过试图在他们的CI / CD管道中窃取他们现有的做法（针对数据中心进行优化）而试图进入云时代，却没有真正理解其中一些做法现在已经过时了。尝试采用持续部署而不首先完全接受持续交付是一场失败的战斗。
查看这些方法涵盖的内容以及CD如何要求CI的另一种方法是下图：
确保以正确的顺序处理每个开发范例。定位持续交付是一个更加现实的目标，也是工具选择丰富的目标
https://thenewstack.io/understanding-the-difference-between-ci-and-cd/