文/秋之川
第二十七章 如何结束代码混乱的时代？
当我们开始进行新需求测试的时候，线上突然发现一个很严重的问题，需要立即修复，然后发布。找开发讨论测试范围的时候，得知需要做很多额外的回归测试，问其原因，才得知他们起初并没有分支的概念，都是在一个代码主干里去开发的，现在要单独发布一个修复补丁，可能会包含很多未经测试的新代码，甚至于未完成的代码。
这是何等混乱的一种情况，在这种情况下，怎么才能保证版本质量呢？如果靠人山人海的回归测试肯定是不现实的，且不说人力成本的问题，那始终无法明确边界的回归测试就是一个很大的风险，谁也不能保证测试的充分性。
版本管理是唯一的根本性解决方案，这是很多刚刚转做测试项目管理的人容易忽略的一个解决途径，因为下意识里会把代码的管理划到开发管理的范畴里，其实它也是质量管理里的一个重要环节。
我们先来看一下版本管理的几个组成部分吧：
命名规则
提测包目录
发布包目录
Bug和包的关系
规范了版本包，接下来还需要根据产品的发布特性梳理整个项目期间的版本发包规则：
- 所有的代码都 Checkin 到主 Trunk 1.0；
- 开发到提测时间节点时，打一个 Tag 0.9；
- 基于 Tag 1.0 构建一个 Test Build 1.0；
- 根据约定好的构建节奏，持续构建 TB 1.1，TB1.2，TB1.3...用于功能验证测试；
- 验证测试完成之后，当 P40 和 P30 bug 数量衰减到0的时候，打一个 Tag 1.6；
- 基于 Tag 1.6 开一个 Branch 1.0，用于这次的验收发布验证或灰度发布；
- 在这个 Branch 1.0 的测试过程中，有任何代码的改动，都需要同步 merge 回主 Trunk 1.0；
- Branch 1.0 开出来之后，下个版本的新代码就可以开始 checkin 到 Trunk 1.0 了；
- 在下个版本的开发过程中，如果有现网紧急修复，就可以基于 Branch 1.0 去打分支进行补丁版本发布了；
版本发布流程
《告诉你如何从执行测试到管理测试》带你迈出第（27）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
