发版 - tag - 沐木https://oldletter.cn/tags/%E5%8F%91%E7%89%88/发版 - tag - 沐木Hugo -- gohugo.iozh-cnFri, 15 Mar 2024 00:00:00 +0000发版流程实战：从代码提交到生产上线的完整链路https://oldletter.cn/posts/devops-01-release-workflow/Fri, 15 Mar 2024 00:00:00 +0000mumuhttps://oldletter.cn/posts/devops-01-release-workflow/

作者：林 | 系列：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（经典方案）

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

]]>