敏捷开发下的版本管理

作者:抹茶小嗨 来源:站长网整理 2017-11-07 10:28:54 0 0

如何提高敏捷开发环境下开发和测试效率?

离不开好的版本管理方法。

第一步,设计好的版本管理模型

1. Master

顾名思义,既然名字叫Master,那么该分支就是主分支的意思。master分支永远是production-ready的状态,即稳定可产品化发布的状态。

2. Develop

开发分支,我们平常开发的一个主要分支了,不管是要做新的feature还是需要做bug fix,都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本,即完成了某个feature或者修复了某个bug后的开发稳定版本。

3. Feature branches

功能分支。这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当我在一个大的develop的迭代之下,往往我们会把每一个迭代分成很多个功能点,并将功能点分派给不同人的人员去开发。每一个人员开发的功能点就会形成一个feature分支,当功能点开发测试完毕之后,再合并到develop分支。

4. release branches

预发分支。这个分支系列从develop分支出来,进行预发环境下的测试,如果出现缺陷,那么就在该release分支下进行修复,修复完毕测试通过后,即分别并入master分支后develop分支,随后master分支做正常发布。

5. Hotfix branches

紧急线上修复,当线上出现bug且特别紧急的时候,就可以从master拉出分支到这里进行修复,修复完成后分别并入master和develop分支。



第二步,管理策略

在使用SVN管理版本时,其中develop的主程序必须是从master的稳定版内容merge过来,为了避免代码在开发时开发人员相互干扰,因此将根据产品人员提交的产品路线的需求单位进行特性研发,因此将产生的分支命名为feathers branch,边开发边在本地调试修改,因此一个版本会有多条feathers branch,且不断提交新的覆盖原有。

当该分支代码通过了code review,项目组长即可以将此段代码合并入develop,所有特性都集成进入develop主线时,即可发布release Branch ,交给测试人员进行测试,

当测试通过所有的预发分支进行测试,开发在预发分支上进行bug的修复,完成后即可以提交入master

最后,master上的代码为最终合并入develop中。

在master上线过程中一旦发现紧急版本升级将进入hotfix branch,因为此时代码修改并非是全量修改,而是正对某bug的紧急修复,因此产生的版本为1.1.X,厉害者X可达3000以上的四位数。

循环往复,据说比版本管理已经在国外应用的非常成熟,且国外相当多的开源软件都是如此管理,如git。

声明:本文仅代表作者观点,不代表本站立场,如需转载请保留出处和链接!

下一篇 : 认识URL Schemes

分享:

扫一扫在手机阅读、分享本文

评论