有很多关于持续集成（CI）和持续交付（CD）的资料。很多文章用技术术语来进行解释，以及它们怎么帮助你的组织。可惜的是，在一些情况下，这些方法通常与特定工具、甚至供应商相关联。在公司食堂里非常常见的谈话可能是：
- 你在你们团队里面使用持续集成吗？
- 当然，我们使用 X 工具
让我来告诉你一些秘密。持续集成和持续交付都是开发方法。它们没有链接到特定的工具或者供应商。尽管有DO（比如Codefresh）这样的工具和解决方法在这两方面帮助你，实际上，一个公司可以只使用 Bash 脚本和 Perl one-liners（不是真的使用，但是有可能的）来练习 CI / CD。
所以，我们不会陷入使用工具和技术术语来解释 CI / DI 的陷阱，我们将用最重要的东西来解释：人！
关于人的故事 — 软件集成的黑暗时代
Alice, Bob, Charlie, David, 和 Elizabeth，他们都在 SoftwareCo 公司。开发 SuperBigProject 应用。Alice, Bob, 和 Charlie 是开发者。David 是一个测试工程师。Elizabeth 是团队的项目经理。
开发应用的传统方法如下：
Alice, Bob, 和 Charlie 在它们各自的工作区，工作在3个不同的 feature。每个开发人员都以各自的方法编写和测试代码。他们使用一个长周期的 feature 分支，在它们合并进生产之前可能存在几周或者甚至几个月。
在某个时间点，Elizabeth（PM）召集整个团队，并宣布：“各位，我们需要构建一个 Release”。
此时，Alice, Bob, 和 Charlie 争先恐后地集成所有3个 feature 分支到同一个分支中。这是一个非常紧张的时刻，因为这些分支之前并没有合并一起进行测试过。由于错误的假设或者环境原因，会出现很多bug和问题（请记住，目前为止，所有 feature 仅仅在各自的工作站中进行过测试，彼此是隔离的）。
一旦这个高度紧张的时期结束了，合并的结果将传递给将执行额外的手动和自动测试的 David，此期间也很耗时, 因为他是可以根据发现的决定性 bug 的数量来批准或阻止发布的人。当他测试时, 所有的目光都落在了大卫身上, 因为他的测试可以暴露出严重的问题, 会导致 Release 的 delay。
最后，测试结束了，Elizabeth 高兴地宣布，该版本已经打包好，并运往客户。
那么，人们面对这个虚构的（又非常现实）的故事是什么感受呢？
- Alice, Bob, 和 Charlie（开发）都不高兴，因为他们总是在发布即将发生之前了解集成问题。集成期感觉就像交火, 同一时刻出现很多问题。
- David（测试）也不高兴，因为他的工作实在不平衡。当他在等待开发在 feature 完成它们的工作的时候是和平时期。然后在测试阶段他陷于测试工作中，需要处理意想不到的测试场景，并且每个人都站在他的肩旁上看他。
- Elizabeth（管理人员）也不高兴。集成阶段是项目的关键路径。这是一个紧张的时期, 任何意想不到的问题,都会阻碍推动产品的进一步交付。Elizabeth 一直梦想软件发布没有任何意外情况, 但这在现实中从来不会发生。项目时间线中的集成阶段总变成一个猜谜游戏。
团队的每个人都不高兴（顺便一提，如果你的公司仍然在这样开发软件，请尝试了解这种开发工作流对团队的士气造成的损害）。
这里的主要问题是单一的“集成”阶段发生在每个产品发布。这是工作流的难点，它阻碍了团队进行无压力发布过程。
在集成中增加“持续”
现在我们已经知道了什么是“集成”，很容易理解“持续集成”的需要之处。俗话说，“如果某事是痛苦的，那就多做它”。持续集成实质上是通过高频率的重复集成步骤减轻它的痛苦。最显而易见的方法就是在每次 feature 合并后进行集成（而不是在宣布正式 release 之前等待）。
