互联网敏捷开发配置管理策略思考

希望尽早发布

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

2、配置管理策略

根据目前公司的实际情况，建议采用稳定主干策略为主（The stable trunk）。参考淘宝网最佳实践之ABS自动编译可以看到，淘宝也采用了类似的版本管理策略。

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

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的支持有很大的提升，大大简化了分支合并的难度，可以参考What’s New in Subversion 1.6?。