P&P Summit Day Three: Continuous Integration

The pre-lunch session was given by Wayne Allen from Corillian, the same company that Scott Hanselman and Patrick Cauldwell work for. The talk was about continuous integration, or the idea that your code is constantly being compiled, tested and perhaps deployed so that you know when you have problems faster.

Unfortunately for Wayne his keyboard locked up and had some technical difficulty.

The first thing he states is you can do continuous integration even if you aren’t an agile shop. You do continuous integration because “late integration sucks”.    All the statements about “it works on my machine”, etc. A continuous build will help or negate these.

He then starts going through some stages of continuous integration.

Stage 0: You have nothing…developer builds.

Stage 1: You have something…perhaps a separate build box and a manual process.

Stage 2: Developers check in something and an automatic build occurs. Results of the build and tests are sent to the team.

During stage 2 you should have:

• 10 minute build max. - keep the time down so that you know faster and people aren’t gone by the time the build is done.
• Clean builds (no warnings) - want this to be clean so that people notice when things are actually wrong. Warnings like missing XML comments would probably start having people ignore the build notification.
• Same build scripts for developers and the build server.
• Build configuration under source control.
• New build server in an hour if necessary.

–Sorry, didn’t get all the talk as an emergency phone call took some of the time out.

After stage 2 where do you go? Static analysis, FXCop, code analysis, etc. Also things like Ncover, Ndepends, etc. Of course, you should use the thing you think is necessary that meets your needs and checks for the things that you have issues with. For example, if you push to test and there are bugs all over the place then you may want to use Ncover or a code coverage check during your process to ensure you have tests that cover your code base.

Some information about testing during this process:

• Separate what is a unit test and a functional test.
• Move long running tests of the build server.
• Multiple server testing. If it’s a distributed application then you have test distributed. Move it off the build server.
• Multiple platform testing.
• Testing new installs and upgrades. Test installs and deployment. I wish this was done more often where I’m at now.
• Testing specialized hardware
• Testing databases/MSMQ/mainframes, etc.
• Testing internationalism.

This next step in pulling in continuous integration into your process is dealing with the hard stuff like managing multiple projects, using VPCs and 3rd party dependencies.

Once you have all that you are at Stage 3, but remember there can be a lot of maintenance costs with this level of integration.

I’m not sure if it was the technical difficulty at the start but Wayne did not present well. Good information, but he was a very dry speaker.