Elevate: Continuous Delivery

This Monday, Neil Ford of ThoughtWorks held a talk about Continous Delivery at an Avega Elevate. I wanted to give a brief recap of this, not only due to the quality of the lecture but also because the topic touches on issues about moving organizations towards a Lean or Agile process.

With continuous delivery you strive to keep track of every change in your product. Not only does this mean to version control the code but it also includes keeping track of changes to the platform you are running the system on, the dependencies or 3rd party libraries, the application configuration files, the database schemas etcetera. You strive to build and thouroughly test each of these changes made to your product, so that there is always some deliverable ready to be shipped to a potential customer.

Now, continous integration in some shape or form is something I think most teams do today, or at least that’s my experience from the last couple of years. But what Ford argued is that you can now, with the increased quality in tools, automate a great deal of the, usually arduous, process of acually building and deploying your product. The idea here being that if you have total control of what components your product consists of, and you continously build and test it against a homogenous environment, you will be able to not only deliver, but also deploy, your product to production at every change in the product.

I won’t delve further into contious delivery here (I might retread the topic), because I think Ford hinted at other benefits of this than minimizing human resources and effort. If you really want to have an Agile organization, you would ideally want to be able to change your mind on a whim, and cast your product straight in the opposite direction of where it’s going, wouldn’t you? Ford didn’t like the abundant buzz around the word ‘pivoting’ but I’ll use it here, because it’s a very good word for this. How much time does it take for your organization to put a change of one line of code into production? If you have two companies in which one can deliver four times a year, and one can deliver 365 times a year; which one would most likely be most competitive? For me, this is a huge thing to think about when striving for agility.

I’d also like to mention the way Ford described the way his company worked when producing software. Everything needed by the developers, including IDE, machine setup (Ford reminded us a couple of times that yes, nowadays machines can be built from source code) was in version control. At the office, the work stations each had an exact copy of the version controlled environment so that every developer used replicas when developing. Furthermore, each day a work station would be manned by a pair of developers, pair programming for that day. The next day, the pairs were rotated and each developer might end up at a different work station where a new developer constellation would take on the challenges of software production (I should mention that each employee also had their own laptops that could contain personal software such as Itunes etc).

What a great way of incorporating XP practices, Agile, and team learning and interchange!