This article is part of my online newsletter called the Scrum Addendum. If you enjoyed this article you should signup for the complete series.
The Agile engineering practice of Continuous Integration is becoming a normal part of most teams daily activity. Once this has been mastered by the team, there’s a natural tendency for the team to be more confident about the quality of the software that they are “delivering”. For many teams “delivering” software means that it’s software that is “done” but still awaiting migration to a pre-production or production environment. What happens when we remove this barrier and allow the team to take the concept of Continuous Integration and apply it to Deployment?
I’ve just finished reading an excellent article on Continuous Deployment. Now that Continuous Integration has become (almost) mainstream and services are expected to be “always on”, the interest and demand for practices such as Continuous Deployment will increase. With Continuous Deployment the cost of rolling out an update is very nearly zero* because both deployment and releasing activities are fully automate.
I first had a discussion about Continuous Deployment with Rupert Perry the CEO of Pirum Systems. Rupert is a first rate developer who wrote the first version of their systems with the CTO. While we were discussing some of the advantages of Continuous Deployment, Rupert told me a story.
He was in a client’s office trying to make a sale and was demonstrating the live system. The client wanted to sort by a particular column, and Rupert responded, “Let’s try it,” even though he had not worked directly on that function. The function failed … but here is where the story becomes interesting. The developers who were monitoring the system noticed the failed function. It wasn’t a lot of work to fix the problem, so they coded, tested and deployed a solution. They called Rupert and asked him to demonstrate the function again, which he did successfully. The elapsed time for all this was in the order of 15 minutes to 20 minutes.
Oh, and Rupert made the sale!!
While my experience has given me strong beliefs about what works well with Agile, I am always learning. As a result, my views evolve sometimes, as is the case with take on the necessity of refactoring. While I always thought this was a good thing, a conversation with a friend changed my opinion. More on that next week.
*It’s not quite zero because there’s a cost involved in initially building and configuring the CD system.