发版流程实战：从代码提交到生产上线的完整链路

mumu — Fri, 15 Mar 2024 00:00:00 +0000

作者：林 | 系列：DevOps 实战 | 适合读者：后端/运维/架构师

一、为什么需要一套规范的发版流程

很多团队的发版流程是"人工操作 + 口头确认"：开发本地打包、运维手动部署、群里喊一声"发了"。这种方式在团队小、服务少的时候还能凑合，但一旦服务超过 5 个、团队超过 10 人，各种问题就来了：

发错版本：分支没合并干净，把半成品发到生产
回滚慢：出问题后找不到上一个稳定版本，或者回滚步骤不一致
环境不一致：测试环境和生产环境配置不同，测试通过了生产挂了
发版窗口长：从代码合并到上线要半天，错过业务窗口

一套规范的发版流程并非为了"流程化而流程化"，重点是为了让发版可重复、可预测、可回滚。

二、整体架构一览

一套完整的发版链路，通常包含以下环节：

flowchart LR Commit["代码提交"] --> Review["代码审查"] Review --> Build["CI 构建与测试"] Build --> Artifact["不可变制品"] Artifact --> Test["测试环境验证"] Test --> Stage["预发布验证"] Stage --> Approval["发布审批"] Approval --> Prod["生产灰度"] Prod --> Observe{"指标达标"} Observe -- "继续" --> Complete["完成发布"] Observe -- "否" --> Rollback["回滚或停止放量"]

每个环境的职责不同：

环境	用途	部署触发方式	数据
dev	开发自测	手动 / push 触发	mock 数据
test	功能测试、集成测试	合并到 develop 触发	测试数据
staging	预发布验证，跟生产一致	合并到 main / 手动	生产数据脱敏副本
prod	线上服务	打 tag / 手动审批	真实数据

三、分支策略

3.1 Git Flow（经典方案）

适合有明确版本发布节奏的项目：

CI/CD 进阶：构建与发布分离，用 Release Manifest 管控生产发布

mumu — Thu, 20 Jun 2024 00:00:00 +0000

作者：林 | 系列：DevOps 实战 | 适合读者：后端/运维/DevOps 工程师

一、问题：你的生产发布靠什么保证"发的是测试通过的版本"？

很多团队的生产发布流程是这样的：

测试在测试环境验证通过
开发或运维在生产流水线里手动填一个 IMAGE_TAG
部署到生产

问题来了，这个 IMAGE_TAG 是谁填的？填的对不对？怎么证明测试环境用的就是这个 tag？

常见翻车场景：

运维填错了 tag，把没测试过的版本发到生产
测试验证的是 commit abc1234，但生产发的是 def5678
出了问题想回滚，但不确定上一个稳定版本是哪个 tag
多人协作时，谁发的、发了什么、什么时候发的，全靠聊天记录

核心矛盾：生产发布的"输入"没有约束，任何人都能填任何 tag。

二、解决方案：Release Manifest

2.1 核心思路

核心约束是一次构建、多环境部署，生产只提升已经验证的制品。

具体来说：

dev/test 流水线负责构建镜像、推送 ACR、发布测试环境
测试环境发布成功后，生成一份 release-manifest.json（发布清单）
测试人员验证通过后，把 manifest 状态标记为 TEST_PASSED
prod 流水线只接受一个输入：RELEASE_ID
prod 流水线根据 RELEASE_ID 读取 manifest，只发布 manifest 里记录的镜像

flowchart TD Commit["代码提交"] --> Build["构建、测试并推送制品"] Build --> Manifest["生成发布清单"] Manifest --> Test["部署测试环境"] Test --> Verify{"验证通过"} Verify -- "否" --> Reject["终止该发布清单"] Verify -- "是" --> Approve["批准清单"] Approve --> Prod["按 RELEASE_ID 部署生产"] Prod --> Record["记录实际部署结果"]

关键约束：prod 不接受 IMAGE_TAG 输入，只接受 RELEASE_ID。镜像版本由 manifest 决定，不由人手填。

K8s - tag - 沐木