1. 课程导入与全景认知

在开始搭建任何流水线之前，我们需要先建立一张"全景地图"。很多团队在引入 GitLab CI/CD 时，第一反应是写 .gitlab-ci.yml、跑通一个 deploy 阶段，然后就认为"持续交付已经落地"。但真实的生产环境往往由开发、测试、预发布、生产等多个环境组成，每个环境的配置、数据、访问权限、发布节奏都不同。如果没有整体设计，流水线会迅速退化成"一堆能跑但没人敢改的脚本"。本课程的目标，就是带你从零设计一套可维护、可扩展、可审计的 GitLab 多环境持续交付平台。

一、为什么需要"多环境"持续交付

单环境交付的典型问题是：所有变更都直接面向生产。开发人员提交代码后，如果只有一条流水线直达生产，那么任何一次误提交、配置错误或依赖升级都可能直接影响线上用户。多环境的核心价值在于逐级验证、逐级收敛风险：代码先进入开发环境验证功能，再进入测试环境验证集成，随后进入预发布环境验证与生产一致的配置和性能，最后才发布到生产。

但多环境并不是简单地"多建几台服务器"。它带来的是一整套工程约束：

• 配置隔离：数据库地址、密钥、副本数、资源配额在不同环境必须不同，且不能硬编码在代码里。
• 制品一致性：同一个构建产物（镜像或包）应当贯穿所有环境，避免"测试环境测的是 A 版本，生产部署的是 B 版本"。
• 发布可控：生产发布需要人工审批、灰度或回滚能力，而开发环境可以自动部署。
• 可追溯：每次部署都能回答"谁、在什么时候、把哪个版本、部署到了哪个环境"。

这四点决定了后续所有设计：制品仓库、变量管理、环境（Environment）对象、审批规则、回滚策略，都是围绕它们展开的。

二、GitLab 平台的能力边界

GitLab 不只是一个代码托管平台，它同时提供了 CI/CD、制品仓库、容器镜像仓库、环境管理、审批与审计等能力。理解它的边界，能避免我们重复造轮子，也能避免把不该交给 GitLab 的事情硬塞进去。

GitLab 原生能做的：

• 流水线编排：通过 .gitlab-ci.yml 定义 stage、job、rules、needs，支持并行、串行、条件触发。
• 环境对象：在 environment 关键字中声明 name 和 url，GitLab 会记录每个环境的部署历史，并支持"重新部署"和"回滚"到某个历史版本。
• 变量与密钥：支持项目级、组级、实例级变量，可标记为 protected 和 masked，避免密钥出现在日志中。
• 制品与镜像：内置 Package Registry 和 Container Registry，可作为制品一致性的存储底座。
• 审批与保护：通过 protected environments 和 approval rules，限制谁能部署到生产。

GitLab 不擅长或不应承担的：

• 复杂业务发布策略：如按用户 ID 灰度、按流量比例切流，通常需要服务网格或网关配合，GitLab 只负责触发。
• 基础设施编排：Kubernetes、Terraform 等由专门工具完成，GitLab 负责调用和记录结果。
• 运行时配置中心：动态配置热更新应由配置中心承担，而不是每次改配置都触发流水线。

三、课程实战项目与整体架构

本课程围绕一个贯穿始终的实战项目展开：一个名为 order-service 的订单服务，使用容器化部署，目标环境为 dev、test、staging、prod 四个环境。项目包含代码仓库、Dockerfile、Kubernetes 部署清单、以及一套逐步演进的 .gitlab-ci.yml。

下图展示了本课程要构建的多环境持续交付平台全景。它把"代码提交 → 构建 → 制品 → 分环境部署 → 验证与回滚"这条主链路，与 GitLab 各能力模块的对应关系一次性呈现出来，便于你在后续章节中随时定位自己正在设计哪一部分。

从图中可以看到，整条链路被划分为三个区域：左侧是"代码与制品"，中间是"GitLab CI/CD 编排"，右侧是"多环境部署目标"。制品仓库是左右两侧的桥梁——它保证同一个镜像被四个环境复用，这是多环境交付中"一致性"的关键。中间的编排层则负责决定"什么条件下、把哪个制品、部署到哪个环境、是否需要人工确认"。

四、学习路径与章节安排

本课程共 30 章，整体遵循"先建底座、再搭流水线、后做治理"的顺序，你可以按以下四个阶段来理解：

1. 认知与设计阶段（第 1～6 章）：建立多环境交付的整体认知，明确 GitLab 能力边界，完成环境划分、分支策略、制品策略和变量体系的设计。
2. 流水线构建阶段（第 7～16 章）：从零编写 .gitlab-ci.yml，实现构建、测试、镜像推送、分环境部署，并引入 environment、rules、needs 等关键能力。
3. 生产化治理阶段（第 17～24 章）：加入审批、保护环境、密钥管理、部署回滚、审计与通知，让流水线达到可上生产的标准。
4. 扩展与复盘阶段（第 25～30 章）：讨论多项目复用、模板化、性能优化、常见故障排查，并完成一次完整的端到端演练。

建议你在学习过程中始终维护一个自己的 order-service 示例仓库，每章结束后把当章的设计落到仓库里。多环境持续交付不是"看懂"就会的，它需要在真实仓库、真实 Runner、真实集群上反复调试才能形成肌肉记忆。