Friday, April 4, 2008

6 steps to successful Continuous Integration

In early seventies, when computer aided projects become bigger and bigger, more independent companies were involved. After few months of development there was a special phase called integration. It was the hardest task to integrate all solutions and it wasn’t uncommon that project was successful until it suddenly fails due to integration hell.

Cure for this illness is Continuous Integration – everyone should integrate with rest not after months but continuously – each week, each day, each hour – as often as possible. This practice helps avoiding problems later. It’s so called “pay me now or pay me more later”.

To increase chance for project it should be integrated continuously. In the rest of article I will introduce 6 practices, which should be used to integrate continuously. Depending on the project and your attitude you can choose only some of described practices, but I strongly advice to fulfill preceding practices before using next one.


Establish vs. maintain cost for Continuous Integration

Chart above shows relationship between cost of initial phase and cost of work required to maintain.

1. Use source code repository

It’s first and required step to start using continuous integration. Initial cost is not so small because you need dedicated machine and backup policy for “heart of software company”. Also each developer must be aware of source control existence and install so on each machine. Consider using Svn, Cvs, Team System.

2. Introduce check-in policy

Check in policy may be introduced after establishing source code repository – quite easy to introduce but some effort is required to follow. Firstly it involves storing all necessary files in repository. Secondly, each developer should check-in as often as possible completed part of work. Frequently integration show problem early and either solution is easy or rollback is necessary for only small part of solution.

3. Automate build

Next step is to perform build automatically – no more than one action should be required to start it. If developer must do more things than he forgets about it or deliberately skips it to save time. Perfect solution is when after each commit build is automatically triggered. Cost of using it is very small after establishment so I strongly advice to use it in all projects.
Consider using Nant, Msbuild for scripting build process and CruiseControl.Net, Microsoft Team System or Team City as Continous integration server.

4. Create auto-deployable test environment

After each build new version of binaries should be automatically deployed to test server. It helps improving better integration with customer – after each fix customer may verify new version. Some work is necessary at the beginning but it’s really worth this effort in later phases of project.

5. Use code quality analysis

Using code analysis is very important in big project with many developers. It helps preserving coding conventions and constantly monitors code. If any time some suspicious code is committed warning should be generated. It differs from code reviews, because here approval or disapproval must be done automatically. Trigger for generating warning should be adjusted for each project or for whole company. Consider using NDepend, FxCop, Simian

6. Use unit test

Although I’m a big fan of XP and TDD I must admit that this is the most time consuming practice. At the beginning it requires reasonably small amount of effort, but when project goes on more and more time developers spend on writing, refactoring and verifying test cases. Only some companies can reach this level of maturity and can enjoy all advantages of continuous integration. Consider using NUnit, Team System Testing, TypeMock, RhinoMock, NMock and many others.

3 comments:

Anonymous said...

Very good. I also learned a LOT by watching this free webinar the other day. The SCM tool distracted me a bit because I was like, woah, you can DO THAT? I didn't know. Check it out:

https://www.accurev.com/webinar.html

Unknown said...

I would like to add one point to your post. I have been doing agile dev for two years and found that a continuous integration server is very important to be really agile.
I recommend using free CruiseControl.Net in .Net projects. With this tool, you get supports for periodic builds on your trunk, see the changes committed till last build, see the number of tests run in the last build and test results in a web dashboard.

In a word, a tool like CruiseControl.Net is a must to really make the agile development as painless as possible and also to ensure XP guidelines (checkins, unit tests and so on).

-Sohan
http://smsohan.blogspot.com

Anonymous said...

We have been using Hudson at work for a 100% .NET environment. Hudson is a very good CI tool, and it is very easy to configure.

Currently it supports
* Most SCMs available
* FxCop reports and trend graphs to show if your code quality over time
* NUnit test reports per build
* NAnt and MSBuild