A release strategy controls how a new application version reaches users. Running versions of a service simultaneously lets a team introduce fixes or features incrementally, catch errors earlier, validate assumptions, and experiment without making every deployment an all-or-nothing event. section 1.4.3 section 8.0
Kubernetes deployments, services, and ingress rules provide the building blocks, but coordinating them by hand is cumbersome. A team may need separate deployments, label changes, and replica calculations to distribute requests by percentage. Related changes must line up across resources; scaling demand adds further work, and a deployment with zero replicas cannot answer requests. GitOps does not remove the need to configure those resources correctly. section 8.0 section 8.1.4
Two platform capabilities reduce that manual work:
- Knative Serving routes traffic among versions deployed at the same time. Its Knative Services support canary releases, blue/green deployments, and A/B testing; its autoscaler adjusts capacity with demand. section 8.5
- Argo Rollouts offers canary and blue/green releases through Rollouts, integrates with ArgoCD, and provides AnalysisTemplates and AnalysisRuns for automated checks of new releases. section 8.5
Releasing the Conference application
Deploy different versions of a Conference service simultaneously, then use Knative Services to route traffic between them. Alternatively, use an Argo Rollout for a canary or blue/green release. In either case, check that service API changes remain compatible with dependent services: traffic management alone cannot prevent downtime caused by broken contracts. section 8.5 section 8.1.4
