Eric Ries recently posted a nice little piece on Continuous Deployment. In it, he describes the process used at IMVU where all code that's written for an application is immediately deployed to production. In the post, he describes the five key ingredients to making continuous deployment work.
- Continuous Integration Server
- Source Control Commit Check
- Simple Deployment Script
- Real Time Alerting
- Root Cause Analysis
enterprise developers however, immediately flip the bit at the notion
of deploying enterprise software in a similar manner. The risks of
deploying code that has not passed through the quality checks necessary
is too great. The cost of downtime, lost revenue, and customer
dissatisfaction can be significant. The complexity surrounding legacy
integration presents special challenges. In general, continuous
deployment on large enterprise software development projects is not
However, enterprise development teams can, and should, strive to develop software that is continuously deployable. About a year ago, Paul Duvall spoke of continuous production, where development teams automate most everything it takes to create software so that it can be deployed into the user’s environment any time. He offers 12 suggestions on the type of tasks that could be automated, depending on your project.
- Compilation of source code.
- Database Integration and Migration.
- Testing of various types, including unit, component, system, acceptance, security, load and performance.
- Code inspection and analysis to uncover duplicate code, verify standards compliance, code coverage, and generate metrics.
- Generate deployment configurations.
- Perform remote deployments to staging environments.
- Create an installation distribution.
- Generation of distribution media
- Source labeling and build labeling.
- Automated notification of build status.
- Automating the promotion through QA, Staging and Production.
- Generating necessary documentation.
With this approach, the team is capable of producing production ready software at any time (ie. software that is continuously deployable), but stops just short of actually deploying the system to a production environment. Paul provides the following important clarification when speaking of continuous production:
Note: This does not mean that you will be taking up cycles producing production-ready software with every change to the version control repository. Test, Stage and Production builds are more likely to be performed on demand (by a person). However, the point is that your build environments are capable of building production-ready software on a continuous basis.
While the practice of continuous deployment is slightly different from software that is continuously deployable, each aim to tighten the development cycle and emphasize quality throughout the software lifecycle. Each also present the technical practices and infrastructure necessary to make it happen. But continuous integration can be difficult, and John Feminella discusses some of these challenges, while summing it up brilliantly when he says that
continuous integration is as much a discipline as it is a practice.
Continuously deployable software can have a positive affect on how the software development effort is managed, as well. In a series of articles by Israel Gat, which I summarized in a post on Internal and External releases, he describes some higher level management practices surrounding how software development teams can separate the notion of an engineering release of their software from a business release of their software. Ultimately, allow the business to select which release of the system they would like to deploy. But for this to work, the software must be in a continuously deployable state.
There is a wealth of knowledge embodied in each of the posts linked to in this article. Examining and combining the great content can provide a foundation for teams to build the technical and management practices necessary to improve their development processes and ensure their system is continuously deployable.