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:deployimage:registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest# 使用专业的部署镜像script:-echo "---开始部署到 Staging 环境---"# 这里可以添加部署到 AWS S3, Kubernetes, 或其他服务器的脚本-aws s3 sync ./dist s3://your-staging-bucketenvironment: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}# 使用分支名作为 keypaths:-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 的核心工作原理和基础配置！

你的下一步：

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