version-control - Team Foundation Server 源代码控制结构

Question

我一直致力于为新的一年推出 Team Foundation Server 标准化源代码控制结构。我已经开始使用 Microsoft Team Foundation Server Branching Guidance CodePlex 上可用的文档。

我希望得到一些反馈并回答我对拟议结构的一些具体问题。当谈到在 TFS 中构建源代码控制时，我了解到有很多“标准”可供选择，但实际上并没有一个标准。

首先，我将概述和描述决策和用法。

$/                                                
    {Team Project}/                               
        {Subproject}/                             
            Development/                          
                Trunk/                            
                    Source/
                    Tests/
                    Sandcastle/
                    TeamBuildTypes/
                        {Build Name}/
                Branches/
                    {Branch Name}/
                        Source/
                        Tests/
                        Sandcastle/
                        TeamBuildTypes/
                            {Build Name}/

            Integration/
                Source/
                Tests/
                Sandcastle/
                TeamBuildTypes/
                    {Build Name}/
            Production/
                Releases/
                    {Release Version}/
                        Source/
                        Tests/
                        Sandcastle/
                        TeamBuildTypes/
                            {Build Name}/
                Branches/
                    {Branch Name}/
                        Source/
                        Tests/
                        Sandcastle/
                        TeamBuildTypes/
                           {Build Name}/

一般逻辑是，团队项目可以包含单个逻辑项目(其中没有 {Subproject} 条目)或多个相关项目以产品或工具套件的形式存在。三大容器被称为 Development , Integration , 和 Production .

内 Development container's Trunk，在 Source中对构成产品的两个项目都有规定。文件夹，在 Tests 中提供了相应的单元测试文件夹。大多数次要开发将发生在主干中，分支可通过 Trunk 获得。文件夹的兄弟 Branches文件夹，它充当分支容器。一个或多个解决方案文件将存在于 Trunk 中。 ，允许该级别的分支捕获解决方案、源代码和单元测试。
Integration容器，通常在非 TFS 实现中称为“main”，仅用于集成来自 Development 的变更集创建稳定且可测试的构建。它最初是作为 Development 的分支创建的。一旦获得可测试的产品，就可以使用容器。此容器的构建将用于我们的测试环境和负载测试环境。我们选择在可测试的构建中包含负载测试，以便我们可以监控性能变化，能够快速隔离可能导致任何违规行为的变更集。
Production用于生产预生产和生产质量构建。它最初是作为 Integration 的分支创建的。一旦建议发布一个稳定的构建，容器。内 Releases文件夹，遵循“按版本分支”结构，在一个地方提供快照和隔离。 (例如，当 Release 1.1 准备好进行预生产构建时，稳定的 Integration 容器会分支到 Release 1.1 结构中的新 Production/Releases 文件夹中。后续的 RC 和 RTW/RTM 会提升到此文件夹中，以及。)也存在分支结构，如 Branches 中所示。容器。这允许“修补程序”，通常是修订标记(Major.Minor.Revision)。分支从当前版本创建并合并回新的修订标记 - 如 Release 1.1.1 . Changeset 将反向集成到 Development容器 Trunk接受后。

我们认为这种结构是健壮性和复杂性之间的公平平衡。但是有一些烦人的问题我无法从逻辑上融入模型。他们是:

团队 build - Development和 Integration容器最初将作为夜间构建开始，最终转向持续集成 (CI)。生产容器将手动构建。

构建定义应该在哪里？ 编辑 - 根据几个响应，TeamBuildTypes 文件夹已移动到主干并分支到适当的容器。然而，这确实导致了一个新问题(如下)。

通过将 TeamBuildTypes 文件夹放在其适当的容器中，是否意味着所有构建定义都将在适当的文件夹之间复制？例如，具有用于开发质量构建的构建定义以及可测试的构建等。所有这些都位于整个结构的所有 TeamBuildType 文件夹中。

文档生成 - 我们使用 SandcaSTLe 生成文档。具体来说，我们也使用 Sandcastle Help File Builder来管理输出。这将生成一个特定于 SFHB 的格式的项目文件。

生成的文档是否应该存储在源代码控制结构中？

应该为每个容器生成文档，还是只对预生产和生产质量构建有值(value)？

为了保持快速的本地构建时间，文档创建是否应该由构建定义所有？

SHFB 特定的文件应该存放在哪里？我最初的想法是把它作为 Source 的同行。和 Tests文件夹。 我同意与 Source 同行的建议和 Tests .图表已更改以反射(reflect)此更改。

第三方二进制文件

二进制文件(控件、库等)是否应该存储在源代码管理中？

如果是这样，它应该是它自己的团队项目吗？

一般文档 - 未生成的文档，例如需求、设计文档、测试计划等，不会反射(reflect)在源代码控制结构中的文件夹中。在与我的开发人员和同行进行了一些研究和讨论后，使用 Team Explorer 中的内置 Documents 文件夹提供了更多好处，因为它反射(reflect)了 Team Project Portal 中的结构，并且一些(业务)用户不需要额外的复杂性来学习TFS 的源代码控制方面。

当我得到问题的答案时，我将更新结构以提供更清晰的画面。我也欢迎任何其他与潜在变化相关的评论。如果我有任何其他问题，我一定会修改这篇文章。

编辑:

澄清。 Source和 Tests文件夹确实位于 Integration 下容器，以及。

Micah 和 Josh 都提出了有关第三方二进制文件的重要观点。添加了有关该问题的问题。

文档生成可能很慢。添加了关于文档创建是否应由特定团队构建类型所有的问题。

添加了与非生成文档相关的解决方案，例如需求、设计文档、测试计划等。

添加了与用于构建定义的 TeamBuildTypes 文件夹相关的解决方案。

根据各种反馈，将 TeamBuildTypes 文件夹移至主干/分支级别。

Answer 1

我喜欢您将 SandcaSTLe 文件作为源和测试的对等体的想法，我将添加一个文档文件夹，然后将包含 SandcaSTLe 文件和可选的实际文档。

显然存在意见分歧，我相信我会因此而被否决(因为我以前曾经这样做过)。出于以下几个原因，我会将生成的文档放在 TFS 中:

您将需要每个版本的文档，并且使用 TFS 是确保您的文档保留在正确位置的简单方法。

使用 TFS 来存储它意味着每个人都会知道去哪里获取文档。

我没有看到我一直在纠结的一件事是第三方依赖的位置，可能是它们属于源下，因此它们与每个项目有关，尽管如果您想跨项目共享它们，您可以添加一个新的顶部水平节点。

编辑

对于我的二进制文件，我通常以

$/第三方/公司/产品/版本/源(可选)

所以例如我有

$/第三方/
微软/
词库/
3.1
4.0
组件艺术/
网页界面/
2008.1/
来源

我喜欢添加源代码，我不得不修补我讨厌做的 CA 源代码，但是当第三方不修复错误时，您必须求助于此。