理解 CI 和 CD 之间的区别（翻译）

博客搬迁至https://blog.wangjiegulu.com

RSS订阅：https://blog.wangjiegulu.com/feed.xml

原文链接：https://blog.wangjiegulu.com/2018/09/10/understanding-the-difference-between-ci-and-cd/

理解 CI 和 CD 之间的区别

原文：https://thenewstack.io/understanding-the-difference-between-ci-and-cd/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

有很多关于持续集成（CI）和持续交付（CD）的资料。很多文章用技术术语来进行解释，以及它们怎么帮助你的组织。可惜的是，在一些情况下，这些方法通常与特定工具、甚至供应商相关联。在公司食堂里非常常见的谈话可能是：

1. 你在你们团队里面使用持续集成吗？
2. 当然，我们使用 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 高兴地宣布，该版本已经打包好，并运往客户。

那么，人们面对这个虚构的（又非常现实）的故事是什么感受呢？

1. Alice, Bob, 和 Charlie（开发）都不高兴，因为他们总是在发布即将发生之前了解集成问题。集成期感觉就像交火, 同一时刻出现很多问题。
2. David（测试）也不高兴，因为他的工作实在不平衡。当他在等待开发在 feature 完成它们的工作的时候是和平时期。然后在测试阶段他陷于测试工作中，需要处理意想不到的测试场景，并且每个人都站在他的肩旁上看他。
3. Elizabeth（管理人员）也不高兴。集成阶段是项目的关键路径。这是一个紧张的时期, 任何意想不到的问题,都会阻碍推动产品的进一步交付。Elizabeth 一直梦想软件发布没有任何意外情况, 但这在现实中从来不会发生。项目时间线中的集成阶段总变成一个猜谜游戏。

团队的每个人都不高兴（顺便一提，如果你的公司仍然在这样开发软件，请尝试了解这种开发工作流对团队的士气造成的损害）。

这里的主要问题是单一的“集成”阶段发生在每个产品发布。这是工作流的难点，它阻碍了团队进行无压力发布过程。

在集成中增加“持续”

现在我们已经知道了什么是“集成”，很容易理解“持续集成”的需要之处。俗话说，“如果某事是痛苦的，那就多做它”。持续集成实质上是通过高频率的重复集成步骤减轻它的痛苦。最显而易见的方法就是在每次 feature 合并后进行集成（而不是在宣布正式 release 之前等待）。

当一个团队实践持续集成...

1. 所有 feature 分支都直接合并到主分支（主线）中。
2. 开发人员不是孤立工作的。所有 feature 都是从主线开始开发的。
3. 如果主线是健康的，而不是在它单独的工作站上工作，则一项 feature 被视为已完成。
4. 测试在 feature 级别和主线级别都会被触发。

这些是持续集成的要点！当然，还有更多的细节（实际上关于这个主题有一本完整的书籍）。但是重要的一点是，所有合并和测试并不是在一个单一的有压力的集成时刻，集成一直在连续的时刻发生。

持续集成是开发软件的一种更好的方法（相比于“简单”集成），因为它：

1. 减少在合并 feature 时出现的意外次数。
2. 解决“在我的机子上没问题”的问题
3. 将测试周期切片到每个 feature 逐渐合并到主线中的阶段（而不是一次性的）。

其结果就是，一个使用 CI 的团队不是生活在过山车上 (在开发时期很平静，伴随着的是有压力的 release)，而是可以在如何接近完成项目的渐进方式中得到更好的可见性。

利用 CI 工作是现代软件开发的支柱之一。这一点上，该技术被非常好的记录和知晓。如果现在你们的软件项目中还没有实践 CI，你的组织没有任何借口不去实践它。

软件交付的黑暗时代

现在我们知道了 “集成” 的历史，以及持续集成的工作原理，我们可以将它带到一个下一级，持续交付。

如果我们回到原来的故事，我们可以看到类似模式的发布方式正在发生：

执行 Release 发布实质上是一个“大爆炸”事件。在软件被认为已经测试过，有人会负责包装和部署的过程。部署软件到生产也是一个非常有压力的阶段，传统来说会涉及到很多手动的步骤（和 checklists）。部署可能是很少次的（有的公司每六个月才会部署一次）。在极端情况下，部署可能只发生一次（瀑布流设计方法）。

