My blog has moved!

Visit or and update your bookmarks.

Tuesday, March 31, 2009

Implementing TeamCity for .NET Projects: Evolving Your Build Automation Solution

As the title suggests, I will be focusing on using TeamCity with .NET projects. However, make no mistake: TeamCity is well-positioned and well-tuned for use with many development environments, and many of the concepts I will discuss are applicable to those environments.

Posts in this Series:

  1. Just Build It! (A Simple Build Configuration)
  2. Triggering Builds
  3. Nightly Builds and Creating Artifacts
  4. Using Build Scripts
  5. Deployments
  6. Setting Up Notifications (Coming Soon)

During my talk at Boise Code Camp 2009, we discussed the evolution of build automation and continuous integration. If you are not familiar with build automation and continuous integration, Martin Fowler’s article is a nice primer on the subject.

When I started on my current project, our team was not using a build server. We were encountering problems with incomplete check-ins, hostile merging, missing dependencies, and inconsistent and bloated production builds. The classic “it works on my machine” and “your code broke my code” syndromes were very prevalent. Prior to this gig, I had worked on a team that was using a continuous integration solution and I knew that we needed to implement something similar.

While investigating options, I compared Team Foundation Build,, and TeamCity. TeamCity quickly became the forerunner strictly due to the ease of configuration and raving reviews from the community. Both Team Build and Cruise Control use XML configuration (yes, MSBuild is XML). Although I am very comfortable with scripting builds using nAnt, this was a barrier to implementation as a team. I wanted a low-friction entry point with the ability to implement more powerful functionality later.

In the next several posts, I would like to expound on the evolution of our build process, starting with basic patterns, and then exploring more powerful patterns, all implemented using TeamCity. The patterns I will discuss are…

  • Simple Build Automation
  • Build and Test
  • Continuous Integration
  • Nightly Builds
  • Artifact Creation
  • Alternative Build Runners (Build scripting)
  • Build Dependencies
  • Deployments
  • Custom User Interface Elements

You may want to download your own copy of TeamCity (the Professional version is free!). Installation is quick and painless . Make note of which directory you designate to be the .BuildServer directory – for convenience purposes, I suggest placing it in the root of the main TeamCity directory. I will make a sample project available for use in exercising the build server configurations shortly.

Boise Code Camp
Team Foundation Build

Sunday, March 29, 2009

Boise Code Camp Session: Getting Started with Continuous Integration using Team City

Giving a talk today at Boise Code Camp on JetBrains TeamCity build management server. 


  • Benefits of continuous integration
  • Why TeamCity?
  • Evolution of automated builds/continuous integration

Will follow up with examples of evolving your build automation from just compiling code in a team environment to deploying websites.

TeamCity Home Page
Continuous Integration (Martin Fowler)