IPExpo Talk - Why Should I Adopt Continuous Delivery and Where Should I Start?

I was recently asked to participate in the DevOps track at IPExpo Manchester and share some of my experience in adopting continuous delivery. This made a refreshing change from focusing on Jenkins-specific features and techniques. In preparing for this talk it made me think about the projects I have been involved in over the years, what was successful, what was not.

What I concluded was that there is no single "magic answer". It's not the choice of tools, the type of application, the methodology followed or the skills of individual developers. However, ignoring any single one of these aspects is likely to result in missing out on the real benefits of continuous delivery, to name a few:

• Delivering value to users/customers earlier

• Having higher quality systems and deployments

• Having a sustainable (and predictable) development cadence and less team burnout

• Less waste

In the early days, projects I worked on fell into continuous delivery without realising what it was called. The dev teams had adopted agile/Scrum and were building the software incrementally with a robust continuous integration implementation. My team was focusing on the environments and deployment aspects. Being of a development mindset, we were basically lazy in the right sense of the word - why do boring repetitive stuff when you can automate it - so we did. Looking back, we had achieved full automation across all the environments, including full OS installs and config, to app deployment, database change application and load balancer configuration. Each production deployment resulted in a full infra tear down and re-provision. By the way, this was about seven years ago and was pre-Puppet, so the latest and greatest tool is not always needed to be successful. The devil is in rigorous and persistent attention to detail - there's no such thing as partial automation! As I said at the conference, you'd be fairly upset if the "automatic car" you purchased only shifted automatically between gears 1-4 and you had to do 5-7!

But as I thought more, I'd also been involved in more recent projects where despite a desire to adopt continuous delivery, we had not been totally successful. Why was that? As I pondered more, it became clear that we need to cover the areas of people, process and technology with an equal focus. Probably the hardest area is people. Continuous delivery requires a change in mindset - not only within the team, but also the support of the wider stakeholders, such as upper management, business users/stakeholders and critically the way supplier relationships and objectives are managed. The talk I gave presented a number of models for assessing your current state across the various capabilities, and, setting incremental goals to improve. It also discussed how to choose a pathfinder project for an initial adoption of continuous delivery and areas to consider if you are scaling from team level adoption to wider enterprise roll out.

If you would like me to speak further on this subject at your event, please get in touch.