GitLab CI/CD 教程：从入门到精通

2025-3-10

GitLab CI/CD 教程：从入门到精通

引言

在现代软件开发中，持续集成 (CI) 和持续交付/部署 (CD) 已成为不可或缺的实践。它们通过自动化构建、测试和部署流程，显著提高了软件交付的速度和质量。GitLab CI/CD 是 GitLab 内置的一体化 CI/CD 解决方案，它与 GitLab 代码仓库无缝集成，提供了强大且易于使用的自动化管道功能。

本教程将带你从零开始，逐步掌握 GitLab CI/CD 的核心概念、配置方法、最佳实践，并最终达到精通水平。无论你是 DevOps 工程师、开发人员还是测试人员，都可以通过本教程全面了解并应用 GitLab CI/CD。

第一部分：基础入门

1. 什么是 CI/CD？

持续集成 (CI)：CI 强调开发人员频繁地将代码变更合并到共享代码仓库中。每次合并都会触发自动化构建和测试流程，以便尽早发现并解决集成问题。CI 的主要目标是减少集成地狱，提高代码质量。
持续交付 (CD)：CD 是 CI 的延伸。在持续交付中，代码通过自动化构建、测试和部署准备流程后，可以随时手动部署到生产环境。这意味着你可以随时发布新版本，而无需长时间的发布周期。
持续部署 (CD)：持续部署是 CD 的更高级形式。在持续部署中，代码通过所有自动化阶段后，会自动部署到生产环境，无需人工干预。这需要高度的自动化和严格的测试来确保部署的可靠性。

2. GitLab CI/CD 的优势

内置集成：GitLab CI/CD 与 GitLab 代码仓库紧密集成，无需额外配置即可使用。
易于配置：使用 YAML 文件 (.gitlab-ci.yml) 定义 CI/CD 管道，语法简洁易懂。
强大的功能：支持多种构建、测试和部署场景，包括 Docker 集成、并行执行、缓存依赖项等。
可视化界面：GitLab 提供了直观的界面来查看管道状态、构建日志和测试结果。
社区支持：GitLab 拥有庞大的用户社区，可以获得丰富的文档和技术支持。

3. 第一个 GitLab CI/CD 管道

让我们从一个简单的例子开始，创建一个基本的 CI/CD 管道。

在 GitLab 上创建一个新项目。
在项目根目录下创建一个名为 .gitlab-ci.yml 的文件。
在 .gitlab-ci.yml 文件中添加以下内容：

```yaml
stages:
- build
- test

build_job:
stage: build
script:
- echo "Building the project..."
- echo "Build complete."

test_job:
stage: test
script:
- echo "Running tests..."
- echo "Tests passed."
```

代码解释：

stages：定义了管道的阶段。这里我们定义了 build 和 test 两个阶段。
build_job 和 test_job：定义了两个作业，分别属于 build 和 test 阶段。
stage：指定作业所属的阶段。
script：指定作业要执行的命令。这里我们使用 echo 命令模拟构建和测试过程。
将 .gitlab-ci.yml 文件提交到 GitLab 仓库。
GitLab 会自动检测到 .gitlab-ci.yml 文件并触发 CI/CD 管道。
在 GitLab 项目页面的 CI/CD > Pipelines 中，你可以看到管道的执行状态和结果。

第二部分：进阶配置

1. 变量

GitLab CI/CD 支持使用变量来存储和传递配置信息，使管道更具灵活性和可重用性。

预定义变量：GitLab CI/CD 提供了一系列预定义变量，例如 CI_COMMIT_SHA (提交的 SHA 值)、CI_PROJECT_PATH (项目路径) 等。
自定义变量：你可以在 .gitlab-ci.yml 文件中或 GitLab 项目的设置中定义自定义变量。

示例：

```yaml
variables:
MY_VARIABLE: "Hello, GitLab CI/CD!"

job:
script:
- echo $MY_VARIABLE
- echo $CI_COMMIT_SHA
```

2. 缓存

为了加快构建速度，你可以使用缓存来存储依赖项或构建产物。

示例：

```yaml
cache:
paths:
- node_modules/

job:
script:
- npm install
- npm run build
```

3. 制品

构建过程产生的输出文件 (例如可执行文件、文档等) 可以作为制品保存，以便后续阶段或手动下载使用。

示例：

yaml job: script: - npm run build artifacts: paths: - dist/

4. 环境

你可以为作业指定运行环境，例如不同的操作系统、Docker 镜像等。

示例：

yaml job: image: node:16 script: - npm install - npm run build

5. 服务
有些任务需要依赖服务才能运行，比如数据库服务。你可以使用services关键字来连接一个服务容器。

示例
```yaml
test:
image: ruby:2.7
services:
- postgres:11
variables:
POSTGRES_USER: runner
POSTGRES_PASSWORD: ""
POSTGRES_DB: my_project_test
POSTGRES_HOST_AUTH_METHOD: trust # Use "trust" authentication for simplicity.

script:
- bundle install
- bundle exec rake db:create db:migrate
- bundle exec rspec

`` *services关键字定义了作业所需要的依赖服务。在这个示例中，测试作业需要一个 PostgreSQL 数据库服务。 *postgres:11: 指定了 PostgreSQL 服务的 Docker 镜像和版本。GitLab Runner 会自动拉取并启动这个镜像。 * GitLab Runner 会自动设置一些环境变量，例如POSTGRES_HOST和POSTGRES_PORT`，以便你的应用可以连接到服务。

6. 触发器

除了代码提交，你还可以配置其他触发 CI/CD 管道的条件，例如定时触发、API 触发等。

7. 并行执行

