TFS在构建和发布期间合并

问题描述 投票:0回答:1

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

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

谢谢

tfs deployment azure-devops release-management tfvc
1个回答
0
投票

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

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

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

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

© www.soinside.com 2019 - 2024. All rights reserved.