Tryst With Continuous Delivery


November 14, 2016

The first time I heard about Continuous Delivery was @ Ruby Conf India '11, during the talk by Srushti Ambekallu and Brian Guthrie. I've been using Jenkins as a Continuous Integration tool, but the talk exposed me to Deployment Pipeline, a pipeline to push the code to next stage either automatically or manually.

My research led me to the Continuous Delivery book. I also found Jenkin's Build Pipeline Plugin, implemented as prescribed in the book.

cd-pipeline\ Further research on this topic showed me that the concept is not new and many companies are doing it already.

10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

Commit to Production in 8 minutes - Continuous Delivery @ Google,

Continuous Deployment at IMVU: Doing the impossible fifty times a day

Continuous Deployment for Downloadable Client Software

And that was the start of our Continuous Delivery Journey. I implemented Continuous Delivery @ Multunus and spoke about the same @ DevOpsDays '11DroidCon India '11, and Agile India '12.

I listened to a lot of talks in this space and spoke to people like Jez Humble and Fred George during a few occasions. These conversations were inspirational and informative and helped me to get new perspectives.

The First Big Show

The real power of Continuous Delivery was visible to me when we worked with a Media Company. They deployed Android Tablets and Linux Media Players as Kiosk Devices in clinics across the US to air informative content relevant to the patients visiting the clinics.

We built both the kiosk-mode application and also the application that the support team can use for controlling these devices remotely.

This client leveraged Continuous Delivery to their business growth. The following graph shows the growth of devices during the engagement.

The journey through the Continuous Delivery helped me to understand lean thinking better, got more clarity by reading more books in this area, especially:

Spreading The Bug

Continuous Delivery is both good and simple. It's a perfect tool to achieve business success. The question, in that case, is why isn't everyone doing it?

When something is simple, it doesn't equate to being easy. Quite the opposite. Simple things are harder to implement.

We noticed this pattern more when collaborating with other teams during our consulting engagements or during meetups or conferences. These are teams who are maintaining  products in production for many years.

Most of these teams have:

But the  comments from these teams are:

The problems are:

How do I get started?

The usual question that comes up during the conversation about Continuous Delivery, All these makes sense, but how do I get started?

Most of the times, the changes required to be implemented are across the organisation and needs to be planned in such a way that:

This is  based on the below mentioned books and concepts:


So you are convinced to improve your software delivery process.  Do a test drive of the framework with the following steps. 


Value Stream

Value Stream

Action Items

Repeating the above, persistently for few iterations should help you to improve things little by little. Try and let us know your experiences.

Want to know more about the framework? Read our next post.

If you've read this far, only makes sense for you to try this out in your organisation.

Please share your feedback. We'd love to hear your experiences.