只有到 deadline 时才交付软件，这会出现与不频繁集成一样的挑战：

1. 通常发现生产环境与需要在最后一刻进行额外配置的测试环境不同。
2. 在测试环境中工作正常的功能在生产中被发现问题。
3. 在发布时还没有准备就绪的功能，或者根本就不会交付给客户，或者他们进一步推迟发布日期。
4. 发布导致开发人员（想要发布新功能）和运营（想要稳定，不想一次部署太多的新功能）之间的关系变得紧张。

你应该能理解这里的模式。如果我们通过更频繁地来缓解“集成”阶段的痛苦，我们也可以为“交付”阶段做同样的事情。

在交付中增加“持续”

持续交付是尽可能频繁地组装和准备软件（就像它会被发布到生产那样）的实践。最极端的交付方式是在每个 feature 合并之后。

因此，CD，让 CI 走得更远一步。在每个 feature 合并到主线中，软件不仅要测试正确性，而且也要包装和部署到测试环境（比较理想地符合生产环境）。所有这一切都是以完全自动化的方式。注意，上图中缺少的草图 (表示手动步骤)。

还要注意，每个 feature 都是推送到生产的潜在候选者。不是所有候选人都会被发送到生产。根据组织，部署到生产的决定需要人工干预，人类只决定一个 release 是否应该发送到生产（但不会准备这个 release 本身）。这个 release 在测试环境已经被打包，测试和部署。

持续交付比持续集成更难采用。其原因是因为每个发布候选者都有可能达到生产，因此需要自动化整个生命周期：

1. 构建应该是可重复性和确定性的。
2. 所有 release 步骤应该都是自动化的（它比听起来更难）。
3. 所有的配置和关联的文件都应该存在于代码控制中 (而不仅仅是源代码)。
4. 每个 feature / release 都应该在它的测试环境中被测试过（以动态方式创建和销毁的理想方法）。
5. 所有测试套件都应自动化且相对快速（它也是比听起来更难）。

虽然云当然可以帮助满足所有这些要求，但在软件团队 (开发人员和运营部门) 中需要一定程度的纪律，以便真正拥抱持续交付。

一旦 CD 落地，发布会变得微不足道，因为它们可以按个按钮就能执行。每个人（不仅仅是项目经理）都具有 release candidate （译者：release 候选版本，以下对此术语不做翻译）的可见性。当前的 release candidate 可能没有所有请求的功能，或者说它可能无法满足所有的要求，但是这对于发布过程来说并不重要。重要的其实是这个 release 是完整测试和打包的，准备就绪发送到生产（如果需要）。任何项目的相关人员可以给出绿灯并立即把 release 部署到生产。

如果你使用 CD，则软件的生命周期可以概括成如下：

每个 release candidate 都是预先预备好的。一个人决定是否一个 release candidate 版本是否推送到生产。没有推送到生产的 Release Candidate 仍然会作为一个 artifact 储存起来，如果将来有需要可以进行召回。

就像持续集成一样，如果你想知道更多的细节，这里有整本围绕持续交付的书籍。

额外奖励：持续部署

CD 中的 “D” 也可以表示部署（Deployment）。这种开发方法建立在持续交付上, 基本上完全消除了所有人类干预。任何被发现准备就绪的 release candidate （并且通过所有质量测试）都会立即推送到生产。

不可否认的是，只有极少数的公司可以这样做。没有人类干预直接推送到生产应该不能掉以轻心。在撰写这篇文章时，许多公司甚至都没有实践持续交付，更别说部署了。现在应该清楚的是，每种开发方法都需要建立在之前那些基础之上。

在向上移动之前（译者：按上图向上移动），你的组织应该确保每个基础都是真正稳固的。在 Codefresh，我们已经看到了很多公司试图进入云时代，在他们没有真正的理解 CI/CD 管道时试图硬塞进现有的做法（为数据中心进行优化），并且其中一些做法现在已经过时。尝试采用持续部署而不完全拥抱持续交付是一场失败的战役。

另一种方法是查看这些方法涵盖的内容以及 CD 需要 CI 的方式,，如下图所示：

请确保以正确的顺序处理每个开发模式。针对持续交付是一个更现实的目标，可选的工具也很丰富。