前言

本文为《用开源软件打造企业级 DevOps 工作流》系列的第三篇文章。接着上一篇版本控制系统篇，本篇文章主要讲介绍 DevOps 工作流中另一个核心模块 持续集成（CI），这可以说是 DevOps 中的重中之重，因为这涉及到自动化管理项目的部署过程。有了持续集成，我们就可以从手动部署中解脱出来，把时间用在更重要的事情上，例如代码重构、回归测试、架构设计等等。

在本篇文章中，我们将介绍持续集成的基本概念，为什么用持续集成，以及如何利用开源软件 Jenkins 来实现持续集成。

持续集成简介

本系列文章的第一篇概述中我们提到，持续集成可以类比于工厂中的流水线操作。例如生产一辆汽车，一切从裸车架开始，车架用吊钩送上传送带，经过装配、打磨、测试等一系列复杂而紧凑的统一化流程，最终产出一辆功能齐全、质量卓越的完整汽车。

持续集成类似软件开发中的流水线，只是持续集成中的流水线通常来说是自动化的，也就是说不需要任何人为干预，一个软件程序就可以从源码开始，经过一系列的构建步骤，最终形成成熟的产品。什么时候启动这个流水线呢？一般来说，是代码变更的时候。其实，这里所说的流水线还包括了部署的过程，一般说持续集成通常会提到 持续部署（CD）。严格意义上来说这是两个概念：持续集成（CI）是指不断将代码不断同步到主干，持续部署是指代码经过评审后自动部署到生产环境。为了方便起见，我们将这两个概念合二为一，统称为 CI/CD 。

例如上图这个持续集成流水线，当持续集成工具检测到源代码有变更的时候，会启动这个流水线：

1. 首先获取源代码；
2. 并行构建前后端应用；
3. 构建 Docker 镜像；
4. 单元测试；
5. 完成部署。

经历了这几个步骤之后，一次集成过程就算完成了。整个流程不需要人为干预，唯一需要开发者做的，就是提交一次代码更新代码仓库，持续集成工具会自动将后面的事情（包括部署）一步步帮你做完，全程自动化。

为什么用 CI/CD

其实我们可以不用 CI/CD 来完成从编码到部署的过程。那么，为什么我们要用 CI/CD 呢？首先我们看看下面一个流程图。

这是一个从码代码到最终部署交付的流程例子：我们花数小时码代码（Coding），不到 1 分钟提交代码（Commit），然后构建（Build）这个应用花 1 分钟到 1 小时（根据应用复杂程度），接着花数分钟部署（Deploy）这个应用，最后测试（Test）。除开代码和提交的时间，后面的构建+部署时间最少也得花几分钟，而测试可能会花更久。

我们要知道的是，构建和部署一般来说是重复性的工作，例如运行一次 npm run build:prod 打包前端代码，或者将打包好后的前端静态文件拷贝到目标地址。如果是人来操作这些流程，非常浪费时间和精力。虽然构建部署一次可能花不了多少时间，但考虑到企业中通常是多人协同工作，每个人都会提交代码，而且很可能是多次提交，这样需要执行的次数就是远不止一次或几次了。你简单做一做乘法，就知道会有多少人工时间成本会花费在上面，而人工成本目前来说是越来越贵的。因此，使用持续集成将降低时间成本（Time Expense）。

另外，人工来处理构建部署等流程容易出错。人无完人，即使是富有经验的架构师上线部署也可能会出现操作失误导致系统上线失败。在作者的职业生涯中，发现有很多因为人的原因部署失败的情况，例如忘记更改环境变量、数据库连接串配置错误、执行命令输入错误等等。而这些都可以通过自动化的流程来避免，因为机器是很死板的，一旦设置好，就会原封不动的按规定执行，不会出现操作失误（当然排除诸如网络原因等导致的错误）。因此，使用持续集成还可以降低人为错误（Human Error）。

上面这个流程图中红色部分（编码和提交）是无法自动化的，需要人工操作；而绿色部分（构建和部署）是可以自动化的，也是需要尽可能全部自动化的；黄色部分（测试）是半人工半自动化的，因为我们可以通过 单元测试（Unit Test） 来自动化很多测试工作，但一些复杂的测试用例（例如页面的排版是否符合设计预期）则需要人工来完成，因此测试部分是半自动化的。这里多提一下单元测试，固然单元测试是非常有助于提升代码的工程质量，但是编写单元测试却相当耗费时间，差不多跟写功能的时间差不多，因此会将整个项目时间加倍，所以需要在时间与质量之间权衡是否需要采用单元测试。

开源工具 Jenkins

要实现 CI/CD，我们需要一些工具。我们推荐的工具是 Jenkins，这也是企业环境中用的比较多的持续集成开源软件。下面我们将详细介绍一下 Jenkins，包括基本介绍、安装、基本使用以及如何实践应用到 DevOps 工作流中。

Jenkins 简介

可能你对 Jenkins 本身并不陌生，这是因为 Jenkins 从 2011 年开始就已经存在，是最早的也是最常用的选择。它出自 Sun 公司的一个工程师的业余项目，不断改进优化后逐渐壮大成为最热门的持续集成工具（听起来是不是跟 JavaScript 的经历差不多？）。

关于 Jenkins 的介绍，我们主要引用其官网上的描述。以下是官方的关于 Jenkins 的一句话描述：

Jenkins是开源CI&CD软件领导者， 提供超过1000个插件来支持构建、部署、自动化， 满足任何项目的需要。

其中，CI 指代持续集成，CD 指代持续交付。

以下是其主要特点：

• 持续集成和持续交付: 作为一个可扩展的自动化服务器，Jenkins 可以用作简单的 CI 服务器，或者变成任何项目的持续交付中心；
• 简易安装: Jenkins 是一个基于 Java 的独立程序，可以立即运行，包含 Windows、Mac OS X 和其他类 Unix 操作系统；
• 配置简单: Jenkins 可以通过其网页界面轻松设置和配置，其中包括即时错误检查和内置帮助；
• 插件: 通过更新中心中的 1000 多个插件，Jenkins 集成了持续集成和持续交付工具链中几乎所有的工具；
• 扩展: Jenkins 可以通过其插件架构进行扩展，从而为 Jenkins 可以做的事提供几乎无限的可能性；
• 分布式: Jenkins 可以轻松地在多台机器上分配工作，帮助更快速地跨多个平台推动构建、测试和部署。

从介绍总结来看，Jenkins 的核心功能是持续集成和持续交付，另外还有便捷性（安装简单）和扩展性（插件、分布式）。

安装 Jenkins

跟之前的文章里安装 GitLab 一样，我们同样是用 Docker 来安装 Jenkins。在确保您已安装 Docker 、并且能顺利运行 docker ps 的前提下，执行以下命令。

docker run 
  -u root \  # 以root用户运行
  --restar
                    

                        这篇关于用开源软件打造企业级 DevOps 工作流（三）：持续集成的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！