Deployment strategy
The chosen way production moves from the old release to the new one, such as rolling, blue-green, canary, or recreate.
What it is
A deployment strategy is the chosen method for replacing the version currently serving production: stop everything and recreate it, replace instances gradually, prepare a blue-green environment, or send a canary a slice of traffic first. The choice fixes who sees old and new code at the same time, how much spare capacity is needed, and how fast rollback can be.
Choose it before the first serious production release, using the service's real constraints. Kubernetes Deployments provide Recreate and RollingUpdate directly; traffic-splitting strategies such as canary and blue-green usually need an ingress controller, service mesh, or a controller such as Argo Rollouts.
Gotcha: the strategy is not just a YAML label. Database migrations, background jobs, sessions, queues, and cached responses may keep old and new behavior alive together. A zero-downtime strategy fails if those boundaries are not backward compatible.
Ask AI for it
Choose and implement a deployment strategy for this Kubernetes service. Inspect its traffic pattern, capacity, state, database changes, and rollback needs, then select exactly one of Deployment RollingUpdate, Deployment Recreate, or an Argo Rollouts canary or blue-green rollout. Explain the choice in a short decision record and add the manifests, readinessProbe, progressDeadlineSeconds, maxSurge and maxUnavailable values where relevant, a post-deploy smoke test, and one tested rollback command. State how old and new versions remain compatible during the transition.