2012-06-25 18:21:54 iteye_14109 阅读数 316

     软件开发方法一直处在不断发展过程中。在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。那么,敏捷开发有什么好处呢?

 

    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业中,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然,其最大的推动力是采用这种方法所能带来的受益。相关统计表明,敏捷开发可以将效率提高3~10倍,软件的质量也有更加可靠的保证; 同时,还给团队内的每个成员提供了良好的发展机会,技术和合作水平都能得到相应提高。当然,敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。
 
    敏捷开发由几种轻量级的软件开发方法组成,包括极限编程、Scrum、精益开发(Lean Development)、动态系统开发方法、特征驱动开发(Feature Driver Development)、水晶开发(Cristal Clear)等等。所有这些方法都具有以下共同特征,它们也是敏捷开发的原则:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期持续的时间一般较短,通常为1到6周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。有些是在每个迭代周期结束的时候集成, 有些则每天都在这么做。

    5. 开发团队自我管理。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。
 
    敏捷开发的优势:

    满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异,但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。
 
    敏捷开发方式能给企业和用户带来以下好处:

    1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。

    2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

    3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。

    4. 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。

    5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
 
    主要的敏捷方法:

    敏捷开发方法是一组开发方法的统称,主要包括以下几种:

    极限编程其主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致,结对编程(pair-programming)就是其中比较知名的方法之一。除此之外, 其核心做法还有小规模、频繁的版本发布、短迭代周期、测试驱动开发、持续集成、每日站立会议、共同拥有代码、系统隐喻等。

    Scrum Scrum是一个敏捷开发框架,它由一个开发过程、几种角色以及一套规范的实施方法组成。在Scrum中,产品需求被定义为产品需求积压(product backlogs)。所有的产品需求积压都是从一个简单的想法开始,并逐步被细化,直到可以被开发的程度。Scrum将开发过程分为多个Sprint周期,每个Sprint代表一个2~4周的开发周期,有固定的时间长度。

    精益开发精益开发的核心思想是查明和消除浪费。在软件开发过程中bug、没用的功能、等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明,然后设法消除。精益开发的其他原则包括强调学习、在最后时刻做决定、用最快的速度交付用户等。

    其他敏捷方法还包括动态系统开发方法(DSDM)、特征驱动开发(FDD)、Crystal Clear等,各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷开发,并且了解更多的最佳应用。
 
 
如何选择一种敏捷方法:

    选择一种合适的软件开发方法取决于多种因素。在做出决定之前,我们需要充分考虑以下这些方面:

    1. 方法的复杂度。确保你的团队或组织能够应付这种复杂度。

    2. 社区和业界支持。有较多的社区及行业支持可以使你受益匪浅。

    3. 实用工具。一个良好的软件工具可以帮助团队有效地处理日常工作,促进团队协作,并减少管理成本。

    4. 对敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

    5. 你的团队规模。较小规模的团队最好从简单的方式入手。

    6. 你不需要只遵从一种方法。你可以为团队选择一个主要的方法(如Scrum),然后借鉴其他方法。

 

2011-06-20 17:05:54 john521 阅读数 47

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

    目前公司配置管理在策略上采用的是不稳定主干(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)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

   此种分支策略使用主干作为新功能开发主线,分支用作发布。此种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。 freebsd的主干永远是current,也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定,达到一个发布的里程碑以后,从主干分出来一 个stable分支。freebsd是每个大版本一个分支。也就是说4.x,5.x,6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善, 而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后,就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。
   此种分支管理策略比较适合诸如传统软件产品的开发模式,例如微软Windows开发,对于互联网开发不是很适合。已经在主干上集成的新功能,如果达不到里 程碑的要求,稳定分支就不能创建,很有可能影响下一个发布的计划。还有一个问题就是bug修改必须在各个分支之间合并。

  2)、稳定主干策略(The stable trunk)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

    此种分支策略使用主干作为稳定版的发布。主干上永远是稳定版本,可以随时发布。bug的修改和新功能的增加,全部在分支上进行。而且每个bug和新功能都 有不同的开发分支,完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
    这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成,就不可能合并到主干,也就不会影响其他变更的 发布。另外,每个分支的生命期比较短,唯一长期存在的就是主干,这样每次合并的风险很小。每次发布之前,只要比较主干上的最新版本和上一次发布的版本就能 够知道这次发布的文件范围了。
   此种分支策略的缺点之一是如果某个开发分支因为功能比较复杂,或者应发布计划的要求而长期没有合并到主干上,很可能在最后合并的时候出现冲突。另外由于对于每一分支都要进行测试才能够合并到主干中,测试工作量较大。

  3)、敏捷发布策略(The agile release strategy)

