第2章 第一站：从代码提交到持续集成

第2章 第一站：从代码提交到持续集成

章节摘要：发布之旅正式启程。本章跟随一次代码提交走完它进入主干后的第一段路：版本控制与分支策略决定它以什么身份、什么顺序进入主线；持续集成流水线在几分钟内对它做出"能编译、能通过测试"的判决；自动化测试金字塔决定这份判决本身可不可信。读完本章，你能独立设计一条可靠的 CI 流水线，并理解每一步为什么存在。

学习目标

阅读完本章，你应当能够：

1. 对比主流分支策略的适用场景并为团队做出选择
2. 编写一条包含构建、测试、制品发布的流水线配置
3. 读懂 CI 失败日志并快速定位失败层级
4. 按测试金字塔规划自动化测试的投资比例
5. 把"提交到反馈"的时间压缩到十分钟以内

核心概念速览

第一站的全部意义：让每个提交在被合入主干之前和之后，都能在十分钟内得到一份可信赖的质量判决。

子章节导航

2.1 版本控制与分支策略

提交是旅程的起点，起点决定了后面的路况。这一节讲 Git 的分支模型、主干开发与特性分支的取舍、合并请求与代码评审的流程设计，以及"提交信息怎么写才对未来的排障有用"。

2.2 持续集成实践

持续集成是第一站的心脏。这一节用一份完整的流水线配置和一段真实的失败排查过程，讲清 CI 的构成要件：触发时机、缓存策略、测试分层执行、失败通知，以及最关键的纪律——红了必须马上修。

2.3 自动化测试金字塔

CI 的判决质量取决于测试体系。这一节讲测试金字塔各层的分工与配比、什么样的单元测试才有回归价值、契约测试如何缓解集成爆炸，并给出测试套件变慢之后的瘦身方法。

子章节之间的逻辑关系

三节是串行的上下游关系：2.1 决定变更进入主干的方式，2.2 决定变更被验证的速度，2.3 决定验证的可信度。

  2.1 版本控制与分支策略      2.2 持续集成流水线        2.3 测试金字塔
  提交以什么形态进入 ──────▶  进入后多久得到判决 ──────▶  判决本身的证据强度
  （入口治理）               （反馈速度）              （质量深度）
        │                        │                        │
        └──────── 三者共同决定第一站的产出：一个可信的制品 ─┘
​

前置知识与后续延伸

• 前置：第 1 章的反馈原则（本站的每个设计都是它的工程化）；会用 Git 的基本命令。
• 为后续铺垫：本站产出的制品是第 3 章的主角——持续交付要把它安全地送到各个环境。如果第一站的制品不可信，第二站的一切发布策略都是空中楼阁。