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.