✨【GitLab】【CI/CD】核心概念一览

🍃前言

你好啊😎

我是你的人类朋友！

今天说下基于GitLab的cicd相关核心概念

这年头基本是必备知识了

建议全文背诵

注：GitLab CI/CD 是 GitLab 提供的自动化工具链，用于实现持续集成(CI)和持续交付/部署(CD)。

1. Pipeline（流水线）

• 当你推送代码到仓库时自动触发的一系列任务
• 代码会从测试 到部署一步步通过
• Pipeline 就是 GitLab CI/CD 的"总指挥"，它负责管理整个自动化流程

2. Stage（阶段）

• Pipeline 中的逻辑分组，代表开发流程的一个大的步骤
• 【大的步骤】一般包括：构建(build) → 测试(test) → 部署(deploy)
• 一个阶段包含多个 【job】，这些 job 会【并行执行】

job就是一个个具体的任务。比如「安装依赖」「运行测试」「编译代码」「打包镜像」「部署服务器」之类的，后面会讲到

3. Job（作业）

• 最基本的执行单元，定义具体要做什么
• 例如："运行单元测试"、"编译前端代码"
• 每个 job 至少需要一个脚本(script)来执行命令

4. Runner（执行器）

• 实际执行 job 的"工人"
• GitLab提供公共Runner（大家共用），你也可以自己配置私人Runner（独享性能/环境）
• 支持在不同环境和平台上运行（Docker、虚拟机、物理机等）

5. .gitlab-ci.yml 文件【重点】

• 定义整个 CI/CD 流程的配置文件
• 放在项目根目录下
• 用 YAML 语法编写，告诉 GitLab 要运行哪些 job 和 stage

##🧩 下面是整体的工作流程

1. 代码推送/触发事件

   • 你推送代码到仓库
   • 或触发其他事件（Merge Request、定时任务、API调用等）

2. 条件检查

   • GitLab 会先检查 .gitlab-ci.yml 中的 rules/only/except 条件
   • 只有满足条件才会继续，否则流程终止

3. 创建 Pipeline

   • GitLab 生成一个 Pipeline，包含所有 Stage 和 Job
   • 每个 Job 会根据 rules 或 when 决定是否执行

4. Stage 顺序执行

   • Pipeline 按 stages 定义的顺序运行（如 build → test → deploy）
   • 同一 Stage 的 Job 默认并行执行 （除非设置 needs 依赖）

5. Runner 分配执行

   • GitLab 分配可用 Runner（共享或专用）执行 Job
   • 每个 Job 运行在独立环境（Docker/虚拟机/Shell）

6. 结果判断

   • 如果某个 Job 失败 ，默认会终止后续 Stage（除非设置 allow_failure: true）
   • 如果所有 Job 成功，进入最终部署阶段

7. 部署（可能需手动批准）

   • 如果部署 Job 设置了 when: manual，需手动点击执行
   • 否则自动部署到目标环境

👋最后

上面就是文章的全部内容

这些概念搞清楚之后，最好尝试手动部署

部署成功基本就是入门了。

下次见！

🚗~~~~~ ~~ ~