基于 GitLab CI 的持续集成流程

THEOREM

基于 GitLab CI 的持续集成流程（图片来源于网络 (opens new window)）

先决条件

1. 部署了 kubernetes 集群，或其他云厂商基于 kubernetes 构建的集群。
2. 存在 GitLab 或其他代码管理工具。可以独立部署，也可以部署在集群中。
3. 选择一种 CI 工具，这里选择 GitLab CI，其他可选有：Jenkins、Travis 等，没有限制。
4. 存在 Docker 镜像仓库，可以独立部署，也可以部署在集群中。

持续构建(CB) + 持续部署(CD) = 持续集成(CI)

1. 开发人员从 GitLab 中检出代码。修改后提交（增加新特性或修改 bug）到 GitLab。
2. GitLab 触发 GitLab CI 执行自动构建。
3. GitLab CI 根据预先定义的任务，开始执行自动构建。
4. GitLab CI 根据预先定义的任务，开始执行自动化测试：包括但不限于静态代码扫描、代码安全性漏洞扫描、单元测试、集成测试、性能测试等。
5. GitLab CI 生成质量报告、性能报告、测试覆盖率等数据。
6. 经由开发人员、质量管理人员查看结果，审批通过后，进入下一阶段（此处省略掉一部分流程）。
7. GitLab CI 开始自动构建 Docker 镜像和部署文件。
8. 部署代码到 开发环境，这里采用滚动更新。
9. 经由质量管理人员审批通过后，允许部署到测试环境，这里会根据实际需要，采取灰度发布、金丝雀发布等方式进行部署，同时对部分用户开发测试体验。
10. 如果用户反馈良好，并经由质量管理团队审批通过，将触发声场环境升级。

由于时间关系，省略掉一些细节描述。

这一套流程中会有很多阶段，其中一些阶段如果不通过（如存在 bug、质量不通过等），将会打回，从头开始重新运行流程，直到最终部署到生成环境。