The Tools I Use To Rock – part 2 – Team City

There are a lot of tools available to create an automatic build for your development process: CruiseControl, Visual Studio Team Foundation Server, Hudson and TeamCity, for example.

The first automatic build we created was done with Cruise Control. About a year later we decided to change to TeamCity. This article explains why we chose TeamCity, and how you can create an automatic build with TeamCity yourself.

We’ll asume you’ve got TeamCity installed. Should you need help with the installation, check out the following articles.

From CruiseControl for TeamCity

As stated, we created our first build early 2010, using Cruise Control. The main reason for choosing Cruise Control was that I had worked with this tool before at my former employer. At same time busy migrating from classic ASP to ASP.NET 4.0 ánd adapting Scrum, something “known” was very welcome. A couple of problems occurred from day 1 of using Cruise Control, configuring the builds was horrible and there were a lot of strange file-access-right problems. Time to reconsider!

After comparing a couple of programs we choose TeamCity as our new build environment. It follows the KISS principle really strictly, has a really basic and easy-to-use interface. A big plus for TeamCity was that we were already using other programs from its manufacturer Jetbrains: ReSharper, dotTrace and dotCover with great satisfaction.

Improving

When we finished our first couple of build configurations in TeamCity, a single build contained ten(!!) build steps. Last summer Mendelt joined our company for a couple of months. He had a lot of experience with MS Build, which he used to reduce the build to five steps. He combined a couple of steps in the MS build file, making it a lot easier to configure a build. Within TeamCity you can directly call a MS build file. In combination with the package “MSBuildextensionpack”, you can almost do everything you can do on a Windows machine from within MS build.

Our build now contains the following steps:

• Source-code checkout. We use Mercurial as source control system, in TeamCity it is important to choose the checkout option “automatically on server” , and make sure that your checkout directory is not the same directory as the “VCS clone” directory
• Calling the MS Build configuration file, with the “build” parameter. This section of the MS Build file compiles the solution and takes care of the transformation of the web.config file
• Unit Tests, using NUnit
• Calling the MS Build configuration file, with the “DeployAcceptance” parameter . All files are copied to the correct IIS folder
• Database synchronization, we run database synchronization scripts via SQL Compare by Redgate

Should one of the steps fails, the next one won’t be executed. You can download a Windows tray application that notifies you of a build failure (for example when one of your front-end-developers breaks the build, because he/she forgot to check-in some images).

Running multiple builds

With the free version of TeamCity you are allowed to run twenty different build configurations. A maximum of three build agents can run these builds. When you’ve got more than one team developing software at the same time it’s recommended to run the maximum of three agents, otherwise teams have to wait for each other (builds are put in a queue when another build is busy). You can also configure which agent runs a particular build. For more information about running multiple agents check out the following article by Steven Smith . If you want to run more agents or builds, you can switch to the paid version of TeamCity. You can buy an extra agent for 263 euro or buy the whole Enterprise Server version for 1759 euro.

Embrace change

One of the things I learned while setting up an automatic build environment is that you should never be afraid to start over (like we did we the conversion from CC to TC) and keep improving. For example, at the moment we are busy with the automation of the production deployments and the content deployments.

Conclusion

Nowadays there’s no excuse not to have an automatic build. The investment to setup an environment repays itself really quickly! Right now me or one of my colleagues can create a new build within five minutes, giving us an acceptance environment where customer, product owner or team members can track progress at all times.

My advice would be to start with one project and see what happens over the course of 6 months of using TeamCity. I bet you’ll never want to work without an automatic build again.

Download

We’ve attached our own MSbuild file so you can easily get started. Let us know how it works out for you!

Example MSbuild