This session will provide some insightful and practical guidance around branching and merging with Team Foundation Server. Setting up a specific version control structure for a new Team Project and defining the appropriate Branching strategy go hand-in-hand and need to be addressed before development starts. We will look into different scenarios how to support parallel development and how the new branching visualization features in TFS 2010 will help you to understand the big picture. In addition this session will cover guidelines on how to include a versioning strategy in your Team Builds to synchronize build numbers and assembly version numbers.

Slides were already dropped at the download section. Let me know if you would have comments/feedback on the session!

Everybody should be already familiar with Continuous Integration or should I say Continuous Building?Automatically building a development codeline after a check-in is often not immediately followed by an integration action towards a main branch. I picked up the term Continuous Building in this article of Martin Fowler.

Apart from the fact how this “build automation” should be called, there are many reasons why you should enforce this behavior on different branch types for your applications. The ultimate goal is to improve the quality of the software application and to reduce the time to release the application in production. By setting up early validation (compilation, automatic testing + other quality gates) through “build automation” you will at least be notified as soon as possible of all kinds of validation errors (= quality check) and you will have a chance to fix them before other team members will be impacted by pulling a get latest on the repository.

Automatically firing a validation build after a check-in will in the end not prevent broken builds and that’s where the Gated Check-in Build will come into play with Team Foundation Server 2010.

The Gated Check-in Build in TFS2010 will prevent broken builds by not automatically committing your pending changes to the repository, but the system will instead create a separate shelveset that will be picked up by the Gated Check-in Build. The build itself will finally decide if the pending changes need to be committed to the repository based on the applied quality gates.

The picture above describes the full process of a Gated Check-In build.

How to setup a Gated Check-in build?

The Trigger Tab in the Build Definition window has now an extra option for selecting Gated Check-in.

At the moment a check-in is attempted by a developer in the branch where the Gated Check-in build is active, the developer will be faced with a dialog box.

Cancelling this window will not kick off the build, but will also not commit your pending changes to the repository. If you really want to overrule this build with committing your changes directly to the repository, you may select the 2nd checkbox to bypass the validation build (not recommended). By default your pending changes will reside in your local workspace (first checkbox). In the situation where you immediately want to start with new changes – not relying on previous changes – it might be appropriate to uncheck the first option.

In the ideal situation, the build will complete without any validation errors and will eventually commit the changes to the repository. This will also lead to a Gated Check-in notification for the original committer via the Team Build Notification tool.

If you had previously chosen to preserve the changes locally (default), you may have noticed that the files you were working on were still checked out during the build … and in fact after a successful build these changes do not reflect the as-is situation anymore of the repository. With the above window you get the option to immediately reconcile your workspace with the up-to-date repository. So, clicking the “Reconcile …” button will give you the opportunity to select the desired files to force an undo in your local workspace and to pickup the changes that were committed by the Gated Check-in build for these files.

Another way to reconcile your workspace (if you for example ignored this window or when the build notification is way too slow) is by right-clicking the completed Gated Check-in Build in the Build Explorer and selecting the option to reconcile your workspace.

If you did not choose to preserve the changes locally, there won’t be any changes to reconcile after the Gated Check-in build, even if you forced the reconciliation.

The Gated Check-in build may also be kicked off manually where you may need to create a shelveset or where you may point to an existing shelveset.

A last thing to note is that the comment that was originally supplied to the changeset by the developer will be suffixed with the NoCICheckinComment variable (default = ***NO_CI***) to prevent that another continuous integration build will be fired after the final check-in done by the Gated Check-in build.

Summary

What meant to be a small post on the Gated Check-in feature in Team Foundation Server 2010 ended up in a more detailed explanation of how it works and how you can work with it in the Visual Studio IDE. Remember that you should setup the most appropriate build types according to your specific branches. Not all branches may need a Gated Check-in build. Only configure this for branches that should never have a broken build. A Gated Check-in build may for example validate a big merge operation from a development branch to a stable main branch.

