如何建立变更管控流水线

星球有同学问了这样一个问题：研发过程中，事前变更管控流水线该怎么建设？

将这个问题进行拆解，可以得到三个重要的点：事前变更、变更管控、流水线建设。

其中事前变更属于研发过程计划内的操作，即可预料的变更。对变更进行管控的目的在于风险可控，而建设流水线的好处则在于将手工操作转化为机器自动执行，降低手动误操作带来的不可控风险。

下面的内容，我会结合自己的实践经验，就这三点分享一些我的思考。

事前变更

从软件工程的角度来说，一次软件版本迭代的生命周期，大致要经过需求-设计-编码-测试-运维-交付六个阶段，其中每个阶段的流转都涉及到大量的变更。比如：

• 编码：研发完成编码并自测通过，要将代码发布到开发环境进行联调。

• 测试：冒烟测试通过后，研发提测，将最新分支代码发布到测试环境。

• 线上发布：回归和验收测试通过，质量符合线上要求，运维同学线上发布。

上述几个环节，无一不涉及到变更。典型的有：DDL 表结构变更、环境参数配置变更、注册配置中心相关变更、数据库基础数据同步以及部分线上业务开关。

这些变更，都是软件研发交付过程中必要的操作，即可预料的事前变更。

但只要是变更，就可能会存在隐藏的风险，这些风险会对最终的交付质量产生重大的影响。因此各种研发规范和测试流程就应运而生，与之对应的则是每个环节都要进行的评审。

无论是研发规范和测试流程，还是各种评审，做这些动作的原因在于：每个人的工作习惯、技术栈、沟通方式都不同。

流程规范是为了将团队中不同的人划入同一个大的方向中，并告诉大家前进的目标以及关键的节点。评审是为了尽早的发现需求、方案、代码、用例中可能存在的风险，并及时处理。而测试的执行动作，更多的是检查代码实现的需求是否在各个方面符合预期的目标。

变更管控

据不完全数据统计，大部分线上问题，最直接的原因都是变更导致。变更并不是简单的代码发布，还包含配置变更/服务器变更/DDL 变更甚至业务活动的开关等变更，理论上所有变更都会对线上质量造成影响，因此变更管控很重要。

对变更进行管控的目的：一方面是通过不同的角色参与，从不同的角度进行 review，查漏补缺；另一方面通过 check 和审批的方式落实责任，这样才能提高团队所有成员对于变更的风险认知和质量保障意识。

在变更 review 和 double check 时候，需要变更申请人说明变更内容/影响范围/异常情况的解决方案等，这样即使变更出问题，也可以及时修复，将风险控制在合理范围内。

虽然说搞各种流程规范和管控会无形中增加管理和沟通成本，但在实际的工作场景中，我们不能把对线上质量的期望，放在团队每个人都具有高度的专业素养和极强的技术能力之上。

流程只是引导，在软件开发这种技术工程领域，强制的技术手段，严格的检查和完善的监控告警机制，可信度更胜于人的主观行动。

流水线建设

聊完了是事前变更和变更管控的目的，接下来聊聊变更管控流水线的建设思路。

1. 通过评审评估出变更范围，影响范围，及各种依赖项。

2. 针对变更范围和影响到的范围，梳理出用例集并全量验证。

3. 针对各项常见变更沉淀为变更手册，并将变更尽可能转变为自动执行。

4. 变更分级，重大变更审批，测试做好 double check，准备好可能的风险预案。

5. 风险预案需要通过验收，且执行变更时要有人值守，做好监控观测和应急响应。

6. 做好权限管理，细分到环境和变更操作类型(如禁止研发的线上发布权限，由 QA/运维或者专门的线上配置管理员进行发布变更操作)。

从我的角度来理解，变更管控和流水线建设都是预防机制，更进一步可以通过质量内建和测试左移右移来提升交付质量。

每个阶段都有风险，那就通过质量门禁在每个环节设定准入准出标准，降低风险流转到下一环节带来的影响。参与项目的每个人技术能力、工作习惯、理解能力各不相同，那就推动质量内建在团队中落地，通过流程规范和卡点确保工作在执行过程中的满足标准。

测试环境不稳定，设计和编码阶段存在风险，通过测试左移来推动单元测试、code review、分支管理更好的执行。打包部署线上发布存在不足，那就通过测试右移完善监控体系，制定线上巡检和防资损机制，主导复盘和持续迭代优化。

最终形成质量交付闭环。