不会持续集成和持续部署？今天带你玩转CI/CD

一、CI/CD基础

玩转CI/CD，首先简单说一下概念吧，给新同学扫个盲，其实CI/CD 可以分成三部分：

谁才是世界上最好的 CI/CD 工具？TeamCity、Jenkins、Travis CI、AppVeyor 或是 Azure Pipelines ？我的答案是“和开发流程不割裂的工具才是最好的工具”，在我们公司内部常用的代码托管平台是 Gitlab，同时其也向用户提供了 CI/CD 的集成工具，这样的话就为我们去定制一些前端的 CI/CD 流程提供了更多的想象空间。

先来说下我们团队目前正在使用的 CI/CD 是什么样的，贴张总体设计图，以表诚意：

如图所示，我们将一部分自定义流程，整合进我们现有的 Gitlib 的生命周期中，通过 PR 的行为来触发 CI/CD 的流程，将这些人工环节转变为自动化地执行，实现了一套闭环的流程。

二、CI/CD 流程的核心能力

1. webhook

借助代码托管平台 Gitlab 的 webhook 推送功能，使后端服务器有能力拦截 Gitlab 触发的各种事件，这样我们的服务端就可以感知到 Gitlab 中的变化，当用户 push 代码时，Gitlab 会通过 http 请求向服务端发送相关详情。

2. API

Gitlab 将自身的功能以 REST API 的形式，提供给第三方开发者调用。如图所示，我们可以通过 api 查询或者操作相关内容，例如：“修改文件”、“创建仓库”、“编辑留言板”、“查询群组成员”等操作，因此，这为我们实现更多的个性化服务提供了可能。

3. pipeline

Gitlab 本身集成了 CI/CD 的能力，当我们 push 代码或者发起一个 PR 时，Gitlab 首先会扫描仓库根目录是否存在 .gitlab-ci.yml 文件，并对其进行语法分析，将文件中用户自定义的 shell 脚本提取出来，并发送到 gitlab-runner 服务器进行执行，之后将执行的状态反馈到 Gitlab 网页端上，这样的一个自动触发执行 shell 脚本的机制被称为流水线，英文名又称 pipeline 。当然用户也可以通过配置 「.gitlab-ci.yml」文件，来指定什么时间节点触发 gitlab-runner 服务器来执行这些 shell 脚本 。

如图所示，在一个微信小程序项目中的流水线中，我们通过集成 miniprogram-ci 在小程序构建完成后将静态资源推送到微信侧服务器。

三、将 CI/CD 工具集成进项目模板

我们内部根据不同的技术栈沉淀了8套前端工程模板，并且根据不同的业务场景为每个模板配置了不同的 CI/CD 流程。这样其它研发同学新建项目时无需从零搭建工程框架，同时也不需要重新配置 .gitlab-ci.yml 文件，以及无需手动为 Gitlab 仓库添加接收 webhook 的服务器域名，研发同学只需要打开网页端选中需要的模板，之后输入 Gitlab 仓库信息，即可一键创建工程并同步到 Gitlab 代码仓库。

1. PR Commit Message 检测

在一些简单（如文案类）的代码改动时，我们可能不会执行 npm install 命令，而是修改完代码之后，直接提交代码，这时我们本地的 npm 插件没被安装，也没有被执行，因此就不会进行代码格式校验。

为了确保大家代码规范的统一性，我们尝试在 PR 环节利用服务端的能力对 「Commit Message」进行二次校验，流程图如下：

我们利用 Gitlab 的 webhook 功能，对 PR 事件进行处理，同时我们在 pipeline 中拉取服务端校验 commit message 的结果，一旦服务端校验不通过则会立即中断 pipeline 进而阻塞 PR 的 merge 行为。同理，我们也可以对流程中添加其他类似的代码检测流程，例如 eslint 代码扫描：

2. 代码构建预览

为了方便对 PR 进行 code review，我们尝试加入了构建预览功能，将打包后的代码上传到预发服务器，实现细节参考了netlifly 的 workflow 的实现机制。

通过在 Gitlab 留言板来展示预发链接，配置 Host 后即可一键点击查看预览效果。

3. 静态资源自动上传 CDN

在 PR 合并分支后，下一个研发环节就是上线操作了，通过我们集成的「一键发布」功能，可以将 HTML 文件推送到公司发布平台，同时静态资源也会被推送到前端 CDN 服务器中。当静态资源使用 CDN 路径时，需要配置 webpack 的 publicPath 字段，我们尝试在打包环节将 publicPath 作为环境变量注入到 Node.js 中，在项目构建配置文件中通过 precess.env 动态获取 publicPath ，以此解决 CDN 的资源路径问题。

在完成打包后，只需使用 CDN upload tool 将打包后的 dist 目录推送到动态生成的 publicPath 中即可。

总结

以上就是我们团队在实际应用场景下，总结出来的一些 CI/CD 的自定义环节，让我们拥有了更丰富的功能指令，更加智能化的流水线，欢迎大家一起来讨论，哪一个才是你们最中意的功能呢？下一期，我们会对大家最感兴趣的内容进行详细讲解，敬请期待哦！