理解 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 的方式,，以下图所示：

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