代码之家 › 专栏 › 技术社区 › Rebecca Chernoff

TFS按功能分支策略,适用于具有独立功能时间表的多个环境

merge branch tfs

Rebecca Chernoff · 技术社区 · 14 年前

关于TFS分支策略有很多问题,但是我还没有找到一个适合我的场景的策略。我的TFS项目由一个包含Web项目、业务层项目和数据层项目的解决方案组成。该项目是一个报告门户。报表在很大程度上被隔离在项目的子文件夹中。但是,在整个项目中有一些特性,比如会话管理。在给定的时间段内,工作流可能发生如下情况:

稳定的代码快照。
开始编写报告A。
包含报告A的项目需要推送到我们的qa环境中。
包含报告A和报告B的项目需要推送到我们的qa环境中。
只包含报告B的项目需要推送到我们的prod环境中。

我最初尝试的分支策略是将Main放在QA和prod环境之间,基本上只是一个容器,在分支到生产分支进行生产发布之前进行合并。每一份报告都将由main的一个分支机构编写。对于我们的测试和qa环境,将从main创建一个分支,并将适当的开发分支合并到这个“建议的更新”分支中。但这不起作用,因为我正在将开发/功能分支合并到一个不是父分支的分支中。我不能把Main放在这个层次上,因为一份报告可能要开发几个星期,而另一份可能要在一个时间表上开发,并在短短几天内完成生产过程。我的测试和qa的“建议更新”分支需要能够通过合并适当的dev分支来独立创建。

如果有关系的话,我们现在就在TFS2008上,希望很快就能上TFS2010。这是一个立即需要开始我们目前的TFS2008服务器。

2 回复 | 直到 14 年前

user1228 user1228 14 年前

我不是每件事都很清楚;阅读理解等等。

据我所知,你目前的程序是 偏差->测试->质量保证->生产

此外,您还有几个“团队”(1个或多个开发人员),他们必须处理单独的报表,每个报表最终都必须通过上述流程进入生产。团队可能正在开发不同于所有其他团队的代码,或者团队可能会发现,在其他团队达到稳定之前,他们无法向前移动他们的代码。

首先,创建一个生产分支机构。此分支仅包含生产代码。只有你的QA团队才能接触这个分支。

质量保证 分支机构。该分支机构也仅由QA团队维护。他们手动将测试代码合并到这个分支中,运行质量保证测试,然后与产品合并。每次它们与生产 ,或者测试代码被接受到QA中,一个标签被应用到分支。如果测试代码失败,分支将恢复到先前的标签。

开发团队管理他们自己的分支。它们是通过从 质量保证 最新标签。这确保他们使用的是最新批准的代码。开发人员使用并测试这个分支。如果团队之间相互依赖,那么他们应该在同一个分支上工作,除非很明显从共享的分支创建辅助分支分支会更容易。一年一次开发分支满足为开发人员设置的里程碑,应通知QA分支已准备好与QA合并以进行测试。

根据开发的复杂程度,您甚至可以考虑将和生产

MrHinsh - Martin Hinshelwood 14 年前

我想你应该看看由VS ALM流浪者组织的分支指引。

http://tfsbranchingguideiii.codeplex.com/

这也应该回答你所有的问题。你正在看一个相当先进的分支计划。我的博客上也有一些很好的实用指南。我知道我说的是Scrum团队,但它是基于指导的基本特性分支。

http://blog.hinshelwood.com/archive/2010/04/14/guidance-a-branching-strategy-for-scrum-teams.aspx

如果你有机会请投赞成票在新的“Visual Studio ALM” Visual Studio ALM MVP和Visual Studio 你的问题。

http://area51.stackexchange.com/proposals/15894/visual-studio-alm

Jim K 5 年前

[我知道这个问题很老,但这可能会帮助其他遇到这个问题的人]

QA发布是将所有被认为已经过充分测试并准备好进行QA的特性/问题分支合并到MAIN中的结果。当发现bug时,新的bug分支从MAIN分支出来,这些分支被修复并合并回MAIN。当所有的QA版本都被认为可以生产时,PROD构建是从MAIN开始的。简言之,MAIN是代码的真实来源之一。

如果您需要提前工作,可以使用集成测试分支(test)来确定哪些特性是“生产就绪”的,但是特性/问题分支应该根据具体情况合并到MAIN,而不是从测试分支批量合并。

修补程序可以从PROD标签分支,然后进行修复、测试并合并回MAIN以获得新的PROD版本。

https://youtu.be/9SZ7kSQ2424