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.
Related articles
- #QConLondon 2012 (restreaming.wordpress.com)
- QConLondon 2012 tutorial on Cloud Architecture (restreaming.wordpress.com)
- Value of DevOps Culture: It’s not just hugs and kumbaya (dev2ops.org)
Hey Dušan – to answer your question. For my current project I believe that a single line change would take us about 1.5 hours to get it into production. This is from, committing to the Git repository, pushing it through dev and QA environments etc. Hope that helps satisfy your question.
)
We got much feedback, like yours, that seeing some real action – rather than just 100% slides would be preferred. I agree and we’ll try to work on it!
Tom, thanks for your reply. As I’ve already written, I consider your tutorial great and well worth of my time. I definitely recommend it to every software engineer. Even more os, if you’ll spice it up with some hands on demonstrations in the future.