TFS 2010 项目结构并充分利用它
我们最近决定转向 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
公共文件夹包含 3rd 方和我们全面使用的内部库（App1、App2、WebApp1...等）
我们需要实现以下目标：
- 发布版本必须依赖于Libs 的最新生产版本。
- 如果测试失败，则不应构建依赖的项目，并应通知团队。
- 简单的分支：开发、生产、版本化版本以及我们如何相应地构建它们。
我已经阅读了以下指南 Visual Studio TFS 分支指南 2010，但它只解决了其中的分支部分。
we recently decided to move to TFS 2010. we would like also to improve our source control structure and projects structure.
here is the structure the team agreed on:
|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
The common folder holds 3rd party and our in-house libraries which is used all-over(App1,App2,WebApp1...etc)
We need to acheive the following :
- Release versions must depend on latest production release of Libs.
- if tests failed, depended projects shouldn't build and team should be notified.
- simple branching: development, production,versioned releases and how we can structure them accordingly.
I have already read the following guide Visual Studio TFS Branching Guide 2010 but it only addresses the branching bit of it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我所知，你并不是真的在问问题。但我可以就您的目标提供一些反馈/讨论。
发布版本应该取决于开发时所使用的内容。与当前版本无关。您可能想更深入地了解此要求是什么以及您认为需要它的原因。
TFS 不支持开箱即用的链接构建，您可以修改构建模板以添加支持，但这不是一个特别干净的解决方案（imo）。
您可以利用内置的 tfs 警报订阅自行订阅失败的构建，但这取决于每个开发人员是否这样做。 （除非您订阅邮件组或创建自定义事件邮件程序）。
同样，为什么要自动更新其他项目中的依赖项？当然，使用拉取更新比推送更好，并使用 NuGet 等技术来处理引用。
这听起来就像每次发布时都简单地进行分支，这非常简单。
但是，如果您知道要发布哪个变更集，则不必进行分支，并且只有在需要时才可以进行分支（例如修复生产错误）。这需要做更多的工作，因为您要么需要在发布时手动标记代码（此时您不会通过分支获得任何好处），要么有一个自动发布流程来为您完成这些工作。
其他说明
您不想使用多个团队项目集合 - 这在管理构建服务器时会带来一场噩梦。
您可能需要更新图表以显示什么是团队项目、分支以及什么是标准文件夹。
You aren't really asking a question from what I can tell. But I can give some feedback/discussion on your goals.
A release version should depend on whatever it used while it was being developed. Not whatever the current version is. You may want to go into more depth on what this requirement is and why you think you need it.
TFS doesn't support chaining builds out of the box, you can modify the build template to add support, but it's not a particularly clean solution (imo).
You can self subscribe to failing builds utilising the built in tfs alerts subscriptions, however it is up to each developer to do so. (Unless you subscribe a mailing group or create a custom event mailer).
Again why are you automatically updating dependencies in other projects? surely you'd be better off using a pull for updates than a push and use a technology like NuGet to handle your references.
That sounds like simply branching each time you do a release, which is very simple.
If you however knew which changeset you releases you wouldn't have to branch and could branch only if you needed it (eg to fix a production bug). It takes a lot more work as you either need to manually label your code on release (at which point you gain nothing over branching) or have an automated release process which does it for you.
Other notes
You dont' want to use multiple Team Project Collections - this adds in a nightmare when it comes to managing build servers.
You may want to update your diagram to show what is a Team Project, Branch, and what is just a standard folder.
使用 TFS 一段时间后，我想提醒一下：
您从开发人员的角度看待事情，就像我们开始思考如何最好地部署项目时所做的那样。但是，您还应该考虑项目管理要求。
拥有不同的TFS项目，意味着向经理报告的数据不同。
因此，如果 App1 和 WebApp1 对于运行您的项目的人来说是同一个整体项目的一部分，那么如果您将它们放在不同的 TFS 项目中，那么以下形式的问题将很困难：“我的团队在这个项目上花费了多少小时”来回答。
在决定项目结构之前我会认真研究这个问题。
现在关于您的问题：
正如 Betty（上面）提到的那样，这不是一个好的做法。如果开发是在 Lib v1.0 的生产版本中进行的，并且在稳定期间的某个时候 Lib 更改为 v2.0 ，会发生什么？
我相信这是您的构建脚本的问题，而不是您的布局的问题
- 简单分支
我们尝试实现一种简单的基于主线的方法，其中我们有一个或多个开发分支（实际上取决于您的具体要求）。
有时，当开发代码被认为是“稳定的”（即通过了基本单元测试）时，它会被合并到主线上。开发人员在他们的开发分支上继续，而主线上的代码则进行更广泛的测试。发现的错误最初会在 DEV 分支上报告和修复，然后合并回主线。一旦 MAIN 线上的代码足够好，RELEASE 分支上就会开始稳定。之后，错误修复将在 RELEASE 分支上进行，并合并回 MAIN 行。请注意，“稳定”、“足够好”这些价值观对组织来说意味着不同的含义。
Having used TFS for a while, I would like to give a caution:
You look at things from the developer's side, as we did when we started thinking about how to best deploy the projects. However, you should also take under account project management requirements.
Having different TFS projects, means different reporting data to the manager.
Thus if App1 and WebApp1 are to the person that runs your projects part of the same overall project, then if you have them in different TFS projects, questions of the form: 'How many hours did my team spend on this project' will be difficult to answer.
I would seriously look into this issue before deciding on the project structure.
Now regarding your questions:
As Betty (above) mentions this is not good practive. What will happen if development took place with production release of Lib v1.0 and sometime during stabilization Lib changed to v2.0 ?
I believe this is a matter of your build script, not of your layout
-simple branching
We try to implement a simple MAIN-line based approach,where we have one or more development branches (depends really on your specific requirements).
Once in a while, when dev code is considered 'stable' i.e. passed basic unit tests, it is merged onto the MAIN line. Developers carry on, on their development branches whereas code on the MAIN line goes more extensive testing. Bugs found are reported and fixed initially on the DEV branches and merged back onto the main line. Once code on the MAIN line is good enough, stabilization starts on a RELEASE branch. After that point, bugfixes take place on the RELEASE branch and merged back into the MAIN line. Note that 'stable', 'good enough' are values that mean different things to organizations.