Progressive Delivery: Deploying and Releasing in Stages

July 22, 2024

Article by Mateusz Kwaśniewski

In the realm of Continuous Delivery (CD), where the objective is to ensure that software is always in a deployable state, there is still significant value in not exposing all users to new capabilities immediately. Progressive Delivery leverages this principle by gradually rolling out changes to a subset of users, testing in production, gathering feedback, and then expanding the release based on the results.

Why Progressive Delivery?

When working on new features, it’s often beneficial to experiment with a small percentage of users first—perhaps even as small as 1%. This controlled exposure allows teams to gather feedback on usability, correctness, and other factors before increasing the rollout percentage. This incremental approach can be implemented at both deployment time and runtime.

Progressive Deployment

Progressive deployment involves deploying a new version of software to a small percentage of users initially. This approach helps reduce the risk of introducing bugs or issues for all users when rolling out a new version of our application. One common technique used for this purpose is canary deployment. Various technologies support canary deployments. For instance, at Unleash, we use a custom-built Kubernetes operator to manage deployment channels.

At Unleash, we categorize our customers into groups such as demo users, early Pro plan users, established Pro plan users, and Enterprise plan users, deploying the new version to each group at a different pace. With each deployment, every customer in a channel gets all new code created since the last deployment. Charity Majors likens deployment to a chainsaw, emphasizing its broad nature, compared to a scalpel-like feature flag explored below.

After each deployment, we can observe application stability and the impact of changes, such as one-liner bug fixes or trivial code changes (e.g. automated refactorings). For very simple changes, deployment and release can be the same thing. However, we don’t want to use deployment as a release mechanism for more complex features and code changes where the probability and impact of issues are high.

Progressive Release

Beyond deployment, we use feature flags (yes, we use Unleash to build Unleash) to control which customers can access individual new features at runtime without needing a code deployment. This practice of progressive release allows us to gradually expose features. This enables us to validate the solution meets users expectations and is performant in real-world scenarios.

In each new deployment, all code paths are physically in production, but not all are enabled for every customer. This decouples deployment (code being in production) from release (code being available to users). Using Charity Majors’ metaphor again, while deployment is a chainsaw, progressive release is a powerful scalpel, offering precise control over feature exposure.