软件开发“最后一公里”-持续集成和持续部署 #

前面的文章中，我们介绍了工程化如何在开发和构建阶段为前端提效。在开发和构建之后，我们项目还要经过部署才能上线。接下来我们就一起看下在部署过程中，我们怎么使用工程化能力进行降本提效。

什么是部署 #

软件部署（英语：Software deployment）是为将一个软件系统投入使用而进行的所有活动，[1]包括硬件配置、软件的安装、环境变量设置等。在一些机器上批量安装某一程序也称为软件部署，分为指派与发布两种类型。 ——《维基百科》

“从功能开发完成直到成功部署”这一阶段被称为软件开发“最后一公里”。部署（Deploy）指的是将构建后的新版本应用或者服务安装到目标环境（开发、测试或者生成）中。发布指的是将新版本的应用或者服务最终交给用户使用。

在前端项目中，部署相对简单，一般指的是将构建好的静态资源文件放在服务器上。那么接下来我们看下在我们平时开发过程中，传统的手动部署方案和自动化部署方案的流程以及其对比。

手动部署 #

手动部署，顾名思义，就是我们手动将构建后的产物上传至目标服务器。其流程大致如下：

1. 源码构建：在项目中执行构建命令，一般为 npm run build，在发布前的构建环节，我们一般会获取生成环境的配置信息然后进行编译\构建过程（代码效验、代码压缩、自动化测试等操作），最终生成可上线的构建产物。
2. 连接服务器：使用 FTP 或者 SSH 工具连接服务器。
3. 上传资源：将构建后的产物上传至 web 目录。

手动部署的优点和缺点都是显而易见的。优点就是简单、门槛低，我们可以直接将构建产物拖动上传到服务器就完成了部署和发布的过程。但是手动部署从名字上就可以感觉到一点都不“程序员” ヾ(=･ω･=)o，人效低并且安全风险高。

自动化部署 #

为了解决手动部署人效低且风险高的问题，我们可以将部署流程自动化，自动化部署流程如下：

1. 获取代码：首先我们需要从远程仓库拉取最新的代码。在获取完代码之后我们还可以进行对代码的安全检查和单元测试的操作。
2. 安装依赖：然后需要安装项目构建时所需要的依赖包为后面构建环节做准备。
3. 构建源码：在获取完依赖之后，我们就需要对源码就行构建操作，生成构建产物。在构建完成之后，我们可以对构建后的产物进行检查，比如资源文件是不是过大等。
4. 上传资源：在源码构建完毕之后我们就可以将构建产物上传至服务器或者 CDN。
5. 通过构建完成：最后，最好有触达通知我们构建完成，本次自动化部署才算真正完成。

手动部署和自动化部署对比 #

在了解了手动部署好自动化部署之后，我们来对比下两者的优缺点。

手动部署优点 #

虽然我们不提倡手动部署，但是凡事都会有正反两面，对吧  (●ﾟωﾟ●)。手动部署的优点，在我来看就是门槛低、单一次部署来看，会更方便一些。

在我自己刚开始搭建自己网站的时候，为了更快的看到效果，就直接在自己本地开发完之后，本地执行构建，拿到构建好的静态资源之后直接丢到服务器上，在线上就可以立即看到修改的内容。当然，这样的便捷只是一时的，如果花时间将自动化部署搭建好，那么每次开发完就只需要几个命令点一点就可以完成部署任务。

单一次部署来看，手动部署会节省部署时间，因为手动部署因为是在本地操作，所以不需要再从远程仓库获取代码，并且我们在开发的时候已经安装过依赖了，也不需要重复进行依赖的安装，这使得手动部署在流程上比自动化部署要少两个环节。同时，手动部署在构建完成之后可以直观的看到构建产物，会方便调试和问题的排查。

手动部署的缺点 #

手动部署的缺点主要有以下几点：

流程规范和稳定性差 #

首先是流程规范性，手动部署全靠人工手动操作，人工操作在整个过程可能中很难保证每次的流程顺序和处理过程都一致，并且无日志追踪，出现问题不容易及时发现和复盘。

同时，本地部署依赖于开发者的本地环境，在团队开发中，不同团队成员的本地环境可能是不一样的（包括但不限于 nodeJS 版本、操作系统），不同环境的构建产物可能不同。所以手动部署会降低项目的稳定性和增加项目的风险。

可回溯性差 #

手动部署通常只会在本地保留一次最新的构建产物，那么在线上代码出问题的时候，不能方便及时的做到代码回滚。同时，手动部署缺乏部署日志，在团队之间，不能方便查看发布记录。并且在项目部署过程中遇到的问题不方便共享查看解决，比如构建失败日志、单测执行失败等。

自动化部署优点 #

自动化部署就可以解决可手动部署的缺点。自动化部署有完善的流程规范，降低手动操作出错的可能性。同时，可以保证构建和部署环境的一致性，避免不同环境产生的影响。同时自动化部署有详细的日志记录模块，出错可追踪，更好的方便后期的排查和复盘。最后，自动化部署会保留多次构建产物，方便及时回滚。

CI/CD 持续集成和持续交付 #

CI 指持续集成（Continuous Integration），CD 指持续交付（Continuous Delivery）和 持续部署（Continuous Deployment），是一种软件开发实践。意思是通过一系列自动化的脚本执行，实现开发过程中的代码的交付和部署，能够快速交付，提高团队开发的效率。

持续集成指的是频繁的将代码集成到主干环境，在保证高质量的同时，可以让产品快速迭代。持续交付是在持续集成之后，将软件的新版本交付给 QA 或者用户。在通过交付指标之后，自动部署到生产环境。

