从手工构建到持续集成

早期团队的上线是这样的：开发本地打完包，拷到服务器，再手动重启。每个人打的包都可能不一样，出了问题根本说不清这次到底上了什么。持续集成要解决的，就是把「打包发布」这件反复做的事，变成一条每次提交都自动跑的流水线。

它的核心思想很朴素：代码一合入主干，就自动触发构建和测试，第一时间暴露问题，并且产出一个确定、可追溯的产物。

持续集成不是装个工具，而是让「每次改动都被自动验证」成为团队的默认动作。
本文核心知识点
  • 流水线阶段构建、测试、扫描、打包、部署串成一条链。
  • 制品管理每次构建产出固定版本、可回溯的产物。
  • 发布门禁测试不绿就拦住，不让带病上线。
  • 灰度回滚小步放量，出问题快速退回去。
  • 流水线治理可见、可改、可维护，不是黑盒。
持续集成示意：蓝色渐变背景上一条从左到右的发光流水线管道，管上依次串联构建、测试、打包与发布节点，右侧是发光制品仓库与小火箭，扁平科技插画
流水线把人工步骤自动化，让每次提交都走同一条被验证过的路。

一条流水线该有哪些阶段

一条可用的发布流水线，不是把几个命令堆在一起，而是按顺序串起一个个可失败、可重试的阶段。前面不过，后面就不跑。

阶段做什么失败后果
拉取与构建拿到代码，打出产物直接中断，通知提交人
自动测试跑单元与集成测试不允许合入或部署
扫描检查依赖与漏洞扫描高危问题标红拦截
部署预发部署到类生产环境失败回退，不进生产
 
# 一条流水线的阶段顺序（示意）
checkout   # 拉取指定版本代码
build      # 构建产物
test       # 跑自动测试，一条红就停
scan       # 依赖/镜像扫描
package    # 产出固定版本号制品
deploy-staging  # 部署预发验证
# 任一步失败即停止并通知，不靠人盯着。

阶段划分清楚，出问题时一眼就知道卡在哪一环，而不是整条流水线糊成一团。

制品管理：让每次构建可追溯

流水线跑完一次，会产出一个制品——一个确定版本、可以随时再部署的包。制品管理就是给这些产物编号、存档、记录它来自哪次提交。

  • 每个制品对应唯一版本号和那次提交的记录。
  • 部署用的是仓库里的制品，不是谁本地的临时包。
  • 出问题时，能反查到这个制品对应哪段代码、谁提交的。
# 制品要能回答三个问题
- 这个包是哪个版本？
- 它对应哪次代码提交？
- 现在生产上跑的是哪一个？
# 答不上来，说明制品管理还没真正做起来。

有了可追溯的制品，回滚才不是「重新打个差不多的包」，而是精确切回上一个验证过的版本。

发布门禁：流水线自动把关

发布门禁是流水线里的一道硬关卡：该过的检查全绿了，才允许进入发布。它把质量要求从「靠人自觉」变成「系统不让过」。

门禁项通过标准
自动测试全套测试无失败
构建产物可复现、版本号固定
漏洞扫描无未处理的高危问题
预发验证类生产环境跑通核心流程

门禁一旦被绕开，后面所有自动化的努力都会打折。所以门禁要设计成绕不开，而不是写在文档里靠大家自觉。