# 基于 GitLab CI 的持续集成流程

THEOREM

基于 GitLab CI 的持续集成流程(图片来源于网络)

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

# 先决条件

  1. 部署了 kubernetes 集群,或其他云厂商基于 kubernetes 构建的集群。
  2. 存在 GitLab 或其他代码管理工具。可以独立部署,也可以部署在集群中。
  3. 选择一种 CI 工具,这里选择 GitLab CI,其他可选有:JenkinsTravis 等,没有限制。
  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、质量不通过等),将会打回,从头开始重新运行流程,直到最终部署到生成环境。