1. 课程导入与全景认知

在软件交付从“能上线”走向“可重复、可审计、可回滚”的过程中，团队真正缺少的往往不是某一条流水线脚本，而是一套把发布过程与版本状态统一管理起来的工程机制。本课程讨论的发布编排（Release Orchestration）与版本治理（Version Governance），正是围绕这一目标展开：前者关注“一次发布如何被有序地驱动、卡点和放行”，后者关注“版本号、分支、标签、制品与变更记录如何形成可信的对应关系”。

一、两个核心概念：编排的是过程，治理的是状态

发布编排指把构建、测试、审批、部署、验证、回滚等环节组织成一条可观测、可干预、可重入的发布链路。它回答的问题是：这次发布包含哪些变更？按什么顺序推进？在哪个环境需要人工确认？失败后从哪一步继续或回退？

版本治理指对版本标识、分支策略、标签规则、制品来源、变更追溯建立统一约束。它回答的问题是：v2.4.0 到底对应哪个提交？这个制品是否由受保护分支构建？线上运行的版本能否反查到需求单与合并请求？

两者不是并列的两件事，而是同一交付链上的两个视角：编排产生过程数据，治理沉淀状态数据；没有治理，编排的结果无法被信任；没有编排，治理规则只能停留在文档里。

二、目标：从“发布成功”升级为“发布可证明”

一个成熟的发布体系通常追求四个可度量的目标：

• 可重复：同一版本在相同输入下能产生一致的构建与部署结果，减少“这次能上、下次不行”。
• 可追溯：从线上版本号可反查到提交、合并请求、需求单、构建任务与审批记录。
• 可控制：关键环境有明确的准入条件与放行点，避免“谁都能直接推生产”。
• 可恢复：发布失败时能快速定位影响范围，并回退到上一个已知良好版本。

这四个目标决定了发布编排与版本治理不能只靠人工约定，而需要落到 GitLab 的分支保护、标签、CI/CD 变量、环境、审批规则与制品仓库等具体能力上。

三、核心挑战：变更、环境与版本的三重错位

实际工程中，发布问题很少是“脚本写错了”这么简单，更常见的是三类错位：

第一，变更与版本错位。多个合并请求同时进入主干，若没有统一的版本递增规则，构建出的制品可能包含未预期的变更。例如主干上已有 7 个合并请求，但发布说明只写了 3 个，线上行为与文档不一致。

第二，环境与配置错位。同一制品在测试环境通过，到生产环境因变量、密钥或依赖版本不同而失败。这类问题往往不是代码缺陷，而是环境差异未被编排层显式管理。

第三，人与流程错位。审批靠口头确认、回滚靠手工操作、发布窗口靠群消息同步，导致过程不可审计，事故复盘时缺少证据链。

四、GitLab 的定位与能力边界

GitLab 在本课程中的定位是发布编排与版本治理的承载平台，而不是替代所有周边系统的“万能发布中心”。它天然具备以下能力：

• 版本锚点：提交、分支、标签、合并请求构成版本治理的原始依据。
• 流水线编排：.gitlab-ci.yml 中的 stage、job、needs、rules 可表达构建、测试、部署的顺序与条件。
• 环境与部署：Environments 记录每个环境当前部署的版本，支持查看部署历史与重新部署。
• 审批与保护：Protected Branches、Protected Environments、Approval Rules 控制谁能合并、谁能部署。
• 制品与追溯：Package Registry、Container Registry、Job Artifacts 保存可部署产物，并与流水线关联。

但也要明确边界：GitLab 不负责业务层面的变更风险评估，不替代配置中心、服务网格或云平台的发布策略，也不自动保证跨系统的数据一致性。它提供的是编排骨架与治理证据，具体策略仍需团队按业务约束设计。

五、一个可操作的认知框架：从提交到线上版本

为了把上述概念落到具体对象上，可以用一条最小链路来理解本课程后续要展开的内容。假设团队采用 main 作为集成分支，发布时从 main 切出 release/2.4，并在通过验收后打标签 v2.4.0。一次典型发布包含以下关键对象与判断：

这张表不是固定模板，而是说明一个原则：每一个发布动作都应对应一个可检查的对象和一个可判断的条件。如果某个环节只有“执行部署”而没有判断依据，它就不具备治理意义。

六、本课程要建立的能力

后续章节将围绕这条链路逐步展开：如何设计分支与标签规则，如何用 .gitlab-ci.yml 表达发布阶段与条件，如何利用环境和审批控制放行，如何保存与追溯制品，以及如何在失败时回退与复盘。学完本课程，你应当能够独立回答三个问题：

1. 当前线上运行的版本，对应哪个提交、哪次流水线、哪些变更？
2. 下一次发布要经过哪些环境、哪些卡点、由谁放行？
3. 如果发布失败，依据什么判断影响范围，并回退到哪个版本？