软件发布流程图
软件发布流程图：范围冻结、自动化测试关口、预发布环境与 UAT、放行与否的审批、部署、回滚与热修复。
什么是软件发布流程
软件发布流程，就是横在一个代码已可用于发布的构建与一套稳定的生产系统之间的那些关口。步骤本身大家都熟悉（切一条分支、构建它、测试它、发出去），但把这条流程写下来的价值恰恰在于关口：范围停止变动的那个点，一次失败的测试套件把工作退回研发、而不是让它继续往前的那个点，某位有权限的人说“放行”的那个点，以及一次糟糕的发布被回滚、而不是被拿来讨论的那个点。每一道关口都会留下一份记录：这次发布里有什么、测了什么、谁批准的，以及上线之后发生了什么。
多数发布问题是交接问题，而不是工程问题。分支在还有三个合并在路上的时候就被切了出来，于是没有人说得清构建里到底装了什么。QA 拿一套回归测试去跑一个几个月前就已经偏离生产环境的预发布环境。放行与否的判断在一次视频会议上作出，没有任何书面标准，于是嗓门最大的意见胜出。一次发布在下午晚些时候发了出去，没有约定的监控时长，而出问题的第一个信号是第二天早上的一封客户邮件。把这条流程画成泳道之后，每一次交接都变得明确，也能看出此刻是谁托着这次发布。
这份模板是一条可用的发布流程，横跨五条泳道——开发、QA、发布经理、运维与产品负责人——铺排在从范围冻结到结案的五个阶段上。它包含了团队通常不会画出来的三个回路：把失败退回发布分支的自动化测试关口；把一次发布退回返工、而不是放它出门的“不放行”决策；以及那条热修复通道——它让一个发布之后才发现的缺陷重新进入部署与验证，而不必有人另外发明一条平行流程。
本流程图涵盖的内容
本模板包含
- 前三条泳道里的范围与分支：开发里代码已可用于发布，QA 确认测试范围与准入标准，然后由发布经理冻结范围并创建发布分支。
- 自动化测试关口：开发进行构建并运行自动化测试，随后由 QA 拥有“自动化测试是否通过？”这个决策，它把失败送往“在发布分支上修复缺陷”并退回构建，而不是让它继续往前。
- 预发布环境与 UAT 作为三次彼此独立的交接：运维把构建部署到预发布环境，QA 对它执行回归测试，产品负责人执行 UAT 并记录验收。
- 审批既是一份记录、也是一个决策：发布经理汇总发布就绪文档，产品负责人批准该版本发布到生产环境，而“放行还是不放行？”这个决策要么把它放出去，要么把它退回缺陷修复步骤。
- 运维泳道里的生产环境通道：在发布窗口内部署，在生产环境执行冒烟测试，然后是“这个版本是否健康？”这个决策——它把一次失败的发布导向“回滚到上一个版本”并退回缺陷修复。
- 监控与结案：一段明确的观察期、把热修复回路经由部署与冒烟测试送回去的“生产环境是否发现缺陷？”决策，以及最后一个发布版本说明并结案的步骤。
何时使用本模板
- 你们要为一个一直凭习惯和聊天记录发版的团队编写或重写发布程序，并且需要在它被写进流水线之前先有一张大家认可的图。
- 你们在为新来的研发、QA 或值班人员做入职，他们需要知道自己拥有哪一道关口，以及当他们把它拦住时下游会发生什么。
- 你们要在下一次发布把争论逼出来之前，先定清楚放行与否的判断究竟由谁作出、依据什么标准。
- 你们要回答一份客户安全问卷，或者一次关于变更如何被测试、批准和回滚的内部审计问询。
- 你们正在一次糟糕的发布之后复盘流程，希望讨论集中在哪一道关口被跳过了，而不是靠记忆重建当时的经过。
运作方式
把泳道改成你们真实的角色
把开发、QA、发布经理、运维与产品负责人换成你们实际拥有的角色。相当多的团队没有专职的发布经理，那就把这条泳道并入技术负责人，而不是留下一条空带。如果你们没有独立的运维团队，就把部署并入开发，并在图上写明这一点。
定义范围冻结到底意味着什么
把你们的冻结规则写在创建分支那一步旁边：分支创建之后还允许什么落到这条分支上、由谁批准例外，以及分支怎么打标签。记下这条分支是从哪个提交创建的，因为正是它让构建可复现，也让你们可以从差异生成版本说明。
定义每一道测试关口的“通过”指什么
“自动化测试是否通过？”这个决策的好坏，取决于它的定义。写明哪些测试套件必须为绿、你们能接受的抖动率或覆盖率门槛，以及谁可以推翻一个红色构建。对预发布环境的回归测试和 UAT 也做同样的事，好让产品负责人知道自己签的到底是什么。
在需要之前就写好放行与否的标准
把那个笼统的决策换成你们自己的检查清单：没有未关闭的严重缺陷、回滚已经演练、值班安排已经确认、有依赖关系的团队已经知会，以及一个明确的截止时间。指名谁主持这次判断、谁可以否决。等一次发布已经在门口等着才去商定这些，正是糟糕的发布获得批准的方式。
定下回滚触发条件、观察期与热修复通道
写明什么会让“这个版本是否健康？”给出“失败”：一个具体的错误率、一条延迟阈值或者一次未通过的冒烟测试，而不是一个主观判断。定下观察期有多长、监控哪些指标。然后商定一次热修复需要什么审批、谁可以在工作时间之外批准，以及它如何合并回主干——因为一个只活在发布分支上的修复，是下一次回归的常见来源。
把它发布出去，并只保留一个当前版本
把这张图分享到工作真正发生的地方——发布检查清单旁边，或者运行手册里——并取得图中具名人员的签署确认。保留此前的各个版本，这样你们才能说清程序是在什么时候、为什么被改动的，并在任何一次出了问题的发布之后复盘它。
常见问题
软件发布流程分为哪些阶段？
五个阶段能覆盖多数团队。第一，范围与分支：商定本次发布包含什么、确认测试准入标准、冻结范围并创建发布分支。第二，构建与测试：产出一个候选版本，运行自动化测试套件，并把失败退回分支而不是让它继续往前。第三，预发布环境与 UAT：部署到预发布环境，执行回归测试，并取得产品负责人的 UAT 验收。第四，审批：汇总一份就绪文档，并作出一次明确的放行与否决策。第五，发布与监控：在约定的窗口内部署，执行冒烟测试，按明确的观察期盯住它，然后发布版本说明并结案。
发布流程和部署流水线有什么区别？
部署流水线是自动化：它在被触发时构建、测试并交付代码。发布流程则是围绕它的决策——谁商定了范围、谁确认了这些测试确实有意义、谁批准了发布到生产环境、发布出问题时会怎么样，以及团队什么时候可以解除待命。一条成熟的流水线会消除人工步骤，但它不会消除决策。这张图有意把决策画成决策，好让你们看清其中哪些已经由流水线强制执行，哪些仍然依赖有人记得。
放行与否的决策应该由谁作出、依据什么？
应该由一位具名的人主持，通常是发布经理或者生产环境的责任人，而产品负责人的批准应当已经作为输入被记录在案，而不是在会上再讨论一遍。依据发布之前就写好的标准来决定：没有未关闭的严重缺陷、回归测试与 UAT 已完成、回滚已经演练、值班安排已经确认、有依赖关系的团队已经知会。记录谁参加了、决定了什么，而不只是结果。如果你们要接受 SOC 2 审计，相关准则是 CC8.1，它要求变更经过授权、测试、批准并留下文档；能够证明这一点的正是发布就绪文档和审批留痕，而这张图展示的是它们在哪里产生。
怎样在不绕过发布流程的前提下处理热修复？
热修复是把流程压缩，而不是跳过它。在这份模板里，监控期间发现的缺陷会被导向开发泳道中的“构建并测试热修复”，随后在部署处重新进入流程，并经过与一次计划内发布完全相同的生产环境冒烟测试和同一个“这个版本是否健康？”检查。改变的是审批的速度，而不是验证。有两条规则能让它保持诚实：事先商定谁可以在工作时间之外批准一次热修复；并且当天就把这个修复合并回主干——因为一个只存在于发布分支上的修复，会在下一次发布里以回归的形式重新出现。