subversion,git,Mercurial,配置管理,敏捷开发,分支,branching strategy

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

    采用敏捷发布策略要求主干的版本:
  • 任何时候都可以发布 :在任何时候,产品所有者都可以基于主干的最新版本,发布新版本的产品
  • 希望尽早发布

  此种模式较适合敏捷开发软件的要求,但对程序员及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?

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

 

5、参考文档

  http://www.programmer.com.cn/3223/

  http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.commonpatterns.feature

  http://martinfowler.com/bliki/FeatureBranch.html

  http://codicesoftware.blogspot.com/2010/03/branching-strategies.html

  http://msdn.microsoft.com/en-us/library/bb668955.aspx

  http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

  http://www.cmcrossroads.com/bradapp/acme/branching/

  http://www.vance.com/steve/perforce/Branching_Strategies.html

  http://blog.gravityfree.ca/2009/02/using-feature-branches.html

  http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

  http://thinkernel.bokee.com/4518935.html

  http://www.infoq.com/cn/articles/agile-version-control

2012-05-21 11:46:00 Eileenym 阅读数 26

    由于互联网行业需求变化快、开发迭代周期短、上线频繁的现实状况决定了合理的软件配置管理策略对于软件质量保证、协作开发效率至关重要。
    目前公司配置管理在策略上采用的是不稳定主干(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中。
    采用敏捷发布策略要求主干的版本:
o 任何时候都可以发布 :在任何时候,产品所有者都可以基于主干的最新版本,发布新版本的产品
o 希望尽早发布
  此种模式较适合敏捷开发软件的要求,但对程序员及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)

 

2017-05-12 14:11:14 tianbaochao 阅读数 1561

http://blog.sina.com.cn/s/blog_74bd788f0101aohh.html

 

在敏捷开发中,单一主干代码管理经常被提及,那为什么要采用单一主干代码管理?单一主干代码管理带来哪些好处?如何做到持续发布新功能并定期稳定的可商用的版本?

         为什么采用单一主干代码管理?

在敏捷研发中的代码管理控制时,我们需要牢记两点[1]

首先,只有频繁提交代码,你才能享受版本控制带来的众多好处,比如及时回滚到最近的无错误版本。

其次,一旦将变更提交到版本控制中,那么团队的所有人都能看到这些变更。由于提交意味着公开,无论修改了什么,都要确保它不会破坏原有的系统,所有每一位开发人员必须谨慎的对待其提交可能带来的影响。

如果在版本控制系统中为新功能建立单独的分支,到某个时间点后,当这些修改内容的质量令人满意了,再将其合并到主干,这个类似“两阶段提交”。这种方式存在以下问题

1.       它违背了持续集成的宗旨,因为新建分支的做法推迟了新功能的整合,只有当该分支被合并时才可能发现集成问题。

2.       如果多个开发者同事分别创建多个分支,问题会成指数增加,而合并过程也会及其负责。

3.       它让重构代码变得非常困难,因为分支往往涉及多个文件,会让合并变得更加困难。

 

         单一主干代码管理带来的好处?

在代码管理时,如果单一主干代码管理,可以给开发团队带来如下的好处。

1.       确保所有的代码被持续集成,只有单一主干才能使得所有开发人员的代码被持续集成。

2.       确保开发人员及时获得他人代码,将开发人员间的影响及时暴露,减少由于沟通不及时带来的隐性问题。

3.       避免项目后期的“合并地狱”和“集成地狱”。

 

