The deploy stage is where built artifacts become running software, and choosing a strategy shapes both safety and velocity. A recreate deployment simply shuts down the old version and starts the new one, which is simple but causes downtime and is suitable only for development environments, applications that cannot run multiple versions simultaneously, or major schema changes where backward compatibility is impossible. Rolling deployment incrementally replaces instances of the old version with the new batch by batch and is the default in Kubernetes — it requires no extra infrastructure but means mixed versions run during the rollout, slowing rollback. Blue-green deployment maintains two identical production environments and switches traffic from the old (blue) to the new (green) environment once it is verified, giving zero-downtime releases and instant rollback at the cost of double infrastructure and tricky database migrations.
Canary deployment routes a small percentage of real production traffic — typically 5%, then 25%, then 50%, then 100% — to the new version while monitoring error rate and latency. The newer version gets real-world load without putting all customers at risk, and metrics-degradation triggers automatic rollback. A/B testing is similar in mechanics but different in purpose: the split measures business outcomes such as conversion or revenue rather than stability, with traffic routed by user ID, geography, or cookies. A beta release is separate from both — it is a user-opt-in program that collects qualitative feedback rather than measuring production traffic. Dark launching deploys a new code path behind a feature flag and exercises it with real production traffic without exposing outputs to users, validating scale before any visible change. Each strategy trades off infrastructure cost, complexity, and risk in a different way, and the maturity of monitoring and traffic management decides which is safe.
Progressive delivery is the umbrella term for canary, blue-green, feature flags, and dark launches combined with automated safety checks driven by metrics and error budgets. A service mesh such as Istio, Linkerd, or Consul makes progressive delivery practical by giving every pod a sidecar that controls traffic without app changes — a `VirtualService` can route 5% of requests to v2 and 95% to v1 and ramp the weights up over time. Argo Rollouts is a Kubernetes controller that supersedes standard Deployments with first-class canary and blue-green strategies, automated Prometheus analysis, and traffic splitting through Istio or NGINX. Spinnaker, the Netflix-origin platform, includes canary analysis with both manual judgment and automated scoring via Kayenta, which compares canary and baseline metric distributions using statistical tests such as Jensen-Shannon divergence and produces a score from 0 to 100 that drives the pipeline forward or rolls it back.
GitOps extends the same ideas to infrastructure and configuration. In a GitOps model, Git is the single source of truth for both application code and the desired state of the cluster, and an agent continuously reconciles actual state to that description. ArgoCD watches Git repositories and syncs cluster state to match; Flux CD provides similar functionality with a more modular toolkit architecture that platform teams often prefer. Both detect drift and alert when the running cluster deviates from what Git describes. Combined with Helm charts, which package Kubernetes manifests as versioned templates, GitOps gives you reproducible, auditable infrastructure deployments driven by pull requests. Multi-environment deployments typically flow `dev → staging → production`, with environment protection rules (`environment: production` with required reviewers in GitHub Actions) gating the final promotion; ideally the exact same immutable artifact is promoted through each tier rather than being rebuilt per environment.
Ephemeral preview environments push progressive delivery into the pull request workflow. Each PR can be deployed to a unique URL — tools like Vercel, Netlify, Render, Heroku Review Apps, Gitpod, or ArgoCD PR apps spin up a dedicated environment, expose it for design and integration review, and tear it down automatically when the merge or close occurs. SHIPPED is the final tier in a typical release pipeline where the artifact is exposed to all end users; lower tiers such as DEV, STAGING, and PROD-CANARY gate access to internal users or a small percentage of real traffic first, building confidence progressively. Feature flag services like LaunchDarkly, Flagsmith, Unleash, and GrowthBook decouple release from deploy: a flag ships in production but stays off until you flip it, allowing dark launches, gradual rollouts, A/B tests, and instant rollback with no rebuild. Argo Rollouts and ArgoCD are complementary — ArgoCD applies the new ReplicaSet definition, and Argo Rollouts drives the gradual traffic shift.