GitLab CI/CD 介绍和使用_gti cicd-优快云博客

本文链接：https://blog.youkuaiyun.com/Soul_Programmer_Swh/article/details/99705632

本文详细介绍了持续集成的概念、好处以及常见的持续集成工具，重点讲解了GitLab CI/CD的各个方面，包括GitLab、GitLab CI/CD、GitLab Runner的概念，以及Pipelines、Stages、Jobs等核心概念。此外，还提供了安装GitLab Runner的步骤、.gitlab-ci.yml的配置示例以及GitLab CI/CD的常用配置选项，帮助读者理解并掌握GitLab CI/CD的实践应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、持续集成介绍

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。—— Martin Fowler

1 概念

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

2 持续集成的好处

自动化构建且状态对每个人可见。可以使用Maven、Gradle等来实现自动化构建，可以在构建过程中实现自动化测试（前提是有写单元测试用例）。集成服务器在持续集成过程中发现问题可以及时发送警告给相关的干系人。
**解放了重复性劳动。**自动化部署工作可以解放集成、测试、部署等重复性劳动，而机器集成的频率明显比手工高很多。
**更快地发现和修复问题。**持续集成更早的获取变更，更早的进入测试，更早的发现问题，解决问题的成本显著下降。
**更快的交付成果。**更早发现错误减少解决错误所需的工作量。集成服务器在构建环节发现错误可以及时通知开发人员修复。集成服务器在部署环节发现错误可以回退到上一版本，服务器始终有一个可用的版本。
**减少手工的错误。**在重复性动作上，人容易犯错，而机器犯错的几率几乎为零。
**减少了等待时间。**缩短了从开发、集成、测试、部署各个环节的时间，从而也就缩短了中间可以出现的等待时机。持续集成，意味着开发、集成、测试、部署也得以持续。
**更高的产品质量。**集成服务器往往提供代码质量检测等功能，对不规范或有错误的地方会进行标致，也可以设置邮件和短信等进行警告。

3 常用持续集成工具

二、Gitlab 持续集成

[外链图片转存失败(img-93v8L3VB-1566115077727)(https://docs.gitlab.com/ee/ci/img/cicd_pipeline_infograph.png)]

1 概念介绍

(1) GitLab

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

(2) GitLab CI/CD

GitLab CI/CD 是GitLab Continuous Integration（Gitlab持续集成）的简称。GitLab 自GitLab 8.0开始提供了持续集成的功能，且对所有项目默认开启。只要在项目仓库的根目录添加.gitlab-ci.yml文件，并且配置了Runner（运行器），那么每一次push或者合并请求（Merge Request）都会触发CI Pipeline。

(3) GitLab Runner

GitLab Runner GitLab Runner是一个开源项目，可以运行在 GNU / Linux，macOS 和 Windows 操作系统上。每次push的时候 GitLab CI 会根据.gitlab-ci.yml配置文件运行你流水线（Pipeline）中各个阶段的任务（Job），并将结果发送回 GitLab。GitLab Runner 是基于 Gitlab CI 的 API 进行构建的相互隔离的机器（或虚拟机）。GitLab Runner 不需要和 Gitlab 安装在同一台机器上，且考虑到 GitLab Runner 的资源消耗问题和安全问题，也不建议这两者安装在同一台机器上。

Gitlab Runner 分为三种：

共享Runner(Shared runners)
专享Runner(Specific runners)
分组Runner(Group Runners)

(4) Pipelines

Pipelines 中文称为流水线，是分阶段执行的构建任务。如：安装依赖、运行测试、打包、部署开发服务器、部署生产服务器等流程。每一次push或者Merge Request都会触发生成一条新的Pipeline。

下面是流水线示例图：

[外链图片转存失败(img-HjJVfv6x-1566115077729)(https://docs.gitlab.com/ce/ci/img/pipelines_index.png)]

(5) Stages

Stages 表示构建阶段，可以理解为上面所说“安装依赖”、“运行测试”等环节的流程。我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点：

所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始（当然可以在.gitlab-ci.yml文件中配置上一阶段失败时下一阶段也执行）
只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

下面是一个流水线内的阶段任务示例图：

[外链图片转存失败(img-ipwGJWAg-1566115077730)(https://docs.gitlab.com/ce/ci/img/pipelines.png)]

(6) Jobs

Jobs 表示构建的作业（或称之为任务），表示某个 Stage 里面执行的具体任务。我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：

相同 Stage 中的 Jobs 无执行顺序要求，会并行执行
相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 也失败（可以在.gitlab-ci.yml文件中配置允许某 Job 可以失败，也算该 Stage 成功）

(7) .gitlab-ci.yml

GitLab 中默认开启了 Gitlab CI/CD 的支持，且使用YAML文件.gitlab-ci.yml来管理项目构建配置。该文件需要存放于项目仓库的根目录（默认路径，可在 GitLab 中修改），它定义该项目的 CI/CD 如何配置。所以，我们只需要在.gitlab-ci.yml配置文件中定义流水线的各个阶段，以及各个阶段中的若干作业（任务）即可。

下面是.gitlab-ci.yml文件的一个简单的Hello World示例：

# 定义 test 和 package 两个 Stages
stages:
  - test
  - package

# 定义 package 阶段的一个 job
package-job:
  stage: package
  script:
    - echo "Hello, package-job"
    - echo "I am in package stage"

# 定义 test 阶段的一个 job
test-job:
  stage: test
  script:
    - echo "Hello, test-job"
    - echo "I am in test stage"

以上配置中，用 stages 关键字来定义 Pipeline 中的各个构建阶段，然后用一些非关键字来定义 jobs。每个 job 中可以可以再用 stage 关键字来指定该 job 对应哪个 stage。job 里面的script关键字是每个 job 中必须要包含的，它表示每个 job 要执行的命令。