Implementing TeamCity for .NET Projects: Evolving Your Build Automation Solution
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:
- Just Build It! (A Simple Build Configuration)
- Triggering Builds
- Nightly Builds? and Creating Artifacts
- Using Build Scripts
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
- 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
9 thoughts on “Implementing TeamCity for .NET Projects: Evolving Your Build Automation Solution”
Have you had a chance to look at our Parabuild for Continuous Integration?
notification is not working, i performed the test operation while configurating the project,it worked fine but when i run the build notification is not sent.It would be great help if you could help.
when will you post the article about deployment? im following your guide since that i want to implement it at my job 🙂
@Alex I’m glad the guide has been helpful. I will get back to posting about TeamCity and deployments soon.
Comments are closed.