Progressive delivery is a modern way of delivering applications so that end users are not affected by issues, bugs, latency, and vulnerabilities that typically accompany any release. Rather than deploying an update to the entire user base, progressive delivery is about deploying to a subset of users first, and then gradually expanding the release until it reaches all users. There are many tactics such as canary releasing, blue-green deployments, and A/B testing that are examples of progressive delivery. As organizations look to release new features more often, and still deliver a stable and seamless user experience, progressive delivery is key to modern software operations. (If this is new to you, here is an intro article to service meshes and progressive delivery.) 

Yet, there are many challenges that teams implementing progressive delivery face. Progressive delivery requires clearly defining the subset of users, the pace of rollout, and fallback mechanisms. These are typically done manually by Platform teams and are error-prone. Further, Platform Operators need vital real-time monitoring metrics to assess whether a deployment is going as planned or if it needs intervention. These challenges require modern solutions that are not based on manual effort, and can be scaled effortlessly. That is what GitOps offers.

Making sure the entire system is declarative, GitOps brings greater control for defining which parts of a system receive an update. This can be defined in a Git repository in great detail. Once defined, a tool like Flagger is able to read these instructions and roll out the deployment with the help of a service mesh tool like Istio, Linkerd, or Kuma Mesh. Recently, we have written extensively about how Flagger works with service mesh tools like Linkerd and Kuma Mesh to handle progressive delivery.

We have now combined this information into a concise Use Case page describing the benefits of using GitOps to manage progressive delivery. Have a look!