团队基础：多重发布结构 [英] Team Foundation: Multiple release structure
问题描述
我需要帮助来建立TFS分支结构。
当前情况如下，我们的应用程序是SaaS，我相信我们需要多个发布同时分支。
通过TFS分支指南III，我相当确定我们将需要高级分支模型。
我们首先拥有一个主分支，该分支将容纳应用程序的当前位置（我们来自Visual Source Safe）。然后，我们将创建一个开发分支，并暂时保留该分支。我们还将创建一个新的 Service Pack， Hotfix和 Release A分支树，其中将包含我们当前的更改集。然后，我们的质量检查团队将分析发布A分支，如果通过，则将其关闭（只读），然后将其合并回主要。
到目前为止，一切都很好。
问题出现了，质量检查周期大约需要一个月，所以与此同时，我们希望我们的开发人员负责发行版B的新服务包和开发项目，这些项目也将具有自己的服务包，修补程序和发行版B分支。
这意味着我们一次有2个发行分支（当然，除非有更聪明的方式这样做）。
问题：
如果在完成开发项目之前创建了发行版B，则需要发行版A的修补程序，我该如何从将A发行到发行B，而没有同时完成任何开发项目？
请查看 http：//blog.hinshelwood中的图形。 com / guidance-a-branching-strategy-for-scrum-teams / 并阅读整个博客条目：
您的开发项目在图形中被称为 Sprint 1和 Sprint 2 ...注意Sprint与Release隔离-您只能进入它们通过合并。
I am in need of help setting up a TFS branching structure.
The current scenario is as follows, our application is a SaaS, and I believe we need multiple "Release" branches simultaneously.
Going through the TFS Branching Guide III, I'm fairly certain that we will need the "Advanced" branching model.
We start with having a "main" branch, which will house the application as it stands right now (we're coming from Visual Source Safe). From that we will create a "Development" branch, and leave that alone for now. We will also create a new "Service Pack", "Hotfix", and "Release A" branch tree which will contain our current set of changes. We will then have our QA team analyze the "Release A" branch, and if it passes we will then close it (read only), and merge it back to "main".
That's all fine and dandy so far.
The problem arises, is that the QA cycle takes approximately a month, so in the meantime, we want our developers to work on new "Service Pack" and "Development" projects for "Release B", which will also have its own "Service Pack", "Hotfix", and "Release B" branches.
This means that we have 2 release branches going at a time (unless of course there's a smarter way of doing it).
Question: If "Release B" is created BEFORE a "Development" project is completed, then a "Hotfix" for "Release A" is required, how do I propagate that "Hotfix" from "Release A" into "Release B" without picking up any "Development" projects that get completed in the meantime?
Take a look at the graphic from http://blog.hinshelwood.com/guidance-a-branching-strategy-for-scrum-teams/ And also read the entire blog entry:
Your "Development" projects are called "Sprint 1" and "Sprint 2" in the graphic...notice how the Sprints are isolated from Release--you can't get to them except via merge.
这篇关于团队基础：多重发布结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
