由于互联网行业需求变化快、开发迭代周期短、上线频繁的现实状况决定了合理的软件配置管理策略对于软件质量保证、协作开发效率至关重要。
目前公司配置管理在策略上采用的是不稳定主干（unstable-trunk）模式，所有的项目都在同一主干上进行修改，在每周上线后并没有明确的stable分支版本，基本上是靠SCM人员手工拷贝代码来管理维护的。这就引起了很多问题：
1）、多个项目组开发人员都可能并发对同样代码进行修改，造成了严重的代码冲突问题。例如张三修改了a.java并上QA测试服务器，在QA测试过 程中，李四也对a.java进行修改并上QA，李四的代码覆盖了张三的代码。由于是SCM人员并不清楚代码冲突情况，这样张三和李四的代码上QA很容易相 互影响并很难查具体原因
2）、由于没有明确stable分支版本，导致上QA、上生产只能采用增量更新，上QA、上生产出问题后的代码回滚很麻烦，严重影响了测试、上线效率。对于生产环境运行的代码的具体版本并没有明确的管理，导致生产系统出问题后要排查问题也很难查。
3）、由于核心基础包没有与上层应用隔离，导致大家都会对核心包进行修改，修改后代码质量并没有有效控制。于是出现因为修改基础包影响整个系统功能等现象
类似的问题很多。要在新的项目实施及后期运营中避免类似问题的重现，至少要从如下几个方面来：
1）、分支管理策略：采用适当的分支管理策略来保证开发库、测试库、发布库的隔离
2）、适当引入每日编译、持续集成、Code Review等敏捷开发的最佳实践
3）、采用自动化脚本完成上QA、上生产的部署工作，避免人工失误
4）、对核心框架、后台应用、前端页面开发采用不同的配置管理策略
1、分支策略（Branching Strategy）
代码分支管理策略一般分为3种（参考Branching Strategy Questioned）
1）、不稳定主干策略（The unstable trunk strategy）
此种分支策略使用主干作为新功能开发主线，分支用作发布。此种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。 freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一 个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善， 而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。
此种分支管理策略比较适合诸如传统软件产品的开发模式，例如微软Windows开发，对于互联网开发不是很适合。已经在主干上集成的新功能，如果达不到里程碑的要求，稳定分支就不能创建，很有可能影响下一个发布的计划。还有一个问题就是bug修改必须在各个分支之间合并。
2）、稳定主干策略（The stable trunk）
此种分支策略使用主干作为稳定版的发布。主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新 功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的 发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能 够知道这次发布的文件范围了。
此种分支策略的缺点之一是如果某个开发分支因为功能比较复杂，或者应发布计划的要求而长期没有合并到主干上，很可能在最后合并的时候出现冲突。另外由于对于每一分支都要进行测试才能够合并到主干中，测试工作量较大。
3）、敏捷发布策略（The agile release strategy）
此种模式在采用敏捷开发模式（例如Scrum）的项目中广泛采用，这些项目有固定的迭代周期（例如Scrum中每个Sprint的两周时间），新的 功能开发都在Task branch(Feature branch)上进行，在接近迭代周期的发布阶段时候，新建Release branch来完成本迭代周期的发布，各Task branch(Feature branch)的功能merge到Release Branch中。在完成发布后，Release branch的功能merge到Trunk和尚在进行的Task branch中。
