我们正在使用 visualstudio.com TFS 来存储源代码。我们有 DEV、STG 和 PROD 分支机构。现在我想自动构建和发布到 IIS 服务器。 但在我看来，TFS 从我提交的分支编译代码，这是唯一的构建，之后我可以在所有服务器上安装相同的二进制文件。 但是好像不行，因为如果我们在live代码上发现了一个bug，所以我们需要修复它，但是我们在DEV中已经有了新的代码，我们不想还原，并且安装了在开发服务器上修复的旧代码？
我认为我们应该做的是将代码从 DEV 合并到 STG，从 STG 合并到 PROD，但我找不到任何模块。它看起来很奇怪，如果我是唯一一个这样做的人，我会感到惊讶，特别是因为它可以与 Jenkins 一起使用。
谢谢
【问题讨论】：
标签： tfs deployment azure-devops release-management tfvc
我通常不鼓励在分支之间自动合并代码；合并应该是一个深思熟虑的动作。当有人表达这种愿望时，通常表明他们正在使用的分支模型和部署模型存在问题。
代码升级分支（您有一个对应于每个环境的分支，如您所描述的场景）是一种不好的做法，因为它鼓励您为每个环境构建不同的二进制文件集。您为较低的环境构建一些东西，对其进行测试、验证，然后完全忽略该测试并从源代码进行重建。这会让你感到害怕，尤其是对于生产分支——你不知道你刚刚构建的东西是否能正常工作。
当前的想法是尽量减少您拥有的分支数量，而是将正在进行的工作隔离在功能切换之后，以便可以简单地禁用尚未准备好投入生产的功能，但仍允许进行部署。有了足够成熟的功能切换实践和测试实践，您实际上可以完全消除分支并从单个分支中工作，只要您的自动化和手动 QA 流程认为他们正在测试的版本是好的，就可以将二进制文件推广到生产环境。
假设您使用的是 TFVC，如果您想维护代码升级分支策略，那么您需要维护多个构建和发布，每个分支/环境一个。通常，在这种情况下，我会完全消除阶段分支。任何进入 Dev 分支的东西都会被构建并部署到 Dev。任何进入 Prod 分支的东西都会被构建并遵循从 staging->production 的部署管道。修补程序可以直接进入 prod 分支并向后合并。有很多分支策略；你需要read up on the subject 并设计一个最适合你的团队的分支和发布策略。
【讨论】：