Continuous Integration – CC .Net

Posted: 2009-03-01 in Code and Computers


A quickie about Continuous Integration can be found on wiki…

This post isn’t about why and how Continuous Integration works but more about personal experiences with CI.

Continuous Integration in the Real World

For the past year we have been running Continuous Integration on 3 main projects and about 15 little projects.
Little projects are the basic 5 guy programming team working on a project for about 6 weeks deliver and patch on demand (or between sprints).
Large project consists of one or two teams working on the same project usually all year round, in our case automation software.

So where does CI (Continuous Integration ) fit into this? Easy, damm easy. CI was install to fit a need, the issue of programmer checks in something that builds on his/her machine and not on others machine. This is a massive deal when you get different working hours, but still pretty critical for similar working hours. Some guy checks in code goes home get sick (worse case) guy come in early next morning does the obvious refresh fails the build.

Steps through others code till error is found fixes (if possible) sends angry email to check in person.

With CI the server triggers to build when a new check in is receive, a monitoring and speakers are attached and if the build fails it screams (literally, we have a blood curdling scream triggered to fire when a build breaks). The check in person puts his/her jacket back on the coat rack and fixes the issue before heading home. At work we recommend a check-in 10 minutes before starting the pack up to head home. In practice most people check in about 5 times a day dues to other advantages the build server offers.

What we have found is that no matter how big or small the project is CI always at least once a weeks saves some skin. More so on new projects where stability of files is low and refactoring is high until a stable architecture is created.

Our Setup

Agile Agile Agile…. to say the least. Half the original ideas have not developed or were faulty in practice, the other half have been  added due to experience.

Basically as it stands today we have on all build the following checks

Two FxCop scripts. One checks all rules we aspire too and is used for statistics on how far we are from this path. The is what we consider to be turned on rules, rules that will cause the build to fail and the developer to fix it before heading home.

NCover, used to get the detail coverage of coverage from the NUnit test that are set to run. If any of these test break the build server screams.. We plan to change this to enable all test and have them ran at midnight each night and turn off all NUnit test for the absolute CI part of the build. This is due to the time taken to run some test it is impractical to run them each check in.

MSBuild, well obviously.

And nothing else… The CI part is ran by CC .NET and works very well except for a small maintenance every other week of removing the statistics it collects.

I did hack one off the java script files to get some statistics over number of lines and weird things like that just for shits and giggles, but 99% of the people shouldn’t require this 😀

If possible, or by request, I will publish a sample script later, our CI integrates with what we call CME or in the real world known as Clear case  and Clear quest.

Machine Hardware

This is a weird thing to have but the biggest problem is getting stuck on hurdles. So the easiest way around this is to to repeat the start phrase, Agile Agile Agile. Find any shitty machine check it has about a 1gb of ram, 20gb of hdd, and a processor 😉 and you are good to go. Laptops work also.

Our machine was an old developers machine that was formatted and had only the basics installed (safer).  The build server handles easily 25 projects (its only a shitty machine) from 3 difference sections. The machine is not backed up and sits at a spare desk. The larger projects take about 7 minutes+ to build on the server running no Unit Test. Build times are only an issue at the end of the day when developers are ready to go home and they have to wait for the green light. Most developers read emails and other things they haven’t had time to do during the day during this period.

The machine was used for proof of concept and was found to be good enough, over the past year other sections have gained access and plonk there projects on it. Our CI settings scripts has also been around to help other departments setup there own machine.

The machine has no restrictions on being rebooted and is done so usually during the day (developers don’t really care until home time) on a off regular period just to keep it fresh.

The biggest advantage with this setup is that no IT resources are required and if it crashes or needs anything anyone can do it without having to jump through a bunch of hurdles. If it totally dies any machine freshly formatted will do. the hardest part is that CC .Net settings which are copied to a network share if any change is made (rarely).
Actually just to emphasis a main point, we didn’t want IT involved if we need them then the solution is to complex and it will fail before it begins.

During vacation time I used some free hours to transfer and upgrade our version of CI, it took less than a day and when completed only required 15 seconds of work from the developers to re-point CC tray to the new server address. I am sure someone probably found this too much effort but a quick piss off puts them back into line.


This week our manager developed with us for 3 weeks, his comment summed it up well. How did we ever survive without CI, it saves so much god dam time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s