团队当前情况
负责互联网产品的开发,发布更新较为频繁。
有固定的发布周期,同时也存在比较多的hotfix。
修改任务通常比较小,改动范围通常不大,时间通常较短。
不同的功能页面有不同的小组负责,耦合度相对较低。
团队目前没有采用分支策略,开发人员协商进行增量更新,出现错误的几率较高。
已使用微软TFS做为版本控制工具,可以更充分的挖掘使用TFS的分支功能。
我的初步实践
参考上述策略,结合当前团队的现状,我初步设计了下面的版本控制解决方案。
此方案已稳定主干策略为主结合了一些敏捷发布策略的思路,具体实施方案如下:
1、主干时刻处于稳定状态,随时可以发布。设专门人员对主干代码进行管理,普通开发人员只读。
2、为开发任务建立开发分支。常规的可以以小组为单位建立分支,较大的任务可以建立专门的分支。
3、在发布日,从主干复制一个测试分支,需要在本发布日发布的各开发分支向此测试分支合并。
4、对测试分支代码进行测试,出现bug在测试分支上更改,无误后发布。
5、测试分支代码发布后,合并入主干,并在主干上进行标记。
6、对紧急修复(Hotfix)的情况,可以从主干复制出测试分支,在测试分支上进行紧急修改,并在测试后发布,发布后同样将代码合并会主干,做标记。
7、 Hotfix仅限于可以很快解决的小问题,如果更改时间过长,则需采用常规方法完成。
8、如果在测试分支测试过程中需要hotfix工作,则在复制一个新的测试分支进行hotfix,测试后发布。然后同时合并入原测试分支和主干,并在主干上做标记。此过程未在上图中画出。
9、测试分支发布后,开发分支可以删除;测试分支合并入主干后,测试分支可以定期删除。
方案的优缺点
方案优点
1、解决了没有实施分支策略时,代码不能经常签入的问题。
2、主干代码始终处于稳定的状态随时可以发布,降低了风险。
3、可以基于一个完整的测试分支进行测试及发布,而不是以口口相传的方式增量更新。
方案缺点
1、建立分支、合并分支增加了工作量。考虑实际情况,以及版本控制工具的辅助,增加的工作量应该可以接受。
2、如果某些开发分支工期跨越多个发布周期,修改过于剧烈,合并分支时可能工作量较大。可以考虑分解任务,避免过大的任务出现。
3、在同一时间最好只有一个测试分支,因此建立测试分支的权限需要限制,除hotfix场景外应当避免。