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 CruiseControl.net 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.
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:
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.
Results Top Level Tests
Passed (All Tests/)SederSoftware.BranchingExample2.Tests.UnitTest1.TestMethod2
Passed (All Tests/)SederSoftware.BranchingExample2.Tests.UnitTest1.TestMethod1
3/3 test(s) Passed
Test Run Completed.
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…
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.