tfs - Team Foundation Server 2010 分支设置

Question

我们正在设置一个全新的 TFS 2010 服务器，之前没有使用过 TFS(或者，可怕的是，没有其他中央源管理系统)。这是我们的小团队(由 6-7 名程序员组成)讨论的一般结构，我很好奇，根据其他人使用 TFS 的经验，这是否是个好主意(这些名称只是描述性的，而不是什么我们计划使用):

$/
    Our Organization's Collection/
        .Net technology projects/
            class libraries projects/
                Project 1/
                Project 2/
                Project 3/
                etc.../
            ASP.NET projects/
                Project 1/
                Project 2/
                Project 3/
                etc.../
            Windows Workflow Foundation projects/
                etc.../
            WPF projects/
                etc.../
        Other non .NET source code/
        SQL/
        Server configuration/

(等等)

使用一年后我们会后悔这个结构吗？应用程序将跨越此结构的许多部分 - 这会成为管理问题吗？

我们在什么级别设置发布/主/开发分支？

感谢您的任何意见和指导!

Answer 1

立即计划。必要时分支。

对于一个从未管理过分支/合并的团队，我完全建议让一切都尽可能简单地开始(也就是说，暂时忘记分支)。在最近将我们的源代码从 VSS 转换为 TFS2010 并为具有相似经验水平的相似规模的团队实现 Branch By Quality 策略后，我的建议是:

除非需要，否则不要实现分支策略。一旦确定有必要，您始终可以分支。继续将项目引入 TFS 以进行源代码控制，并确保每个人都对软件和保持软件稳定所需的团队合作感到满意。

与此同时，找到感兴趣的团队成员，并给他们时间在您的代码库的并行或简化实例上进行研究、培训、测试和实践。他们将需要在模仿您的部署过程的情况下练习创建项目、分支和合并；他们将需要时间与团队的其他成员沟通，以微调您的流程并记录下来；随着学习曲线变平，他们需要愿意成为团队其他成员的资源。通过这种方式，您可以让团队成员做好准备并有信心加强并实现您选择的分支模式。

在确定需要之前，您不希望跳入分支策略。大量的管理开销涉及大量的风险。

---

话虽如此:

一旦您开始分支以满足需求，我认为您在管理现有资源时不会遇到任何问题。这里的关键是确保您不会过度架构它并使您的源/部署管理复杂化。还知道您的 TFS 结构将反射(reflect)在您的本地文件系统/工作区中。

我们为每个独立的解决方案或一组相关的重用库创建了一个单独的团队项目。在一个案例中，我们将一组高度依赖的解决方案组合在一个团队项目下——一个同时部署的大型多应用程序 Intranet 门户。这样做使我们能够简化部署和源代码管理。下面是我们在高层次上的分支结构:

这是一个包含许多子项目的大型项目。每个分支都是一个完整的副本(只是差异/版本存储在服务器上)。集合中此项目的上方和下方有大量团队项目，看起来很像您在顶部的列表。

最终答案取决于应用程序的相互依赖性、结构和部署策略。你对你在那里的结构有什么特别的担忧吗？