This post is part of “Progressive Delivery” series.

  1. Introduction to Progressive Delivery (this post)
  2. Practical Progressive Delivery with Argo Rollouts - Setup
  3. Practical Progressive Delivery with Argo Rollouts - BlueGreen
  4. Practical Progressive Delivery with Argo Rollouts - Canary
  5. Practical Progressive Delivery with Argo Rollouts - Auto rollback with metrics

Table of Contents:

Background

Software delivery is one of the most important process in software engineering. It is the point where the software starts to create value for the customers. Doing it right can make a different to the company and team that deliver the software.

This post will talk about a modern software delivery approach, Progressive Delivery, how it is different from the approach before it, why it can help us deliver the software faster, with less risk, and add more value to the customers.

Software delivery approaches

Methods that are used to deliver the softwares from traditional to modern.

Simple deployment. Replacing the old version with the new version. It is the riskiest one since the service won’t be available if the new version failed. Another downside is that it requires some down time.

Simple deployment

Rolling update deployment. This is a little bit more advance than the simple deployment and used when we have multiple servers running the service. User accesses the service through a Load Balancer that directs users to the actual service. The deployment will replace the old version one instance at a time until every instances become the new version. The benefit is that it needs less or zero down time.

Rolling update deployment

BlueGreen deployment. It means we deploy the new version along side the old version. Then, ensure that the new version is working properly and then switching all the traffic to the new version. This only work if the users access the service through a Load Balancer or gateway. The risk is low with this approach because we will switch to the new version only when it is ready and if something happened, we can switch back to the old version.

BlueGreen deployment

Canary deployment. This is fined-tune version of the BlueGreen deployment. We start with deploying the new version in parallel with the old one the same as BlueGreen. The different is that we let some user traffic to the new version, let’s say, 10% goes to the new version and the remaining 90% goes to the old version. After that, we keep monitor the traffic, if it goes well, we can send more traffic to the new version. This approach reduces more risk since we can test with the real user traffic and if something goes wrong, the impact will be limited to only a number of users. One thing to note is that this approach requires Load Balancer to be able to route some traffic to specific version.

Canary deployment

Progressive Delivery

Progressive Delivery means we deploy new software versions or features to the production as soon as they are done. Then, configure the system to let only specific users to access the new versions or features. Then, we monitor and measure the feedback of each version. This has several benefits.

  • Delivery faster. We can deploy the new features as soon as they are ready since we can set who we want to be able to access them, thus teams don’t need to hold the ready features. Teams can also test their softwares in the real environment before releasing it to the users.
  • Reducing risk. We can allow only a selected number of users to access the new feature. If there is a problem with it, we can rollback before it impacts all the users.
  • Experimentation. Because we can choose which users should access which versions or features, we can run an experiment by splitting the users into groups and let them access different versions, then compare the result of the usage between versions. Sometimes, this method is called “A/B Testing”.

As you can see, Canary deployment can support some aspects of Progressive Delivery because it can split users to access different versions. Some other techniques are also needed to fully support Progressive Delivery such as feature flag and user event recording and analysis tools.

Feature flag

Feature flag is a technique that is used to determine if a user is allowed to see or use a feature by having a mapping between user’s attributes such as country and gender and a feature. The software will use this mapping in conjunction with the current user information to decide if the feature should be available to that user or not. This logic can be in a front end UI or backend API.

User event recording

The software keeps track of user events that come from the users taking an action such as clicking a button or opening a link.

Analysis

The system can use the data about the user accessing a feature with the events that that user produced to find a relationship and create a user’s behavior model. For example, a user from some countries tends to click a particular button more than others.

Conclusion

Progressive Delivery has lots benefit over traditional delivery methods. To do it successfully, you need to be able to manage multiple software versions at the same time. More importantly, you need to be able to correct all the data needed to perform an analysis to see which feature can delivery more value to your customers. You can get your hands on Progressive Delivery by following this post.