🚀 快速掌握 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 更清晰）运行机制解析：
- 当你提交并推送这个文件后，GitLab 会触发一个新的 Pipeline。
- Pipeline 按照
stages的顺序执行：build->test。 - Build 阶段：
job_build开始运行。- Runner 拉取
node:18-alpine镜像。 - 执行
npm install。 - 成功后，将
node_modules/目录保存为 Artifacts。
- 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 的核心工作原理和基础配置！
| 概念 | 作用 | 配置文件中的关键字 |
|---|---|---|
| Pipeline | CI/CD 流程的整体执行体 | (无，自动生成) |
| Stage | 定义作业的执行顺序和分组 | stages |
| Job | 执行具体命令的最小单元 | job_name: |
| Runner | 实际执行命令的代理程序 | tags(用于选择特定 Runner) |
| Artifacts | 在同一 Pipeline 的 Job 之间传递文件 | artifacts |
你的下一步：
- 在你自己的 GitLab 项目中创建
.gitlab-ci.yml文件。 - 将上面的示例代码复制进去并提交。
- 进入 GitLab 项目的CI/CD > Pipelines页面，查看你的第一个 Pipeline 运行情况。
)
