If your organization has established an efficient CI/CD pipeline and you’ve made a successful transition to DevOps culture, you probably already understand the benefits of doing DevOps. Your teams share information and collaborate efficiently, and you’ve seen measurable increases in software delivery speed and quality. Aside from continuing to do what you’re doing, though, where do you go from here? How can your teams reach the next phase of DevOps maturity?
Once you’re comfortable with continuous integration and continuous delivery practices, the next step is to get really good at progressive delivery.
Continuous Delivery vs Progressive Delivery
First of all, what’s the difference between continuous delivery and progressive delivery? The goal of continuous delivery is to always keep code ready to be deployed. It helps developers release faster. With more frequent releases that introduce smaller incremental changes, developers can also reduce the chances of things going wrong in production.
Progressive delivery can be seen as an iteration on the concept of continuous delivery. It’s a natural evolution — while increasing release speed and quality is still the end goal of progressive delivery, its focus shifts from the code level to the feature level.
This shift opens up another way for you to de-risk your deployments. With progressive delivery, developers roll out features to a small, low-risk audience first (such as internal QA teams). Features are then released to real users in a controlled, measured manner. This is different from a canary release using standard CD tooling. Developers can gradually “turn on” new features via flags instead of staged deployments — there are no feature branches. Or they can use feature toggles that set up A/B testing to learn which version users prefer.
It’s a repeatable, automated way to test and learn in production based on real user behavior and feedback. Developers can ensure the highest quality code reaches users fast without the risk of releasing to all users at once. This can significantly improve the team’s failure rate, one of the DORA metrics that leaders use to measure DevOps performance.
We put together this chart to help compare continuous delivery and progressive delivery.
How Do Developer (and Operations) Teams Achieve Progressive Delivery?
To get started with progressive delivery, teams need mature CI/CD pipelines — and they need feature flags. Feature flags are a crucial element — without them, progressive delivery is impossible. Using the fine-grained controls that feature flags grant at the feature level, developers can test in production on real users with very low risk. If something goes wrong, anyone (a developer or otherwise) can turn off the associated flag and revert back immediately.
This is the foundation of progressive delivery, but developer teams must figure out how to build it into a repeatable, automated practice — especially if they need it at enterprise scale. While feature flag adoption is key, developers also need to manage feature flags well in order for progressive delivery to take root and grow.
More Than Feature Flags: So, What Else?
You can’t have progressive delivery without feature flags. Still, you can’t just drop in a few feature flags and say you’ve achieved progressive delivery. If you want those practices to stick, you need to institute a repeatable, sustainable process for feature flag management.
To do this, CI/CD and feature flags should go together in lockstep. Your feature flag management tool needs to integrate with your pipelines, ideally evolving into a seamless software delivery system for progressive delivery at enterprise scale.
We wrote about what to do to make this happen in our blog post on enterprise progressive delivery. Essentially, your CD pipeline needs to be able to accept flags as input and maintain common visibility — and it needs to be able to show how all your flags are configured in tandem with current release criteria. Your CD pipeline needs standardized controls and governance for feature flags — for example, it should be able to control change permissions and read audit logs. You may also want to engage in smart automation at the feature level for things like gathering feature flag performance data and setting consistent rollout and rollback policies.
Finally, progressive delivery needs support at the cultural level in your organization as well as the technological. Developer teams should be ready to embrace cultural changes like releasing “incomplete” code to production — moving away from the idea of production as a single source of truth.
If you have strong CI/CD processes in place, it makes sense to consider progressive delivery as your next step to making releases even faster and better. It applies the continuous delivery concepts of moving fast and de-risking deployments to the world of features, but progressive delivery isn’t just “continuous delivery with feature flags.” It’s a holistic change to the software delivery model.