We recently ran a survey focused on engineering velocity and release practices and it reveals engineering organizations are struggling because they’re missing the right automation.
This post is the first in a series analyzing results from the survey.
The problem is driven by two factors:
- The move to microservices makes code delivery much more complex and difficult to manage.
- There are fewer and fewer companies that aren’t “technology” driven at their heart.
Teams have been speedily adopting microservices to handle problems of scale and for the most part, microservices have delivered on their promise. While microservices solve some developer scale problems by allowing smaller teams to own a smaller chunk of an application in the form of a microservice, it’s also created a lot more complexity to deliver that code to production. Instead of having a single automated pipeline, teams with 300 microservices need 300 pipelines (or maybe several really robust pipelines).
The second point is familiar but bears repeating. 15 years ago you could manufacture a grill and sell it without a technology organization. That’s no longer true and even the most traditional old school businesses have engineering teams as key contributors. This often means smaller engineering teams with less experience and fewer resources which makes tools much more important.
Let’s get into the takeaways!
Survey Participants
We surveyed members of engineering and operations teams across the industry. This is not a survey of Codefresh’s users, but rather engineering teams in general.
More than half of engineering teams released monthly or slower in 2018 and very few expect to improve in 2019.
Only a few teams expect to improve their release cadence going into 2019 but reading these results I imagine there are a lot of teams desperate to get out of quarterly release cycles. It’s shocking in 2019 that so many organizations still only deploy quarterly.
Teams want operations out of the deployment process, putting more control into the hands of engineers and release managers.
The changes here are not dramatic but there is a clear shift away from operations running deployment with a full 8 point drop. The responsibility of deployment is shifting left to the application engineer.
Almost no one has automated the entire CI/CD process.
A plurality of engineering teams have automated less than 10% of the process.
It’s no wonder that so few engineering teams deploy quickly when so much isn’t automated. In fact, it’s the biggest obstacle to engineering teams.
Every single respondent said automation was a major reason they don’t deploy faster.
Missing automation is the biggest missing piece for these teams. Considering engineering is one of the most expensive line items for any organization, it’s shocking just how little of the process is automated. We did a case study with an engineering team that was able to improve their code/build/release cycle by 24x just by introducing solid automation. Increasing developer velocity is absolutely critical for these organizations. Not only does it make engineers happier, but it makes them more competitive and delivers more value by delivering changes faster and with more frequency.
For a comparison, I recently talked to an engineering team that implemented a change that would earn their company an extra $10 million/yr. Imagine if they could get that change into production just a week faster. That’s an extra $200k towards their bottom line for just that one change. Now average it out across all the changes and overall the engineering teams and a picture starts to form about just how important automation is.