我们正在使用visualstudio.com TFS来存储源代码。我们有DEV，STG和PROD分支机构。现在我想自动构建和发布到IIS服务器。 但是对我来说，TFS编译来自我所承诺的分支的代码，并且这是唯一的构建，之后我可以在所有服务器上安装相同的二进制文件。 但它似乎没有问题，因为如果我们在实时代码中发现了一个错误，我们需要修复它，但我们已经在DEV中有了新代码，而我们并不想恢复，并在开发服务器上安装带有修复程序的旧代码？
我认为我们应该做的是将DEV中的代码合并到STG，从STG合并到PROD，但我找不到任何模块。它看起来很奇怪，如果我是唯一一个这样做的人，我会感到惊讶，特别是因为它对詹金斯来说是可行的。
感谢
答案 0 :(得分：0)
我通常不鼓励在分支机构之间自动合并代码;合并应该是刻意的行动。当有人表达了这种愿望时，它通常表明他们正在使用的分支模型和部署模型存在问题。
代码促销分支（您有一个分支对应于每个环境，如您所描述的场景中）是一种不好的做法，因为它鼓励您为每个环境构建不同的二进制集。您为较低的环境构建了一些东西，测试它，验证它，然后完全忽视从源代码进行测试和重建。这应该会让你感到害怕，特别是对于生产分支机构 - 你不知道你刚刚建造的是否会正常工作。
目前的想法是尽量减少您拥有的分支机构数量，而是隔离功能切换背后的正在进行的工作，以便可以简单地禁用尚未准备好生产的功能，但仍允许进行部署。有了足够成熟的功能切换实践和测试实践，您实际上可以完全消除分支并在单个分支中工作，只要您的自动和手动QA流程认为他们正在测试的版本是好的，就可以将二进制文件推向生产。 / p>
假设您正在使用TFVC，如果您想维护代码促销分支策略，那么您需要维护多个构建和发布，每个分支/环境一个。通常，在这种情况下，我完全消除了阶段分支。任何进入Dev分支的东西都会构建并部署到Dev。任何进入Prod分支的东西都是构建的，并遵循staging-＆gt;生产的部署管道。修补程序可以直接进入prod分支并向后合并。有大量的分支策略;您需要read up on the subject并设计最适合您团队的分支和发布策略。