Starting back up with TFS

Earlier in the year, I set up Team Foundation Server 2010 and have used it as a basic source control system. I also set up for continuous delivery for a couple of websites too. However, I didn’t really deal with a branching/merging plan though.

At work, we use extremely old tooling and don’t use TFS. However, we’re slated to start with VS2010, and TFS is being piloted. Additionally, it’s been on my list to get a better understanding of using TFS in a production environment. So, here I am – digging in!

Co-worker Jamie ran across the ALM Rangers, a group of people at Microsoft that have addressed documentation and real-world best practices around setting up TFS.

In particular, there is this guidance documentation that they offer:

Visual Studio TFS Branching Guide 2010

It’s a .zip file that contains several PDF’s and a PowerPoint slide deck. It’s fantastic at covering the basics of branching and merging, and it has a lot of smart things to say about putting together your branching strategy, for your TFS implementation.

I have a couple of sample TFS projects where I’m actually going through and implementing what they suggest. I don’t have it all locked down as of now, but I’ve made some progress.

Check-In Policies:
First, even aside from branching/merging – I wanted to get the check-in policies squared away. In Team Explorer from within Visual Studio, if you right-click on the Project, choose “Team Project Settings…”, then “Source Control” – you’ll see a screen like this:


I’ve added these check-in policies: Builds, Changeset Comments, and Testing. I added builds because you really should make sure your solution builds before you check in any files; comments because they are useful, and testing policy because all unit tests should pass before you check in.

This all works as expected, if I didn’t do these things, I get a warning like this:


Getting the Testing Policy to work automatically:
Now, I’m a fan of everything being as automated as possible. For example, I would want the unit tests to run as part of the build. Oh! That’s easy, I’ll just create a post-build script for the unit test project. This took a little trial-and-error, but using this as a post-build script, seems to work well:

cd "$(SolutionDir)"
mstest.exe /testmetadata:"$(SolutionDir)$(SolutionName).vsmdi"

Now, when you do a Build Solution, sure enough, the unit tests run:

—— Rebuild All started: Project: SederSoftware.BranchingExample2.Tests, Configuration: Debug Any CPU ——
  SederSoftware.BranchingExample2.Tests -> K:TFSSederSoftware.BranchingExample2DevelopmentSrcSederSoftware.BranchingExample2_SolutionSederSoftware.BranchingExample2.TestsbinDebugSederSoftware.BranchingExample2.Tests.dll
  Microsoft (R) Test Execution Command Line Tool Version 10.0.30319.1
  Copyright (c) Microsoft Corporation. All rights reserved.
  Loading K:TFSSederSoftware.BranchingExample2DevelopmentSrcSederSoftware.BranchingExample2_SolutionSederSoftware.BranchingExample2_Solution.vsmdi…
  Starting execution…
  Results               Top Level Tests
  ——-               —————
  Passed                (All Tests/)SederSoftware.BranchingExample2.Tests.UnitTest1.TestMethod2
  Passed                (All Tests/)SederSoftware.BranchingExample2.Tests.UnitTest1.TestMethod1
  Passed                SederSoftware.BranchingExample2.Tests.UnitTest1.TestMethod3
  3/3 test(s) Passed
  Test Run Completed.
    Passed  3
    Total   3
  Results file:  K:TFSSederSoftware.BranchingExample2DevelopmentSrcSederSoftware.BranchingExample2_SolutionTestResultsrseder_RCSWS01 2010-12-19 09_15_24.trx
  Test Settings: Local
—— Rebuild All started: Project: SederSoftware.BranchingExample2, Configuration: Debug Any CPU ——
  SederSoftware.BranchingExample2 -> K:TFSSederSoftware.BranchingExample2DevelopmentSrcSederSoftware.BranchingExample2_SolutionSederSoftware.BranchingExample2binDebugSederSoftware.BranchingExample2.dll
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========

Yet, when I then try to check the solution in, I get this:


When I compare click the GUI button to run tests, and running them manually – they both generate a file in the TestResults directory off of the root – which is what I was expecting this policy to check for.

However, it seems to be looking at something in the UI, instead. Because if I simply double-click the latest test run (which occurred from the last Build Solution) from the “Test Runs” window, it brings up the “Test Results” window.

Without doing anything else (and remember, I didn’t re-run the tests) – I can now check in. There is something about interacting with the VS GUI that satisfies this testing policy, where ACTUALLY running the tests doesn’t. That’s pretty annoying – so I’m still investigating this…

Next Steps:
I want to figure out The Riddle of the Testing Policy described above. Also, I want to try the branch/merge techniques described by the TFS Rangers (noted above).

One thing I didn’t really get and I haven’t figured out – is how to automate some of this stuff. So much of of branching, merging, versioning, etc is all GUI-based and requires a lot of clicking. It seems to me it may be better to be able to script some of this stuff.

For example, what if it’s Monday morning and I want to rebase from the Main branch so I pick up the latest changes – but I click on the wrong stream (not to cross-polinate ClearCase terms)?

I might just breeze past this dialog:


Woops! I just merged my development stream in with Main, rather than merging Main into my development stream. It seems that things like this should be automatable, and they may be – but that’s one of the other things I want to try to get past. Otherwise, to leave the developer to click a bunch of times, that seems like it’s going to be error-prone.

Posted in Team Foundation Server, Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9 other followers

%d bloggers like this: