tfs - 合并/分支策略

Question

我们正在尝试实现 ALM Rangers 在最新的 Visual Studio TFS Branching and Merging Guide 中描述的“基本双分支计划”。 .从指导:

The basic branch plan with a MAIN, DEV, and RELEASE branch enables concurrent development for your next release, a stable MAIN branch for testing and a RELEASE branch for any ship blocking bug fixes. Multiple development areas are supported by creating additional development branches from MAIN. These are peers to each other and children of MAIN.

Additional releases are supported by creating release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release 2.0 branch is peer to release 3.0 and both are children of MAIN). If supporting only a single release in production at a time, you may consider a single release branch, and make bug fixes directly on this branch. Once the RELEASE branch is created MAIN and the development branches can start taking changes approved for the next product release.

我们不确定是否要使用单个发布分支(和标签发布)，或者为每个发布创建一个新的发布分支。但是，有一些问题适用于任何一种方式，但指南似乎没有解决这些问题。
我的主要问题是:我们应该在什么时间点创建一个 RELEASE 分支(或者如果我们这样做的话，将测试代码移动到单个 RELEASE 分支)？

我的第一 react 是只有在准备好发布时才创建它，但是你会遇到为下一个 sprint 工作的开发和测试创建死锁的问题；在创建 RELEASE 分支之前，您无法将这些更改 checkin MAIN(如果这样做，则更难以分离出您只想转到 RELEASE 的更改)。

第二个想法是在 sprint 开始时创建 RELEASE 分支，当更改通过 MAIN 中的测试时，将它们合并到当前的 RELEASE 分支。一旦我们到达 sprint 的结尾，我们可以锁定该 RELEASE 分支，并为下一个 sprint 创建一个新分支。这听起来可行，但我在任何地方都没有看到任何讨论，所以我只是想看看人们在做什么。

Answer 1

我会给出与 Adarsh Shah 相同的建议在大多数情况下，2 个分支(MAIN，RELEASE)就足够了，并且使用 feature branches对于您不想立即提交到 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 插入生产。我发现这种方法效果很好。你基本上有一个完整的冲刺来解决发布分支中的最后一个问题。

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