项目情境：
1. 通用版本与客户化版本并存，对大多数中小客户发布和维护通用版本，基于通用版本针对大客户发布特定的版本。 与之相对应，有通用版本的开发和维护团队，也有特定大客户团队跟进和维护大客户的需求
2. 发布内容分为应用和平台，在应用层面基本部署实现了TA，continuous integration等敏捷基础设施和应用了典型的敏捷实践,TDD等，但在平台（基于third party IBM,HP,Redhat/Unix定制化的安装部署脚本,配置) 层面由于发布和测试成本的高昂，还是类似瀑布型的开发模式

软件版本管理主要的挑战：
1. 通用版本的开发和维护并行进行，并且有自己单独的发布，比如开发团队在1.0后为通用版本开发至2.0, 而维护团队在其间可能已经发布了1.1, 1.2...，现阶段，使用不同的分支来维护
2. 不同的客户化团队同时基于3.0也可能发布自己的release, e.g. 1.0_customer1, 1.0_customer2 ，仍然拥有各自的分支
3. 在应用部分和平台部分有不同的客户化分支结构，比如customer1 使用通用版本的平台，而cusomter2使用自己的平台

那么基于这种模式，在应用和平台极易出现树状的交叉引用，带来发布和维护的困难
对于维护而言，在客户版本分支或通用版本发现的任何bug，都可能存在相互影响，如通用版本发现的bug可能在每个客户分支上都需要merge，反之也一样，这样就会带来多倍的merging和回归测试

现在考虑应用以下策略来应对这个问题：
1. 平台和应用区分策略
1.1对平台规划为通用部分和可客户化部分，风险大测试成本高的部分必须包括在通用平台部分
对通用平台进行严格的分支创建管理和merge计划，因为平台内容回归测试成本高，计划制定周期化的merge和回归测试。
一来对测试需求尽量进行合并由一轮测试来进行覆盖
二来通过频繁的merge减少风险和确保通用部分的稳定
但缺点在于，每个团队都没有合并其他团队产品内容的动力，需要在部门层面投资，以及可能影响版本发布和客户响应速度
1.2 对经常可能变更和客户间差异巨大的可客户化部分，不强制merge,实行谁动谁负责的原则，部门层面只保证通用版本的稳定性，但对这部分的界定会有一定难度，不一定能划分的清楚。
1.3 对平台根据领域，网络，数据库，操作系统等分为不同的发布内容，单独进行开发和维护，使用label来进行稳定版本的标记。在发布前平台互相和与应用集成时，选取合适label来进行集成测试和发布

2）对应用开发部分，采取灵活的分支管理，在应用部分，由于有TA和CI的保证，质量风险和回归测试成本相对较低，允许各团队创建和维护自己的分支，但仍要求尽量减少分支数量，并选择合适的时机进行merge，但merge时要求必须实现TA，以控制回归测试的成本和对其他团队的影响，这点在周期紧的情况下难以做到，我的想法是没有TA，宁可不merge，否则后期的质量风险和回归测试工作量会非常大。

3）与版本管理相关的就是发布
现在的想法是最终的代码或内容merge到维护团队的分支上由维护团队按需进行发布，将来也由他们来进行维护，如果merge不了的一定要让维护团队充分理解和同意并具备维护能力。可以让维护团队来merge或者与开发团队一起merge，顺便实现交接还可review帮助质量。
但这里需要解决维护团队的工作量问题，维护团队可能成为瓶颈影响客户团队的发布，那末折中的办法是允许先发布再合并
尽量采取增量包发布的方式，减小发布前测试的工作量。

小弟的一点拙见仅为抛砖引玉，不知道各位有没有在类似的情景中工作或遇到类似的问题，欢迎大家feel free进行点评和指正，特别是考虑不周的地方。