How to schedule a Team Build

Team builds in TFS2005 do not have a built in automated scheduler available.
Yes, that’s right you read correctly – the tool billed as a continuous integration platform does not provide an easy way to schedule the build types out of the VS environment – that’s crazy!

However, there is a command line tool “TFSBuild.exe” that you can use to start a build.
Therefore you can manually create a windows schedule to kick the build off at set times and here is a quick step guide if you are having problems with this:

1. In the source control folder for the team build type, create a .bat file (e.g. My
2. insert the following in the bat file and check it in:
   TFSBuild start http://192.168.1.x:8080 ProjectName “Build Type Name”
3. Log onto the TFS box and get latest from source control on the team build type
4. Go to Start -> Programs -> Accessories ->System Tools ->Schedule Tasks
5. Set up a new schedule task to run the bat file
6. Ensure that the “Start in” path is set to “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE”

In TFS 2008 this has been addressed and options are available on the right click of the build type in the Builds menu to facilitate this.

The Visual Studio 2005 Process Editor (WIT changes part 2)

In part one I discussed the value of the process editor and the installation of the Power Tools download.

In this second part I wanted to show the capabilities of the process editor itself.

Once the Power Tools are installed, Visual Studio 2005 has some new integrated menu options available.
When in Team Explorer the “Team” menu now has an extra option available for “Process Editor”:

The first item in the list facilitates opening and working on a local process template.
These process templates can be downloaded from the Team Server by using the existing “Process Template Manager” on the Team -> Team Foundation Server settings menu option.

The second menu item is the one used to make the changes on the work item and the options are:

• Open WIT from server
• Open WIT from file
• Import WIT
• Export WIT

This is where automation of the witexport and witimport command line process comes in -from the process editor I can now do all of my work item changes and upload them to the server project using this handy tool.

The third option is for Global Lists allowing storage of listitem values for the whole team to use on work item fields.
The options are the same as for WITs – open from server/file, import and export.

The final option to explore is the fourth in the list – Work Item Field Explorer.
With this I can connect to the server and explore all available fields, including the customised ones.

That’s it – a brief exploration of the process editor.
In the third part of this post series, I will look at making the changes and uploading them to the server.

Using Team Foundation Server Power Tools (WIT changes part 1)

Recently I’ve been customising work item templates in team foundation server – the company I am at have previously been using the CMMI process out-of-the-box but inevitably after some continued use the process now needs some changes and some work item adjusted.

I realise that some companies customise straight away – their processes are clearly defined and TFS needs to be implemented in a particular manner in order for the team to function correctly.
Our situation was less rigid, so it was decided to go with the standard process until it was felt that changes were needed.

Changing work item templates, when new to team foundation server seems quite daunting – the first things I needed to learn about changing the work item templates were the witimport and witexport commands – these allow the import and export of XML definitions for work items on an existing project via the command line and editing the xml by hand was fiddly to say the least.

But with the use of the Team Foundation Server Power Tools it is a relatively painless process and in the latest release, the Visual Studio Team System Process Editor saves the day – it enables a visual representation of the work item templates and processes and allows you to easily customise them, all integrated into Visual Studio.

Before I installed the power tool, I first had to check if I had the Domain-Specific Language Tools for Visual Studio 2005 Redistributable Components installed (what a mouth-full!) as this is a pre-requisite for the process editor.
I didn’t, so I downloaded and installed this first.

Now I was all set up and ready to go – time to make the changes!

In the second part I’ll be exploring the process editor capabilities and what we used to effect our changes.

Branching in source control musings

Every week I’ll be looking to share a particular topic that I’ve been thinking about usually based on a post from an interesting blog or article.

This week, the post that got me thinking the most was one on the coding horror blog entitled Software Branching and Parallel Universes.

In the current environment I’m working in there is no branching involved – all code is developed in the same common code and exclusive checkouts are used to ensure that no cross-over or interference occurs. This limits the opportunity for parallel development, but to be honest that isn’t really a factor with so many products for us to maintain at any one time – that is probably the defining factor in the lack of branching use.

That’s not to say it hasn’t been discussed and that initial discussions haven’t taken place on it. Unfortunately most of these discussions haven’t evolved into anything concrete, but perhaps the Coding Horror post will spark something into life for us.

Branch per Task
Every development task is a new, independent branch. Tasks are merged into the permanent main branch as they are completed.

This is probably the most appropriate to my current environment – we have internal web site projects (many of them!) that don’t really version… they get enhanced as new functionality is plugged in or change requests are developed and implemented.

A task orientated approach may prove very useful but it brings back questions that we have faltered on before (and effectively given up on).
Say we have a website – websiteA – and this has 5 common core class library projects that it shares with up to 10 other sites. A change request may result in a branch being created for websiteA-Change1045 (as an example) and this can be worked on in isolation.
However, invariably some changes require the common code to be improved upon in some way and here we will also have to branch each and every component library we wish to modify. Without a clear branching strategy we can see that this could get ugly.. especially as simply typing inside a file in VS2005 automatically checks out the file behind the scenes with no confirmation request.. this would be very easy to do on the existing “release/original” code for those libraries in source control.

I guess it is all about thinking ahead with that clear branching strategy and also what advantages this gives to the build features of Team Foundation Server that we currently use.
At present we cannot build to a UAT environment automatically due to the nature of the check-ins happening on the common code (they often occur post-development but pre-full integration testing).

On a lighter note, the post also suggests thinking about branching in terms of parallel universes:

Perhaps the most accessible way to think of branches is as parallel universes. They’re places where, for whatever reason, history didn’t go quite the same way as it did in your universe. From that point forward, that universe can be slightly different– or it can be radically and utterly transformed.

One of the recent definitive parallel universes is the Star Wars Infinities series from Dark Horse Comics.
It is silliness in a world that is revered by many and is a recommended read if not solely for it’s boldness in taking on the canon pedants.

Undo a check out in Team Foundation Server source control

Almost every team that uses source control will inevitably find themeselves in a situation where a file is checked out and locked and needs to become available for someone to work on it. Often the person who has the file checked out is currently on holiday or has left the company or, as with our recent situation, the original machine used for the check out no longer exists.

In Team Foundation Server source control, the workspace is a local copy of the files on the server and this copy is isolated from any other changes that may occur on the files. You can in fact have multiple workspaces across different machines – something that happens frequently for contractors who hot-desk.
If one of these machines is rebuilt or simply dies, the original workspace relationship on the check out in source control remains and the file can never be checked in.

So how do you undo a check out?
First, you must have administation priviliges; secondly, if you are not in a domain-controlled environment (as is our situation) you have to be on the team foundation server itself.

Using the Visual Studio 2005 Command Prompt, you can make use of the TF command-line utility to issue a command to undo or unlock the check out.

In our experience, the Undo Command was the operation best served to reverse the check out and lock actions as this “removes pending changes from a workspace”:

TF UNDO $filepath$ /Workspace:$workspace$;$user$ /s:$server$

e.g. TF UNDO $/MyProject/Folder1/File1.cs
        /Workspace:MX4545;john.smith /s:http://myteamserver:8080

Note that you must specify the workspace and user that you wish to reverse actions for – if you are unsure of the current workspace that the file is checked out under, simply go into your source control and attempt to check the file out.
You will receive a warning informing you of the user and workspace the file is checked out to.

Note that when you run this command successfully what appears to be a yellow error comes up in the command window:
“The workspace MX4545;john.smith is not on this computer. Run get (get all if edits were undone) on the computer hosting that workspace to update it with the changes that have been made on the server.”
This is infact showing you that it was successful but the files for that workspace/user require a get latest to become up to date with your undo changes you have made.

An alternative method to unlock the file is the Lock Command:

TF LOCK $filepath$ /lock:none /Workspace:$workspace$;$user$ /s:$server$

… but we found this problematic due to the following note in the msdn documentation:

Having the Unlock other user’s changes permission set to Allow is required to remove a lock held by another user if you do not have Write permission for that user’s workspace.

One other handy command related to this is the Status Command with which you can obtain a list of all files checked out to a particular user – particlarly useful when a user no longer exists and you need to undo all files checked out by that individual.