TFSBuildLab

UPDATED WIKI: Home

MOlausson — Fri, 21 Dec 2007 09:32:36 GMT

Project Description
TFSBuildLab is a project to simplify the day to day operations when using automated builds and continuous integration with Visual Studio Team System.

This project handles common Team System issues such as:

Many of these issues are handled in the TFS 2008 release (http://download.microsoft.com/download/5/9/c/59cd0dc5-4691-4c3e-840c-66d865f27692/orcas-continuous-integration.xps), but for those out there using TFS 2005 TFSBuildLab is an easy way to handle build automation. We've also aimed to be as forward-compatible as possible so the features in TFSBuildLab will be very similar (conceptually atleast) to the ones in TFS 2008.

Project Documentation

Our blogs:

Mathias Olausson - http://olausson.net/blog
Peter Blomqvist - http://peterblomqvist.blogspot.com

UPDATED RELEASE: Version 1.1 (dec 20, 2007)

Thu, 20 Dec 2007 19:23:14 GMT

It's time for yet another release (probably gonna the be the last one containing any new features since TFS 2008 is out there). The next planned release will contain a tool or guidance for converting your TfsBuildLab database configuration to utilize the features available in TFS 2008.

We have been dog fooding TfsBuildLab in production since 2007-04-24 on a several projects the largest of them consisting of 5 parallel development branches each containing aproximately 10 000 source files.

Some statistics since the start:

4969 Automatic cleanups
2511 Scheduled builds
2238 Continous integration builds

*+What's new in version 1.1:+*

We have improved the errorhandling dramaically in this release as well as tried to include more contextual information in the logs.

* Service
** Added support for multiple build servers assosiaed to a trigger.
** Added support for status notifications out build completion.
** Fixed problem with to many changeset involved in build failure notifications when checkin occurs at the same time as a build is failing.

* Admin Client
** Overview of scheduled builds for a team project.
** Support for multiple reports on the dashboard.
** Add transaction support when copy config, this addresses the problem of caches becoming corrupt.

* Notification Client
** Support for notification on assignment changes to work items.
** Fixed problem with the configuration no always being persisted.

*+Upgrading from v1.0 to v1.1+*

There are no database changes in this release thus the upgrade is simple just reinstall the new version and keep the old database intact. Remever to preserver your original config files and copy them back to the installation folder again to replace the empty default configurations.

*+The release consists the follwing parts:+*

_TFSBuildLab.Server.Setup.msi_

This setup is intended to run on the application tier of your TFS installation (although this is not a requirement, this is what we are testing). If the database already exists the setup will simply skip the database parts of the setup.

_TFSBuildLab.Administration.Setup.msi_

Run this setup on any machine that needs access to administration of triggers and retention policies.

_TFSBuildLab.Developer.Setup.msi_

This setup will install both the checkin policies and the the tray icon application for build and checkin monitoring and is intended to run on the developer machines.

*+Prerequisites+*

Due to the depencies to .NET Framework 3.0 we are limited to running on either Windows XP or Windows 2003 Server (we do currently don't support Windows Vista). The service requires that a database server exists to host it's database, we currently support either SQL Server 2005 or SQL Server 2000.

Unfourtunately we are unable to upload archives including the dependencies so you'll have to take care of that on your own:

Microsoft .NET Framework 2.0 Redistributable Package
http://www.microsoft.com/downloads/details.aspx?familyid=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en

Microsoft .NET Framework 3.0 Redistributable Package
http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

NEW POST: Specify a build per source control sub-directory

PeterBlomqvist — Thu, 20 Dec 2007 19:06:21 GMT

Jason,

It seems that the issue would be a syntactical error in the trigger data (guess we could validate it but we never got around to do that) since what you are trying todo is exactly what TfsBuildLab does. If you look in the documentation around CI triggers you'll see an example like this one:

Trigger Data = \$/DEMO

It is important that you prefix the $ with a \ in other words \$ = $ this is due to the fact that the dollar sign is a keyword in RegExp. This should get your triggers working in your example you are using a | as a prefix. Let me know if this does the trick for you.

Ps. After reading it through another time it seems your problem is that the build is triggered to often? If this is the case and it still doesn't work for you after looking over the syntax in the trigger file could you please post a reply containing the branch structure of your project along with which build types you have and when they should trigger and finally the contents of the trigger table in the TfsBuildLab database.

Since what you are describing is exactly what we are doing we have several build types that correspond to various branches and the different build types are triggered based on the checkin path. Anyway let me know your config and we'll have you up and running in no time (I think ;).

/Peter

NEW POST: Specify a build per source control sub-directory

jasoncamp — Thu, 20 Dec 2007 13:22:49 GMT

I appricate your quick response. As I read back though my original question, I see that I wasn't very clear. What I am trying to do is use TFSBuildLab to initiate builds based on where the check-in was made. We have 3 builds per team project that are named development, staging and production. When I check in code to $/TeamProject1/Development, I want the development build to run. Even when I put |$/TeamProject1/Development in the TriggerPath, any check-in to $/TeamProject1 will initiate the development build. I guess I could use Benjamin Day's solution (http://blog.benday.com/archive/2007/11/19/23167.aspx), but I was wondering if I could do this with TFSBuildLab seeing as I have it installed and running in our environment.

Source code checked in

PeterBlomqvist — Thu, 20 Dec 2007 06:05:54 GMT

Bugfix releated to triggering scheduled builds.

Source code checked in

PeterBlomqvist — Thu, 20 Dec 2007 06:05:54 GMT

Bugfix releated to triggering scheduled builds.

NEW POST: Specify a build per source control sub-directory

PeterBlomqvist — Wed, 19 Dec 2007 21:51:50 GMT

Jason,

TfsBuildLab only triggers the build, it relies totally on the builddirectories specified in your build scripts (altough the release that is gonna go out on friday will let you specify a list of available build servers). The TriggerPath is the path in source control that will cause a trigger to execute once a checkin is performed in that path.

In other work the trigger path releates to the path of the items in the changeset that will cause the trigger to run and the build directory is picked up from your build script. Does this make sense.

/Peter

Source code checked in

PeterBlomqvist — Wed, 19 Dec 2007 21:06:41 GMT

Forgot to update version info

Source code checked in

PeterBlomqvist — Wed, 19 Dec 2007 20:19:32 GMT

Minor changes to setup projects done * Add more error handling - FaultExceptions - Messageboxes - Tracing done * Add transactional support on CopyConfig. done * Overview of schedules for teamproject (... button on edit/add form) done * Add WIT assignment/remove notify to tray icon done * Possibility for multiple reports and one default. done * Multiple build servers support, add column to trigger and only use the workspace file if needed. done * Bugg in notification client, xml filen sparas inte vid shutdown. done * Add send email on schedule completion global setting. [CIBuildCompletionNotificationEmail] new setting in config. done * Add support for multiple buildservers. * New grid in AddTrigger dialog. * Support in for servers on the Trigger class. * Load/Save support in the db manager for triggers. * Use the collection of servers in the actual starting of a build. done * Fix problem with delayed resolvment of checkin persons * Change changeset property in QueueEntry to a list of ints. * Move get latest changeset list to before starting the build. * Assosiate the changesets with the queueentry before registering the build for notifications. * Rewrite the send notification feature to use the queue entry changesets.

NEW POST: Specify a build per source control sub-directory

jasoncamp — Wed, 19 Dec 2007 20:18:00 GMT

I am unable to get the TFSBuildLab to initiate a build to a particular subdirectory. It seems that any subdirectory that I put in the TriggerPath still initiates the build for any check-ins under that team project. Is this the case?

Source code checked in

PeterBlomqvist — Tue, 18 Dec 2007 22:11:48 GMT

v1.1 (Improved error handling + Switch to VS2008) Bugg: Add transactional support when copying a configuration. Bugg: Notification settings for tray icon was not alwats saved. Bugg: Sometime broken build notifications where sent to the wrong changeset commiters. New: Overview of schedules for a teamproject in the admin client. New: Notifications in tray icon client when WIT assignment changes. New: Global notification email for general build completion status. New: Support for multiple buildservers on checkin triggers.

Source code checked in

PeterBlomqvist — Fri, 07 Dec 2007 21:00:04 GMT

Fixed bug with not saving settings after adding watches in the notification client

Source code checked in

PeterBlomqvist — Mon, 03 Dec 2007 11:10:15 GMT

Fixed some glitches in the dynamic layout logic for the AddTrigger form

NEW POST: Can't get CI working

jasoncamp — Fri, 30 Nov 2007 15:11:01 GMT

Nevermind, my mistake. Didn't have the user in the TFS admin group.

NEW POST: Can't get CI working

jasoncamp — Fri, 30 Nov 2007 14:18:53 GMT

I can't get CI to work. I am creating a new trigger within the TFSBuildLab admin tool and setting the TriggerPath to |$/test/development, but nothing happens. What else needs to be done? The documentation also talks a lot about a tray icon, but I don't see that either. Do I really need the | before the source code path for the TriggerPath? How can I diagnose this issue?

NEW POST: Multiple build server support/behaviour?

JeremyGray — Thu, 22 Nov 2007 15:23:43 GMT

Hey, Peter. Thanks for the quick response!

The functionality you describe as being in the current version of TFSBuildLab will certainly be sufficient, as I've already got people on-board with the caveat that there may be times when a build server is idle yet a build is queued, due to the static mapping of team build types to servers. In fact, they are more than just on-board - my peers, reports, and managers are all very very happy with the job TFSBuildLab is doing!

That said, if in a future version we were able to configure a list of usable build servers for each team build type and have the CI process feed a just-freed build machine with the oldest queued build that is configured to run on it, it would be truly awesome. Truly. I would literally have people doing high-fives, especially over on the QA team, where the current TFSBuildLab support for multiple build machines is going to be a large enough improvement but where this potential future functionality we're discussing would put the solution into an entirely different league.

NEW POST: Multiple build server support/behaviour?

PeterBlomqvist — Thu, 22 Nov 2007 12:18:29 GMT

Hi Jeremy,

Currently TfsBuildLab will just trigger builds on the buildserver specified in the BuildMachine parameter in the buildscript. Did you have anything particular in mind on how you would like it to work?

We will probably release v1.1 in a week or two with some minor updates before starting to look at a migration path to TFS 2008 for our users, our intentions are to let you just run an upgrade wizard to the built in functionality in TFS 2008.

Anyway let me know what you need and I'll see if it is something that we could accommodate easily. It would probably be rather easy to add a possiblity to list a bunch of servers along with the trigger that are to be used and just ignore what it says in the build script.

/Peter

NEW POST: Multiple build server support/behaviour?

JeremyGray — Thu, 22 Nov 2007 06:57:41 GMT

Before I get too far into messing with this tomorrow, I thought I might be well-advised to post this quick question here in case I'm just going to end up painting myself into a corner tomorrow:

I am about to clone my current build server x3 so as to introduce some parallelism into the build process. I expect that I'll be making explicit ties between team build types and specific build servers, which is sub-optimal but quite fine in my current scenario. I'll also be adding a further 3 or so build servers within a couple of weeks, each helping parallelize some other build-process-driven activities (execution of automated testing suites, to be specific.)

Is TFSBuildLab going to keep these servers busy as it is coded right now? Or does it just see a single queue of builds it needs to process one at a time?

NEW POST: Simple retention policies not working

JeremyGray — Thu, 22 Nov 2007 06:53:42 GMT

Apologies for being away so long. Things have been busy, and TfsBuildLab has been working. ;)

UPDATED WIKI: Home

MOlausson — Mon, 05 Nov 2007 08:11:51 GMT

Project Description
TFSBuildLab is a project to simplify the day to day operations when using automated builds and Team System.

This project handles common Team System issues such as:

Many of these issues are handled in the upcoming TFS 2008 release (http://download.microsoft.com/download/5/9/c/59cd0dc5-4691-4c3e-840c-66d865f27692/orcas-continuous-integration.xps), but we wanted to have a good implementation until then and we also aim to be as forward-compatible as possible.

Project Documentation

Our blogs:

Mathias Olausson - http://olausson.net/blog
Peter Blomqvist - http://peterblomqvist.blogspot.com