We keep our code ready to ship.
Most software development efforts have a hidden delay between when the team says “we’re done” and when the software is actually ready to ship. Sometimes that delay can stretch on for months. It’s the little things: merging everyone’s pieces together, creating an installer, prepopulating the database, building the manual, and so forth. Meanwhile, the team gets stressed out because they forgot how long these things take. They rush, leave out helpful build automation, and introduce more bugs and delays.
The ultimate goal is to be able to deploy at any time.
Continuous integration is a better approach. It keeps everybody’s code integrated and builds release infrastructure along with the rest of the application. The ultimate goal of continuous integration is to be able to deploy all but the last few hours of work at any time.
Practically speaking, you won’t actually release software in the middle of an iteration. Stories will be half-done and features will be incomplete. The point is to be technologically ready to release even if you’re not functionally ready to release.
If you’ve ever experienced a painful multiday (or multiweek) integration, integrating every few hours probably seems foolish. Why go through that hell so often?
Actually, short cycles make integration less painful. Shorter cycles lead to smaller changes, which means there are fewer chances for your changes to overlap with someone else’s. ...