What is Progressive Delivery and How to Implement it?

Why Progressive Delivery?

More than ever, customer experience is of utmost importance for all organizations to stay relevant and stand out from the crowd. And with faster time-to-market with CI/CD pipelines ensuring control of the software release to customers can be tricky. 

Many of our prospects quote two fundamental reasons for the poor adoption of their product: 

1. The application did not provide adequate value to the customers, or 
2. The application was unstable and clunky 

To overcome the challenge of providing a better customer experience with your product, you need Progressive Delivery to mitigate any eventualities while delivering software at speed. 

What is Progressive Delivery?

Progressive Delivery is the ability to deploy new software in a controlled fashion and provide safeguards and control levers that help us mitigate the risks of continually pushing new code to a production environment. 

Various rollout strategies play a vital role in achieving progressive delivery while introducing an application into the production environment. Deployment or rollout strategies are used for exposing users to the new features or changes in the software. They confer many advantages, such as risk mitigation, better quality, and reduced downtime. 

The execution of deployment strategies takes place in three phases.

At first, deploy the software, then gradually shift the traffic using a load balancer to expose users to the new version. 

Secondly, we then monitor and analyze the performance of the software in the production environment.  

Then, based on the behavior and health of the deployed application, we decide whether to rollback or rollforward.

Though there are many deployment strategies, we will highlight four important deployment strategies to implement Progressive Delivery for your organization. 

Implement Progressive Delivery using various Rollout Strategies

1. Targeted Rollout
2. Canary Deployment
3. Ring Deployment
4. Percentage Rollout

Targeted rollout 

As the name implies, the targeted rollout is a strategy where a selected group of customers with shared attributes is exposed to the new release of the software. This strategy is relevant when a new feature is developed with some hypothesis and needs to be beta tested.

After rolling out the product to a sect of the audience, customer feedback needs to be taken. Critical parameters about the application’s health need to be determined before progressing or halting the delivery.

Owners: Product manager, or a business manager 

Canary Deployment

We pick a small percentage of production traffic in this kind of rollout and expose it to the new version (called canary), say by 5% initially, and then gradually to 10%, 20% based on the performance and quality of the application in each stage. If there are critical anomalies and application health behaves abnormally, we retreat to the older version (also called the baseline version)

Unlike targeted rollout, this strategy does take into account the type of customers.

Owners: DevOps Engineers, Product Manager, SREs

In case you want to understand more about canary, please read What Canary Analysis is. 

If you are using Spinnaker, then read how to deploy canary into Kubernetes using Kayenta. 

Ring Deployment

Ring deployment strategy is used to gradually progress a new feature to bigger sets of users (also known as rings) based on acceptance of the users in the previous rings. It is an evolved form of the targeted rollout, as the users in each ring are determined based on some common attributes. 

The user sets can be classified into different rings such as canaries ( with the least number of users), early adopters ( more users than canary), and finally, all the users. When you feel the users in the canary ring are satisfied, you should move it to early adopters. 

Owner: Product Managers

Percentage rollout 

Like Ring deployment, Percentage rollout is used when your target audience is uniform and cannot be categorized into subgroups. In that case, to minimize the risk, we can rollout the software feature to a small percentage of users (say 10%) and observe their reaction. If the new feature is getting good reception, the traffic to the feature can gradually be increased to more users. And slowly shape the traffic in increasing percentages to mount the pressure on the new release. Based on the results from each traffic increment, we finally decide whether to rollback or roll forward. 

If issues are spotted in the first 30% of the release, there is always a provision to restore the previous version. 

Owners: Product Managers

Note: All the strategies above require making data-driven decisions by teaming up with product owners, developers, and SRE’s to ensure the optimal functioning of the application stably and see that it delivers the value that the customers are looking for. 

Top three consideration while implementing Progressive Delivery 

Use CD pipelines to automate deployment strategies

Implementing progressive delivery would require creating and maintaining many scripts manually. The idea of CI/CD is to roll out as many features in a shorter period, but the inability to manually handle deployment and rollout can be a real challenge. So you need an orchestration tool that can help you in defining and automating the deployment pipelines. Once you have those pipelines in place, with small human intervention for decision making, you can take a call regarding critical events such as rollback or roll forward. 

Faster decision-making during deployment

The key to progressive delivery is to make decisions to incrementing traffic or rollback based on specific criteria. But if the decision would depend on the data gathering, it might take hours to approve or reject a canary, and you surely don’t want to scrabble in production environments. You need a mechanism to scan logs and metrics and assess the risk of your software in real-time. 

Reduce risk early in the software delivery process

Suppose you want to deliver a new feature into production without any risk. In that case, you need to analyze your software from the beginning of the software delivery process—adequate and faster checks before progressing the software to the next stage in the pipeline. The below image represents the automation and command that is required for faster, secure and safe software delivery process.

E.g. is the unit/integration testing done? Is the security scan above 80%? Or, Has the software passed smoke and sanity testing? Or, Is the Kubernetes manifest a valid YAML? Are the Dockerfiles hardened? Have the QA-approved test cases, etc.

Implement security, compliance, and verification gates in your pipeline to progress software from one stage to another stage only if it has passed all the SDLC policies in your organization.

(Our head of sales engineering, Bob, refers to this as Command and Control in SDLC).

Achieve Progressive Delivery with OpsMx

OpsMx offers Intelligent Software Delivery (ISD) platform built in Spinnaker to help you achieve progressive delivery. Our ISD platform provides

• Automated pipelines to deploy software safely using strategies like a canary
• AI/ML-based verification to analyze the quality and performance of your software on a real-time basis
• Policy, Security, and Approval gates to enforce in the pipeline and minimize the software risk.

Watch the whole webinar on progressive delivery by Bob, Head of Sales Engineering at OpsMx.