这样的做法可以让开发人员花更多的时间在架构设计和代码优化上,而不是从事代码合并工作。

 

 

         单一代码管理在已上线软件中存在的问题

那如何在单一主干代码做到持续集成新功能或优化代码,修复现网版本的bug及定期上线最新的商用版本?

         在实际开发工作中,单一主干的代码管理在项目新建立期间问题不太大,但是如果项目进入到维护期时,容易引入如下问题,

A. 紧急修复的即时性和版本开发的周期性的矛盾。

B. 版本连续开发中,开发和测试存在时间差,导致无法快速发布稳定的可商用的版本。

敏捷开发代码管理规则:为什么要采用单一主干代码管理?如何做到单一主干代码管理?
 

图1 研发过程中代码管理的状况

如图1所示,当我们在T0发布现网的版本后,开发人员每天checkin开发的最新代码,但每天开发的代码未必完全能够完成整个用户故事。如果在Tn开始下一版本的预发布,则测试团队在Tn时刻开始测试会遇到如下几种情况

1.       在Tn之前还存在一些没有解决的Bug

2.       在Tn之前还存在没有完全开发完成新的用户故事

3.       测试人员在Tn上的版本进行测试,会测试出一些新的bug

在这种情况下,开发人员会不断的checkin新代码,fix bug和完成新的用户故事,同时新checkin的代码可能产生新的bug,这样不断的循环,会导致生成一个稳定的版本变得十分困难而且非常耗时,一般会做法会采用如下方法,

1.       在Tn时刻确保所有的功能已经被开发完成,如果有没有开发完成的功能,所有开发人员等待剩余新功能的开发人员完成工作,完成后再开始测试工作。在测试中一般会采用以下两种方法,

a)         方法一,在Tn时刻为release版本分出分支,测试和研发基于生产的版本分支进行测试和代码开发。

b)         方法二,在Tn时刻不为release版本生产分支,所有开发人员停止新功能的研发工作,只完成测试人员测试出来的bug,此过程直到QA通过版本发布为止。

可以通过对以上两种方式分析,存在无法单一主干管理或者导致开发人员无法持续研发新的功能的问题,如果采用方法一还可能导致版本合并的问题。

 

如何能做到单一代码管理并不影响持续的新功能开发和软件发布?

         综上,在敏捷研发过程中,采用单一主干代码管理必须辅助一些规则,才能实现上面提到的矛盾。通过分析主要矛盾集中在持续的开发新功能和定期发布版本的矛盾,而且bug fix是属于小范围改动应该在于可控范围内,所制定规则如下,        

1.       新功能开发流程:增加一个打开状态的开关,此开关可以通过developing和developed两个标志来区分研发中,测试中和发布的状况,具体规则如下,

a)       研发状态:研发人员在开发新功能时,需要根据开发进度设置新功能块的状态,例:当新功能处于开发状态时,需要将此功能块设置成developing(开发中)状态。

b)       测试状态:当开发人员开发完毕,并完成本地测试没问题之后,将此功能块从developing状态改变成developed(开发完成)状态,交由测试人员对新功能进行测试。

c)       发布状态:当新功能测试完毕之后,由产品经理和功能负责人一起决定是否发布此功能,如果决定发布,将developed标识从功能模块中去掉,并通过团队评审,进入主干代码。


敏捷开发代码管理规则:为什么要采用单一主干代码管理?如何做到单一主干代码管理?
 

图2新功能研发代码管理规则

2.       定期发布稳定版本流程:

a)       开始测试预发布版本

1.       当从Tn时刻开始测试即将发布的版本时,通知所有研发人员,从这个时刻起停止所有新功能的状态变更,但是可以继续研发代码,并每天按照平时一样checkin 代码。

2.       所有的bug fix必须保证全部修复完成后才能checkin 代码(bug一般都能在1-2个工作日内完成修改)

b)       测试中:从Tn这个版本测试出来的问题,研发人员马上进行修复,并checkin到主干代码中,每天测试人员从库里取出编译出的最新版本进行测试(因为新模块的研发通过开关进行了控制,所以新模块的研发代码不会对软件质量造成影响),通过这个机制可以确保每天的代码是高于前一天的代码质量。

