Everyone wants to deliver better software without sacrificing speed or safety.
And yet, the velocity of releasing software remains a relatively subjective experience for each organization. For instance, it’s very easy to say you’re performing continuous delivery (CD), but what that actually looks like in practice differs depending on the company.
To get a better feel for the state of continuous delivery and how teams are delivering software, LaunchDarkly and Sleuth partnered with DZone to survey software developers, architects, site reliability engineers, platform engineers, and other IT professionals.
For the purposes of this report, we’re defining continuous delivery as the process of releasing new code to quality assurance for testing on a rapid, continuous basis.
Our questions aimed to gain a stronger understanding of the motivations driving the adoption of continuous delivery, metrics being tracked, use of feature flags, and more.
Reasons for adopting Continuous Delivery
It’s been said that the c-suite loves continuous delivery more than developers do.
We wanted to understand why continuous delivery is attractive to software professionals in general, and specific job roles in particular, so we asked and then segmented by job role.
The top two reasons for adopting continuous delivery (increased speed of feature delivery; shortened development cycles) are related to velocity from a developer’s point of view. Other goals that represent the same improvements — but from project management/ops perspectives, e.g. increased release frequency and reduced deployment error rate — are ranked lower overall.*
To read full download the whitepaper:
Hyperdrive: A Continuous Delivery Report
