Continuous Delivery: What it is, why it works - and why you need it. Part 1

This is the first of three blog postings on the concept of continuous delivery. It’s an important process that can really help SaaS companies improve their efficiency. This blog explains why continuous delivery works, and gives six good reasons to adopt the process. Future postings will show the best practices for successful implementation of continuous delivery, and explain how you can turbocharge the process.

The concept of continuous delivery has become a buzzword in the software-as-a-service (SaaS) field in recent years. It’s touted as a way to improve efficiency and make product releases go more smoothly.

Like any SaaS company, Klipfolio is always on the lookout for new ideas to improve the way we work.

Nearly two years after embracing continuous delivery, we’re thrilled with the results.

And we’re eager to share our continuous delivery story in this series of blogs.

What is continuous delivery?

Martin Fowler, a self-described "loud-mouthed pundit on the topic of software development," gives this definition: "Continuous delivery is a software development discipline where you build software in such a way that the software can be released to production at any time."

Jez Humble of the University of California, Berkeley, co-wrote a book entitled Continuous Delivery with David Farley, who is now based in the U.K. Humble defines it on his website this way:

"Continuous delivery is the ability to get changes of all types - including new features, configuration changes, bug fixes and experiments - into production, or into the hands of users, safely and quickly in a sustainable way. (The) goal is to make deployments - whether of a large-scale distributed system, a complex production environment, an embedded system, or an app - predictable, routine affairs that can be performed on demand.

Continuous delivery, as we see it, is a collection of processes, tools and culture used to deliver incremental value - for example, release software improvements like features and bug fixes - to the customers.

It’s about changing the way SaaS companies work - speeding up the process by breaking the product changes down into smaller, easy-to-manage increments that can be released quickly. It is worth mentioning that continuous delivery is not just relevant to software development teams. It’s a philosophy and approach that has a positive effect on the business as a whole, making it more nimble.

When we started our continuous delivery journey almost two years ago, we were releasing our software once a week at most.

The process was mostly manual and only one person in the team was responsible for the releases.

Today, we ship software to production almost every day, and anyone in the development team can do the releases.

In 2016 we had 183 releases. Our target for 2017 is at least 200, which we are tracking closely using our own dashboarding product.

What are the benefits of continuous delivery?

The fact is, that even though we’re doing around 200 releases a year - that’s closing in on one for each working day of the year - our releases are better, our customers are happier, and we have a better team. That is because continuous delivery allows:

1. Problems to be fixed more quickly
2. Faster delivery of new features
3. A reduction in exposure to risk
4. Speedy course adjustments as feedback comes in
5. Improved software development process and practices
6. Better team morale

Continuous delivery helps fix problems more quickly

By changing the processes of our software delivery pipeline, we’ve become more agile. Not only have we reduced our time to market, but our improved agility is worth its weight in gold when it comes to customer satisfaction. There have been cases where we’ve been able to fix a software bug with more confidence within hours after a customer raised the issue.

Continuous delivery helps deliver new features faster

That improved agility of our software delivery pipeline has also allowed us to be more responsive to our clients’ needs and market realities. By implementing continuous delivery processes, we’ve vastly improved our ability to respond to customer requests. When it comes to new features suggested by customers, for example, we’ve had cases where we’ve gone from ideation to production in less than two weeks.

Continuous delivery allows cut exposure to risk

By breaking our work into smaller increments, we’ve reduced the possibility of error. When you ship more often, you essentially ship smaller known changes of your software to production. In some cases, we even ship subsets of a feature to production and start testing it internally before exposing the feature to the public. This not only reduces the potential for problems, but also makes it easier to identify the source of any problems that do crop up, and react to them. And there are no big bang events when we do a marketing launch of our large features, since in most cases they are already in production and have been tested by some of our customers already.

Continuous delivery makes it easy to change course as feedback comes in

Because we release so often, we don’t have to deliver every element of a feature at the same time. We can deliver a first set of features - the minimum viable product - and use tools like Mixpanel to observe how users interact with our product. Once we get user feedback, we can decide on the next set of priorities. This reduces guesswork and delivers what customers need to be successful. If you release less often, it’s much harder to have that level of fluidity in your planning and execution.

Continuous delivery makes software development process better

To release more frequently, we were forced to rethink our processes and practices. This resulted in a more mature development team. We’ve automated many of the manual steps, we’ve added many new automated tests, developed a development manifesto that we follow and other things that I’ll address in my next post.

Continuous delivery boosts team morale

Morale is always an important – if not the most important – aspect of any team. The positive energy created when the team is really humming is a spur to creativity and ideas. We’ve found that engineers experience an incredible sense of accomplishment whenever they ship a fix or feature to customers. Because they are shipping more often, team morale stays high. I have had many new team members express amazement about how agile we are as a company and how great our team is after they shipped their code changes in less than two weeks after starting work. (For new hires, this is an important part of the onboarding process; see our recent onboarding blog.)

Continuous delivery is a journey that lasts as long as your product does. Senior management and the rest of the departments have to buy in to the concept and invest in it. It takes time, effort, and change to make continuous delivery work, but it makes the whole organization more agile and gets the team thinking differently, which in turn delivers value.

In the next blog in this series, I’ll look at how to achieve continuous delivery, and list the steps and best practices to follow.

Ali Pourshahid, PhD, is Director, Software Development, at Klipfolio. He can be reached at @ali_pourshahid