合并/分支战略

我们正在尝试在最新的Visual Studio TFS分支和合并指南中实现ALM Rangers所描述的"基本双分支计划" .从指导:

具有MAIN,DEV和RELEASE分支的基本分支计划支持您的下一个版本的并发开发,用于测试的稳定MAIN分支和用于任何船舶阻止错误修复的RELEASE分支.通过从MAIN创建其他开发分支来支持多个开发区域.这些是彼此的对等和MAIN的孩子.

通过为每个产品版本创建发布分支来支持其他版本.每个发布分支都是MAIN的子级和彼此的对等(例如,发布2.0分支是对等发布3.0并且都是MAIN的子级).如果一次只支持生产中的单个版本,您可以考虑单个版本分支,并直接在此分支上修复错误.创建RELEASE分支后,MAIN和开发分支机构可以开始接受为下一个产品发布批准的更改.

我们尚未决定是否要使用单个Release分支(和标签发布),或者每个版本创建一个新的发布分支.但是,有一些问题适用于任何一种方式,这些问题似乎没有得到指导的解决.

我的主要问题是:在什么时候我们应该创建一个RELEASE分支(或者将测试代码移动到单个RELEASE分支,如果这是我们的方式)？

我的第一反应是只在准备好发布时才创建它,但是你遇到了为开发和测试下一个sprint的工作创建死锁的问题; 在创建RELEASE分支之前,您无法将这些更改检查到MAIN(如果这样做,则更难分离您只想转到RELEASE的更改).

第二个想法是在sprint开始时创建RELEASE分支,并且当更改通过MAIN中的测试时,将它们合并到当前的RELEASE分支.一旦我们到达sprint的末尾,我们就可以锁定RELEASE分支,并为下一个sprint创建一个新的分支.这听起来像它可以工作,但我看不到任何地方的讨论,所以我只是想看看人们在做什么.

Jensen.. 5

我会给Adarsh Shah提供相同的建议,因为在大多数情况下2个分支(MAIN,RELEASE)就足够了,并且使用功能分支来处理你不想立即进入MAIN的东西,因为它需要一段时间才能完全准备测试.通过RELEASE,我指的是每个实际版本的分支.

请记住,从理论上讲,MAIN应该随时处于释放就绪状态.这意味着使用特征分支也可以进行大量的小改动,只要该功能不被认为是准备好的,就不会将东西合并到MAIN中.现在,您应该尝试这一点,看看哪种方式最适合您的环境.如果您发现将MAIN保持在发布就绪状态太难了,请务必创建一个单独的DEV分支来提交日常工作.然而,根据我的经验,通过一些良好的指导,自动和手动测试,您可以快速进入MAIN可以被认为非常稳定的流程.我曾经在我们有一个非常不稳定的DEV分支和一个稳定的MAIN分支的环境中工作,以及我们没有DEV分支的环境.有时需要DEV分支,有时它会使它们保持同步,因为DEV和MAIN都相当稳定,基本上只是彼此的副本.

现在,何时应该创建发布分支.这取决于您正在进行的开发类型.对于小型桌面项目或具有相当稳定的发布周期的网站(例如,每个sprint发布一个版本),我发现在sprint 结束时创建一个发布分支最容易,之后只能将其推送到生产sprint.

S1 - - S2 - - S3 - - S4 // Each sprint
     \ R1 - \ R2 - \ R3 // Release branch created at the end of a sprint
            \ P1 - \ P2 // Pushed to production at the start of the next sprint

因此,在S1结束时,我从MAIN创建了发布分支R1,但它尚未推向生产阶段.在S2期间,两个新功能都在MAIN上实现,并且关键错误在R1上得到修复.如果R1上的修复程序被批准,它也会被合并回MAIN,如果需要的话.在S2结束时,创建一个新的R2,并将R1推入生产环境.我发现这种方法很有效.你基本上有一个完整的sprint来解决发布分支中的最后一个问题.

当然,如果生产中出现严重的关键错误,则此错误优先于其他所有错误.然后可以创建正在生产的现有R分支的RXa,RXb,...分支,实现热修复并将该热修复推送到生产中.然后,您可以考虑是否需要将热修复中的更改合并到MAIN分支中.不要在MAIN分支上创建一个热修复并将其合并,但是你会发现它很快变得太复杂,因为在MAIN上很多周围的代码可能已经改变了.