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

许多年来，一代又一代的 IT 人像西西弗斯一样，孜孜不倦地追求着一个目标——用最快的速度将质量最好的软件交付给用户。极为幸运的是，我们并没有遭遇西西弗斯式的悲剧，一次又一次在巨石就快到达山顶时前功尽弃，而是在这场看似无止境的攀爬中，到达了一个又一个令人兴奋的里程碑，取得了一个又一个卓有成效的成果，比如敏捷开发、DevOps，以及本文将要介绍的 CI/CD。

推动软件交付前行的 IT 人

敏捷开发、DevOps、CI/CD 这三块里程碑从不同的角度通力合作，将软件交付的效率与质量推到了一个新的高度。如果说敏捷开发关注加速软件交付的开发流程，DevOps 关注的是开发与运维团队紧密协作的文化，那么 CI/CD 则关注如何实现频繁交付的自动化流水线工具。

三大里程碑：敏捷、CI/CD 、DevOps

敏捷与 DevOps 的概念我们在之前的文章中都已经有所了解，那么 CI/CD 又是什么？它是如何提高我们的交付能力的呢？

简单来说 CI（Continuous Intergration ）—— 持续集成，指开发人员能够频繁将代码集成到公共代码仓库的主分支中。而 CD（Continuous Deployment）——持续部署，以持续集成过程为其理论基石，其核心是部署一条流水线，实现应用程序从构建、部署、测试到发布这整个过程的自动化，从而提高软件的交付能力。

不过在深入回答这两个问题之前，不妨先看看我们在现实中究竟有哪些不恰当的做法，从而又遇到了怎样的交付问题。

软件交付中的问题

在以往的软件交付中，风险似乎成为了永恒的主题，成为了一把悬在开发团队与运维团队头上的利剑。

悬于开发与运维团队头上的风险之剑

这里风险一方面是因为许多的软件交付需要太多的手工操作。正是因为手工操作，在这个过程中有太多步骤可能出错。假如其中有一步没有完美地执行，应用程序就无法正确地运行。一旦发生这种情况，我们很难一下子说清楚哪里出了错，或到底是哪一步出了错。

而在实际的交付过程中，还有许许多多的交付行为也带来了风险，接下来让我们来一一列举一些常见的不恰当的交付行为，具体看看它们带来了怎样的问题。

1. 手工部署软件

一种常见的交付方式就是手工部署软件。很多团队都使用手工的方式发布软件，也就是说部署应用程序所需的步骤是独立的原子性操作，由某个人或某个小组来分别执行。

但是由于现在的大多数应用程序，无论规模大小，其部署过程都比较复杂，而且包含很多非常灵活的部分。每个步骤里都有一些需要人为判断的事情，因此很容易发生人为错误。即便不是这样，这些步骤的执行顺序和时机的不同也会导致结果的差异性，而这种差异性很可能给我们带来不良后果。

具体而言，手工部署软件的做法以及遇到的问题，往往是像下面列举的这样：

有一份非常详尽的文档，该文档描述了执行步骤及每个步骤中易出错的地方。
手工测试来确认该应用程序是否运行正确。
在发布当天开发团队频繁地接到电话，客户要求解释部署为何会出错。
在发布时，常常会修正一些在发布过程中发现的问题。
如果是集群环境部署，常常发现在集群中各环境的配置都不相同，比如应用服务器的连接池设置不同或文件系统有不同的目录结构等。
发布过程需要较长的时间（超过几分钟）。
发布结果不可预测，常常不得不回滚或遇到不可预见的问题。
发布后凌晨两点还睡眼惺忪地坐在显示器前，绞尽脑汁想着怎么让刚刚部署。

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

另一种常见的交付方式就是等到代码开发完毕才部署到类生产环境（比如试运行环境），运维人员只有在产品被发布到生产环境时才第一次见到这个软件。

这样做的后果是部署工作中的很多步骤根本没有在试运行环境上测试过，所以常常遇到问题。

比如直到最后部署才发现系统设计中存在对生产环境的错误假设。例如，部署的某个应用软件是用文件系统做数据缓存的。这在开发环境中是没有什么问题的，但在集群环境中可能就不行了。解决这类问题可能要花很长时间，而且在问题解决之前，根本无法完成应用程序的部署。

再比如，直到应用程序部署到了试运行环境才发现新的缺陷，但是常常没有时间修复所有问题。

此外开发团队和真正执行部署任务的人员之间的协作非常少，而且由于部署中问题之多，开发团队与部署团队之间的协作关系也受到了挑战。

此外，当我们开发完成之后才向类生产环境部署时，下列一些事情会进一步恶化软件的交付：

假如一个应用程序是全新开发的，那么第一次将它部署到试运行环境时，可能会非常棘手。
假如发布周期越长，开发团队在部署前作出错误假设的时间就越长，修复这些问题的时间也就越长。
假如交付过程被划分到开发、运维、测试等部门的那些大型组织中，各部门之间的协作成本可能会非常高。此时为了完成某个部署任务（更糟糕的情况是，为了解决部署过程中出现的问题），开发人员、测试人员和运维人员总是高举着问题单（不断地互发电子邮件）。
假如开发环境与生产环境差异性很大，开发过程中所做的那些假设与现实之间的差距也会很大。
如果应用程序是由用户自行安装的（你可能没有太多权限来对用户的环境进行操作），或者其中的某些组件不在企业控制范围之内，此时可能需要很多额外的测试工作。

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

在配置管理方面同样也有着一个手工管理模式。很多组织通过专门的运维团队来手工管理生产环境的配置。比如说修改数据库的连接配置或者增加应用服务器线程池中的线程数时，那么运维团队会登录到生产服务器上进行手工修改。

其中的问题同样出现在手工管理，太多的配置细节可能出错，太多的修改未被记录。而我们希望完全掌握生产环境中的任何配置信息，而且能够重复地创建开发的应用程序所依赖的每个基础设施。

具体而言，手工配置管理的做法以及遇到的问题，往往是像下面列举的这样：

多次部署到试运行环境都非常成功，但当部署到生产环境时就失败。
集群中各节点的行为有所不同。例如，与其他节点相比，某个节点所承担的负载少一些，或者处理请求的时间花得多一些。
运维团队需要较长时间为每次发布准备环境。
系统无法回滚到之前部署的某个配置，这些配置包括操作系统、应用服务器、关系型数据库管理系统、Web服务器或其他基础设施设置。
不知道从什么时候起，集群中的某些服务器所用的操作系统、第三方基础设施、依赖库的版本或补丁级别就不同了。
直接改生产环境上的配置来改变系统配置。

以上便是在软件交付中常见的一些问题，存在更好的解决方法吗？CI/CD 给出了肯定的答案，那就是构建一条自动化的部署流水线，实现频繁且自动化地发布软件。本文是 CI/CD 系列的第一篇，深入了解具体 CI/CD 是什么、如何做的，请听下回分解。