Progressive delivery
Many issues could come up with continuously deploying to production. Even if the software is tested well during the previous phases and our deployment mechanisms are working perfectly, we can encounter situations where everything is running from a technical perspective and still the experience for the end users is very dissatisfying. For instance, a customer might click on a button on a website, and it takes about 30 seconds to get a response, although there is not much load on the system. Such things could come up because the software is not tested under the conditions present in the production environment, and the things users are executing have not been tested in this constellation before. Long story short, we should always aim to deploy our software often and automatically, but we need additional mechanisms that safeguard our deployment process. One of them is progressive delivery.
(Orit Golowinski, https://www.devopsinstitute.com/progressive-delivery-7-methods/)
Using progressive delivery, the software is deployed in a phased way, ensuring that not all users are affected by a problem. In Chapter 6, we will take a closer look at Blue-Green Deployments and Canary Releases, which can be used to not only create preview environments but also to shift production traffic between different versions of a product. At this point, we are able to deploy automatically after a new feature has been introduced and might be able to deliver it to a small user base to see how it performs. As we aim for automation and might not want to make such decisions manually, modern progressive delivery controllers are able to make such decisions based on data. For instance, a new software version gets automatically deployed to 1 of 5 production environments. We want to ensure that requests do not take longer than 500 milliseconds, and in the newer release, the response time must not be more than 10% higher than before. Therefore, we monitor such parameters and configure our progressive delivery controller to wait for some time and shift the next 20% of traffic if our conditions are met.
Progressive delivery is not only used to limit the blast radius of errors but also to validate user acceptance of newly implemented features. Using observability data, we could also find out whether there is a decrease in orders in various timeframes when a new feature is rolled out and can automatically roll back the feature in this case.
We will dive deeper into the various deployment strategies, as well as observability and feature flagging, in Chapter 6 and Chapter 7.