如果你的管道包含多个独立的作业，可以使用 parallel 关键字来并行执行这些作业，从而缩短整体执行时间。

示例：

```yaml
stages:
- build
- test

build_job:
stage: build
script:
- echo "Building..."

test_job_1:
stage: test
script:
- echo "Running test 1..."
parallel: 2

test_job_2:
stage: test
script:
- echo "Running test 2..."
parallel: 2
```

8. 矩阵构建
使用矩阵构建（Matrix Builds）可以让你在一次流水线运行中，使用不同的变量组合来多次运行同一个作业。这对于测试不同版本的软件、不同的操作系统或不同的配置非常有用。

```yaml
build:
stage: build
image: $IMAGE_NAME
script:
- echo "Building for $OS and $VERSION"
- ./build.sh

parallel:
matrix:
- OS: [ubuntu, centos, windows]
VERSION: [1.0, 2.0]
IMAGE_NAME:
- ubuntu:latest
- centos:latest
- windows:latest
`` *matrix关键字定义了一个构建矩阵。 *OS: [ubuntu, centos]和VERSION: [1.0, 2.0]定义了两个变量，每个变量有多个值。 * GitLab CI/CD 会根据这些变量的所有可能组合来生成多个作业实例，例如： *OS=ubuntu, VERSION=1.0*OS=ubuntu, VERSION=2.0*OS=centos, VERSION=1.0*OS=centos, VERSION=2.0*OS=windows, VERSION=1.0*OS=windows, VERSION=2.0`

9. 规则（Rules）
rules 关键字可以让你更精细地控制作业的执行条件。你可以根据分支名、标签名、提交消息、流水线来源等因素来决定是否执行某个作业。

yaml job_with_rules: stage: deploy script: - echo "Deploying..." rules: - if: '$CI_COMMIT_BRANCH == "main"' # 仅在 main 分支上运行 - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' # 仅在合并请求事件中运行 when: manual # 手动触发 - when: always # 总是运行（兜底规则）

第三部分：最佳实践

保持 .gitlab-ci.yml 文件简洁：避免将复杂的逻辑直接写入 .gitlab-ci.yml 文件，可以将脚本提取到单独的文件中，然后在 .gitlab-ci.yml 中调用。
使用模板和包含：如果多个项目有相似的 CI/CD 配置，可以使用模板或 include 关键字来避免重复代码。
充分利用缓存：合理配置缓存可以显著提高构建速度，尤其是在依赖项较多的项目中。
尽早并频繁地运行测试：CI 的核心目标是尽早发现问题，因此应该在每次代码提交时都运行自动化测试。
监控管道状态：使用 GitLab 的可视化界面或通知机制来监控管道的执行状态，及时发现并解决问题。
安全最佳实践：
- 保护敏感信息：不要将 API 密钥、密码等敏感信息直接写入 .gitlab-ci.yml 文件，应该使用 GitLab 的 Secret Variables 功能。
- 限制 Runner 权限：为 Runner 分配最小必要的权限，避免潜在的安全风险。
- 定期审查配置：定期审查 .gitlab-ci.yml 文件和 Runner 配置，确保符合安全最佳实践。

第四部分：高级应用

多项目管道：对于大型项目或微服务架构，可以使用多项目管道来管理多个仓库之间的依赖关系和构建顺序。
父子管道：可以将复杂的管道拆分为多个子管道，然后在父管道中触发和管理这些子管道。
GitLab Pages：可以使用 GitLab CI/CD 自动构建和部署静态网站到 GitLab Pages。
与第三方工具集成：GitLab CI/CD 可以与各种第三方工具集成，例如 Docker Hub、Kubernetes、AWS、GCP 等。
自定义 Runner：如果 GitLab 提供的共享 Runner 无法满足需求，你可以配置自己的 Runner，以便更好地控制构建环境和资源。
安装 GitLab Runner：在你的服务器或虚拟机上安装 GitLab Runner。
注册 Runner：将 Runner 注册到你的 GitLab 项目或群组。
配置 Runner：配置 Runner 的执行器 (例如 shell、Docker、Kubernetes)、并发数、缓存等。

第五部分常见问题和故障排查

管道失败：
- 查看构建日志：仔细阅读构建日志，找出错误信息和原因。
- 检查 .gitlab-ci.yml 文件：确保语法正确，配置项没有遗漏或错误。
- 检查 Runner 状态：确保 Runner 正在运行，并且有足够的资源。
- 调试脚本：在脚本中添加调试语句，例如 echo 或 set -x，以便更好地跟踪执行过程。
构建速度慢：
- 优化依赖项：减少不必要的依赖项，使用更轻量级的工具。
- 配置缓存：合理配置缓存，避免重复下载和构建依赖项。
- 使用并行执行：将独立的作业并行执行，缩短整体构建时间。
- 升级 Runner：使用性能更好的 Runner，或者增加 Runner 的资源。
环境问题：
- 使用 Docker 镜像：使用 Docker 镜像可以确保构建环境的一致性，避免因环境差异导致的问题。
- 检查环境变量：确保作业所需的

作者：admin

链接：https://hostlocvps.com/2025/03/10/gitlab-ci-cd-%e6%95%99%e7%a8%8b%ef%bc%9a%e4%bb%8e%e5%85%a5%e9%97%a8%e5%88%b0%e7%b2%be%e9%80%9a/

文章版权归作者所有，未经允许请勿转载。

THE END

Conda加速技巧：优化安装和环境创建

<<上一篇

[特定场景] 出现 "no such file or directory" 怎么办？ (例如：Python 出现 "no such file or directory" 怎么办？)

下一篇>>