svnclub并行开发分支模式

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,并行开发的分支模式,-,如何有效地使用主干和分支？,1,提纲,1,分支是什么？,2,什么情况下用分支？,3,分支有几种？,4,分支模式是什么？,5,分支模式有几种？,-,技术分类,-,目的分类,6 FreeBSD,是如何使用分支模式的？,7 Linux Kernel,是如何使用分支模式的？,8,如何选择合适的分支模式？,-,技术比较先进的？,-,符合产品开发特点？,9,分支使用中经常考虑的问题？,2,1,什么是分支？,分支：开发主线的副本，用于并行开发。,软件开发中，多个发布版本需要维护，多个平台变种需要支持。这些要求的解决，分支就应用而生：,分支是代码主线的拷贝，没有破坏基线，软件变更发生在基线的副本上，在测试完成后，这些变更在开发主线和分支间同步。,分支有自己的版本记录，甚至分支。这些功能都是版本控制系统的基本功能，如,CVS,、,SVN,、,GIT,等等。,3,2,什么情况下,使用分支？,发生软件变种,建立长分支或者嵌套分支，在主干做变更，如果分支需要这些变更，则合并。,发生缺陷修复,用长分支修复缺陷，并合并回开发主线。,发生试验代码,用短分支，试验完合并回主干。,发生大型软件变更，代码重写,根据重写的规模，可以用长分支或者短分支。,发生产品发布,用长分支，合并变革到主干，发布后，可以转化为缺陷修复分支。,4,3,分支有几种？,长分支：持续存在的分支，或者多次合并后废弃的的分支。,短分支：合并回主干一次而且不会再用的分支。,嵌套分支：依据分支创建分支，合并回分支或主干。,5,-,长分支的,3,种类型,持续存在的长分支，不断合并回分支。,开发主干不受分支变更的影响，但是分支需要主干所作的变更。网站镜像可能需要这种方法。,持续存在的长分支，不断合并回干线。,这种分支可以应用在：分支不应该被持续开发的干线影响，但是干线需要分支所作的变更。无乱何种情况，只要分支是作为测试并提供发行发布版只用，就可以使用这种分支类型。,测试中的项目也可以采用次方法。把测试的内容放到分支上，再把要测试的内容放到分支上。,6,长分支，双向合并,分支的变更能够被整合到干线，而干线的变更也能够被整合到分支。,如果开发人员在分支进行不稳定程序代码的开发工作，当每个阶段完成时，分支就可以被合并回干线，而且当分支开发人员要合并干线的变更时，也可以跟干线同步。,当发布的代码重写，且有新功能加入干线的时候，可以采用这种做法。,-,长分支的,3,种类型,7,-,短分支,短分支可以做独立分支，以便用于简便的变更。,如果你想新增单项功能、撰写试验性质的代码或准备一个发布版、单一用途的短分支应该很适用。,8,-,嵌套分支,在分支上再创建分支，为减少混淆，嵌套的越简单越好。,开发一组新功能，在继续前，进行测试。,9,4,分支模式是什么？,分支模式是做事的步骤，是减少多任务相互冲突的协调机制。,分支模式通过控制变更，实现组织开发团队进行沟通、协作的方法。,分支模式是版本控制、构建（,build,）、发布（,release,）的基础。也是任何开发过程中都必须有效解决的基础框架。,10,开发主线的代码根据是否成熟稳定分为：,主干代码基本稳定（,basically stable) -,主干稳定，分支不稳定；,主干代码基本不稳定（,basically unstable,）,-,分支稳定，主干不稳定；,5,分支模式,-,技术分类,11,-,主干稳定,主干稳定（,Basically stable,）,干线中的代码是准备发布的代码,分支则用来开发、修复缺陷、,QA,、重整、试验性质代码,严格的做法：没有经过,QA,考验的任何内容都不能合并到干线，这样可以确保无论何时都可从干线取得准备发布的版本。,宽松的做法：通过开发人员单元测试,(unit test,）的任何内容都可以被合并到干线。这种宽松的做法必须把准备发布的版本放到分支中，并与发布前进行全面的,QA,分析 。,12,-,主干稳定,优点,任何时候都能从干线取得发布版，经过,QA,测试就能发布。,干线含有不会经常改变的稳定程序代码，所有你可以在分支中进行试样性质的工作，这样即使合并到干线，也不太可能造成别人的工作出错。,缺点,最大的确定是合并工作通常是,QA,测试人员来做，而非懂得所合并的程序的真正意义的人来做。此外，分支建立以后以及合并前，干线肯能会有大幅的变更。,开发工程师周期性地从从主干向分支合并或者放松分支合并的严格限制，可以减少主干稳定带来的不利。,13,-,分支稳定,分支稳定,干线包含最新的程序代码，无乱是否稳定，而准备发布的版本则是应该被创建为分支来进行,QA,。,以不稳定为基础的最严格的做法是：所有的开发都在干线上进行，而分支只用于准备发布的版本、缺陷修复、以及发布版。,宽松的做法：也让分支用于试样性质的程序代码、重整以及其他特殊情况的程序代码。由分支的管理者负责把分支合并回干线。,14,-,分支稳定,以不稳定为基础,优点：合并不会经常做，而且比较好做，通常由熟悉代码的人来做。,缺点：干线中的程序代码常会包含缺陷、试样性质的工作，有时可能无法编译。,15,依据分支模式可以完成的应用分为：,发布分支模式；,目的分支模式；,贩卖分支模式；,5,分支模式,目的分类,16,1,发布分支模式：同时维护项目、产品的多个变种、版本。,目录结构 软件,1.0,发布时，创建一个,1.0,的分支，隔离主干新版本,2.0,的开发，所有对已发布产品的缺陷维护和特新变更都在分支上进行并发布，如,1.1,，,1.2,，,1.3,。,5,分支模式,-,目的分类,17,18,2,目的分支模式：对于每一个特性或者缺陷，或者需要，则创建分支，任务完成后，分支上代码合并回主干。,使用目的分支前，有几个问题是需要考虑的？,谁创建分支？,什么时候创建？,什么样的任务颗粒度需要创建分支？,分支如何组织管理？,以上问题，没有标准答案，但是影响项目的复杂程度。,目录结构,19,20,6 FreeBSD,如何使用分支模式？,开发过程,全球约,300,人有写仓库的权限，一个小于,10,人的核心团队；,FreeBSD -CURRENT,指的是正在发展中的操作系统版本，它实在是只适合给 系统发展者 以及有毅力的 业余爱好者 使用，它终将在适当的时机成为,RELEASE,。,FreeBSD -STABLE,指的是生产适用的操作系统版本，主要使用对象是对于稳定性及低变异性的需求远胜过对最新,-,CURRENT,版新功能的需求者。,每次从,-STABLE,分支发布新版本大约,4,个月的时间。,特性冻结 发布前,45,天到发布前,30,天，发信通知，提醒集成新的特性，这时，开发团队执行了,MFC,，从,current,合并到,stable,。,代码缓行,code slush,， 发布前,30,天到发布前,15,天，所有提交稳定分支的代码需要评审（主要是错误修复，安全问题）,代码冻结 发布前,15,天，发布候选包（,RC,）发布，在正式发布前，每周发布一个,RC,。,选择可以正式发布的,RC,版本从,stable-X,发行，同时创建发布版本标签（,TAG,）,release-X.Y,和安全分支,(,releng,-X.Y,）,已发布版本的维护,21,6 FreeBSD,是如何使用分支模式？,发布工程介绍,http:/,cvsweb.geekcn.org/src/sys/conf/newvers.sh?graph,=1;cvsroot=,freebsd,http:/,svn.freebsd.org,22,7 Linux Kernal,是如何使用分支模式的？,Linux kernel,开发模式,一个永久的稳定分支，一个永久的开发分支（非,cvs,工具,Git,）,当决定某个时间发布新的稳定版本，开发分支进入需求冻结期（,freature,freeze),当所有发现的缺陷被修复后，开发人员从冻结的开发分支上，创建了一个稳定的发布分支。,同时，立即开始新的开发的分支进行开发。,每,23,个月从稳定分支中发布新的版本，主要解决了缺陷修复和安全性等问题。,Git,is a distributed,revision control,/ software code management project created by,Linus,Torvalds, initially for the,Linux kernel,development.,这种模式可以满足大部分项目，但是有点官僚，通过最小化在一个时间同时活跃的分支数目，来简化开发周期。,23,-Linux kernel Release cycle,Development model,随着,2.6.x,的发布，,Linux kernel,已经转向相对严格，基于时间要求的发布模式（,2-3,个月将发布一个版本）,选择快速发布模式（,quick release cycle),可以在几个月内将新特性、安全、驱动等集成在,kernel,内提供给用户。,开发团队发布,2.6.19kernel,作为一个稳定的发布。然后，开发人员继续新特性开发，发布供测试用的,RC,版本，等到发布候选足够稳定，,2.6.20kernel,作为稳定版发布。,在新版本开发中，,2.6.19,中发现的缺陷和安全问题被及时在分支中维护，并作为,2.6.19.1,，,2.6.19.2,等发布。,24,8,如何选择合适的分支模式？,-,技术先进？,目的分支模式技术比较先进，更好地支持并行开发,25,8,如何选择合适的分支模式？,-,符合产品特点,志愿组织,多分支,多合并,商业组织,分支数量少于,3,个,合并周期少于一,1,周,尽量少创建分支,对进行需求的评审,26,8,如何选择合适的分支模式？,-,符合产品特点,支持连续不间断的集成，从而保持新开发过程的稳定基准,提交应急版本（只包括所有必要的修复）进行测试和交付用户,包含有所有必要的修复而无其它更改的测试版本发布,使应急发布对新开发过程的影响最小化,必要时，回退到以前的产品状态,现场支持多个连续版本,支持多个共存版本，如不同平台或不同用户的备选版本,27,-,建议使用的分支开发模式,尽量将开发主线放在干线上，其余的开发活动则纳入分支,主干,(TRUNK),用于开发，活跃开发在主干,集成测试前需求冻结,系统测试前代码冷藏,发布候选阶段代码冻结,对已发布产品的修复在分支上进行，人工压低并发活跃的数量,产品发布时，创建分支,合并周期少于一,1,周,尽量少创建分支,合并可以由主要工程师完成,减少管理难度，减少合并操作的难度,28,29,9,分支使用中经常考虑的问题？,什么时候进行分支？,什么时候进行合并？,如何选择有效的分支策略？,如何保证不同分支上的代码同步问题？,如果建立对分支访问控制的授权机制？,如何避免频繁的合并冲突？,如何处理被复用的代码,30,Thanks,！,31,