28%. That is the number of teams currently practicing continuous delivery (CD) across all projects, company wide. That means a whopping 72% of software teams are likely to feel dread instead of relief when they hear the term “release” (Source).
The software industry has started practicing continuous integration (CI) in droves because continuously testing your code lets you react to problems in a more agile way. But continuous delivery – as that 28% statistic illustrates – is a different story.
Some might theorize the reason why continuous delivery adoption is comparatively low is that many applications were originally built before CD really came on the scene, and are therefore hard to retrofit into an automated test and deploy process. Others might point the finger at staffing issues. But I don’t buy it – the software industry lacks neither the tools, nor the technology, nor the talent needed to make continuous delivery a reality.
Continuous delivery’s low adoption rate boils down to one thing: it hasn’t been a priority.
This is a mistake – for two reasons that I’ll get to in a moment. But before we talk about why continuous delivery is so important, let’s clear up some confusion about what it is and is not.
Why continuous delivery is universally applicable
We already know that continuous integration is the practice of building and running a battery of automated tests after each code change is made or at frequent intervals throughout the day. In other words, continuously (more or less). Continuous delivery adds another step: each time a build passes all your tests, it’s automatically deployed out to a test or staging environment where it can undergo further testing such as load tests, manual exploratory testing, etc. That process may happen just once before changes are released to customers, or you might repeat it for days (or weeks), building up a critical mass of features and fixes, until finally you decide it’s time to ship.
Let me repeat that last part: you decide. Continuous delivery involves human decision-making around what to release to customers, and when. So when I say “every development team should be practicing continuous delivery”, I mean it. Even teams that make software for the aerospace, financial, or health care industries can do it without falling afoul of regulatory or safety standards. And speaking of universally applicable, the teams at NASA’s Jet Propulsion Laboratory practice continuous delivery in developing the software that landed the Curiosity rover on Mars, processes the data it sends back each day, and beams the next day’s mission plan back up to it. (Now that’s some next-level $#!τ right there.)
It’s the human-decision factor that distinguishes continuous delivery from continuous deployment, which has been made famous in the tech world by companies like Etsy and Netflix. A continuous deployment system automates the entire process from code to customer, allowing you to ship changes several times a day. It’s fabulous in many ways, but it’s just not a good fit for every piece of software. Mobile app users, for example, would go ballistic if they were prompted to download updates every few hours.
So now that we understand why every team can practice continuous delivery, let’s talk about why every team should make it a priority.
The need for speed
Humans are increasingly impatient. We expect the next new thing, and we expect it now, thank you very much. With continuous delivery and it’s requisite automation, you can trickle out “next new things” every few days or weeks – it really just depends on how frequently your customers want to absorb changes.
All teams at Atlassian practice some flavor of continuous delivery. The team that develops Bitbucket Cloud releases small feature sets (usually just a handful of user stories and bug fixes) a couple times a week, which lets them respond to customer requests and complaints in a timely manner. And yes, sometimes they hold larger or more complicated features back until the whole thing is ready so they can do a big “reveal” and get some marketing juice out of it. (Human decisions for the win!)
The teams that make the Jira and Confluence product families work in much the same way when it comes to their Cloud offerings. Then every few months, all the changes that have been rolled out to, say, Confluence Cloud are packaged up and released as the next version of Confluence Server, which is the install-on-premises option.
A steady flow of improvements keeps customer satisfaction high – continuous delivery is just good business.
Our team of growth hackers, on the other hand, uses continuous delivery to get experiments out the door quickly. Will changing the text on a button entice more customers to use a certain feature? Will a new on-boarding flow help our evaluation-to-purchase conversion rate? There’s only one way to find out: try it, and see. With continuous delivery, we can get feedback from users in record time, which takes a lot of the guess-work out of improving our products.
Behind the scenes, continuous delivery lets development teams get test results within just a few minutes and gives them an opportunity to explore further when passing builds get deployed to a test environment. The fast feedback means they don’t switch contexts by moving on to other coding tasks or layer more code on top of code that – oops! – turns out to be broken. Bugs get fixed almost as quickly as they are introduced, and with less effort, which means more time available for paying down technical debt and getting those “next new things” into customers’ hands.
Juicier problems, stronger teams
Automation not only gets your product to market faster, it lets you get more out of your teams without asking them to work longer hours. As our lead developer on the Bamboo team likes to say, “Free people up to solve problems, and make a computer do the rest.” I think she’s on to something there.
You don’t need an Ivy League MBA to know that people are more engaged with their work and more productive when that work is actually interesting. And because continuous delivery by definition automates a metric ton of routine manual tasks, it becomes a mechanism for increasing employee satisfaction.
For starters, engineers get to tackle the interesting problems of constructing the continuous delivery pipeline and developing a test automation strategy. Then, with the mind-numbingly repetitive aspects of their jobs automated away, there’s time for exploring new technologies, experimenting with hare-brained ideas that might just turn into a breakthrough for your product, and of course, working through your backlog of features and fixes. All of which is simply a lot more fun to work on than manually testing login functionality for the 20th time this week.
It’s just business
In short, practicing continuous delivery is a competitive advantage. Delivering frequent, incremental changes and getting customer feedback on them lets you take small, calculated risks with your product, and shape it to suit your market’s needs faster that other companies in your space. And making computers do the routine work not only helps you get more value from your team members, but increases their sense of job satisfaction (which makes them more engaged in their work, which helps you get more value from them, and so on… upward spiral!).
At Atlassian, we’ve seen huge returns on our investment in continuous delivery in both those ways. And we want the same for you. That’s why we’re excited to introduce The Pipeline – our guide to continuous delivery with Jira Software, Bitbucket, and Bamboo. Inside, you’ll find more about building the business case for continuous delivery, continuous delivery workflows for various product types, and loads of tips for putting it all together using Atlassian tools.
Whether you’re just starting to think about continuous delivery, or already a practitioner, The Pipeline is designed to help your team work smarter, build better, ship faster, and become stronger.
Learn more about continuous delivery
And if you’ve found this post useful, please share it on your social network of choice so your fellow software makers can learn from it, too!