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”
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. 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.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.
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. 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.
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!).