Brian On Software

In the course of the next few weeks, I’ll be writing a series of articles on how to set up a Continuous Integration (CI) environment for .NET development using TeamCity as the build integration server (with MySQL as the backend database), Subversion as the version-control server, MSBuild as the software build engine, NUnit as the unit testing framework, NCover as the tests coverage tool, NDepend as the static code analysis tool, and other tools that might give us important feedback on a build.  I hope that this series will be helpful in better managing and communicating your open source projects, academic projects and commercial projects.  Even though that I’m targeting development with .NET, the principles can faithfully be applied in a CI environment which uses different tools than the ones mentioned above.

You might be wondering why I won’t be using CruiseControl.NET as the build integration server.  The answer is pretty simple.  First of all, there are many articles that already describe very well how to install, configure and properly use CruiseControl.NET as a build integration server.  Second of all, I believe that CruiseControl.NET is dead in terms of ongoing development.  I’m not saying that CC.NET isn’t good at all, on the contrary, but the fact that it wasn’t updated in almost a year tells me that it’s probably stalling.  At the present moment, TeamCity is by far the best build integration server out there in terms of features, extensibility, performance, portability and scalability.  Thanks to its open discussion forums, newsgroups and accessible JIRA tracking dashboard, JetBrains is in a good position to redefine the principles behind CI and, most importantly, to further innovate in the CI space.  Another thing you might be wondering is how much setting up this kind of CI environment is going to cost you.  That answer is also very simple.  It’ll cost you a little learning curve to know how to properly use the tools and also some time in properly configuring the tools.  In other words, setting this kind of CI environment will cost you absolutely nothing in terms of financial expenses, except maybe buying a machine to act as a remote server to run your builds.  In fact, since the release of TeamCity 3.1, the Professional Edition is free to use (refer to this post for more information).  I’ll go more into the details of each tool in the later posts in order to separate the concerns and keep this series as loosely coupled as possible so that you can refer to each specific part individually.  I guess the principles of object-oriented programming follow us in everything we do in life…

I will not cover the whole concept, principles and best practices of Continuous Integration because other people have already done an excellent job in doing that.  I highly recommend you to look at Martin Fowler’s article on Continuous Integration, as well as to get a hold of Paul Duvall’s excellent book on Continuous Integration (from the Martin Fowler Signature Series of Addison-Wesley) to further understand some key patterns, best practices and strategies to successfully deploy and use a CI environment.  I read the entire book before setting up a CI environment at a client side, and I’m glad I did because the material that Paul covers in his book are real-world scenarios that most people face when setting up this kind of an ecosystem inside an organization. 

On a last note, it is important to know that I’m setting up this kind of infrastructure in a Windows environment.  Written in Java, TeamCity can be installed and executed on any platform that supports the JVM, such as Mac OS X, Linux, Windows, etc.  Subversion can also be installed and executed under Mac OS X, Linux and Windows.  As for the supporting build tools like NUnit and NCover, these only work under Windows.  I really hope that other people will write about setting up this kind of environment in other platforms than Windows to help out those that use different systems.  I’ll also update the information related to this series to reflect changes to the way we use the tools, new strategies to consider and the feedback I’ll receive from these articles.  Another point to consider is that you might want to try out this kind of CI setup in a virtual environment with various virtual machines.  The following approach might give you a general idea how you could implement a solid CI environment:

Here’s an early overview of the activities that will be covered in this series:

• Part I: Beginning the CI Journey with Subversion
• Part II: Setting Up Our Build Server With TeamCity

Similar posts you might be interested in reading:

• Jay Flowers on Continuous Integration (MSDN Magazine - March 2008)
• Part II: Setting Up Our Build Server With TeamCity
• Part I: Beginning the CI Journey with Subversion
• Book Review #7: "The Dip: A Little Book That Teaches You When to Quit (and When to Stick)"
• This Week’s Geek Links (May 16th, 2008)
• Better Modelling with the Visual Studio Class Designer
• TeamCity 3.1 Released

Posted under Agile(TDD/XP/CI). RSS 2.0 feed Leave a response, or trackback.
This post has been viewed: 977 times.
>> Email This Post To A Friend.