如何使用 TFVC 组织开发生命周期

Question

我们正在开发一个系统，我们将在未来一年左右进行大量更改。 我们将 Azure DevOps 与 TFVC 结合使用。 我们的计划是开发、内部测试，然后发布到临时环境中供客户进行内部测试，然后在解决错误后发布到实时环境中，但我们希望以相当小的迭代来完成，所以我们不立即发布大量更改，我们可以获得更改的早期反馈，以确保我们走在正确的轨道上，并且不会在大更新后被大量问题淹没。

令我担心的问题是，一旦我们发布到测试环境中，客户端将需要时间对其进行测试，在此期间，我们将一直致力于其他改进/错误修复。 如果客户只是说一切都很好，我可以在我们发布临时版本时使用 VS 获取特定版本，然后构建并发布该版本以使其生效，但如果出现任何问题，我们需要解决这些问题，我们最终将不得不让客户测试我们一直在努力的所有新内容，而且我们可能正处于无法发布到暂存阶段的大型更改中。

我看过 TFS 分支，但它们似乎弄乱了路径，设置和使用起来很痛苦，而且我觉得它们并不适合这种情况。

人们一般是如何解决这个问题的？

（我很欣赏很多人会争辩说 Git 是一个更好的源代码控制系统，但我特别问的是如何使用 TFVC 来做到这一点）

Answer 1

TFVC 中的分支远非轻量级，并且可以使本地分支之间的切换变得笨拙。

切换时本地路径的更改很难避免，可以通过更改工作区定义、重新映射文​​件夹并强制获取最新版本来完成。

此处使用的另一个选项是git tfs ，它将允许您在服务器上使用 TFVC，但在本地使用 Git 并获得本地优势（包括多个本地分支以及在它们之间切换的能力）。

在开发过程中使用环境和批准的一种技术是创建升级级别的分支。 一个分支用于主动开发，从那个分支分支到下一个环境（测试），然后下一个（接受？）一直到生产。

 Development
 \— Test
       \— Acceptance
             \— Production

每次开发足够稳定时，将代码合并到测试中。 任何问题都可以直接在测试中修复，也可以通过在开发中修复然后挑选。

开发和生产之间的距离越大，保持分支同步就越困难。

另一种方法是使用发布分支，基本上将上述结构稍微折叠一下：

 Main
 \— Release 1
 \— Release 2

活跃的开发发生在 Main 中，代码在发布分支上被合并和热修复。 在发布分支上所做的任何更改也必须合并回来。

有更好的解决方案

您可以帮助客户更快地测试潜在版本，而不是通过提前开发新功能来提高工作效率吗？ 在这种情况下，您不需要等待太长时间来完成测试，可以提供超级快速的修复，然后将注意力转移到更多新的开发上。 它将防止合并、重新出现未正确合并回 main 的代码中的错误等各种问题。