Practice: Daily Deployment

Put new software into production every night. Any gap between what is on a
programmer's desk and what is in production is a risk. A programmer out of
sync with the deployed software risks making decisions without getting
accurate feedback about those decisions.
  Daily deployment is a corollary practice because it has so many
prerequisites. The defect rate must be at most a handful per year. The build
environment must be smoothly automated. The deployment tools must be
automated, including the ability to roll out incrementally and roll back in
case of failure. Most importantly, the trust in the team and with customers
must be highly developed.
  The trend towards more frequently deployed software is clear. My instant
messaging program fetches updates every few days. Large Web sites change
imperceptibly daily. Daily deployment is an extrapolation of this trend.
  Daily deployment is a good example of a practice that points in a
direction. If you can't deploy more frequently than once a year, daily
deployment might seem like a pipe dream. I've seen teams that think they
deploy once a year actually deploy 12 times a year-one release and 11
patches. The team is capable of rolling out small increments of
functionality, but the team is embarrassed about needing to do so rather
than seeing its capability as an opportunity. Twelve releases sound a lot
better than 11 patches.
  How do you implement daily deployment when you have projects that take
weeks or months before they are usable? There are many tasks involved in a
big project: restructuring the database, implementing new features, and
changing the user interface. As long as you don't change the user's
experience of the system, you can deploy all the rest of that work. On the
last day you put the "keystone" in place, the change to the user interface.
  There are many barriers to deploying frequently. Some are technical, like
having too many defects or needing an inexpensive way to deploy. Some are
psychological or social, like a deployment process so stressful that people
don't want to go through it twice as often. Some are business-related, like
not having a way of charging for more frequent releases. Whatever the
barrier, working to remove it and then letting more frequent deployment come
as a natural consequence will help you improve development.