TFS在构建和发布期间合并

Posted 2021-05-05

我们使用visualstudio.com TFS来存储源代码。我们有DEV，STG和PROD分支机构。现在我想自动构建和发布到IIS服务器。但是对我来说，TFS编译来自我所承诺的分支的代码，这是唯一的构建，之后我可以在所有服务器上安装相同的二进制文件。但它似乎没有问题，因为如果我们发现实时代码有错误，所以我们需要修复它，但我们已经在DEV中有了新代码，我们不想还原，并安装在dev服务器上修复旧代码？

我认为我们应该做的是将DEV中的代码合并到STG，从STG到PROD，但我找不到任何模块。它看起来很奇怪，如果我是唯一一个这样做的人，我会感到惊讶，特别是因为它可以和詹金斯一起使用。

谢谢

答案

我通常不鼓励在分支之间自动合并代码;合并应该是刻意的行动。当有人表达这种愿望时，通常表明他们正在使用的分支模型和部署模型存在问题。

代码促销分支（您有一个分支对应于每个环境，如您所描述的方案）是一种不好的做法，因为它鼓励您为每个环境构建不同的二进制集。您为较低的环境构建了一些东西，测试它，验证它，然后完全忽略该测试并从源代码重建。这应该让你感到害怕，特别是对于生产分支 - 你不知道你刚刚建造的东西是否会正常运作。

目前的想法是最小化您拥有的分支数量，而是隔离功能切换背后的正在进行的工作，以便可以简单地禁用尚未准备好生产的功能，但仍允许进行部署。通过足够成熟的功能切换实践和测试实践，您实际上可以完全消除分支并在单个分支中工作，只要您的自动和手动QA流程认为他们正在测试的版本是好的，就可以将二进制文件推广到生产中。

假设您正在使用TFVC，如果您想维护代码促销分支策略，那么您将需要维护多个构建和发布，每个分支/环境一个。通常，在这种情况下，我会彻底消除阶段分支。任何进入Dev分支的东西都会构建并部署到Dev。任何进入Prod分支的东西都是构建的，并遵循staging-> production的部署管道。修补程序可以直接进入prod分支并向后合并。有大量的分支策略;你需要read up on the subject并设计一个最适合你团队的分支和发布策略。