Extreme Programming Pocket Guide

Chapter 10. Releasing

Releasing software is special, especially if it doesn’t happen at the end of every iteration, as in the case of shrink-wrapped software development. It’s a time for retrospection and celebration. Discuss the project. Throw a party, and then relax and rest up to tackle the next iteration.

The customer has several options at the end of an iteration. He can put the software into production immediately. This can be appropriate early in the project’s life cycle, or with software deployed to a website or to thin clients. He can also release the software to production at specific milestones, triggered by the completion of specific features or by calendar dates. This works better in commercial software situations with quarterly or yearly releases. Short iterations help; for example, knowing that iterations always take three weeks helps to plan the delivery of major new features.

Knowing that you’ll release the software soon will change how you work. To keep migrations simple, your changes must be small. On the surface, this conflicts with XP’s goal of embracing change. In practice, the more frequent the releases, the smaller the migrations can be. While releasing a new version of the software every day can be distracting, an iteration period of two or three weeks strikes a good balance. The possible differences between the previous and current code are limited.

Frequent releases make it easier to learn from the current iteration and to prepare for the next iteration. ...