如何使用 TFS 执行特征分支策略

Question

我正在尝试为我们公司提出一个新的分支战略，我想知道是否有任何我没有考虑到我提出的边缘情况。

首先，这是我们当前的分支策略：

每个团队都有自己的开发分支，团队 1 和 2 非常小，因此他们没有像团队 3 那样的单独 QA 环境。每个团队将他们的更改合并到主分支并返回到他们的开发分支。

目前我在 Team 3，我要替换的策略专门在 Team 3 的部分下。我们正在挑选从 Main 到 INT 到 QA 到 Dev 的变更集，然后一路备份。没有完整的分支合并，我开始相信我们所做的每次合并都是毫无根据的合并，因为我们只是挑选。

我正在尝试做的是消除不断挑选变更集并返回合并整个分支的需要，这是我想出的：

对于长期运行的功能，我们将创建功能分支，而 dev 将主要用于处理旨在在下一个版本中投入生产的错误和用户故事。

QA 分支没有进行任何开发，我们只会在 DEV 准备好进行测试时将更改合并到 QA。

一旦所有的测试都通过了，我们将合并到 Main 并为下一个版本创建一个脱离 main 的版本分支。版本分支将允许我们有一个干净的分支来执行修补程序，因为我们有多个团队合并到 main。

希望尽可能多地利用功能分支和搁置集，以消除挑选变更集的需要，并希望减少我们目前遇到的疯狂合并冲突。

这看起来是一个合理的策略吗？

Answer 1

按环境进行分支通常是一种不好的做法。您应该构建一次，然后通过环境管道部署该构建。每次合并代码并创建新版本时，您实际上都放弃了所有已完成的测试并从头开始。

在功能切换后隔离正在开发的功能。由于每个功能都被视为“完成”，请将其合并到 Main，这将启动您的 QA 周期。然后其他团队应该从 Main 合并回他们的功能分支，以便继续针对相同的代码库进行开发。

如果某个功能被认为尚未准备好投入生产，请通过功能切换禁用它，然后您仍然可以发布已准备好的功能。越晚将功能集成在一起，某人错过错误的可能性就越大。具有集成但禁用的功能可以帮助您证明，至少，禁用的功能不会破坏其他任何东西。它可能无法正常工作，但至少不会破坏应用程序。

随着这种模型对团队来说变得更加自然，您可以完全放弃功能分支，直接在主干上工作。

More reading on feature toggles.