Agile Zone is brought to you in partnership with:

Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Continuous Deployment? Or Continuously Deployable?

04.09.2009
| 9957 views |
  • submit to reddit

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

Most 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 feasible.

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.

  1. Compilation of source code.
  2. Database Integration and Migration.
  3. Testing of various types, including unit, component, system, acceptance, security, load and performance.
  4. Code inspection and analysis to uncover duplicate code, verify standards compliance, code coverage, and generate metrics.
  5. Generate deployment configurations.
  6. Perform remote deployments to staging environments.
  7. Create an installation distribution.
  8. Generation of distribution media
  9. Source labeling and build labeling.
  10. Automated notification of build status.
  11. Automating the promotion through QA, Staging and Production.
  12. 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.

Published at DZone with permission of its author, Kirk Knoernschild.

Comments

Mike P(Okidoky) replied on Thu, 2009/04/09 - 1:30pm

I bet most companies are not convinced that such an extensive life cycle as described here is the cheaper way to operate. I bet most muddle by with just a mild bit of QA ing.

Paul Duvall replied on Mon, 2009/04/13 - 9:54am in response to: Mike P(Okidoky)

If they're not convinced it's a cheaper way to operate, they might choose to not automate the testing tasks (and, perhaps, automate them later):

  • Testing of various types, including unit, component, system, acceptance, security, load and performance.

They can still do the "QAing" manually. All the other items I mentioned in my list of 12 are repeatable, error-prone and mundane and should be automated. Automated testing can be a considerable investment with returns later in the cycle. Automation of deployment, database, etc. can give very obvious and measurable returns quickly.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.