Continuous Integration

Task today is to decide and implement an Continuous Integration build process, I will be looking at two options CruseControl and Team City. The are a lot more but for the purpose of the current .NET environment these are the two I’ll be looking at.

When working in a team, the developer needs to know that any changes he makes and stores in to your repository will work for others. When the developer submits code to the repository they must first update their code to reflect the changes in the repository since they took their copy. The more changes there are to the repository, the more work the developer must do before submitting their own changes.

Eventually, the repository may become so different from the developer’s baseline that they enter what is sometimes called, “integration hell,” where the time it takes to integrate is greater than the time it took to make their original changes. In a worse case scenario, the changes the developer is making may have to be discarded and the work redone.

Continuous Integration is the practice of integrating early and often, so as to avoid the pitfalls of “integration hell”. The ultimate goal is to reduce timely rework and thus reduce cost and time. When done well, continuous integration has been shown to achieve these goals.

After speaking and Googling for each of the products, I quickly came to the conclusion that although a number of clients I have work with before have been using CruseControl I have found it quite hard to setup and the configuration of XML configuration files can be a bit of a nightmare, and as such we just need a tool to work and not have to maintain. So for the rest of this article I will be focusing on Team City by JetBrains.

I will be using version 4.5.1. TeamCity-4.5.1.exe (231 mb)

What I like about this product is the licensing, currently the Professional version is free for up to 20 users and 20 build configurations, and when the project get larger you purchase an enterprise license, currently £1,560, ideal way of working and getting you to use the produce.

It’s worth watching this short introduction video from Dime Cast, to find out how easy it is to create and use Team City.

The Server automates the integration process by monitoring the team’s source control repository directly. Every time a developer commits a new set of modifications, the server will automatically launch an integration build to validate the changes. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not.

Effectively, integration becomes as easy as checking in code. Using an automated integration server not only makes integration easy, it also guarantees that an integration build will happen. There is no danger of developers forgetting to validate their changes after checking in.

The Team City offers several key features:

• Integration with a variety of Source Control systems

• Integration with other external tools, such as NAnt and Visual Studio

• Can build multiple projects on one server

• Remote management and reporting

So down to the installation, once downloaded (231mb file), I installed using all the default settings and it worked, very easy to setup.

Next was to setup a project, again quite easy, I was attaching to a Visual SourceSafe (VSS) solution, I ran in to my first issue as I was getting directory authentication failed. This was because the running “TeamCity Web Server” was using my System login and it did not have permissions to the network drive for the VSS. A quick change to the TeamCity Build Server service login and it all worked.

I ran the build on a simple project and it worked without a hitch.

Next was to install the System Tray Notifier, quite simple, going to the “My Settings & Tools” tab brings a list of download, after a simple download and run, then pointing the HTTP location of the Team City installation, it worked.

What can I say it’s all just too easy to setup.

Pre-tested Commit

One issue I had, but not with Team City, is that if you are using MS Test, the built in Visual Studio 2008 testing tool, then you will need to run MS Test. But to run MS Test it is tightly coupled with Visual Studio. Which means to run MS test you’ll need to install a version of Visual Studio on your Continous Intergration machine. Therefore it might be worth using NUnit for testing.

One very nice feature of Team City is the ability to perform a Pre-tested Commit, this is possible when you install the Visual Studio Addin

An approach which prevents committing defective code into a build, so the entire team’s process is not affected.

Submitted code changes first go through testing. If it passes all of the tests, TeamCity can automatically submit the changes to version control. From there, it will automatically be integrated into the next build. If any test fails, the code is not committed, and the submitting developer is notified.

The TeamCity plugins for IntelliJ IDEA, Microsoft Visual Studio 2005/2008 and Eclipse extend the respective IDE with the remote run and pre-tested commit features. Developers test their changes by performing a Remote Run. A pre-tested commit is enabled when commit changes if successful option is selected.