>

Team City has a killer feature called remote run. This gives you the ability to test your changes on the build server before actually committing anything.

Why is this needed, you might ask? 

Let me try to explain with an example. I’ve recently committed some features to NServiceBus where the tests where using Sqlite for in memory testing of NHibernate mappings. The coding went smooth and all test where green “on my machine”. I’ve danced the checkin dance and finally committed the changes.

What do you think happened?

Well the “it works on my machine” devil paid me a visit and made sure that the Continuous Integration choked with a classic “Bad Image Format” exception. It turns out that the build agent over at http://teamcity.codebetter.com is 64-bit and that caused the NUnit test runner to fail because I’ve compiled against the x86 version of Sqllite. But before I’ve got this fixed I had caused 10 failed builds, I don’t have a x64 machine so I had to do trial and error debugging. And trust me repeatedly failing the build is a great way to piss off your fellow developers. If I had been using the “personal build” feature before I committed  this wouldn't have happened.

To start using this feature do the following:

  1. Download the Team City Visual Studio plug in (login to your Team City server and click on “My Settings & Tools”)
  2. Download the CollabNet Subversion client and install it
  3. Open visual studio and
    1. Login to Team City (from the “Team City” menu)
    2. Click on “Remote run”
    3. Make sure subversion support is enabled (see picture below)

personal_build

That should be it. Another great “move” added to my check in dance!

Thanks to Tuna Toksoz for helping me with the Sqlite issue and reminding me of the “personal build” feature!