This week I’m in Las Vegas (on invitation by IDesign) for the launch of Visual Studio at Devconnections. The Launch Day of Visual Studio 2010 was great but on Tuesday and Wednesday there’s also a promising Application Lifecycle Management track I want to follow.

Visual Studio Lab Management 2010 enables teams to accelerate setup/tear down and restoration of complex virtual environments to a known state for test execution and build automation. It extends build automation by automating virtual machine provisioning, build deployment and build verification in an integrated manner. It also allows testers to file rich bugs with links to environment checkpoints that developers can use to recreate complex environments, effectively reducing wasted time and resources in your development and test lifecycle.

A week ago at my main customer SD Worx in Antwerp, I managed to install a full-blown Team Foundation Server 2010 (RC), including Visual Studio Lab Management (RC) in an isolated environment.

I really got spoilt and got two physical servers at my disposal with each 20GB of RAM. This is the current configuration:

Note that the Team Foundation Server 2010 is setup with Network Load Balancing (NLB) for TFS services. I also should setup NLB for Reporting Services and WSS on both AT servers. SQL Reporting Services is installed on the application tier while SQL Analysis Services is installed on the data tier. One Team Project Collection is created with one MSF Agile Team Project. A Build Controller for the Team Project Collection is setup on Build Server A that manages a Build Agent on Build Server A and another Build Agent on Build Server B.

The second physical server will also serve as the HyperVHost machine, the VmmMachine and LibraryMachine for Visual Studio Lab Management.

This setup should give the opportunity for a small workgroup to further test the benefits of the entire Team Foundation Server 2010 environment. In total I must have spent about 4 days in installing and configuring this setup. I did follow the guidelines on the Visual Studio Lab Management Blog where the team posted a series on Getting Started with Lab Management.

I was really happy with the fact that the installation/configuration of System Center Virtual Machine Manager and the other more IT Pro related stuff was pretty straightforward. More information on Lab Management can also be found at MSDN.

Next step is to schedule some internal workshops with the team to kick-off all the testing on the platform. Pretty excited to see this evolve!

I also want to thank the Lab Management Product Team for their support and follow-up of this installation at my client. To be continued!

Dear Pieter Gheysens,Congratulations! We are pleased to present you with the 2010 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Team System technical communities during the past year.

Looking forward to another very interesting “Team System” year with the final release of Visual Studio 2010 just around the corner! The release of Visual Studio 2010 will probably also be the time that the “Team System” moniker will disappear in the MVP title. I’m still not sure what the new title will be like: Team Foundation Server MVP? ALM MVP? Visual Studio MVP? Visual Studio ALM MVP?

A demo on Branching & Merging with TFS2010 was the major part during the presentation and I did practically cover everything I wanted to share with the audience: Branch metadata, Fine-grained security, Branching Visualization, Tracking individual changesets across branches, forward/reverse integration … except for one little important merge action that I forgot to show!

After the creation of my dev branches (from main) I also renamed the solution in those dev branches with an additional suffix to avoid confusion while loading different solutions into Visual Studio 2010. This was done in changeset 121 and I renamed the solution from WebsiteSparkles to WebsiteSparkles_dev1.

Afterwards I did some code changes in the dev branches and pushed some explicit changesets back (Reverse Integration) to the main branch, using the cherry pick option in the merge wizard to avoid merging also the solution rename.

As a result changeset 121 will always remain a merge candidate in the Source Control Merge Wizard.

In some cases you really want to merge changes back to main on the latest version of the development branch without cherry-picking all required changesets. To be able to do that, you need to get rid of changeset 121 as a merge candidate.

This can only be done through the command-line with the tf merge /discard command.

This discard command will make sure that changeset 121 will not be a merge candidate anymore. Note that you still need to commit this action to the repository after executing the command. The discard command will only update your local workspace but won’t do an automatic check-in.

Next time you will run the merge wizard and look for merge candidates, changeset 121 won’t be listed anymore and you may merge from a latest version of this development branch for upcoming changes.

Providing this discard command from within the source control merge wizard would be a very nice addition!