Yes, you can stumble into Continuous Delivery by making incremental improvements to how you do things over a long period of time. But stumbling is not the most efficient strategy ever employed. A better approach is to envision what you want your system to look like once you have CD in place and then chip away at the vision. So what might you try to have in a fully implemented CD systems? Well, that is going to be different from location to location, but to me it comes to basic attributes; Agile and Automated.

Of course, these are very big terms and not very useful without some clarification as to what I mean.

The first attribute is Agile. Agile has gone from being a term that almost sorta meant something to a marketing term you can not buy certifications in. Jumped the shark indeed. Even the fall back position of ‘adheres to the Agile Manifesto’ doesn’t seem to ring quite right anymore. But Elisabeth Hendrickson’s definition is fantastic and nicely captures what I try to get teams to think about when ‘going Agile’.

  • Deliver a continuous stream of potentially shippable product increments
  • At a sustainable pace
  • While adapting to the changing needs and priorities of their organization

All these are fundamental ways an organization builds its product. Timeboxes, no crunching, periodic reflection, pair programming, etc. are all possible individually in any development methodology but as you use them jointly on a project Agility really has a chance of happening. (The key word in that last sentence happens to be ‘chance’.)

The other umbrella attribute is Automated and deals with how the product moves towards production. Like with Agile, there are facets of Automation that help further clarify what I mean.

  • Deployments are non-events. Can you push a button on the Friday before a long-weekend at 4:45 in the afternoon with the car parked downstairs with camping gear and comfortably leave the building? You should.
  • No humans. There is always room for humans in certain parts of the product’s march to production. Like in testing. (Continuous Deployment for me is near un-ethical, but you’ll notice its champions are developers not testers.) But pushing code around the network and onto machines? No human! This is for both system code/configuration and application code/configuration.

Now that I’ve defined what it will look like conceptually I can start to look at what needs to be done to get there. Well, the Agile stuff has been covered a lot in the last 3 ish years I’m going to skip that as the level of understanding available to those who [barely] look for it is pretty good. The Automation side is only really starting to get traction and is one which I’ll be hosting a day-long workshop on at this year’s STPCon. And will be blogging about as I start getting content ready for it.