刚刚过节回来，XY便找我讨论配置管理计划，我有点纳闷，节前不是已经讨论清楚了吗？

老大提了个新的设想，得到了很多人的拥护，所以原来的被推翻了。XY找纸画给我看，其实变化不是很多，只是基于现有的一些现状，老大又做了些调整。

原来的设想是，主干作为开发分支，存放的是新的需求变更和重大的缺陷，因而它是不稳定的，经过产品封版测试后，打出相对稳定的产品分支来，在产品分支上只做比较小的缺陷修改，针对该产品分支提出的重大的缺陷和变更将被推迟到新的主干版本上。
现在的设想是：主干是最新版本的产品分支（3.3)，在上面做缺陷处理，同时分出一个新的开发分支来（3.4dev），用来放置新的需求变更和重大的缺陷，在开发分支上的新的需求和变更开发完毕后，经过测试后，将差异的部分合并到主干上，然后标记出3.4产品版本来，同时打出新的开发分支（3.5dev）来，并找到上一个版本（3.3）打出一个新的产品分支来维护。

从配置管理员的角度，新的做法其实比旧的做法复杂了，并且新的做法存在一下几个缺点和局限。

1 由于开发分支长期不同步到主干上，所以合并的难度增大，主干上修改的缺陷极有可能和新的缺陷/变更发生冲突；
2 对开发分支的封版测试并不意味着新的产品版本的诞生，因而合并完毕后，还要进行更多遍的测试。
3 不太适合多个产品版本同时开发，
4 产品规划策略应该是尽量只维护最新的产品版本和开发版本，且这两个版本由一个团队来维护。

但是，当开发人员每天只面对的是一个产品版本的缺陷，并且需求变更少于缺陷的发生频率时，这又是比较合适的。目前的技术中心产品即是属于这种情况，在新的方法中，开发人员不用去同步日益发生的大量的缺陷到主干，这会让他们感觉到一种略带虚无的满足。

同领域建模的理论一样，配置计划没有对此之分，只有合适不合适一说。先推行之后再说吧。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1601081