由于互联网行业需求变化快、开发迭代周期短、上线频繁的现实状况决定了合理的软件配置管理策略对于软件质量保证、协作开发效率至关重要。

目前公司配置管理在策略上采用的是不稳定主干模式，所有的项目都在同一主干上进行修改，在每周上线后并没有明确的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、分支策略

代码分支管理策略一般分为3种

1）不稳定主干策略

此种分支策略使用主干作为新功能开发主线，分支用作发布。此种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。 freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。

此种分支管理策略比较适合诸如传统软件产品的开发模式，例如微软Windows开发，对于互联网开发不是很适合。已经在主干上集成的新功能，如果达不到里程碑的要求，稳定分支就不能创建，很有可能影响下一个发布的计划。还有一个问题就是bug修改必须在各个分支之间合并。

2）稳定主干策略

此种分支策略使用主干作为稳定版的发布。主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。

这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。

此种分支策略的缺点之一是如果某个开发分支因为功能比较复杂，或者应发布计划的要求而长期没有合并到主干上，很可能在最后合并的时候出现冲突。另外由于对于每一分支都要进行测试才能够合并到主干中，测试工作量较大。

3）敏捷发布策略

此种模式在采用敏捷开发模式（例如Scrum）的项目中广泛采用，这些项目有固定的迭代周期（例如Scrum中每个Sprint的两周时间），新的功能开发都在Task branch(Feature branch)上进行，在接近迭代周期的发布阶段时候，新建Release branch来完成本迭代周期的发布，各Task branch(Feature branch)的功能merge到Release Branch中。在完成发布后，Release branch的功能merge到Trunk和尚在进行的Task branch中。

采用敏捷发布策略要求主干的版本：

1）任何时候都可以发布 ：在任何时候，产品所有者都可以基于主干的最新版本，发布新版本的产品

2）希望尽早发布

此种模式较适合敏捷开发软件的要求，但对程序员及SCM要求较高。

关于敏捷发布策略可以参考：多个敏捷团队之间的版本控制

2、配置管理策略根据目前公司的实际情况，建议采用稳定主

干策略为主。淘宝也采用了类似的版本管理策略。

具体操作策略如下（尚需要细化）：

1）trunk保持稳定，保证可以随时发布。trunk只有SCM人员才具有写权限，开发人员等只有读权限。

2）为降低SCM分支管理的压力，branch的权限可以授予给指定的几个组长

3）在每一个项目开始前，采用Branch per feature(Branch per Task)的分支管理模式（Common Branching Patterns ），由各组长或SCM人员按照branch管理规范建立对应项目的开发分支development branch，例如airline_product1_feature_leader_date、airline_product2_bug_leader_date。

项目定义：新功能开发、bug修复、需求变更等

4）在每周的上线发布后，在主干建立基线release版本（通过svn tag），以当前的主干作为基线，建立下一发布周期的test branch

5）开发人员在所在项目的development branch完成开发及集成测试后提交上线单，由SCM人员根据项目上线单的分支名称merge分支代码到本发布周期的test branch，进行测试。如果在测试过程中有新的上线单且有可能与其他上线单存在冲突，则在merge到test branch的过程中，SCM人员可以很容易及时排查问题。

只要对上线单命名按照规范进行定义（例如与分支名称相同），此部分工作可以由脚本来自动化，存在冲突再人工干预。

6）测试人员完成本发布周期test branch所有上线单的功能测试后，由SCM人员将本发布周期的test branch合并到trunk，并通过打tag来release 一个上线版本

7）系统人员利用自动化部署脚本从trunk检出对应的release版本进行上线部署

此部分工作采用自动化脚本完成，自动化脚本主要完成如下操作：从trunk检出完整的release 版本并打包，并包含部署包的md5验证码-> 上传部署包到生产系统各服务器->校验发布包的md5验证码是否正确,保证文件正确传输->完整备份生产系统的运行包->部署生产系统

8）每日晚上对trunk进行持续集成，保证能够正常编译和部署。工具建议采用hudson

9）对于核心代码及后台代码的修改，采用Pre-commit review模式，必须通过code review后，才能够提交到trunk中。工具可以采用reviewboard

10）其他一些值得讨论的问题

开发分支的生命周期问题 ：上线后，原有的development branch变为只读的或者可以定期删除掉。

紧急上线策略 ：紧急上线不遵循每周两次的上线周期，因此对于需要紧急上线的程序可以从trunk检出最近的release版本代码建立临时测试分支（test branch），紧急上线仍然需要按照规范建立对应的development branch，然后与临时测试分支合并，测试通过后上线，同时由SCM人员将紧急上线的development branch合并到当前的测试分支，继续进行测试。

不同项目的配置管理策略 ：对核心框架、后台应用、前端页面开发可以采用不同的配置管理策略，例如核心框架可以采用不稳定主干策略（The unstable trunk strategy）；后台应用采用稳定主干策略（The stable trunk ）

3、版本控制工具选择

SVN的集中管理模式较为适合目前公司协作开发的需要，例如SVN所提供的集中式权限控制，对代码、二进制文件及文档的集中管理，类似 TortoiseSVN的支持工具以及Eclipse 插件等。而Git/Mercurial（hg）的分布式管理特性，很适合开发人员本地版本开发管理。

因此可以结合SVN和Git/Mercurial（hg）来作为版本控制工具。用SVN进行集中管理，用Mercurial（hg）在多个不同机器上进行开发，功能完善并测试完成后再提交至 SVN Repository。可以借助git-svn、HgSubversion、hgsvn这样的工具来结合使用。考虑到目前的开发环境为Windows环境，建议采用Mercurial。

值得一提的是SVN从1.5版本开始，对branching merge的支持有很大的提升，大大简化了分支合并的难度。

4、一些工具

code review http://www.reviewboard.org/

持续集成 https://hudson.dev.java.net/

自动部署 http://www.smartfrog.org/ http://www.capify.org

商业软件中采用atlassian的系列产品倒是不错的选择：Jira+Crucible+FishEye+Bamboo