合并/分支战略

Question

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

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

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

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

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

1. 我的第一反应是只在准备好发布时才创建它,但是你遇到了为开发和测试下一个sprint的工作创建死锁的问题; 在创建RELEASE分支之前,您无法将这些更改检查到MAIN(如果这样做,则更难分离您只想转到RELEASE的更改).
2. 第二个想法是在sprint开始时创建RELEASE分支,并且当更改通过MAIN中的测试时,将它们合并到当前的RELEASE分支.一旦我们到达sprint的末尾,我们就可以锁定RELEASE分支,并为下一个sprint创建一个新的分支.这听起来像它可以工作,但我看不到任何地方的讨论,所以我只是想看看人们在做什么.

Answer 1

我会给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上很多周围的代码可能已经改变了.

Answer 2

这是我的建议：

1) 在主分支上进行所有开发，直到代码完成。代码完成是指开发人员停止为该冲刺开发新功能但可以修复回归错误的时间。代码完成可能会在发布前几天完成，也可能长达一周，具体取决于您的冲刺时间有多长）。

2) 从此时的 MAIN 创建一个新的 RELEASE 分支。将分支部署到 QA/Staging 环境以进行冒烟测试。之后，QA 团队将使用 RELEASE 分支对发布进行测试。

3) 开发人员可以在此时开始开发下一个冲刺的新功能，并开始将更改签入 MAIN 分支。测试期间发现的任何回归问题将首先在 RELEASE 分支中修复，然后合并回 MAIN。

4) RELEASE 分支中代码的任何更改都将被推送到 QA/Staging 进行进一步测试。

5) 发布完成后，生产中发现的任何错误都将在 RELEASE 分支中修复，并热修复到 Prod，并合并回 MAIN。

1号就太晚了，不。IMO 2 还为时过早。

我建议为每个 RELEASE 创建一个新分支，然后定期删除旧的 RELEASE 分支，而不是使用标签。

另外，我更喜欢只有 2 个分支 MAIN（也是 DEV）和 RELEASE，除非任何分支开发人员需要任何特定的功能/框架更改等。在根文件夹下，我通常创建 MAIN、RELEASES（所有发布分支）和 BRANCHES（所有特定于功能/框架更改等的分支，但这些仅在特殊情况下创建，并非总是如此）