July 2007 Archives

Now that the V1 of the TFS Migration and Synchronization Toolkit is up and running on CodePlex, Matt and the team are looking for feedback on what systems you would like migration options allowing you to abandon your old system and move to TFS.  Please spare a moment to take a look at the features suggested and vote for your favorite.

If you are going to get into the Zen of TFS Team Build, then at some point you are going to have to read the TeamBuild .targets file (located in %ProgramFiles%\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets).  The TeamBuild build scripts are usually extensions of this master build script.  In Orcas the script has has several revisions to make sure as many hooks are provided as possible, but extraordinary lengths have been gone to to make sure that scripts written to target the old (VS 2005) version of the file will still work with the new one.   The problem with all MSBuild scripts, and a problem that is shared with Nant and Ant scripts alike, is that they take a little bit of working out.  You cannot just pick up a script and read it from beginning to end due to the way that dependencies work in these process execution languages and the fact that you can have multiple entry points.  Fortunately, the TeamBuild .targets file is very well commented and there is also additional documentation available on MSDN listing the points you should start to look when hooking in your logic.

However, when you eventually override your first target to write a custom bit of code in the build process, you are going to need to know some properties that are available for you.  Below is my list of 30 build properties that you will find useful.  There are over 70 available if you read the target file you will find them all, these are just the ones that I find most useful - some to read the properties available, and some to override to easily alter the behavior of the build script.

With Team Build in Team Foundation Server, you can have multiple build types for multiple projects.  For example, we have a build that runs fast that we can have running Continuous Integration on, and a slower build (that does obfuscation, release packaging etc) that is run on demand when we want to perform a release to QA (some of which later go on to become public releases).

A neat feature in the Team Build stuff is that you specify a drop location for your builds and the packaged binaries along with the build log and test results will be placed in a folder corresponding to the build name.  In all the demos you see, this will typically be specified as something like \\server\drop and you may well do this yourself at first.  Pretty quickly the drop folder will fill up with builds and get confusing.

A better way is a rather simple solution that I almost didn't mention, however when I mentioned this to a friend of mine and it caused some head-slapping, so I thought I'd discuss it here.  Apologies if you'd already figured this out this rather basic step.

Simply, put your builds into folders.  Something like:-

• \\server\drop\product\buildType\

To give an example:-

• \\jeeves\drop\teamprise\ci
• \\jeeves\drop\teamprise\release

You can obviously take this further if need be.  For example we currently have builds going on in two main places, we are putting Teamprise 2.2 through final testing while, in parallel, we work on the next major release in trunk.  In the example above, it means we have 4 builds types in total and can follow the convention of \\server\drop\product\branch\buildType to make:-

• \\jeeves\drop\teamprise\2.2\ci
• \\jeeves\drop\teamprise\2.2\release
• \\jeeves\drop\teamprise\trunk\ci
• \\jeeves\drop\teamprise\trunk\release

 Pretty simple really, but helps to plan this stuff up front.

A new project has been released over on CodePlex from the Patterns and Practices folks which attempts to improve the guidance generation process.  

"The interim solution makes it easier to customise the narrative guidance than the current mechanisms, but I should emphasize that it will be replaced by our longer term solution. Please use it in the meantime if you'd like to, but don't place any reliance on it being there long term."

I've just taken a quick look at the tool.  While it is faster than MSFWinBuild it is still quite rough around the edges and you are still left editing the guidance XML file (which for Agile is a single file with over 10,000 lines...).

Any software processs should evolve as you change it to meet the stengths and weeknesses in your organization.  As those stengths and weekness change, but also as new tools, techniques and technologies are made available, so your process will need some tweaking.  With the current tooling, many teams let their process guidance pages get out of date with their actual process usage - which is a very bad thing (especially when a new member of the team joins or worse, the external auditor comes to inspect your team).

It is a very welcome development that work is going on in this area.  I cannot wait to see that "longer term solution" when it arrives, in the meantime I'll be using the process generator tool.

People go on about iPod + iTunes + Store being this all time great combination.  I'll admit that I love my iPod, and if/when one comes out with similar capabilities to the iPhone player I'll be buying it.  However, I don't think I'm being controversial here when I say that iTunes on Windows really sucks.

It's not just the fact that the interface is alien to the OS in which it is running, or the fact that the much vaunted coverflow is much less "scrolling like butter" more "scrolls like screeching fingernails on a chalkboard".  It's not even the fact that it is a highly intrusive install, requiring QuickTime and making it take over more default file types than it should.  It's just the fact that it is really buggy, has a habit of totally crashing (especially when I am trying to access the iTunes store), occasionally trashes it's own library xml file that it requires for some reason and is a complete resource hog.  The software sucks.

What is worse is that the initial release of an iTunes version *always* sucks.  This is a universal given.  Recently 7.3 was pushed out the door to enable the iPhone on June 29th.  On July 11th they released a new version 7.3.1 - the release notes? iTunes 7.3.1 fixes a minor problem with accessing the iTune library.  Well, at least they've hopefully fixed that one then.  But seriously - every time a new version of iTunes is released, a bug fix release follows shortly after for some pretty easy to spot regression.

I'm not just ranting because I'm hacked off at having to go through another install and then clean up (to fix all the defaults that QuickTime has taken over), or the fact that they repeated exhibit the same quality mistakes when releasing software.  It is the fact that you'd think the quality of iTunes on Windows would be really important to their overall business model.  You'd think that iTunes should be one huge billboard for them on their switching campaign?

I'm guessing that the iTunes team is a pretty small one at Apple.  I'm guessing the Windows team is possibly the poorer cousins of the rest of the development.  I wish they would spend a little bit more effort on their Windows releases.

Rant over.  I'm about to head over to Teamprise HQ this weekend involving plenty of flying time, hence why was so annoyed this morning when I found all my podcast subscriptions had been lost.  Sigh.

As I've mentioned before - keyword expansion is a feature that many SCM tools have, but TFS does not.  Buck Hodges has just published an excellent post on why this is the case and talks about some of the approaches that people have tried to get around this.  Definitely worth a read.

This took me a while to figure out, so I am writing down here to help me remember later.  It may also be useful if you are playing with Gmail at all (BTW, the spam filtering on Gmail is very good).

To mark all mail as read:-

1. In the search box, type "is:unread"
2. In the select area press "All"
3. A link will appear that says "Select all conversations that match this search", press it
4. From the drop down, select "Mark All as Read".

Took me a while to do something that is usually option away on a context menu in most rich client mail reading applications, but this is mainly because I had thousands of unread mails to mark and so that went off the page.