QCon London 2012 tutorial on Continuous delivery aka. Making deployment a non-event


In most of software development teams, the deployment is a big event. It is a culmination of hard work of developers, victory for the operations people and a big relieve for the management. At my previous company, Najdi search engine, the front-end application of the search engine was a big wooly mess of spaghetti java server pages. It always took Žiga three days to merge to the trunk all the changes that other developers did in their branches, while Aleš nervously walked up and down the aisle, waiting for his extensive human-automated testing to commence. Fortunately, Zemanta's architecture is not monolithic and we release new functionality almost daily. But still, we commemorate every release with a mail to the stuff explaining what new shiny functionality has been put in the wild. Releasing software is usually painful and a natural reaction of most developers to the pain of releasing is to decrease the frequency of releases. In the tutorial on Continuous delivery that I attended yesterday, Tom Sulston and Tom Duckering's counter-intuitively posit that if something is painful, you should do it more often and eventually the pain will go away, thus making deployment a non-event. In short, Sulston and Duckering made a compelling case for continuous delivery approach. At Zemanta, we are well on our way to make deployment a non-event and this tutorial further solidified my determination to push us further in that direction. While the presenters are clearly very knowledgable about the subject, I've lacked the pork (to paraphrase a well known scrum fable). We saw lots of slides on theory of continuous delivery, but I really would prefer to see also a real release pipeline in action. One of the slides presented at the tutorial included a question by Mary and Tom Poppendieck: “How long would it take your organization to deploy a change that involves just one single line of code?” This tutorial did not give me the answer how long is this time for the projects where Sulston and Duckering were involved.