I’ve recently decided to wrap up my previous at home project and start a new project code named WheelJack. I will be posting sometime in the future what WheelJack actually is, but for now you’ll just have to guess based on what I’m writing about.

I will be using Team Foundation Server to manage the project, source code, work items, builds, etc. While we have TFS where I work, we do not utilize all of it’s functionality, and part of this new project is an attempt to better understand what TFS can bring to the table.

I will have to admit that it’s a complete overkill for a single developer scenario, and I face a very real risk of loosing precious time dealing with TFS, but in the end I think it’s worth it. If it becomes to much of a burden, I can always switch over to subversion and re-task the SharePoint site with project management.

Before I sit down and start writing code, I need to setup a new team project, determine my branching strategy, and get Team Build running for nightly and continuous integration builds. For this project I will be using the Scrum Template for Team System created by Conchango.

Detailed instructions for installing a new template into TFS and creating a new Team project are outside the scope of this post. Provided that you have full administrative rights to the TFS box, the MSI installer does all the heavy lifting, and creating a new project is a 5 step wizard process.

With my new project created I can begin adding work items to the product backlog, define sprints, and areas. I’ve also created a Wiki on the project SharePoint site to various information, including feature description, architecture, design and implementation details. The wiki is a great tool to use when working on a project because it is so easy to create content and organize content.

With all of that out of the way for now, I can move onto creating my source tree, which involves the selection of a branching strategy. The branching strategy used for WheelJack is the Single Team Branching Strategy as defined in TFS Branching Guide version 2.0.

Single Team Branching Strategy

The single team branching strategy requires 3 branches, MAIN, DEV and RELEASE, where DEV and RELEASE are branched from MAIN. While I say 3, there will in fact be more then 3 actual branches. Whenever a new release is created, it gets it’s own branch. This strategy also allows for concurrent DEV branches.

Working in DEV

After each successful nightly build, code should be merged from MAIN to DEV. In this project, with only one dev branch, and only one developer, there will usually be nothing to merge. The following situations are examples of when there will actually be code in MAIN that needs to be merged to DEV.

• Once we create a release branch, if a show stopping bug is discovered and fixed in a release  branch, that change is merged to MAIN, and then merged from MAIN to all dev branches.
• If we have multiple dev branches, changes in one DEV branch could be merged to MAIN, and then from MAIN to all other dev branches.

Key features of working in DEV (taken from TFS Branching Guide)

• Focus on wide, flat branches to enable steady code flow to MAIN and then back to peer DEV branches
• Work in DEV branches can be segregated by feature, organization, or temporary collaboration.
• Each DEV branch should be a full branch of MAIN.
• DEV branches should build and run Build Verification Tests (BVT’s) the same way as MAIN.
• Forward Integrate (FI) with each successful build of MAIN
• Reverse Integrate (RI) based on some objective team criteria (e.g. internal quality gates, end of sprint, etc.).

Working in MAIN

Aside from the initial solution and build creation, no work should be done in Main.

Working in a Release Branch

Work in production should be limited to show stopping bugs. Changes should be merged into Main once completed. The following list was taken from the branching guide.

Key features of working with Release Branches (taken from TFS Branching Guide)

• Each RELEASE is a child branch of MAIN.
• Your major product releases from the RELEASE branch and then RELEASE branch access permissions are set to read only.
• Changes from the RELEASE branch RI to main.  This merge is one way.  Once the release branch is created MAIN may be taking changes for next version work not approved for the release branch 
• Duplicate RELEASE branch plan for subsequent major releases. This means there will be one branch per major release.

Source Code Repository Directory Structure

• WheelJack$
  • DEV
    • 1.0 (Version or Feature)
      • Identical to Main
    • 1.1 (Version or Feature)
      • Identical to Main
  • MAIN
    • Source
      • Project1
      • Project1.Tests
      • Project2
      • Project2.Tests
      • References
    • BuildTypes
  • Releases
    • Release 1.0
      • Identical to Main
    • Release 1.1
      • Identical to Main
    • Release 2.0
      • Identical to Main
    • Release 2.1
      • Identical to Main

Every branch from Main contains everything that is in the Main branch, including the Source and BuildTypes folder (BuildTypes contain the Team Build files that define a build).

I started out by creating a new folder on my hard drive that corresponds to the root folder TFS (WheelJack$), and working my way down the hierarchy for Main, creating Source and BuildTypes folders. My project contains a server piece and a client piece, so starting with the server side, I created a folder named MessagingServer, and then created 4 projects under that folder. I also created a _Solutions folder under WheelJack which is where I store all of my Visual Studio Solution files (*.sln). The solution files are not checked into source control.

Below you can see what my folder structure looks like in Windows Explorer, and in Solution Explorer.

After cleaning up the project names, namespaces, and adding the correct project references, I was able to begin looking at setting up the automated builds. I’ll pick up here next time.