Select Page

Continuous Delivery coverI’m reading the book, Continuous Delivery.  It addresses a very important and widely overlooked problem with information systems:  The deployment of a software application into an execution environment is fraught with peril.  Especially if it’s the production environment.  The authors note what every development team knows well, that rolling out a deployment is typically a time of stress and anxiety.  And they remind us why.  It’s most often a manual process that’s not repeatable.  It involves people working in silos:  Developers, DBAs, OS Administrators, Network Administrators, Application Administrators, who all must coordinate.  Reams of documentation, usually out of date, detailing manual procedures are thrown over walls in the hopes that the instructions will be followed.  Sound familiar?  It does to me!  My attitude towards this problem in the past is probably typical for application developers.  “I provided some documentation, and I’m available to answer questions.  Other than that, it’s not my job.”

This attitude can often be explained by organizational bureaucracy. Division of labor and assignment of tasks to people with specialized skills has been typical of the way I.T. businesses work.  The authors identify these anti-patterns:

  • The production of extensive, detailed deployment documentation
  • Reliance on manual testing to confirm that the application is running correctly
  • Frequent calls to the development team with problems on release day
  • Frequent corrections to the release process during the course of a release
  • Clustered environments, differing in configuration across cluster members
  • Releases that take more than a few minutes to perform
  • Releases that are unpredictable, have unforeseen problems, need to be rolled back manually
  • Sitting bleary-eyed in front of a monitor at 2 A.M. the day after the release, trying to make it work

Shouldn’t we move forward to address these problems and apply the same standards we use to develop quality software to the process of deploying that software?  This is the final step in automation that’s been successful with continuous integration where on every change to the software, data, or configuration:

  1. The full set of automated tests:  unit, functional, integration, acceptance, are run.
  2. Any test failure is immediately reported to the development team, and is quickly addressed.
  3. The successful build is deployed to a testing server for review by humans.

The ideal of the authors is that in addition to all of the source code, test code, database scripts, and build scripts, the project revision system holds configuration information for every environment, allowing automatic deployment on command of any version of the software to any defined environment.  A human need only specify the version of the software and a target environment and press the ‘make it so’ button.  But why haven’t we been doing this?

Well, it’s hard!  There are technical challenges.  But there are also organizational challenges, turf wars, and role issues.   Resistance to change often takes the form of, “This is how we do things here.”  I bought the book to dig into the technical solutions the author have discovered.  However, the author state, “It’s axiomatic that most projects fail due to people problems, rather than technical problems.”  They argue that the Operations group needs to be engaged with Development much better than typically found.  Everyone shares the goal of delivering business value.  I’m looking forward to reading more about the author’s experiences in this dimension.  And I want automated deployment for continuous delivery to become part of my job, and not just a job for someone else.