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