ContinuousIntegration

UserPreferences

ContinuousIntegration is the practice of continuously building and testing your project. ContinuousIntegration gives a heartbeat to the project which helps you keep tabs on your progress. It also helps you find and fix defects much faster than weekly or monthly integration.

See Martin Fowler's article (http://www.martinfowler.com/articles/continuousIntegration.html) on ContinuousIntegration

-- MattDiIorio - 31 Jan 2001

Have you ever been on a project that practiced big-bang integration – wait until all the features are done, then throw it all together and see what happens? It usually turns out just like the name implies – a totally chaotic, primordial soup of software. Just getting the code to compile is an amazing feat. Then come the bugs. How painful it is to harness the power of nature to integrate your code! -- MattDiIorio

Why is this a "best practice"?

• avoids big-bang integration
• we don't have to keep as much in our head at once
• fewer files / changes to manage
• reduces file contention
• less chance of accidental loss
• less chance of losing good changes amongst bad changes
• get stuck -- can't go foward, can't go backward

If this is a "best practice", then why don't people do it?

• hard to test small changes without automating or scaffolding or debugging
• afraid to change shared code / published APIs?
• SCM overhead:
• defect tracking requirements
• approval processes

How is it any different if done "eXtreme"?

• one new test, one new method, check it in
• one tiny refactoring, check it in
• many times per day
• really use the SCM -- it's there for the programmer's benefit

What other practices support this practice?

• UnitTesting make it safe
• PairProgramming provide safety and cut the number of integration streams in half

What other practices are supported by this one?

• low integration costs enable faster and Smaller Releases
• lets you know soon if you break something while Refactoring
• reduces file contention for CollectiveOwnership

How do I get started?

• get Ant (http://jakarta.apache.org/) working to fetch your code from your SCM system, build it, and run all the xunit tests.
• get a build machine
• automate it to run once/twice per hour
• try cruise control (sourceforge.com) or something similar or roll your own

Next: SustainablePace

Greg describes how we implemented ContinuousIntegration... Our experience was interesting. At first, the automated build/test broke constantly. It was failing several times a day, which created a big distraction as we had to stop and fix the build/test. As team lead, I started to wonder if I'd to have to turn the system off because it was slowing us down.

Fortunately, we kept it running. In about a week the Engineers became more disciplined about testing and checking in good code. Now, the team infrequently has the build/test failures . Since failures are in newly checked-in code, fixing the problem is usually trivial. Several times ContinuousIntegration has caught problems which might have gone unnoticed for a long time. With the quick feedback, we are able to catch those problems immediately and fix them.

In summary, ContinuousIntegration has increased the discipline of the team. It provides good feedback about progress. It has helped catch bugs immediately after they are introduced, which is the easiest time to fix them. The pain of ContinuousIntegration was very minor. Just some setup time, and the initial distractions of the build breaking a lot. After the first week, ContinuousIntegration ran very smoothly. Occasionally we had to update the build scripts, which is normal for any project. ContinuousIntegration really benefits!

-- GregHouston - 09 Feb 2001