A key challenge in developing applications for the cloud age is dealing with the continually shrinking interval between updates. Why, then, is automation of release and deployment so rarely used?
In the mainframe days, applications were written to run on one and only one machine, not the billions of smartphones, tablets, and IoT devices we develop for today. Years could pass between updates. Even in the client-server days, apps were written to run on a small number of servers running network operating system. Application updates to add new functionality were still spaced far apart. Not so much anymore.
Today, it’s common for apps to get updated biweekly for competition-driven feature enhancements and seemingly daily for bug fixes. And we’re writing for billions of devices running a bunch of different operating systems, whose features change radically with each new version, and all sporting a veritable cornucopia of screen sizes and resolutions.
It makes you wonder why we’re all breaking our necks to develop apps faster if we’re not any good at shipping the code out the door.
You’d think that a faster time to market for would be competitively advantageous, or that rapid updates to fix the bugs that crept into yesterday’s update (due to inadequate testing) would drive any corporate or commercial developer to implement automated release management. But, no.
Theresa Lanowitz, CEO of the research firm voke (yes, with a lower-case “v”) opened my eyes to this in a new study just published by her firm called Market Snapshot Report: Release Management. In a lengthy conversation she expressed surprise that the use of automated release management isn’t more widespread.
Releasing software faster and with higher quality is a challenge for more than 60% of survey participants, Lanowitz said. Just 14% reported no issues. So, what are these challenges? Struggling to release faster was cited by two-thirds of respondents. Just behind was the struggle to release higher-quality software at 60%.
Separately, more than half of those surveyed admitted that their organizations had to delay one or more software versions due to problems with deployment or release. It makes you wonder why we’re all breaking our necks to develop apps faster if we’re not any good at shipping the code out the door.
For the very first time since voke initially started doing this longstanding recurring study, respondents indicated that quality is more important than release. Think about that.
It’s the case of a dog chasing its own tail. If apps were of better quality, they would likely not need to be released as often. And if you build something better in the first place, you have a better chance of satisfying the customer. Check your phone — does the near-daily frequency at which some apps release bug fixes lead to a fatigue factor among users? I think it does.
The voke survey also looked at the build and deploy phases of a development project. Regarding build approach, only 29% do continuous integration with automatic check-in of each build. Gated check-in in which check-ins are accepted only if the changes merge and build successfully, was practiced by just 19%. Further down the list are manual, scheduled, and rolling builds. As for deployment, automation through scripts was performed by 32% with manual scripts just behind at 31%. The use of containers, including as Docker, CoreOS, LXD, Kubernetes, and others, lagged far behind at just 9%.
Lanowitz characterized the lack of automation as surprising as well as damaging to the business, given that release management is not new. I’d call those adoption rates shockingly low.
How well does your organization do when it comes to release management? Are you fully or partially automated? Or are you still completely or primarily manual? What is the impact these practices has on bringing new versions to market quickly and on ensuring that releases are not being deployed to fix bugs in prior releases? Share your experiences with us; we’d like to hear from you.