Argo Rollouts Progressive Delivery Review
Purpose
Review Argo Rollouts canary and blue-green strategy configuration, AnalysisTemplate success and failure condition correctness, traffic management provider alignment, canaryService vs stableService isolation, PDB compatibility with Rollout surge settings, and automated rollback posture. Argo Rollouts' safety depends entirely on AnalysisTemplate conditions that actually fail — an always-true successCondition means automated rollback never fires, regardless of actual error rates.
Lean operating rules
- Prefer live evidence (
kubectl get rollout -A -o yaml, kubectl get analysistemplate -A -o yaml, kubectl argo rollouts status <name>) when the active client exposes it; otherwise fall back to official Argo Rollouts documentation and sanitized YAML from the user.
- Separate confirmed facts from inference. If AnalysisTemplate metric query results, traffic provider actual behavior, or PDB state was not directly queried, say so.
- Treat an AnalysisTemplate with a successCondition that always evaluates to true (e.g.,
result >= 0, true) as a critical finding — automated rollback can never fire.
- Treat a Rollout with no separate
canaryService from stableService as a high finding — canary traffic isolation is broken.
- Treat a production Rollout using
pause: {} (manual promotion) with no AnalysisTemplate as a high finding — there is no automated quality gate.
- Treat a traffic provider in
spec.strategy.canary.trafficRouting that does not match the actual ingress controller installed in the cluster as a high finding — weight changes are silently ignored.
- Treat
failureLimit: 100 or higher on an error-rate metric as a medium finding — the analysis tolerates far too many errors before marking Degraded.
- Keep the answer scoped, evidence-labeled, and explicit about what was not queried.
References
Load these only when needed:
- Workflow and output contract
Response minimum
Return, at minimum:
- the scoped target (Rollout name, AnalysisTemplate name, or traffic provider config) and evidence level,
- the deployment strategy (canary with steps vs canary without steps, blue-green) and whether steps include AnalysisRun gates,
- AnalysisTemplate successCondition and failureCondition correctness,
- canaryService vs stableService isolation posture,
- traffic provider alignment with the actual cluster ingress,
- PDB compatibility with Rollout maxSurge/maxUnavailable,
- the safest next actions and any assumptions or blockers.
1---2name: argo-rollouts-progressive-delivery-review3description: Use this skill when reviewing Argo Rollouts progressive delivery configuration. Trigger when the user asks about canary or blue-green Rollout strategy correctness, AnalysisTemplate success/failure conditions, traffic weighting provider alignment, canaryService isolation, PDB deadlock risk with Rollout maxSurge settings, automated rollback posture, or manual vs automated promotion configuration.4---56# Argo Rollouts Progressive Delivery Review78## Purpose910Review Argo Rollouts canary and blue-green strategy configuration, AnalysisTemplate success and failure condition correctness, traffic management provider alignment, canaryService vs stableService isolation, PDB compatibility with Rollout surge settings, and automated rollback posture. Argo Rollouts' safety depends entirely on AnalysisTemplate conditions that actually fail — an always-true successCondition means automated rollback never fires, regardless of actual error rates.1112## Lean operating rules1314- Prefer live evidence (`kubectl get rollout -A -o yaml`, `kubectl get analysistemplate -A -o yaml`, `kubectl argo rollouts status <name>`) when the active client exposes it; otherwise fall back to official Argo Rollouts documentation and sanitized YAML from the user.15- Separate confirmed facts from inference. If AnalysisTemplate metric query results, traffic provider actual behavior, or PDB state was not directly queried, say so.16- Treat an AnalysisTemplate with a successCondition that always evaluates to true (e.g., `result >= 0`, `true`) as a critical finding — automated rollback can never fire.17- Treat a Rollout with no separate `canaryService` from `stableService` as a high finding — canary traffic isolation is broken.18- Treat a production Rollout using `pause: {}` (manual promotion) with no AnalysisTemplate as a high finding — there is no automated quality gate.19- Treat a traffic provider in `spec.strategy.canary.trafficRouting` that does not match the actual ingress controller installed in the cluster as a high finding — weight changes are silently ignored.20- Treat `failureLimit: 100` or higher on an error-rate metric as a medium finding — the analysis tolerates far too many errors before marking Degraded.21- Keep the answer scoped, evidence-labeled, and explicit about what was not queried.2223## References2425Load these only when needed:26- [Workflow and output contract](references/workflow-and-output.md)2728## Response minimum2930Return, at minimum:31- the scoped target (Rollout name, AnalysisTemplate name, or traffic provider config) and evidence level,32- the deployment strategy (canary with steps vs canary without steps, blue-green) and whether steps include AnalysisRun gates,33- AnalysisTemplate successCondition and failureCondition correctness,34- canaryService vs stableService isolation posture,35- traffic provider alignment with the actual cluster ingress,36- PDB compatibility with Rollout maxSurge/maxUnavailable,37- the safest next actions and any assumptions or blockers.
VincentChuWaiChow