Continuous Release: Move Faster without Breaking Things
From speaking with hundreds of customers over the past few years, I’ve heard a lot about how LaunchDarkly has helped make the process of deploying code behind a flag a stress-free experience. But software releases, the last mile of feature delivery to end users, are still tough to get right for many engineering teams. This got us wondering why releasing code remains challenging when building and deploying has come a long way over the past decade.
The answer lies in the differences between deploy and release.
Because of the advent of agile software development and CI/CD solutions, continuous deployment is an achievable standard for most modern software development organizations. But it wasn’t always like that. Continuous deployment used to be a scary, risky concept to implement. It’s only possible now because of iteration over time, and critically, the introduction of tools that made it safer and more practical to deploy more often. Feature management tools helped, too, by allowing developers to merge their code to production behind feature flags, in a way that was unbeknownst to end users.
In contrast, release processes today are where deployments used to be — less mature and often heavyweight without streamlined best practices and good tooling. This makes the promise of continuous releases seem far-fetched in contrast to the way code is written and deployed. Teams often develop ad hoc or stopgap measures for releases that end up acting as antipatterns. Rituals like one “Release Day” every quarter, or tracking hundreds of pull requests across large spreadsheets or requiring multiple teams to be on a release conference call, are all examples of archaic but necessary ways in which teams reduce the risk of releasing buggy software to production. With cobbled-together release processes, teams miss out on the benefits of having a shared language through process standardization and require more manual intervention, leading to more risk.
For development teams to perfect that last mile of software delivery and truly achieve continuous release, they need a few things:
- Visibility: Understanding the status of multiple releases across the entire software organization is critical to developing efficient release processes. Too often, this requires extensive planning and documentation outside of the tools of record. Teams want a single place to understand the health of an ongoing project at a glance.
- Governance: Developing best practices and safety checks, and codifying them to map to your organization’s specific needs and constraints is tough to get right. But what’s even more difficult is defining that for different types of releases that may have a different risk appetite. For example, a new product launch warrants more thorough testing, scheduling, approvals and a progressive rollout plan, as compared to an emergency bug fix.
- Release progression: Rolling out a change safely across multiple environments and guarding against the downside requires diligence and a lot of manual effort. We constantly hear about the need for engineers to have predefined pathways that can act as conveyor belts and safely deliver their features to customers.
At LaunchDarkly Galaxy 23, our user conference, I’ll be introducing new product capabilities that our team has built to help de-risk releases for small and large teams at scale. LaunchDarkly users will now be able to embed best practices into reusable release pipelines so every change can follow a successful path to production, with built-in progression tracking that sends a prompt when phases are complete. In addition, users will be able to track and know the exact release status of each feature with a releases view that provides real-time visibility across each project for all of your stakeholders.