c)       完成测试,达到发布标志:当在T(n+m)时刻,如果软件质量达到发布要求,则在此版本号上打上发布版本的Tag,并通知所有开发人员可以重新开启修改developing和developed标志,使新的功能在产品中生效。

 

3.       紧急修复现网运营版本的Bug

a)       当系统上报bug后,首先需要对bug进行分析并进行归类,如果不会导致业务无法使用或者crash的bug,则作为一般的日常问题进入产品bug库,尽量不要对现网运营系统进行打补丁。

b)       如果发现了导致业务无法使用或者crash的bug,则找到现网的release版本,并在代码管理库此版本上拉出分支,并在此分支上进行bug fix,解决完成后,将相关代码立即合并会主干代码。

        通过以上规则处理,我们在实际敏捷研发中,在代码库规则中整体展现如下图所示

敏捷开发代码管理规则:为什么要采用单一主干代码管理?如何做到单一主干代码管理?
 

图3 建议的敏捷研发代码管理规则

相关其他工作

                  此处需要CM进行配合,才能很好的完成测试,研发和产品发布之间的配合,具体规则如下图所示:

敏捷开发代码管理规则:为什么要采用单一主干代码管理?如何做到单一主干代码管理?
 

图4 代码配置规则

           本文提到的代码状态规则需要根据不同的项目和编程语言设计方案,我们在Android和iOS系统研发下采用了if(){…} else{…}语句进行实现,在struts框架下研发采用返回不同的状态进行控制实现,其他项目的实际控制方法建议根据实现情况进行调整。

 


[1] Continuous Delivery –Reliable Software Releases Through Build,Test,and Deployment Automation [eng] Jez Humble, David Farley

 

2017-02-25 12:09:06 u011790275 阅读数 839

2017.2.25, Ken Fang, 深圳

问:
给团队讲敏捷要固定节奏,PI 要固定,做不完的需求放到下个 PI,本 PI 做总结和回顾。他们问到一个操作问题:迭代开发的 Story 已经合入主干了,如果 SIT 后发现达不到可商用的质量标准,Story 的代码要从主干摘出成本又很高,这时怎么办?

答:
Story 已合入主干的代码,除非是在集成测试时发现严重缺陷, 才需从主干移除, 否则是没任何理由需从主干移除的。
所谓商用的标准, 往往应该只的是从测试人员的角度,测试人员认为某特性有场景遗漏, 所以, 测试人员认为不应发布。所以, 根本的问题, 不是 PI 结奏固定, 而是发布出去,客户投诉后,测试要担责。
所以,测试人员ㄧ定要走到产品经理那, 走到市场, 去真正理解客户、真正理解客户的业务,如此,测试人员才有能力判断出那些场景的遗漏是属于重大的缺陷,才需要求将已上主干的 Story 代码,移除主干。
PI 节奏要固定;6-8 周,甚至更短;主要的用意是唯有 PI 节奏固定了,团队才能持续改善;持续改善发布的周期与质量。
PI 节奏不固定, 等于是开了个后门, 让团队是去证明自己没做错事罢了。

问:
很多产品的架构没那么灵活,当 Story 合入主干后发现有重大缺陷,而代码从主干移除的效率又很低,这时团队首先会选择延迟 PI 的结束时间。这样做就失去了 PI 周期的意义。请问有什么措施可以提升移除的效率呢?
答:
有三个建议:
1.应该由产品 经理,测试经理,SPO 共同决策,产品是否有重大缺陷到影响到整个产品都没法发布?
2. 确定是那些缺陷是真的影响到使整个产品没法发布, SPO 必需要带领团队在 PI 结束前修复。
3. 虽然架构不好,但还是建议试着将会产生重大缺陷的代码移除;因为,还是会有些 Story 相对是比较独立的。
代码移除没什么高效率的作法;只有一步一脚印去做
所以,开发、测试人员协作,做好每日目标管理。测试人员要真正了解业务。产品经理,测试经理,SPO 共同决策;是很重要的核心、基础。

主干测试总流程

阅读数 535

没有更多推荐了,返回首页