如何使用TFS执行功能分支策略

我正在尝试为我们公司提出一个新的分支策略，并且我想知道是否可能存在任何边缘案例，与...一起。如何使用TFS执行功能分支策略

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

每支球队都有自己的开发分支，团队1和2都非常小，因此它们没有独立的QA环境如Team 3。每个团队将他们的变化合并到Main中，并返回到他们的开发分支。

目前我在Team 3上，而我期待替换的策略特别在Team 3的部分下。我们从樱桃采摘变更集从INT到INT到QA到开发，然后一路重新恢复。没有完整的分支合并，我开始相信，我们所做的每一次合并都是没有根据的合并，因为我们只是樱桃选择。

我试图做的是消除需要不断挑樱桃和变更集回去合并整个分支，这里是我想出来的：

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

在QA分支中没有进行任何开发，我们只会在DEV准备好进行测试时合并DEV以上的变更。

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

希望尽可能多地利用特性分支和搁置集合来消除对cherryset变更集的需要，并希望减少我们目前拥有的疯狂的合并冲突量。

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

来源

2017-02-25 The Pax Bisonica

每个环境的分支通常是不好的做法。您应该构建一次，然后通过环境管道部署该构建。每次你合并代码并创建一个新的构建版本时，你都会有效地抛弃你所做的所有测试，并从头开始。

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

如果某个功能被视为未准备好生产，请通过功能切换将其禁用，然后您仍然可以发布为准备好的功能。后来你将你的功能集成在一起，错过错误的机会就越高。功能集成但禁用可帮助您证明，至少，禁用的功能不会破坏其他任何功能。它可能无法正确工作，但至少不会破坏应用程序。

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

More reading on feature toggles.

来源

2017-02-25 18:23:58

好像有一个很大的开销，使用功能切换。我不知道我想写如果每一个新功能可能会在应用程序，甚至如何实现报表做一些事情.. –

@ThePaxBisonica，您可以检查此网站上的功能隔离：https：//www.visualstudio.com/en-us/articles/branching-strategies-with-tfvc#feature-isolation，或从网站下载分支策略：https：//vsarbranchingguide.codeplex.com/downloads/get/801996 –

根据我的经验，功能切换会在功能之间共享的东西变得非常讨厌，并不是很好的做法。应该使用版本控制来分离完成的功能集。开发人员应定期合并到功能分支和冲突处理中，以避免功能分支过期并变得难以合并。如果可能的话，功能分支不应该穿越冲刺。如果他们这样做，可以使用临时功能切换，但应在下一次冲刺结束时删除。同意在测试后严格推广分支机构。没有樱桃采摘。 – Kevin

如何使用TFS执行功能分支策略

回答

相关问题