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

1、互联网敏捷开发配置管理策略思考山于耳联网行业需求变化快、开发迭代周期短、上线频繁的现实状况决定了合理的软件 配置管理策略对于软件质量保证、协作开发效率至关重要。目前公司配置管理在策略上采用的是不稳定主干（unstable trunk）模式，所有的项目 都在同一主干上进行修改，在每周上线后并没有明确的stable分支版木，基木上是靠scm 人员手工拷贝代码來管理维护的。这就引起了很多问题：1）、多个项ii组开发人员都可能并发对同样代码进行修改，造成了严重的代码冲突问题。 例如张三修改了 a.java并上qa测试服务器，在qa测试过程中，李四也对a.java进行修 改并上qa,李四的代码覆盖了张三

2、的代码。由于是scm人员并不清楚代码冲突情况，这 样张三和李四的代码上qa很容易相互影响并很难查具体原因2）、由于没有明确stable分支版本，导致上qa、上牛产只能采用增量更新，上qa、 上牛产出问题后的代码回滚很麻烦，严巫影响门则试、上线效率。对丁牛产环境运行的代码 的具体版本并没有明确的管理，导致牛产系统出问题后要排查问题也很难查。3）、巾丁核心基础包没有与上层应用隔离，导致大家都会对核心包进行修改，修改后代 码质量并没有有效控制。于是出现因为修改基础包影响整个系统功能等现象类似的问题很多。要在新的项忖实施及后期运营中避免类似问题的重现，至少耍从如下几 个方面来：1）、分支管理策略：采川

3、适当的分支管理策略來保证开发库、测试库、发布库的隔离2）、适当引入每日编译、持续集成、code review等敏捷开发的最佳实践3）、采用口动化脚本完成上qa、上生产的部署工作，避免人工失误4) 、对核心框架、后台应用、询端页而开发采用不同的配置管理策略1、分支策略(branching strategy)代码分支管理策略一般分为3种(参考branching strategy questioned)1) 、不稳定主干策略(the unstable trunk strategy)isolated developme ntrelease branchapp 1.0.0app 1.0.1trunk此种

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

5、分支管理策略比较适合诸如传统软件产品的开发模式，例如微软windows开发，对 于互联网开发不是很适合。已经在主十上集成的新功能，如果达不到里程碑的要求，稳定分 支就不能创建，很有口j能影响下一个发布的计划。还有一个问题就是bug修改必须在各个 分支之间合并。2) 、稳定主干策略(the stable trunk)此种分支策略使川主干作为稳定版的发布。主干上永远是稳定版本，可以随时发布。bug 的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支, 完金分离。而对主干上的每-次发布都做-个标签而不是分支。分支上的开发和测试完毕以 后才合并到主干。这种发布方法的好处是

6、每次发如的内容调整起來比较容易。如果某个新功能或者bug在 下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，侮 个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之 前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范fflto 此种分支策略的缺点z是如果某个开发分支因为功能比较复杂，或者应发布计划的要求而长期没有合并到主干上，很可能在最后合并的时候出现冲突。另外由于对于每一分支都 要进行测试才能够合并到主干中，测试工作量较大。3) 、敏捷发布策略(the agile release strategy)此种模式在采用

7、敏捷开发模式(例如scrum)的项目中广泛采用，这些项目有固定的迭 代周期(例如scrum屮每个sprint的两周时间)，新的功能开发都在task branch(feature branch)±进行，在接近迭代周期的发布阶段时候，新建release branch來完成本迭代周 期的发布，各 task branch(feature branch)的功能 merge 到 release branch 屮。在完 成发布后,release branch的功能merge到trunk和尚在进行的task branch中。采用敏捷发布策略要求主干的版本：o任何时候都町以发布：在任何时候，产品所有者

8、都口j以基于主干的最新版本，发布 新版本的产品o希望尽早发布此种模式较适合敏捷开发软件的要求，但对程序员及scm要求较高。关于敏捷发布策略可以参考：多个敏捷团队之间的版木控制2、配置管理策略根据目前公司的实际情况,建议采用稳定主干策略为主（the stable trunk）。参考淘 宝网最佳实践之abs h动编译可以看到，淘宝也采用了类似的版本管理策略。具体操作策略如下（尚需要细化）:1 ）、trunk保持稳定，保证可以随吋发布。trunk只有scm人员才具有写权限，开发 人员等只有读权限。2）、为降低scm分支管理的压力，branch的权限可以授予给指定的儿个组长3）、在每一个项目开始前,采

