Disclaimer: I no longer use this method to deploy. Check out the Mimicking App Harbor post to see how I use MSDeploy instead.

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. Deployment

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, CruiseControl.net, 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 CruiseControl.net TeamCity

Originally posted at CodeProgression.com on March 31, 2009.