版本控制之道

一说版本控制，就会思索着是不是来大谈svn git或者是branch model。

然而这些东西似乎已经被业界说烂了。网上几乎随处可见这些如何切分支的文章。而我们通常忽略的是为什么这么做，以及如何在一定的原则下去做，从而最大化的获得配置上和执行上的自由度。

现在社会，再谈版本就不再是过去我们从开发的角度来谈的版本了。而是说，这个软件产品对于用户来说的版本。过去我们会说这个产品在alpha或者beta，上线以后叫大版本就是几代几代之类的，小版本就是大版本的补丁了，会有固定的小版本号。

这些再对应入我们产品开发团队所对应的大小版本的发布周期以及发布计划。

为此我们给出一部分执行管理的原则，来帮助最大化减小发布错误的损失和风险。

1. 大版本号，一定来自于产品团队对于商业发布的明确定义，需要定义清楚为什么那天发布，发布内容有什么商业意义。测试和开发团队需要商量此次的发布需要的测试以及质量指标。产品以及市场也要为此定义明确的验收指标。例如，产品的上线前必须完成80-90%的单元测试条件覆盖率。不允许有超过10个的critical缺陷。开发对于代码质量在交付给产品验收之前，需要完成代码扫描，不得超过多大的threshold就是门槛阈值。

2. 小版本号，理论上说，开发提交的每一个变更号对应的就是一个明确的版本编号。这个版本编号就是我们的小版本号。也需要明确的需求说明，改动影响说明。

3. 小版本号还可以细分，哪些是专门针对新需求的，哪些是专门针对线上紧急修复的，还有一部分是内部重构更新的。这些都要能有有全面的体现。

当理解这些基本客户诉求产生的原则后，我们需要考虑的就是如何给与足够的控制。通常这些我们是习惯于交给集成或者发布的专员进行的，但是过去这么做就无形中加大了许多集成和发布专员的劳动力，导致他们做了许多重复无用的劳动。为了减少这些无用的劳动，我们需要做如下调整

1. 需求的提交由开发者自行维护自己需求的分支

2. 缺陷的修复由集成或测试统一开具分支，当结束一个修复周期后进行合并。

3. 大版本的上线由集成开具分支，并在对应的确切日期时间点进行切分支操作

4. 所有分支在合并时，必须提交pull request指令等待专人审核后方可合并

5. 缺陷，需求，重构等分支都要有明确的编号，便于快速识别。例如，缺陷修复版本bugfix，需求版本req，重构版本refactor等等。可以在具体的commit消息中严格规定。

6. 内部发布给具体的测试服务器需要有明确的服务器发布版本的管理列表，例如，测试机01，目前版本bugfix009，测试预生产机01，目前版本req010。这样测试或者产品人员在验收时可以明确知道自己要测试的机器是否有自己所需要的版本的产品被部署了。

7. 软件产品也应该在特定位置有明确标注当前最新的版本号。例如，大版本号，001，小版本号，req001。这样，万一我们没有及时找到版本列表，也可以最快的通过软件本身发现版本号。

如何执行，这个环节我们都知道知易行难。无数人无数组织倒在了开始行进的道路口，因为无从下手。我们的建议是

• 明确哪些人，对哪些版本负责

• 明确哪些版本需要做什么级别的测试

• 明确发布各类不同需要的版本，大致的周期

• 版本号规则的命名

• 定义并且阶段调整版本计划。周知计划。

• 建立版本的持续集成机制

• 所有发布的历史需要有罗列