9、用branch per feature（branch pertask）tl'j分支管理模 式（common branching patterns）,由各组长或scm人员按照branch管理规范建立 对应项口的开发分支development branch,例如airline_productl_featureeader_date、airline_product2_bug_leader_date。项目定义：新功能开发、bug修复、需求变更等4）、在每周的上线发布后，在主干建立基线release版本（通过svn tag）,以当前的 主干作为基线，建立下一发布周期的test branch5）、开

10、发人员在所在项目的development branch完成开发及集成测试肩提交上线单, 由scm人员根据项廿上线单的分支名称merge分支代码到木发布周期的test branch,进 行测试。如果在测试过程中有新的匕线单且有对能与其他匕线单存在冲突，则re merge到 test branch的过程中，scm人员可以很容易及时排查问题。只要对上线单命名按照规范进行定义（例如与分支名称相同），此部分工作可以由脚 本來向动化，存在冲突再人工干预。6）、测试人员完成本发布周期test branch所有上线单的功能测试后，rtl scm人员将本发布周期的test branch合并到trunk,并通过打

11、tag来release 一个上线版本7）、系统人员利用白动化部署脚本从trunk检出对应的release版木进行上线部署此部分工作采用自动化脚木完成，白动化脚木主要完成如下操作：从trunk检出完整的 release版木并打包，并包含部署包的md5验证码-> 上传部署包到牛产系统各服务器- 校验发布包的md5验证码是否正确，保证文件正确传输-完整备份生产系统的运行包-> 部 署生产系统8）、每口晩上对trunk进行持续集成，保证能够正常编译和部署。工具建议采川hudson9）、对于核心代码及后台代码的修改，采用pre-commit review模式，必须通过code review后

12、，才能够提交到trunk中。工具可以采用reviewboard10）、其他一些值得讨论的问题开发分支的生命周期问题：上线后，原有的development branch变为只读的或者町以 定期删除掉。紧急上线策略：紧急上线不遵循每周两次的上线周期，因此对于需要紧急上线的程序可 以从trunk检出最近的release版本代码建立临时测试分支（test branch）,紧急上线仍 然需要按照规范建立对应的development branch,然后与临时测试分支合并，测试通过 后上线,同时由scm人员将紧急上线的development branch合并到当前的测试分支,继 续进行测试。不同项目的配置管

13、理策略：对核心框架、后台应用、前端页血开发对以采用不同的配置 管理策略,例如核心框架可以采用不稳定主干策略(the unstable trunk strategy)；后 台应用采用稳定主干策略(the stable trunk)3、版本控制工具选择svn的集中管理模式较为适合tl前公司协作开发的盂耍，例如svn所提供的集中式权限 控制，对代码、二进制文件及文档的集中管理，类似tortoisesvn的支持工具以及eclipse 插件等。而cit/mercurial (hg)的分布式管理特性，很适合开发人员木地版本开发管理。因此可以结合svn和git/mercurial(hg)来作为版木控制工具。

14、用svn进行集中管理, 用mercurial (hg)在多个不同机器上进行开发，功能完善并测试完成后再提交至svn repository。可以借助git-svn、hgsubversion hgsvn这样的工具来结合使用。考虑到 廿前的开发环境为windows环境，建议采用mercurial值得-提的是svn从1.5版本开始，对branching merge的支持有很大的提升，大大 简化了分支合并的难度，可以参考what's new in subversion 1.6?。4、一些工具code review/持续集成https:/huds

15、on. dev.java. net/自动部署/商业软件中采川atlassian的系列产品倒是不错的选择:jira+crucible + fisheye+bamboo5、参考文档http:/www. prog .c n/3223/http:/sv nbook.red-bea n/1.5/sv n-book.html#sv n.bra m on patter ns.featurehttp:/marti nfo nch.html 3/bra nchi ng-strategies.htm ihttp:/msdn.microsoft.eom/e n-us/library/bb66895 5.aspxhttp: