GitLab CI/CD 自动构建和发布实践 - 流程介绍

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。这篇文章中，我将会介绍基于 GitLab CI/CD 的自动化构建与发布实践。如下图所示，整个流程将分为几个部分：

• 1.首先开发人员在本地完成项目的开发之后，将代码推送到 Gitlab 仓库中。
• 2.当代码提交到 Gitlab 仓库时，会触发 Pipeline，Gitlab Runner 会根据 .gitlab-ci.yml 配置文件运行 Pipeline 中各阶段的任务。我总共定义了 3 个阶段：compile，build，deploy。
• 3.在 compile 阶段，Gitlab Runner 将项目编译成 jar 包，使用 MinIO 作为缓存，首次编译项目时会从 Maven 官网拉取依赖，之后会将依赖压缩后上传至 MinIo，在下一次编译时就可以直接从 MinIO 下载依赖文件。
• 4.在 build 阶段，Gitlab Runner 使用在 compile 阶段编译生成的 jar 包构建 Docker 镜像，并将镜像推送至镜像仓库。
• 5.在 deploy 阶段，Gitlab Runner 使用构建好 Docker 镜像在 Kubernetes 集群中部署应用。

GitLab 介绍

GitLab [1] 是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过 Web 界面进行访问公开的或者私有的项目。它拥有与 GitHub 类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。

GitLab CI/CD 介绍

Gitlab CI/CD [2] 是一个内置在 GitLab 中的工具，用于通过持续方法进行软件开发。

• 持续集成(Continuous Integration)：频繁地(一天多次)将代码集成到主干。让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。
• 持续交付(Continuous Delivery)：频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
• 持续部署(continuous Deployment)：代码通过评审以后，自动部署到生产环境。是持续部署是持续交付的下一步，持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。

GitLab Runner 介绍

GitLab Runner [3] 用于执行 Gitlab CI/CD 触发的一系列作业，并将结果发送回 Gitlab。GitLab Runner 可以在 Docker 容器内运行或部署到 Kubernetes 集群中。

Pipeline

Pipeline [4] 中文称为流水线，是分阶段执行的构建任务。如：安装依赖、运行测试、打包、部署开发服务器、部署生产服务器等流程，合起来称为 Pipeline。

Stage

Stage [5] 表示构建阶段，可以理解为上面所说安装依赖、运行测试等环节的流程。我们可以在一次 Pipeline 中定义多个 Stage。

Job

Job [6] 表示构建的作业（或称之为任务），表示某个 Stage 里面执行的具体任务。我们可以在 Stages 里面定义多个 Jobs。

Pipeline，Stage 和 Job 的关系可以用下图表示。