Monthly Archives: May 2006

Marathon Blogger

Seems to be a fitness related day today. I got my pack for the Global Corporate Challenge today and I am just trying out the pedomiter. The competition officially starts tomorrow and I get to see how my daily walking activity compares to the others in the company. I’m looking forward to it.

On the health and fitness topic, a friend of mine has just started bloging (not sure if he wants to keep his name top secret or not). Anyway, I met him around the time he started running again. He would come back into the office looking like a tomato. Anyway – subscribed!

Darren interviews Ian Griffiths on Vista Vibes!

Its the vibe!

Darren Neimke is hosting TechTalkBlogs at the moment, and one of the things he has kicked off is Vista Vibes (onetwo and three – currently). The idea is to get real peoples opinions on Windows Vista before the marketing department has a chance to put any spin on it, or before the industry pundits get to have their two bobs worth. Because its still not released the people that Darren are interviewing tend to be technical folk who love living on the bleeding edge – the trail blazers if you will.

The first Vista Vibe was with Frank Arrigo and although Frank runs the DPE team at Microsoft, he is usually pretty forthcoming with his own opinions. The second Vista Vibe was with Grant Holliday who has been having fun getting all his kit working on the new operating system. Finally, the third Vista Vibe is with Ian Griffiths who will probably need to take out a restraining order against Joseph because of the whole fan-stalker thing.

One of the things that I liked about Ian’s interview is that it explained why so many people do the spinning textbox demo in WPF, but he also points out how we really need to move beyond that though. I disagree however that WPF isn’t really for Line-of-Business applications. I’m convinced that building lots of small task orientated Navigation Applications in WPF is the way to go for a lot of enterprise development scenarios, especially when you couple it with secure-by-default WCF communication channels, ClickOnce and start menu/shell enhancements.

Keep up the good work Darren – who is next?

Release: Build Clean-up Service for Team Foundation Server

The Team Build facility in Team Foundation Server allows development teams, and in particular configuration managers to define a build that can be performed on a remote server at the click of a button. After the build is complete the results of that build process are uploaded to a drop location on a network volume somewhere.

Builds that are performed can quite often be rejected because of a failure caused by a file not being checked in, or some debug-time setting propogating into a build destined for release. Other builds may be rejected at a later date due to functional testing identifying a problem.

BuildHistory

While recording details about each build that is performed is useful from an auditing perspective, storing the actual artefacts from that build does come at a cost – a storage cost. The solution is to regularly clean the old rejected builds out of the drop folder to reclaim space.

At Readify we try to run a pretty tight ship when it comes to Team Foundation Server. So not just anybody can go in and delete files from the drop location – that might remove good builds that may be required for diagnostics later on down the track. But how do we allow people clean-out the garbage?

Introducing the Build Clean-up Service

This is an extension to Team Foundation Server that I’ve had queued up to develop for quite some time. The clean-up service takes care of cleaning out the “Rejected” and “Unexamined” builds after a specified period of time (configurable).

After installing and starting the build clean-up service a few things happens. First, the “WorkItemStore” is contacted to get a list of Team Projects defined within Team Foundation Server, then a list of builds performed under that scope of that Team Project is retrieved from the “BuildStore”.

Each of the builds is checked in turn to determine whether it is a candidate for clean-up. The rules for determining this are as follows:

  • Has the expiry date for the build been reached? This is a basic calculation to determine whether time since the build was finished is greater than the expiry time span defined in the configuration file. Currently ours is set to fifteen days.
  • Does the drop location exist? This feature was added after I realised that during the installation of our Team Foundation Server I had tested out some builds and subsequently deleted them off the file system – this will be a pretty common scenario I think.
  • Has the build actually completed? If you set quite a low expiry time span and you happened to have a fairly long build process its concievable that the service could kick in and start trying to delete the build while it was still running. So here we make sure we are only considering whether a build is a candidate for clean-up checks for this.
  • Has the build been abandoned? Abandoned build are builds that are either in a Rejected or Unexamined state. By default all builds go into an Unexamined state, but remember that the build needs to have expired as well before it gets cleaned-up so you shouldn’t have good builds going missing before you have a chance to inspect them unless you set a really low processing interval on the service (default is one hour).

Once it has been determined that a build is a candidate for clean-up the service systematically deletes the build artefacts in each of the specified build locations. There are a few things that it doesn’t touch however. The clean-up service will not delete the build log (provided it is called BuildLog.txt) and it will wrote a “Readme.txt” file to explain what happened to the files.

In addition to that, two entries will be placed in the event log, one for the start, and one for the completion of the clean-up for each build. This provides an audit trail that monitoring software can pick up if you require that level of control.

BuildCleanupEvent

Downloading and Installing the Build Clean-up Service

Before you download, install and run the build clean-up service I want to let you know that I take no responsibility for what this does to your system. It was tested on my laptop and a live Team Foundation Server environment but I can’t guarantee that I’ve picked up every issue. I recommend that you take a backup of your drop locations prior to installing and running this service – just in case, and I would warn development teams that it is being turned on. That said – I’m pretty sure that it’ll work for you.

The first thing that you need to do is download and unzip the service onto a machine that has Team Foundation Server components installed on it. I would recommend either the application tier or the team build server (if you have those components distributed). After that you need to use the .NET Framework (2.0) installation utility to register the service on the computer:

InstallUtil.exe BuildCleanup.exe

