【云原生】什么是 CI/CD ? | 摆平交付障碍的 CI/CD

【云原生】什么是 CI/CD ？| 软件交付中常见的问题

在前文中，我们了解到了软件交付过程中的一些常见做法，以及它们所导致的一系列问题。这些问题成为了软件交付的一个又一个绊脚石，如何解决这些棘手的问题，CI/CD 给出了令人满意的答案，帮我们摆平了路上一个又一个的障碍。

摆平交付障碍的 CI/CD

那么 CI/CD 究竟是什么呢？

什么是 CI/CD

简单来说，CI/CD 的核心思想就是部署一条自动化流水线，具体就是指实现应用程序从构建、部署、测试到发布这整个过程的自动化。将高度自动化的测试和部署以及全面的配置管理结合在一起，实现一键式软件发布。也就是说，我们只需要点击一下鼠标，就可将软件部署到任何目标环境，包括开发环境、测试环境或生产环境。

由于每个组织软件交付的流程细节有可能不同，所以在具体实践流水线时也将会是不同的，不过背后的原则始终相同。下面举一个简单的部署流水线的例子，来说明它的大致工作方式。

一个简单的流水线实例

首先，这条流水线的工作特点就是，每次变更都会自动触发创建一个新的流水线实例，比如说应用程序配置的变更、源代码、环境或数据的变更。

流水线中的首要步骤之一就是创建二进制文件和安装包，而其余部分都是基于第一步的产物所做的一系列测试，用于证明其达到了发布质量。每通过一步测试，我都会更加相信这些二进制文件、配置信息、环境和数据所构成的特殊组合可以正常工作。如果这个产品通过了所有的测试环节，那么它就可以发布了。

那么在了解完 CI/CD 的基本思路后，针对前文（什么是 CI/CD ？| 软件交付中常见的问题）中所列举的一些常见问题，CI/CD 又是如何解决的呢？

常见问题的解决

1. 手工部署软件

手工部署软件所带来的常见问题就是很容易发生人为错误。为了规避这个问题，合理且必要的做法就是实现部署的自动化，即 CI/CD。为什么说 CI/CD 是必要的，这是因为不实现 CI/CD必然会导致下列的一系列的问题：

• 如果部署过程没有完全自动化，那么每次部署时都很难不会发生错误，即便使用良好的部署测试，有些错误也很难追查，从而每次部署的问题只是“错误的严重与否”而已。
• 如果部署过程没有实现自动化，那么它就既不可重复也不可靠，从而使我们在调试部署错误的过程中浪费很多时间。
• 如果部署过程没有实现自动化，那么部署流程不得不被写在文档里，这里便会产生文档维护的问题。文档维护是一项复杂而费时的任务，它涉及多人之间的协作，因此文档通常要么是不完整的，要么就是未及时更新的，从而往往无法顺利进行部署工作。而把一套自动化部署脚本作为文档，它就永远是最新且完整的。
• 如果部署过程没有实现自动化，那么文档通常只是为执行部署者写的备忘录，是难以被他人理解的。而自动化自动部署本质上是鼓励协作的，所有内容都在一个脚本里，一览无遗。
• 如果部署过程没有实现自动化，手工部署过程往往会依赖于部署专家。一旦部署人员休假或离职，就会带来很大麻烦。
• 如果部署过程没有实现自动化，那么发挥不了更多运维部署专家们的专业价值。尽管手工部署枯燥且极具重复性，但仍需要有相当程度的专业知识。若要求专家做这些无聊、重复，但有技术要求的任务则必定会出现各种人为失误。然而自动化部署可以把那些成本高昂的资深高技术人员从过度工作中解放出来，让他们投身于更高价值的工作活动当中。
• 如果部署过程没有实现自动化，对部署过程进行测试的唯一方法就是原封不动地做一次（或者几次），这往往费时，还会造成高昂的金钱成本，而测试自动化的部署过程却是既便宜又容易。
• 如果部署过程没有实现自动化，手工部署的脚本更难审核，因为对于一个手工过程来说，没人能确保其执行者会非常严格地遵循文档完成操作，而自动化的部署则是完全可审核的。
• 如果部署过程没有实现自动化，那么我们无法保证实际部署时的成功率。而如果实现了自动化部署，使用相同的脚本将软件部署到各类环境中，那么在发布当天需要向生产环境进行部署时，这个脚本已经被验证过成百上千次了。如果发布时出现任何问题的话，我们可以百分百地确定是环境的具体配置问题，而不是部署脚本的问题。

2. 开发完成之后才向类生产环境部署

开发完成之后才向类生产环境部署，这种做法往往会引发一系列的问题，比如直到应用程序部署到了试运行环境才发现新的缺陷，才发现系统设计中存在对生产环境的错误假设，再比如开发团队和真正执行部署任务的人员缺乏协作。

针对这些问题，CI/CD 的对策就是将测试、部署和发布活动也纳入到开发过程中，让它们成为开发流程正常的一部分。这样的话，当准备好进行系统发布时就几乎很少或不会有风险了，因为我们已经在很多种环境，甚至类生产环境中重复过很多次，也就相当于测试过很多次了。而且做到这点强调各个团队要紧密协作，每个人都需要成为这个软件交付过程的一份子，无论是构建发布团队、还是开发测试人员，都需要从项目开始就一起共事。

3. 生产环境的手工配置管理

手工管理配置的问题同样在于极易出错，太多的配置细节可能出错，我们无法完全掌握生产环境的任何配置信息，不能重复地创建开发的应用程序所依赖的每个基础设施。而与之相反的，我们希望有以下这些能力：

• 我们应该有记录或测试变更的能力。几乎在每次发布的最后都会有一些变更，比如修改数据库的登录账户或者更新所用外部服务的URL。我们应该使用某种方法来引入此类变更，以便这些变更可以被记录并测试。
• 我们应该完全掌握生产环境中的任何信息的能力。生产环境中的每次变更都应该被记录下来，而且做到今后可以查阅。部署失败经常是因为某个人在上次部署时为生产环境打了补丁，但却没有将这个修改记录下来。
• 我们应该具有重建生产环境的能力。
• 我们也应该有能力在部署出错时，通过同一个自动化过程将系统回滚到之前的版本。

为了实现上述目标，CI/CD 的做法是将配置管理也纳入一个自动化的过程，对于测试环境、试运行环境和生产环境的所有方面，尤其是系统中的任何第三方元素的配置，都应该通过一个自动化的过程进行版本控制，这意味着操作系统、补丁级别、操作系统配置、应用程序所依赖的其他软件及其配置、基础设施的配置等都处于受控状态。变更首先会被提交到版本控制系统中，然后通过某个自动化过程对生产环境进行更新。

事实上，上述列举的问题只是交付过程中众多问题的一部分，我们尝试要解决的问题归根到底是要解决软件交付的问题，也就是如何高效、快速、可靠地交付高质量且有价值的软件。如果解决了这最根本的问题，那么背后的一系列问题一概就会全部解决了。在本系列的下一篇文章中，我们将会看到 CI/CD 如何具体解决这个源头问题的。

参考文献：Jez HumBle，David Farley，《持续交付——发布可靠软件的系统方法》

（部分图片来自网络，如有侵权，立即删除）