Question

我们最近决定转向TFS 2010.我们还想改进我们的源代码管理结构和项目结构。

这是团队同意的结构：

 |OurCompanyName (or common root name)
 |
 +--Windows
 +----Applications
 +------App1
 +------App2
 +----Services
 +------WindowsService1
 +------WindowsService2
 |
 +--Web
 +----Applications
 +------WebApp1
 +------WebApp2
 +----Services
 +------WebService1
 +------WebService2
 |
 +--Common
 +----ThirdParty
 +----Libs
 +------DataAccessLib
 +------BusinessLogicLib
 |
 +--Tests
 +----TestProject1
 +----TestProject1

公共文件夹包含第三方和我们内部使用的库（App1，App2，WebApp1等等）

我们需要实现以下目标：

发布版本必须依赖于Libs的最新产品版本。
如果测试失败，则不应构建依赖项目，并应通知团队。
简单分支：开发，生产，版本化版本以及我们如何相应地构建它们。

我已经阅读了以下指南Visual Studio TFS Branching Guide 2010，但它只解决了它的分支位。

Answer 1

你真的不是在问我能说些什么。但我可以就你的目标提供一些反馈/讨论。

发布版本必须依赖于Libs的最新产品版本。

发布版本应该取决于它在开发时使用的内容。不是目前的版本。您可能希望更深入地了解此要求是什么以及您认为自己需要它的原因。

如果测试失败，则不应构建依赖项目，并应通知团队。

TFS不支持开箱即用的链接构建，您可以修改构建模板以添加支持，但它不是一个特别干净的解决方案（imo）。

您可以使用内置的tfs警报订阅自行订阅失败的构建，但是每个开发人员都可以这样做。（除非您订阅邮件组或创建自定义事件邮件程序）。

为什么要自动更新其他项目中的依赖项？当然，你最好使用pull来获取更新，而不是使用像NuGet这样的技术来处理你的引用。

简单分支：开发，生产，版本化版本以及我们如何相应地构建它们。

这听起来就像每次发布时简单分支一样，非常简单。

如果您知道自己发布了哪个变更集，则不必进行分支，只有在需要时才能进行分支（例如修复生产错误）。这需要更多的工作，因为您需要在发布时手动标记代码（此时您没有获得任何分支）或者有自动发布过程为您完成。

其他说明

您不想使用多个团队项目集合 - 这在管理构建服务器时会增加噩梦。

您可能希望更新图表以显示什么是团队项目，分支以及什么是标准文件夹。

Answer 2

暂时使用TFS，我想提醒一下：您从开发人员那里看待事物，就像我们开始考虑如何最好地部署项目时所做的那样。但是，您还应该考虑项目管理要求。

拥有不同的TFS项目，意味着向经理提供不同的报告数据。

因此，如果App1和WebApp1属于同一整体项目中运行项目的人，那么如果您将它们放在不同的TFS项目中，那么表单的问题是：“我的团队在这个项目上花了多少小时”很难回答。在决定项目结构之前，我会认真研究这个问题。

现在关于你的问题：

发布版本必须依赖于Libs的最新产品版本

正如贝蒂（上图）提到的那样，这不是很好。如果使用Lib v1.0的生产版本进行开发并且在稳定期间某些时候Lib变为v2.0会发生什么？

如果测试失败，则不应构建依赖项目，并应通知团队。

我认为这是构建脚本的问题，而不是布局

- 简单分支

我们尝试实施一种简单的基于MAIN-line的方法，我们有一个或多个开发分支（实际上取决于您的具体要求）。偶尔，当dev代码被认为是“稳定的”，即通过基本单元测试时，它被合并到MAIN线上。开发人员在他们的开发分支上继续进行，而MAIN系列上的代码则进行更广泛的测试。发现的错误最初在DEV分支上报告并修复，并合并回主线。一旦MAIN线上的代码足够好，就可以在RELEASE分支上开始稳定。在那之后，错误修正发生在RELEASE分支上并合并回MAIN行。请注意，“稳定”，“足够好”是指对组织来说意味着不同的值。

TFS 2010项目结构并充分利用它

2 个答案: