Team Foundation Server 源代码控制结构 [英] Team Foundation Server Source Control Structure

问题描述

我一直致力于为我们在新的一年推出的 Team Foundation Server 标准化源代码控制结构.我已开始使用 CodePlex 上提供的 Microsoft Team Foundation Server 分支指南 文档.

I have been working on standardizing the source control structure for our Team Foundation Server rollout for the new year. I have started by using the Microsoft Team Foundation Server Branching Guidance documentation available on CodePlex.

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

I was hoping to get some feedback and answers to a few of the specific questions I have about the proposed structure. When it comes to structuring source control in TFS, I have learned that there are so many "standards" to choose from that there is not really a standard.

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

First, I will outline and describe the decisions and usage.

$/                                                
    {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.

The general logic is that a Team Project can contain either a single logical project (where there would be no {Subproject} entry) or multiple related projects in the form of a product or tool suite. The three major containers are called Development, Integration, and Production.

在 Development 容器的 Trunk 中，Source 文件夹中提供了构成产品的两个项目， 中提供了相应的单元测试测试文件夹.大多数次要开发将发生在主干中，通过 Trunk 文件夹的同级 Branches 文件夹提供分支，该文件夹充当分支容器.一个或多个解决方案文件将位于 Trunk 中，允许该级别的分支捕获解决方案、源代码和单元测试.

Within the Development container's Trunk, there are provisions for both the projects which make up the product in the Source folder, with corresponding unit tests available in the Tests folder. A majority of minor development would occur in the trunk, with branching available through the Trunk folder's sibling Branches folder, which acts as a branching container. One or more solution files would live within the Trunk, allowing for branches at that level to capture the solution, source, and unit tests.

Integration 容器，在非 TFS 实现中通常称为main"，仅用于集成来自 Development 的变更集，以创建稳定且可测试的构建.一旦获得可测试的产品，它最初被创建为 Development 容器的一个分支.此容器的构建将用于我们的测试环境和负载测试环境.我们选择在可测试构建中加入负载测试，以便我们可以监控性能变化，并能够快速隔离可能导致任何违规行为的变更集.

The Integration container, often called "main" in non-TFS implementation, is solely used to integrate Changesets from Development to create a stable and testable build. It is initially created as a branch from the Development container once a testable product has been attained. The builds from this container will be used for our testing environment and load testing environment. We choose to include load testing with testable builds so that we can monitor for changes in performance, being able to rapidly isolate Changesets that may have contributed to any irregularities.

Production 用于生成预生产和生产质量构建.一旦推荐发布稳定版本，它最初是作为 Integration 容器的一个分支创建的.在 Releases 文件夹中，遵循按版本分支"结构，在一个地方提供快照和隔离.(例如，当 Release 1.1 准备好进行预生产构建时，稳定的 Integration 容器会分支到新的 Release 1.1 文件夹中Production/Releases 结构.随后的 RC 和 RTW/RTM 也被提升到此文件夹中.)还存在分支结构，如 Branches 容器中所示.这允许修补程序"，通常是修订标记(Major.Minor.Revision).分支是从当前版本创建的，并合并回新的修订标记 - 如 Release 1.1.1.变更集将在接受后反向集成到 Development 容器的 Trunk.

Production is used to produce pre-production and production quality builds. It is initially created as a branch from the Integration container once a stable build has been recommended for release. Within the Releases folder, a "branch by release" structure is followed, providing snapshotting and isolation in a single place. (For example, when Release 1.1 is ready for a pre-production build, the stable Integration container is branched into a new Release 1.1 folder in the Production/Releases structure. Subsequent RCs and RTWs/RTMs are promoted into this folder, as well.) A branching structure is also present, as seen in the Branches container. This allows for "hotfixes", usually a revision marker (Major.Minor.Revision). The branch is created from the current release and merged back into the new revision marker - like Release 1.1.1. The Changeset would be reverse integrated to the Development container's Trunk upon acceptance.

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

We feel that this structure is a fair balance between robustness and complexity. But there are a few nagging questions that I can not logically fit into the model. They are:

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

Team Build - The Development and Integration containers will initially start out as being nightly builds, eventually moving to Continuous Integration (CI). The Production container will be manually built.

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

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

By having the TeamBuildTypes folder in their appropriate containers, does that mean that all build definitions will be reproduced between the appropriate folders? For example, having a build definition for development quality builds, as well as testable builds, etc. all living in all TeamBuildType folders throughout the structure.

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

Documentation Generation - We use Sandcastle to generate documentation. Specifically, we also use Sandcastle Help File Builder to manage the output. This produces a project file in a format specific to SFHB.

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

• Should generated documentation be stored in the source control structure?

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

Should documentation be generated for each container, or does it only posses value for pre-production and production quality builds?

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

To preserve fast local build times, should documentation creation be owned by a build definition?

特定于 SHFB 的文件应该存放在哪里?我最初的想法是将它作为 Source 和 Tests 文件夹的对等体. 我同意建议，它是一个对等 Source 和 Tests.图表已更改以反映此更改.

Where should the SHFB-specific files live? My initial inkling is to put it as a peer to the Source and Tests folders. I agree with the recommondations that it be a peer to Source and Tests. Diagram changed to reflect this change.

第三方二进制文件

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

• Should binaries (controls, libraries, etc.) be stored in source control?

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

If so, should it be it's own Team Project?

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

General Documentation - Non-generated documentation, such as requirements, design documents, test plans, etc. are not going to be reflected by a folder in the source control structure. After some research and discussion with my developers and peers, using the built-in Documents folder in Team Explorer provides more benefit, since it mirrors the structure within the Team Project Portal and some (business) users do not need the additional complexity of learning the source control aspect of TFS.

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

I will update the structure as I get answers to the questions to provide a clearer picture. I also welcome any other comments related to potential changes. If I have any other questions, I will make sure to modify this post.

• 澄清.Source 和 Tests 文件夹也位于 Integration 容器下.

• Clarification. Source and Tests folders do live under the Integration container, as well.

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

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

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

为构建定义添加了与 TeamBuildTypes 文件夹相关的分辨率.

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

推荐答案

我喜欢你将 Sandcastle 文件作为源和测试的对等体的想法，我会添加一个文档文件夹，然后将包含 Sandcastle 文件，以及可选的实际文档.

I like your idea of putting the Sandcastle files as a peer to Source and Tests, I would add a documentation folder, that would then contain the sandcastle files, and optionally the actual documentation.

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

There are definetly differences of opinions and I'm sure I will be downvoted for this (since I have been before). I would put the generated documentation in TFS for a couple of reasons:

1. 您希望在每个版本中都有自己的文档，而使用 TFS 是一种确保您的文档保存在正确位置的简单方法.
2. 使用 TFS 来存储它意味着每个人都会知道去哪里获取文档.

我不明白的一件事是我一直在苦苦挣扎的第三方依赖的位置，可能是它们属于源下，因此它们与每个项目有关，尽管如果您想跨项目共享它们，您可以添加一个新的顶级节点.

One thing I don't see which I always struggle with is where to third party dependancies, it might be that they belong down under the source so they are with each project although if you wanted to share them accross projects you could add a new top level node.

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

For my binaries I usually end up with

$/ThirdParty/Company/Product/Version/Src(可选)

$/ThirdParty/Company/Product/Version/Src(optional)

例如我有

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

$/ThirdParty/ Microsoft/ EntLib/ 3.1 4.0 ComponentArt/ WebUI/ 2008.1/ Src

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

I like to add the source, I've had to patch CA's source which I hate to do but when a third party doesn't fix the bug you have to resort to this.

这篇关于Team Foundation Server 源代码控制结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！