Operating Progressive Delivery with Argo CD and Argo Rollouts

Why GitOps needs progressive delivery

GitOps makes desired state reviewable and convergent. It does not prove a release is safe. Progressive delivery adds controlled traffic movement, health analysis, and rollback criteria that operators can reason about during a live change.

Rollout design principles

• Start with small canary percentages for services with unknown failure modes.
• Keep analysis windows short enough for operator attention but long enough to catch real saturation.
• Roll back on user-impact signals, not only pod health.
• Keep every automated gate explainable from dashboards, logs, traces, or Kubernetes events.

strategy:
  canary:
    steps:
      - setWeight: 10
      - pause: { duration: 180 }
      - analysis:
          templates:
            - templateName: error-rate-check
      - setWeight: 35
      - pause: { duration: 300 }

Multi-signal rollout gates

Use multiple signals before promotion. A single green deployment status is not enough.

• 5xx rate and latency percentile changes
• Message backlog growth and consumer lag
• Saturation in CPU, memory, IO, or connection pools
• Trace-level error concentration after the canary receives traffic

Failure mode: config drift during rollout

If Argo CD reconciliation cadence and rollout cadence conflict, operators can see oscillation between declared state and rollout controller state. Keep the ownership boundary clear: Argo CD should apply the desired rollout object, while the rollout controller owns traffic movement and promotion state.

Recommended runbook

• Freeze non-critical merges during high-risk release windows.
• Check Argo CD application sync, health, and drift before promotion.
• Expose rollout phase, canary health, error budget burn, and saturation in the on-call dashboard.
• Document manual pause, abort, and rollback commands beside the automated rollback thresholds.