聊聊线上发布这件事
上周六星球公开直播时候，有同学在直播评论区提了这样一个问题：
我们每次提测质量很差，测试环境的服务经常发布，打乱测试节奏，导致最终线上发布质量很差，怎么解决？
这是很典型的一个问题，很多测试同学在工作中都遇到过。针对这位同学的提问，我给出了几条建议：
- 提测质量差：制定质量门禁，即每个环节流转到下个环节需要满足的准入准出规则；
- 服务经常发布：权限收口&发布窗口，测试负责发布，保证测试环境稳定性，提高可测性；
- 线上发布质量差：以测试报告作为最终质量标准，发布前出具部署手册，评审通过后灰度发布，逐渐切流；
这篇文章，我想结合上面几点建议，聊聊和线上发布这件事有关的一些内容。
先看一个软件产品从需求到线上交付的大体流程图：
其中浅蓝色背景，紫色字体部分为测试需要100%投入的重点事项；湖蓝色字体部分为测试参与建设的事项。
当然，既然这篇文章聊的是线上发布相关的内容，那本文就挑下面几个部分，聊聊我的看法。
质量门禁
其实与质量门禁相关的概念，很早前就有了，那就是准入准出规则。如何理解呢？
软件从需求到线上发布，是一个庞大复杂且一环套一环的流水线过程，这个在软件工程中就有详细描述。
我们都说质量是设计出来的，代码是对需求设计的具体实现，而测试的这个执行动作，只不过是验证是否达到设计标准。
在整个流水线上，为了验证研发交付到测试阶段的制品是否满足预期标准，那肯定是需要明确可量化的指标来度量的。
所谓的质量门禁，在我看来，就是测试应该主动在交付的每个环节去把控交付的制品是否满足进入下一环节的标准。
标准不一定全部需要测试去制定，但测试同学有责任和义务去主动跟进和把控，否则质量保障又从何谈起呢。
权限收口
权限其实在企业内部，是个很敏感的问题。
一方面，日常工作中很多问题或故障是变更导致的；另一方面，角色不同权限不同，信息差导致的误操作引起。
就像上面提到的那位同学的问题，测试环境发布权限在开发手中，没有规范的发布流程，测试同学也没有主动去做质量门禁，导致了随意发布如流水，测试水深火热的状况。
比较好的实践，是发布权限掌握在测试同学手中。一方面软件产品是否满足流向下一环节的标准，测试同学最清楚；另一方面，测试同学本身就负有把控质量的责任，不能被动的把命运交给其他人。
当然，发布权限不能滥用，决定是否发布，还要考虑到信息同步问题。
发布窗口
团队越大，业务越多，服务数量越多，服务的发布管理就越来越难以控制，本质是上个复杂性指数增加的问题。
一般来说，在测试环境，最好通过设置发布窗口的方式，来定时发布会比较可控。一方面，保证在一定时限内被测服务是稳定的，测试范围和风险是可控和已知的；
另一方面，开发的bugfix以及代码提交，也可以做一定的频次控制，这样有助于分支管理。当然，生产环境的服务发布，就需要另一种思路。
一方面，在比如电商大促或者比较重要的业务发布阶段，进行封版（即该时间段线上禁止发布）；另一方面日常的线上发布和变更，如果CICDl流水线建设的比较好，可以提高发布频次，但前提是发布质量要满足质量门禁的要求。
我们常说的灰度发布，蓝绿发布，金丝雀发布，本质上是一个降低线上发布风险的手段，而且需要配套比较成熟的自动化验证手段和完善的监控报警体系以及故障应急响应机制。
测试报告
很多同学不会写测试报告，或者认为测试报告的重要性没那么重要，这其实是个误区。
作为测试同学，在流程上作为服务线上发布的最后一道环节，测试报告其实非常重要。
测试报告的作用，以我的角度来说主要有如下几点：
- 信息同步：测试报告是信息同步很重要的一种方式，比较正式的方式和渠道，才能引起重视；
- 风险披露：项目进度，资源投入，质量表现，是否存在风险，是否有备份方案，这些都是项目管理中很重要的部分。要做好质量保障，项目管理的手段是必须掌握的。而测试报告，是很好的一种协作和管理方式。
- 准出标准：前面我们在讲质量门禁，而测试报告，就是对质量门禁最好的一种解释。测试报告，相当于对外表示质量达到了某种标准或者进度的承诺，表示可以交付到下一环节。
部署手册
据不完全统计，软件线上故障，大部分是变更引起的。无论是发布新的代码版本，或者进行一些配置信息的变更操作，都可能引起线上故障。如果没有比较完善的监控告警手段和应急响应机制，那线上变更的风险其实是很大的。
我之前工作中有一个比较好的实践是这样的：
- 每次变更都要最少3种角色参与：运维负责变更，研发负责监控，测试同学负责验证；
- 每次变更的信息都需要通过评审：变更原因、变更信息、变更方式、影响范围、冗余手段等；
- 大的变更一定要输出线上部署手册：包含上述第二步的信息，且要说明详细操作步骤，变更是否在测试环境或uat经过验证，且需要审批才可以进行变更；
内容总结
这篇文章要表达的如何在风险可控的情况下进行线上发布。
通过制定质量门禁，管好变更权限和发布窗口，通过测试报告（轮次小结）同步信息暴露风险，最后通过变更部署手册并评审通过，在可观测可验证有冗余手段的情况下进行线上发布变更，这样可以进一步控制发布风险，提高线上交付质量。
