Team Foundation Server source control framework

Question

I am working on standardizing the version control framework for our deployment of Team Foundation Server for the new year. I started by using the Microsoft Team Foundation Server Branching Guidance documentation on CodePlex.

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

First, I will describe and describe solutions 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}/ 

The general logic is that Team Project can contain either one logical project (where there would be no {Subproject} ), or several related projects in the form of a product or a set of tools. The three main containers are called Development , Integration and Production .

In the container of the Development container, there are provisions for both projects that make up the product in the Source folder, with the corresponding unit tests available in the Tests folder. Most of the minor development will occur in the trunk, with branching available through the Trunk sibling Branches folder, which acts as a branch container. One or more decision files will live within Trunk , allowing branches at this level to display decisions, source and unit tests.

The Integration container, often referred to as the “main” container in a non-TFS implementation, is used exclusively to integrate Development to create a stable and testable assembly. It is initially created as a branch from the Development container as soon as the product under test is reached. Assemblies from this container will be used for our test and load test environments. We decided to enable load testing with the test builds so that we could monitor changes in performance, being able to quickly isolate groups of changes that could contribute to any violations.

Production used for the production of finished and production qualities. It is initially created as a branch from the Integration container, as soon as a stable assembly was recommended for release. Inside the Releases folder, a "branch by version" structure is implemented, providing snapshot and isolation in one place. (For example, when Release 1.1 ready for pre-build, the stable Integration container forks into a new Release 1.1 folder in the Production/Releases structure. Subsequent RC files and RTW / RTM files are moved to this folder as well). There is also a branching structure, as shown in the Branches container. This allows for “fixes”, usually a revision marker (Major.Minor.Revision). A branch is created from the current version and merged back into a new version token - for example, Release 1.1.1 . Once the changes are accepted, the change block will be integrated back into the Development Trunk container.

We believe that this structure is a fair balance between reliability and complexity. But there are some glaring questions that I cannot logically fit into the model. It:

Team build . Development and Integration containers initially begin as nightly builds, eventually moving on to Continuous Integration (CI). A production container will be created manually.

• Where should assembly definitions exist? Change Based on several answers, the TeamBuildTypes folder has been moved to the trunk and forked into the appropriate containers. This, however, leads to a new question (follows).

• Having the TeamBuildTypes folder in the appropriate containers, does this mean that all build definitions will be played between the corresponding folders? For example, the definition of an assembly for building development quality, as well as test assemblies, etc., all of which are located in all TeamBuildType folders throughout the structure.

Documentation generation . We use Sandcastle to create documentation. In particular, we also use the Sandbule Help File Builder to control the output. This creates a project file in an SFHB-specific format.

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

• Should documentation be created for each container or is it only valuable for assembly for production and production?

• To preserve fast local assembly times, should documentation be owned by the assembly definition?

• Where should the SHFB-specific files be? My initial information is to put it as a peer in the Source and Tests folders. I agree with the recommendations that this will be equal to Source and Tests . The chart has changed to reflect this change.

Third-party binary materials

• Should binary files (controls, libraries, etc.) be stored in the control source?

• If so, should it be its own Team Project?

General documentation . Not created documentation, such as requirements, project documents, test plans, etc., will not be displayed in the 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 great benefits, because it reflects the structure in the Team Project Portal, and some (business users) do not need the additional complexity of learning the aspect of controlling the TFS source.

---

I am updating the structure as I get answers to questions to provide a clearer image. I also welcome any other comments related to potential changes. If I have any other questions, I will definitely change this post.

edits:

• Explanation. Source and Tests are stored in the Integration container.

• Both Mika and Josh raised big dots regarding third-party binaries. Question added regarding issue.

• Documentation generation can be slow. Added a question about whether documentation should belong to a specific type of Team build.

• Added permission related to non-created documentation, such as requirements, project documentation, test plans, etc.

• Added solution related to TeamBuildTypes folder for build fixes.

• Based on various reviews, we moved the TeamBuildTypes folder to the trunk / branch levels.

Answer 1

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

There are certain differences of opinion, and I am sure that I will be underestimated for this (since I was before). I would put the generated documentation in TFS for two reasons:

• It is advisable that your documentation be released with each version, and using TFS is an easy way to make sure your documentation stays in the right place.
• Using TFS to store it means that everyone will know where to go for documentation.

One thing that I don’t see that I always encounter is with regard to third-party dependencies, maybe they belong to the source, so they are with every project, although if you want to share them on projects that you could add a new top level node.

Edit

For my binaries, I usually end up

$ / ThirdParty / About the company / product / Version / Src (optional)

So for example, I have

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

I like to add the source, I had to fix the CA source, which I don’t like to do, but when the third party doesn’t fix the error you should resort to.

Answer 2

Great layout and explanation. I struggled with the same problems. I ended up with a very similar structure. Mine is changing a bit.

 Development/ Trunk/ Binaries/ -- Shared libraries Source/ Test/ Docs/ -- Documentation TeamBuildTypes/ -- Build definitions 

• Adding a bin folder allows you to have one location in the branch where all your projects can link to shared libraries.
• We put the documentation here so that she can travel with her specific branch.
• Our build definitions are at the development level, since we can define them in one place for all branches, but it can definitely be at the branch level, which may make more sense.

Should binary files (controls, libraries, etc.) be stored in source control? If so, should this be your own project team?

I think that they certainly should be source controlled, but I see no reason to put them in my own team project. One of the issues to keep in mind is that TFS for some reason treats binaries a bit differently. I had problems updating the binary files in the original control, but "Retrieving the Latest" on other machines does not cause the files to be updated. Sometimes you need to do “Get a specific version” and check the option “Overwrite immutable files” for that particular file.

Answer 3

You must place your TeamBuilds folder under your trunk. This was not possible in TFS2005, but Microsoft fixed it for 2008 ...

The reason for this is that your assembly may change with a newer version (for example: new packaging schemes, other testing, etc.), which may lead to its incompatibility with older versions of the service. This is why you must combine the assembly with the code version.

Thus, we can say that you release version 1.0 and put it in the "Releases" folder. You will be able to create it and release fixes while working on version v2.0 on your development trunk (which may require assembly changes).

Answer 4

For your binaries - obviously, the only binaries that need to be versioned are third-party builds that you don't build as part of any automated build. If you have your own libraries that you have under version control, etc., you should look at various strategies for building and synchronizing, etc.

Then I organize them as Josh - and then use the branch to “copy” the binaries to the _ExternalReferences folder, which is a peer in the .NET Project folders in the decision tree. This is a very efficient server-side method, since TFS version control stores only “Deltas” - so essentially every “duplication” of these binaries in many projects is essentially like a “pointer”.

Answer 5

One thing I would recommend is not to use the default location for team builders and include it in the “branch” level, because when you go for various reasons (like code promotion), you want your build scripts to be branched and synchronized with it.

A new and more script-specific guide has also been published at http://www.codeplex.com/TFSBranchingGuideII