5 分钟快速入门 Gitlab CI/CD

🚀 快速掌握 GitLab CI/CD：自动化你的开发流程

GitLab CI/CD 是一个功能强大的工具，它内置于 GitLab 中，用于自动化你的软件构建、测试和部署流程。如果你希望提升开发效率、减少人为错误并实现持续集成/持续部署（CI/CD），那么掌握它至关重要。

本文将通过最核心的概念、最简单的配置，带你快速入门 GitLab CI/CD。

---

核心概念：理解 GitLab CI 的基石

在编写你的第一个配置文件之前，理解以下几个关键概念是掌握 GitLab CI 的前提：

1. 配置文件：.gitlab-ci.yml

这是 GitLab CI/CD 的灵魂 。它是一个 YAML 格式的文件，你需要在项目的根目录下创建它。这个文件定义了 CI/CD 流程中的所有任务、执行顺序和运行环境。

2. Runner

Runner 是实际执行 .gitlab-ci.yml 文件中定义任务的代理程序。

• 你可以使用 GitLab 提供的共享 Runner。
• 你也可以在自己的服务器或环境中安装和注册特定 Runner，以便更好地控制执行环境和资源。

当你在本地提交代码并推送到 GitLab 后，GitLab 就会通知一个可用的 Runner 来执行 CI/CD 管道（Pipeline）。

3. Pipeline（管道）

Pipeline 是整个 CI/CD 流程的最高级别组件 。它包含了一组 Stages（阶段），是基于你的 .gitlab-ci.yml 文件生成的。每一次代码提交，通常都会触发一次 Pipeline 的运行。

4. Stage（阶段）

Stage 定义了 Job（作业）的分组和执行顺序 。例如，你可能有一个 build 阶段，一个 test 阶段，和一个 deploy 阶段。

• 同一 Stage 内的 Job 会并行运行。
• 只有前一个 Stage 所有 Job 都成功，下一个 Stage 才会开始运行。

5. Job（作业）

Job 是 Stage 中最小的执行单元，也是真正执行命令的地方。每个 Job 都有一个唯一的名称，并定义了要执行的脚本、使用的镜像、运行环境等。

---

⚙️ 动手实践：编写你的第一个 .gitlab-ci.yml

假设你有一个简单的 Node.js 项目，目标是实现"构建"和"测试"两个阶段。

在项目的根目录下创建 .gitlab-ci.yml 文件，并输入以下内容：

# 1. 定义阶段 (Stages)
# 定义了 CI/CD 流程的执行顺序：首先是 build，然后是 test。
stages:
  - build
  - test

# 2. 定义构建作业 (Build Job)
# job_build: 是作业名称，可以自定义
job_build:
  stage: build              # 指定该作业属于 build 阶段
  image: node:18-alpine     # 指定 Runner 应该使用哪个 Docker 镜像来执行该作业
  script:                   # 定义要执行的命令列表
    - echo "--- 开始安装依赖 ---"
    - npm install
    - echo "--- 依赖安装完毕 ---"
  artifacts:                # 定义作业成功后要保存的文件或目录
    paths:
      - node_modules/       # 将安装的依赖保存起来，供后续阶段使用
    expire_in: 1 hour

# 3. 定义测试作业 (Test Job)
job_test:
  stage: test               # 指定该作业属于 test 阶段
  image: node:18-alpine     # 再次指定运行环境
  script:
    - echo "--- 正在运行单元测试 ---"
    - npm test              # 假设你的项目里有定义好的测试脚本
    - echo "--- 测试完成 ---"
  needs: ["job_build"]      # 明确依赖 job_build 成功后才运行（虽然 stage 已经保证了顺序，但 explicit needs 更清晰）

运行机制解析：

1. 当你提交并推送这个文件后，GitLab 会触发一个新的 Pipeline。
2. Pipeline 按照 stages 的顺序执行：build -> test。
3. Build 阶段：
   • job_build 开始运行。
   • Runner 拉取 node:18-alpine 镜像。
   • 执行 npm install。
   • 成功后，将 node_modules/ 目录保存为 Artifacts。
4. Test 阶段：
   • job_test 开始运行。
   • Runner 拉取 node:18-alpine 镜像，并自动恢复 job_build 保存的 Artifacts（即 node_modules）。
   • 执行 npm test。
   • 如果测试通过，整个 Pipeline 成功！

---

进阶配置：让 CI/CD 更强大

掌握了基础配置，你可以利用这些关键指令让 CI/CD 更加灵活：

1. 部署阶段（Deploy Stage）

在 .gitlab-ci.yml 中添加一个部署 Job：

# 继承上面的 stages 配置...
# ...

deploy_staging:
  stage: deploy
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest # 使用专业的部署镜像
  script:
    - echo "--- 开始部署到 Staging 环境 ---"
    # 这里可以添加部署到 AWS S3, Kubernetes, 或其他服务器的脚本
    - aws s3 sync ./dist s3://your-staging-bucket
  environment: staging  # 标记这是一个部署环境
  only:                 # 只有满足特定条件时才运行此 Job
    - main              # 仅在 main 分支上运行时才执行部署

2. 缓存（Cache）

如果你的 Artifacts 只需要在 Job 之间传递，使用它。如果需要在 Pipeline 之间保持不变，使用 cache。

• artifacts：用于在同一 Pipeline 的 Job 之间传递文件。
• cache：用于在不同 Pipeline 之间缓存文件，以加快构建速度（例如，缓存 Go Module 或 Maven 依赖）。

cache:
  key: ${CI_COMMIT_REF_SLUG} # 使用分支名作为 key
  paths:
    - node_modules/

3. 使用模板（Templates）

GitLab 提供了许多预设的 CI/CD 模板（如 Nodejs.gitlab-ci.yml），你可以通过 include 关键字直接导入和使用，大大简化配置：

include:
  - template: Auto-DevOps.gitlab-ci.yml # 引入 GitLab 提供的 Auto-DevOps 模板

---

总结与下一步

恭喜你，现在你已经掌握了 GitLab CI/CD 的核心工作原理和基础配置！

概念	作用	配置文件中的关键字
Pipeline	CI/CD 流程的整体执行体	(无，自动生成)
Stage	定义作业的执行顺序和分组	stages
Job	执行具体命令的最小单元	job_name:
Runner	实际执行命令的代理程序	tags (用于选择特定 Runner)
Artifacts	在同一 Pipeline 的 Job 之间传递文件	artifacts

你的下一步：

1. 在你自己的 GitLab 项目中创建 .gitlab-ci.yml 文件。
2. 将上面的示例代码复制进去并提交。
3. 进入 GitLab 项目的 CI/CD > Pipelines 页面，查看你的第一个 Pipeline 运行情况。