CMI's Continuous Integration Series Article #1 Continuous Builds Are Not Continuous Integration
Continuous Builds Are Not Continuous Integration
Uncovering the Value of Continuous Integration
What’s the difference between Continuous Integration and setting up your builds on a Continuous Integration server like Hudson?
More than anything else, Continuous Integration is a mindset that expects all the effort to integrating all the changes being made to a piece of software must be done continuously. That includes the effort to build the software, but it also includes the work to test, debug, and repair any integration issues.
We’ve all seen traditional project schedules for developing software. There is a certain amount of time in the project plan to do the development on all the components in the software, and then there’s a certain amount of time on the back end of the plan or schedule for resolving all the issues that are found when all the separate development efforts are brought together. Then in reality, it takes the software developers longer to develop the code than the project plan allowed for, so the testing phase of the schedule is compressed. The testers complain bitterly about this of course, and pull heroic late night and weekend shifts to get the testing done so the project can be completed on schedule. In the end, the project manager is left with the unpleasant choices to deliver the product late, to deliver the product buggy, or to deliver the product with the budget overrun. Normally, the project does all three. After the product ships, everyone cringes as they wait to see what the market or the business customer does to them. In the background, ambitious people prepare all their excuses why the project failure was not their fault.
By contrast, Continuous Integration pulls the integration test phase up in the schedule, effectively running in parallel with the development. In the Agile environments in which CI evolved, each two- to four-week sprint results in a potentially releasable product. The product is potentially releasable because the product has been fully regression tested in each sprint. The product version at the end of the sprint may not be fully featured, but every feature will work.