CI/CD 即可以仅指持续集成、持续交付构成的关联环节，也可以指持续集成、持续交付、持续部署构成的关联环节。在我们平时的开发中，这些概念都是表示是在代码开发完成后的自动化处理流程。

CI/CD 的具体流程如下：

1. 在代码提交之后，CI 系统会自动通过 webhook 检测到代码变更，自动触发 CI 流程。
2. 然后会进行静态代码检测，通常是进行一些快速的错误检查过程，比如语法检查，如果有错误就直接终止流程。
3. 在进行完基础的代码检查之后，会进入自动构建环节，比如要进行代码效验、代码压缩、自动化测试等操作。
4. 在构建完成之后，会进行一些回归测试、自动化测试、集成测试以及压力测试等。
5. 在完成了必要的测试工作之后，就可以将代码部署到对应的环境中，在部署到生产环境之前，应该先部署在测试环境中再次验证。在部署到生产环境应使用对应的部署策略：蓝绿部署、灰度部署等。
6. 在部署阶段，我们还要对项目的各个指标进行监控，出现异常及时做回滚操作。

几种 CI/CD 工具对比 #

现在，我们已经了解了什么是 CI/CD 以及 CI/CD 的流程，现在社区已经有了很多成熟的 CI/CD 工具供我们选择，下面我们就来对比下几种 CI/CD 工具。

Jenkins #

Jenkins 是一款诞生比较早的老牌的开源 CI/CD 工具，可以自动化执行各种任务，包括构建、测试和部署软件。可以通过配置和编写脚本自动化执行 CI/CD 流程，代替手动 CD/CD 流程，从而节省开发时间，减少错误率，并且会将每一次构建结果记录下来。

功能特点 #

• 易于安装：Jenkins 是一个独立的基于 Java 的程序，随时可以运行在 Linux、MAC OS、Windows 等不同系统。同时也提供了基于 Docker 的容器化搭建方式。
• 易于配置：所有的配置都可以在 web 界面配置。
• 收费方式：免费、开源 (づ｡◕‿‿◕｡)づ
• 强大的插件系统：目前 Jenkins 社区中有 1800+ 个插件，几乎集成了持续集成和持续交付工具链中的所有工具。
• 分布式构建：Jenkins 可以跨多台计算机一起执行任务。
• Job 配置：在 Jenkins 的 Job 配置中可以灵活定制各种复杂的构建与部署选项，例如构建远程触发、构建参数化选项、关联 Jira、执行 Windows 批处理、邮件通知等。

CircleCI #

CircleCI 是一款基于云端的 CI/CD 工具。其配置简单，复杂度低，上手简单。

CircleCI是基于云的CI/CD工具，可自动执行软件构建和交付过程。它提供快速的配置和维护，没有任何复杂性。由于它是基于云的CI/CD工具，因此消除了专用服务器的困扰，并降低了维护本地服务器的成本。此外，基于云的服务器是可扩展的，健壮的，并有助于更快地部署应用程序。

功能特点 #

• 云端服务：无需搭建和管理可直接使用。基于云的服务器是可扩展、健壮的，有助于快速的部署应用。
• 收费方式：有免费和收费两种版本，免费版本只能运行一个 Job，对使用数量和构建环境有一定限制。收费版本可运行多个 Job、对环境和性能有更好的支持。
• 缓存优化：CircleCI 的任务构建是基于容器化的，因此能够缓存依赖安装的数据，从而加速构建流程。
• 配置简单：配置简单、开箱即用。

Github Action #

Github Action 是 github 官方提供的 CI/CD 服务。那么什么是 Github Action 中的 Action 呢？在 CI/CD 中，比如抓取代码、运行测试、发布第三方服务等，这一个个操作点就是一个个的 Action。

这些 Action 操作是可以在多个项目中共享的，所以 Github 允许开发者将不同的操作也就是 action 处理为独立的脚本文件，放在 github action平台上供其他开发者共享使用。同样的，如果你需要某个需求，也可以再 github 上找到同样公共的 action 即可。这样，CI/CD 流程就变成了一个个 action 的集合。

功能特点 #

• workflow：在 github action 中，每一次 CI/CD 的过程就是一个 workflow。
• job：一个 workflow 可以包含多个 job 任务。
• step：每个 job 由多个 step 构成。
• action：每个 step 可以依次执行一个或者多个 action。
• 社区支持：github action 有着很好的社区支持，社区提供了众多的 action 可供选择。
• 收费方式：GitHub 中公开的仓库免费，对于私有仓库提供一定的免费执行时间和空间，超出部分收费。

Gitlab CI #

和 Github CI 类似，Gitlab CI 是 Gitlab 提供的 CI/CD 服务。你只需要在你项目中的根目录下加上 .gitlab-ci.yml 包含构建、测试和部署的脚本即可。GitLab 如果检测到仓库中有该文件，就会使用 Gitlab Runner 工具按照顺序运行你设置的构建、测试和部署的脚本。

总结 #

本篇文章我们主要讲了如何在部署环节中使用工程化能力来提效。首先我们介绍了什么是前端部署，然后对比了手动部署和自动化部署的优缺点。然后和构建环节相结合，介绍了什么是 CI/CD（持续集成和持续部署），对比了几种 CI/CD 工具。

部署是我们开发完之后的过程，在大部分公司中都已经有完善的自动化部署或者 CI/CD 流程，也或者会交给专业的运维同学负责。所以一些刚入门的前端可能并不是很清楚我们在代码开发完成后续的流程，但是 CI/CD 也是软件开发中重要的一环，建议大家在完成了开发任务之后，可以多进行一些思考，有条件的同学还可以多进行一些实践，扩宽我们知识的广度。