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.

\ 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 '11, DroidCon 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:

• Lean Mindset
• Lean Enterprise
• Lean Startup

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:

• Automated tests
• Automated Deployments
• Continuous Integration setup

But the  comments from these teams are:

• Not sure when my code gets merged to master because it is awaiting review
• When will my commit go to production, I don't know
• If the business wants to deploy now, it is not as simple as running a single command. It involves:
  • Merging branches together
  • Do manual testing because of lack of confidence in the test suite
  • Dependency on the OPs team for infra setup even though the script exists

The problems are:

• Lack of flow from commit to production
• Manual testing, because of lack of confidence in the test suite
• Deployments being Coupled with releases

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:

• No, or  little negative Impact on the BAU
• Have small, but visible wins at the early stage itself
• The team that is involved are the early adopters of the change

This is  based on the below mentioned books and concepts:

• DevOps Handbook
• Toyota Kata
• Design Thinking
• Theory of Constraints
• Deming Cycle

DIY

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

• Draw the entire set of actions that happens from the point of identifying what needs to be delivered to the point of deploying it to production. 

\

• Below each step, note  the time it stays at each stage, including the waiting time

• Identify 2-3 burning problems which slow down the delivery flow. Prioritise them. Identify the root cause using 5 Whys.

• Brainstorm and write 3-4 action items, prioritise and pick up one. Apply the Diverge-Converge approach of Design Thinking, to arrive at creative ways to solve the problem.

• Implement it, do frequent reviews and repeat the process

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.