Team Foundation Server 2010分支安装程序

Question

我们正在设置一个全新的TFS2010服务器，以前没有使用过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/

(以此类推)

在使用了一年之后，我们会后悔这个结构吗？应用程序将跨越此结构的许多部分-管理起来会有问题吗？

我们在什么级别设置release/main/dev分支？

感谢您的投入和指导！

Answer 1

现在就开始计划。必要时使用分支。

对于一个从未管理过分支/合并的团队，我强烈建议从一开始就保持一切尽可能简单(这意味着，短期内忘记分支)。在最近将我们的源代码从VSS转换到TFS2010，并为具有相似经验水平的类似规模的团队实施了按质量的分支策略后，我的建议是：

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

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

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

这样说的：

我认为，一旦您开始分支以满足需求，您将不会有任何问题来管理您在那里拥有的东西。这里的关键是确保您不会过度架构这一点，并使源/部署的管理复杂化。还要知道，TFS的结构将反映在本地文件系统/工作区中。

我们为每个独立的解决方案或一组相关的重用库创建了一个单独的团队项目。在一种情况下，我们将一组高度依赖的解决方案组合在一个团队项目下-一个一次性部署的大型多应用程序intranet门户。这样做可以让我们保持部署和源代码管理的简单性。下面是我们在高层次上的分支结构：

​

​

这是一个包含多个子项目的大型项目。每个分支都是一个完整的副本(只有差异/版本存储在服务器上)。在Collection中有大量的团队项目在这个项目之上和之下，并且看起来很像你的列表。

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

Answer 2

除了@hangy的链接，如果它是TFS2010你的设置，那么codeplex's Visual Studio TFS branching guide详细介绍了2010年的当前智慧。