The purpose of this post is to provide an overview of Continuous Delivery to people who may have never heard of it.  I've been a fan of Continuous Delivery for about 6 months now.  For the latest news on the topic I would recommend checking out[1].  I still have a lot to learn, but I think I'm comfortable enough with the basics to talk about it.

What is Continuous Delivery?

One of the biggest pet peeves a stakeholder or PM will experience is not being able to see the ongoing progress of an application.  Admittedly, development methodologies like SCRUM[3] with its iterative development cycles (or sprints) have made feedback pretty quick and easy to quantify, but it still usually has to wait until the end the cycle.  A short sprint of two weeks is sometimes too long for PM to wait.  So what's the solution?  Always have something built, deployed, and tested in a client environment.  This gives an Agile team the ability to release software more often and with more confidence.  Enter the world of Continuous Delivery, colloquially known as "the last mile of software development".

A colleague of mine got me onto the topic of Continuous Delivery when he plopped a book of the same title[2] on my desk.  It has been an area of interest ever since.  Continuous Delivery is an extension of Continuous Integration.  Running a CI build with exhaustive unit, integration, and other automated tests is great, but there is still work to gain confidence that a build is ready for release.  A release candidate (RC) needs to be reviewed by product management (PM) and other development sections like quality assurance (QA).  This is the last mile part, because it is often not automated and prone to human error.

  • In order for an RC to be trustworthy it needs to be deployed to a number of client system/network configurations and supported technology stacks
  • It needs to be thoroughly tested in all these environments

I'm still not convinced.  Why bother with it?

Setting up Continuous Delivery can require a significant amount of upfront investment, so it's not something you can do under the radar without the knowledge of the rest of the development department.  You need buy-in, so how do you get it?  You tell PM how much smoother and often it will make releasing your software to the client. Releasing an application is often a nightmarish scenario for all people in development.   In a lot of cases it requires a symphony of manual human interaction to be confident a release is ready to go.  Upper management is often even more stressed than you at this time (hey, it's their butts on the line at the end of the day), proposing the adoption Continuous Delivery should be easy when you can describe how much risk it will remove from these difficult times.

The easiest way to alleviate release concerns is to be able to automate and audit the release process and have it run as often as possible.

Sounds cool!  How do I apply Continuous Delivery?

The application of Continuous Delivery is creating a fully automated Deploy Pipeline, or as my colleague liked to call it, a Deployment Pipedream ;).  The ultimate goal of which is to make the feedback cycle between developer commit and PM review in a range of different client configurations as short as possible.  In order to achieve such a goal you need an initial investment in the following areas.

  1. Engineer a Silent Install for your app.  A fully automated silent install that can be configured for any supported app configuration and client environment.
  2. Know how to configure all your dependencies through Configuration Management.  An extension of the above point.  Host system configuration and 3rd party dependencies should be inventoried and work should be performed in determining a way to automatically implement these pre-requisites in a client environment.  When choosing a component for the product consideration should be given to whether or not its deployment can be automated.  If a dependency deployment does not lend itself well to automated deployment then other components should be considered (if possible).Configuration management is the process of keeping a record of all supported client configurations for the product and its dependencies.  This includes sample data and other information used in setting up a test environment.  The information should be stored in source control.
  3. Provisioning client environments.  This process would involve automatically deployment client images that we can apply the above configuration to.  It could be accomplished by either working with a VMWare API to automatically restore a host image or by somehow restoring a host image to a clean state.  Client testing environments should be engineered environments, not works of art.  The process to engineer an environment to an acceptable pre-requisite state for our application should be a thoroughly documented process.  Ideally, there should be no surprises or manual intervention required in setting up these environments.
  4. Run testing.  Run automated client acceptance testing on the product and send reports to QA, developers, and PM.

A hypothetical scenario:  Deploying a .NET application server from scratch

If you have an application server component it will likely have dependencies on other components such as your host platform, web server, and RDBMS.  All these dependencies require configuration along with any configuration of the application server itself.  For this example I've chosen the following technologies.

  • Host: Windows 2003 x64 SP2
  • Relational: Microsoft SQL Server 2005
  • Web Server: IIS 6

Setting up each of these dependencies requires us to know how they should be setup (or configured).  It's a relatively straightforward process (if time consuming) to automate the deployment of all these dependencies.  For the above technology stack I will briefly summarize how its configuration can be automated and what I would actually have in my Configuration Management repository. Then I would want to apply configuration and perform the following host environment setup steps.

1) The Host

Deploy an unattended install of Windows 2003 x64.  We need to communicate to the installer what is the right license key, install to the right partition, and to install .NET, IIS, and other system components.

What's stored in Configuration Management?

Answer files (.cif extension) drive an unattended install.  See the following source on Unattended Windows Install[4].

2) The Relational Server

Deploy an unattended install of SQL Server 2005.  We need to communicate to the install what is the right default data and log directories of SQL Server, what components to install (SQL Server is a mammoth software suite comprised of Analysis Services, Reporting Services, Integration Services, etc), what service account credentials to use, etc.

What's stored in Configuration Management?

Installation script (.ini extension) to drive an unattended install.  See the MSDN article How to install SQL Server 2005 from the command prompt[5] for more details.

3) The Web Server

Setup a virtual directory or web site on Windows Internet Information Services (IIS) 6.0.  Things get a little tricky when setting up IIS automatically, but it can be done.  Once you setup a web site or virtual directory option once, then IIS allows you to export this configuration to an XML file.  This file can be used as an input to a Windows Server script to setup IIS for you application server appropriately.

What's stored in Configuration Management?

An exported IIS configuration (.xml extension) that can be run by the iiscnfg.vbs system script.  See the Microsoft Technet article Importing IIS Configuration using IISCNFG.vbs[6] for more details.

4) The Application Server

You've made it, you've setup your host environment and all its dependencies.  Now hopefully deploying your own application server should be as easy as dumping your application target directory to the root directory of your setup IIS web site or server, and applying a tailored application config for this environment.  If you were smart, you would have already engineered a silent install and preconfiguration script option into your project so this deployment is a piece of cake.

What's stored in Configuration Management?

Your application's silent install configuration script and the application config that reflects the defined technology stack of your dependencies.

Final thoughts

The key to this whole process is automation and Configuration Management.  I know it's a huge scope, and it's not something you'll achieve over night, but it's the definitely the direction all projects should move toward.  I would highly recommend the book titled Continuous Delivery[2].  It's an excellent source of information and contains a lot of pragmatic recommendations to achieve this goal.  It's part of the Martin Fowler signature series of technical books by Addison-Wesley.

One thing I would suggest is breaking up Continuous Delivery into smaller phases.  The completion of each will have a working Deployment Pipeline, albeit not a very robust one.  At some point I will post and easy to implement first step for teams that want to start down this path.

Works cited