During the installation process it will prompt for credentials for the service. One sure fire way to make sure it has the right credentials is to make it run under the same service account as the Team Build service, on most systems thats [DOMAIN]\TFSBUILD.

The final step is to edit the BuildCleanup.exe.config configuration file to point the service at the URL for your Team Foundation Server. Once that is done you should be able to start the service by issuing the following command:

net start BuildCleanupService

When the service springs to life you’ll probably get a flurry of activity, depending on how long your Rejected and Unexamined builds have been sitting around for. If you want to get a picture of what the service is doing just look at the event log on the system it is running on.

What’s next?

You tell me! If you have any features that you would like to have added to the Build Cleanup Service then shoot me an e-mail to let me know. I’ve got a few that I would like to see:

  • A Windows Installer-based setup package which includes prompts for setting up things like expiry time spans, processing intervals and the Team Foundation Server URL.
  • Warning e-mails for those that iniated builds that are going to be deleted.
  • Support for changing the build quality indicator to “Deleted”.
  • More robust error handling and logging.

Release: Team Build Restart

One of the most compelling features in Team Foundation Server is the integrated build server feature called Team Build. Team Build allows development teams to put up a build server which springs into life whenever a developer requests that a build is done of a particular solution.

I suspect that most organisations will start out with a shared build server, then as the specific build scenarios of projects become more diverse they will break them out and each team will have their own (possibly virtualised) build server – on on day one, you are going to have one build server, and more than likely its going to be on the same box as your TFS application tier.

One of the issues with doing this is that every time a new Team Project is created it needs to add the user account that the build server is running under to the [Project]\Build Services group and then restart the build service – this requires someone with administrative rights to perform this action.

During our BETA testing of Team Foundation Server we allowed all users to be administrators on the system and that quickly lead to chaos, so I wasn’t keen to go back to that, but I was less keen to become the bottle neck for a team that wanted to get their build happening – so I wrote a tool.

TeamBuildRestartCapture

Team Build Restart is a simple ASP.NET application that can be installed on the same box as your build server (assuming it has IIS). When you visit the page you are presented with a screen (above) which lets you stop and start the Team Build service. The application pool that the site is running in has to have sufficient rights to start and stop services on the box.

This Team Foundation Server tool was brought to you by the number 12:23AM, and the colour pink.

Manipulating time with software installations.

I’m just loading on the new version of the Visual Studio 2005 SDK onto my machine, but before I can do that I’ve got to remove the older version that I was using to test against the RC version of Team Foundation Server.

I only mention this because I think that the team responsible for the installer have managed to figure out how to manipulate time. The following screenshot is part of the uninstallation process.

VSIP2005SDKUninstall

What makes me think they know how to manipulate time? Well – the time remaining has been sitting at thirty-nine seconds for the last two minutes. I wonder if they will be shipping a Time Manipulation SDK any time soon.

I bet I’ll have to upgrade my machine . . .

Martin Granell is back blogging!

Martin Granell has just announced that he is back blogging. He has been crazy busy for quite a few months. Its going to be good because I’d love to throw around some ideas on what application development will look like in a Windows Vista and WinFX timeframe, especially from a strategy and architecture point of view.

Mind you – from that you might think Martin is one of those boring ivory tower architects. Thats simply not the case, Martin is one of the smartest people I know and I am lucky to share a domain name with him (@readify.net). As proof that he has got the goods, I point to one of his most recent posts on a trick he is using to optimise start-up in Windows XP.

Beware: Discussion of IO contention and global Mutex’s follows . . .

An e-mail Scrum.

I’ve been watching Darren step into his new role at Readify with some interest. One of the things that he has to do is get a handle on all the current internal projects that are kicking around. We discussed some of the issues he was having getting an appropriate level of feedback from people working on those projects and I floated the idea of having a daily scrum to improve communication.

Darren was already thinking along the same lines but the challenges were obvious – how do you do a daily scrum in a virtual organisation?

What is a Daily Scrum?

A daily scrum is a strictly controlled meeting which asks each participant three different questions:

  1. What did you finish since the last meeting?
  2. What are you going to finish between now and the next meeting?
  3. What are the impediments that are affecting your work?

These questions work really well if you hold the daily scrum each day because they narrow the scope of estimation down to approximately twenty-four hours and it gets people to commit to delivering work on a daily basis.

The first question is a retrospective so people get automatic feedback on the accuracy of their previous estimate. The second question is a the new estimate, and the third question is really for the Scrum Master who takes those impediments onboard and sees what they can do to remove them.

More important than the questions though is the manner in which they are asked. The meeting is a pure status report. Go in, provide your status, get out. No other communication (other than asking and answering those three questions) is allowed.

So what does a Readify Daily Scum look like?

Who knows – Darren has only been running them for a few days. He seems to be asking the same questions, except he is using e-mail. The difference between e-mail and a face to face meeting is that the e-mail is asynchronous and the face to face meeting is synchronous.

Using asynchronous communication gives the team members the scope to go dark and hold off answering until they have something good to report – you don’t actually want this. One of the fundamental principles of software development is get the bad news early so you have time to work around it.

The help address this issue Darren is sending out an e-mail in the morning with a quick summary of what TFS is telling him, and correlates that against what people said they would be working on the day before – but the gem is that he puts a timelimit on when people have to reply by, therefore making it “kinda-synchronous”.

I’m looking forward to seeing how this particular implementation of the daily scrum goes!