概览¶
如果每次编写完代码后，都需要手动运行编译、测试，会比较麻烦。借助持续集成工具，我们可以和代码版本管理平台集成，在每次上传代码后，让服务器来帮我们编译、测试，并将结果保存下来，方便查看。
本节将带你了解持续集成的过程以及常用平台。
持续集成的过程¶
简单来说，持续集成就是在每次代码提交之前，都运行一系列的自动化工具，以保证代码库中的代码能够正常编译、运行并通过测试。通过自动化的工具，可以避免引入错误，同时也保证大家都对什么样的代码可以提交有一定共识。
一般来说，持续集成是在服务器完成的。持续集成系统和版本管理系统集成，每当开发者在自己的代码分支完成修改并推送到服务器之后，版本管理系统就会通知持续集成系统针对本次提交运行测试。
Git Hooks
对于 Git 而言，这种通知可以使用 Git Hooks 功能中的 post-receive 来实现。当然我们一般不需要自己编写脚本，一些代码托管平台例如 GitHub 或者 GitLab 都有方便易用的 Web 界面来帮助我们连接持续集成系统。
一些权限管理也可以通过 Git Hooks 实现。
持续集成系统一般会收到以下信息：代码库、分支以及对应的 Commit 信息。持续集成系统根据接收到的参数运行一系列编写在配置文件中的脚本，并根据脚本返回值决定本次运行是否成功。最后，持续集成系统也会反过来通知版本管理系统本次运行是否成功，从而帮助版本管理系统决定这个分支能否合并到主分支。
常用的持续集成系统有 Jenkins、Drone CI，或是一些版本管理系统本身就自带 CI 功能，例如 GitHub Actions、GitLab CI。
持续集成的配置¶
一般而言，持续集成系统会读取代码库中指定文件名作为配置文件，例如 Jenkins 会读取 Jenkinsfile，而 GitLab CI 会读取 .gitlab.ci.yml。不同的持续集成系统配置方式差别很大，但是概念上都差不多。首先，一个持续集成配置会有一条流水线（Pipeline），流水线中会有不同的阶段（Stage），一个阶段中会有不同的任务（Job）。任务是运行编译、测试等的基本单元，可以理解为一个脚本。如果任务没有依赖关系，那么就可以并行运行，类似构建系统中的策略。当一个阶段中的所有任务都成功完成后，才会执行下一个阶段的任务。例如，我们可以先在编译阶段检查代码是否能够编译，不能的话就没有必要也没有办法运行测试阶段。
一个典型的流水线可能包含这些阶段：静态检查→编译→测试→打包→部署。
在编写一个任务的时候，往往需要指定几个参数：
- 这个任务属于哪个阶段
- 这个任务的名称
- 这个任务执行所需要的环境，例如需要 Ubuntu 18.04 的虚拟机，或者 Nodejs:15 的 Docker 镜像
- 这个任务的执行脚本，例如
make
当然不同 CI 系统会提供更多高级的功能，例如指定在某些分支上只运行基本的测试，或者定时运行某些任务等。不过最基本的功能就是定义任务，然后将任务组织成阶段和流水线然后执行。