I couldn’t find any additional information (eventlog, TFS Log, …) about the root cause of this failure, but while limiting the test methods for the test run I bumped into a test method which name consisted of 461 characters!

Apparently there’s a hard limit of 256 characters for the test method names that are published to the TFS data warehouse.

My demo should finally be ready now. I will show the complete Lab Build Workflow to build, deploy and test a web application in a virtual environment.

My slides are already availabe for download in the download section of my blog.

I’m also planning to record the demo (screencast) I will be showing at Community Day to put it online at my blog.

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!

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.

• Improving Your Software Development Processes with Visual Studio 2010 (Joel Semeniuk)
• Defining and Managing Software Requirements with Visual Studio Team System (Joel Semeniuk)
• Implementing Scrum Using Team Foundation Server 2010 (Richard Hundhausen)
• Agile Database Techniques Using Visual Studio Ultimate 2010 (Richared Hundhausen)
• Modeling and  Visualization in Visual Studio 2010 (Joel Semeniuk)
• Team Foundation Server 2010—Migrate or Integrate? (Richard Hundhausen)
• Lab Manager – The Ultimate “No More No Repro” Tool (Steven Borg)
• Visual Studio 2010 Quality Tools for Developers (Steven Borg)

I will also be present at the IDesign booth to promote IDesign’s unique Training Classes in Europe. A training class that’s already announced is the Architect’s Master Class with Juval Lowy in Belgium in the week of October 11, 2010.

And this all happens in the Bellagio at Las Vegas! Looking forward to a great week here!

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:

• Physical Server 1 (Windows Server 2008 R2 with Hyper-V):
  • TFS2010AT_A: Application Tier TFS2010 (Windows Server 2008 R2 – 4GB RAM)
  • TFS2010AT_B: Application Tier TFS2010 (Windows Server 2008 R2 – 4GB RAM)
  • TFS2010DT: Data Tier TFS2010 (Windows Server 2008 R2 – 4GB RAM)
• Physical Server 2 (Windows Server 2008 R2 with Hyper-V):
  • VS2010: Client with VS2010 Ultimate (Windows XP Pro with SP3 – 3GB RAM)
  • TFSBUILD2010_A: Build Server (Windows Server 2008 R2 – 2GB RAM)
  • TFSBUILD2010_B: Build Server (Windows Server 2008 R2 – 2GB RAM)
  • TESTVM: Virtual Environment for testing Lab Management (Windows Server 2008 R2 – 2GB RAM)

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.

• Part 1
• Part 2
• Part 3
• Part 4

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?

The session slides can be downloaded in the download section of this blog.

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!

Be sure to download the Upgrade Guide on the blog of Bryan Krieger to proceed with your upgrade to RC!

After the uprgrade process, the version seems to be already RTM?!

Also the TFS Build configuration wizard seems to be smart enough to keep/upgrade existing resources from Beta 2.

While upgrading my full-blown Team Foundation Server 2010 to RC on Windows Server 2008 R2, I must admit that I got an issue while upgrading the Team Project Collections. The wizard apparently got stuck due to some issue with the TFS application pool that wasn’t able to startup correctly. Force a rerun of the job in the Team Foundation Administration Console if you would be confronted with this issue!

While preparing and delivering this course I became even more convinced that the testing offering with Visual Studio 2010 really rocks. Some specific testing features (manual testing with action recording, IntelliTrace, Test Impact Analysis, Coded UI Test, …) will be hard to miss once you get to use them in practice. Testers and developers will certainly be able to work more closely together to reduce the time it takes to find and fix software defects … and that’s what it’s all about in writing quality software!

All my demos did also work fine on the RC release of Visual Studio 2010, so I was pretty happy that I decided to prepare a RC image to use for the course.

I definitely need to blog about some of the cool collaboration stuff between development and testing teams. Note to self: free up some time!

Slidedeck is available at the download section.