持续集成和部署

前端代码写完后，如何部署到服务器上供用户访问？

简单粗暴的做法是将源代码本地打包后，再手动上传到服务器上。对于简单的业余项目来说，这没太大问题。

但在现代化的多人协作场景下，这种方式缺少标准化约束，会导致许多问题。比如本地打包如何保证依赖包的健康和一致性？手动上传构建产物效率低下，以及存在安全风险。

持续集成和部署系统的出现，就是为了将这个过程标准化和自动化。

持续集成和部署简称 CI 和 CD，我们先来说持续集成（CI）。

持续集成系统会按照预先编排好的自动化流水线（pipeline），对源代码进行处理，得到集成产物。

首先，开发者将源代码提交到版本控制系统，随后持续集成系统会创建一个虚拟容器，拉取最新代码，然后执行项目的自定义脚本（通常是安装、构建和测试脚本等等），最后生成集成产物（可以是测试报告、构建产物等）。

这是一个前端开源库 dayjs 使用 Github Actions 持续集成服务，自动运行单元测试的流水线配置。

我们可以看到，流水线会在 master 或 dev 分支代码变更后自动执行，

流水线会创建带有四个不同版本的 Node.js 的虚拟环境，来测试代码对它们的兼容情况。

随后，执行依赖包安装，lint 检查、单元测试和覆盖率脚本，然后将报告通过 codecov 组件上传，最终形成这样一份覆盖率报告。

在这样一个简单的流水线中，我们还可以做更多有价值的事情。

上期视频中我们提到，持续集成过程中容易产生供应链安全的问题，

可以通过依赖锁文件或接入安全组件来屏蔽恶意软件。

除此之外，根据业务研发流程需要，还可以对流水线中的每个阶段设置门禁检查规则。

比如拉取代码后检查基线是否最新，构建前对代码执行静态检查，构建后检查产物大小等等。

接下来我们说持续部署（CD）。

持续部署通常紧接着持续集成进行，即我们将持续集成阶段输出的构建产物，作为持续部署的输入，通过自动化流水线部署到目标环境中。

持续部署系统的重要功能之一是对发布流程的控制。

首先，它可以控制将构建产物发布到应用服务器、NPM 和 CDN 等多个目标。

其次，它可以进行灰度发布，即按照白名单或百分比，分批发布而是不一次性全部发布，来减少故障影响面。

最后，持续部署系统可以在任意时间回滚变更到上一个版本，

假设灰度发布期间观测到预期外的异常，可以快速回滚到上一个版本，实现应急止血。

持续部署系统的另一重要特性是环境隔离。

在分支代码研发的场景中，开发者在开发分支上推送的代码，会部署到开发环境（线下环境），代码经过测试后再合并到主干分支（main），随后部署到生产环境（线上环境）。

这样在保证研发效率的同时，又可以提升生产环境的稳定性。

要自己从零建设一套持续集成和部署系统是非常复杂的，而 Jenkins、Travis CI 和 Github Actions 都是不错的选择。

你可能觉得持续集成和部署是高阶玩法，我用不上，但实际上它是现代研发流程中不可缺少的一部分。

即便是个人项目，你也可以用非常低的成本接入它。

本期我们介绍了持续集成和部署系统的相关概念，功能和应用。下一期我们聊聊应用发布上线后，应该关注哪些问题。

我是小麦，我们下期再见。