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

互联网敏捷开发配置管理策略思考互联网敏捷开发配置管理策略思考 由于互联网行业需求变化快、开发迭代周期短、上线频繁的现实状况决定了合理的软件 配置管理策略对于软件质量保证、协作开发效率至关重要。 目前公司配置管理在策略上采用的是不稳定主干（unstableunstable trunktrunk）模式，所有的项目 都在同一主干上进行修改，在每周上线后并没有明确的 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 1、分支策略（、分支策略（BranchingBranching StrategyStrategy） 代码分支管理策略一般分为 3 种（参考 Branching Strategy Questioned） 1 1）、不稳定主干策略（）、不稳定主干策略（TheThe unstableunstable trunktrunk strategystrategy） 此种分支策略使用主干作为新功能开发主线，分支用作发布。此种分支管理策略被广泛 的应用于开源项目。比如 freebsd 的发布就是一个典型的例子。freebsd 的主干永远是 current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个 发布的里程碑以后，从主干分出来一个 stable 分支。freebsd 是每个大版本一个分支。也 就是说 4.x，5.x，6,x 各一个分支。每个发布分支上只有 bug 修改和现有功能的完善， 而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定 程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个 release 分支。 此种分支管理策略比较适合诸如传统软件产品的开发模式，例如微软 Windows 开发， 对于互联网开发不是很适合。已经在主干上集成的新功能，如果达不到里程碑的要求，稳 定分支就不能创建，很有可能影响下一个发布的计划。还有一个问题就是 bug 修改必须在 各个分支之间合并。 2 2）、稳定主干策略（）、稳定主干策略（TheThe stablestable trunktrunk） 此种分支策略使用主干作为稳定版的发布。主干上永远是稳定版本，可以随时发布。 bug 的修改和新功能的增加，全部在分支上进行。而且每个 bug 和新功能都有不同的开发 分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测 试完毕以后才合并到主干。 这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者 bug 在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外， 每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发 布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围 了。 此种分支策略的缺点之一是如果某个开发分支因为功能比较复杂，或者应发布计划的要 求而长期没有合并到主干上，很可能在最后合并的时候出现冲突。另外由于对于每一分支 都要进行测试才能够合并到主干中，测试工作量较大。 3 3）、敏捷发布策略（）、敏捷发布策略（TheThe agileagile releaserelease strategystrategy） 此种模式在采用敏捷开发模式（例如 Scrum）的项目中广泛采用，这些项目有固定的 迭代周期（例如 Scrum 中每个 Sprint 的两周时间），新的功能开发都在 Task branch(Feature branch)上进行，在接近迭代周期的发布阶段时候，新建 Release branch 来完成本迭代周期的发布，各 Task branch(Feature branch)的功能 merge 到 Release Branch 中。在完成发布后，Release branch 的功能 merge 到 Trunk 和尚在进 行的 Task branch 中。 采用敏捷发布策略要求主干的版本：采用敏捷发布策略要求主干的版本： o任何时候都可以发布 ：在任何时候，产品所有者都可以基于主干的最新版本，发 布新版本的产品 o希望尽早发布 此种模式较适合敏捷开发软件的要求，但对程序员及 SCM 要求较高。 关于敏捷发布策略可以参考：多个敏捷团队之间的版本控制 2 2、配置管理策略、配置管理策略 根据目前公司的实际情况，建议采用稳定主干策略为主（TheThe stablestable trunktrunk）。参考淘 宝网最佳实践之 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）；后 台应用采用稳定主干策略（TheThe stablestable trunktrunk） 3 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 的支持有很大的提升，大大 简化了分支合并的难度，可以参考 Whats New in Subversion 1.6?。 4 4、一些工具、一些工具 code review / 持续集成 / 自动部署 / 商业软件中采用 atlassian 的系列产品倒是不错的选择： Jira+Crucible+FishEye+Bamboo 5 5、参考文档、参考文档 /3223/ /en/1.5/svn- book.html#monpatterns.feature /bliki/FeatureBranch.html /2010/03/branching-strategies.html /en-us/library/bb668955.aspx /en-us/library/aa730834(VS.80).aspx /bradapp/acme/branching/ http:/ww