Receber por email
← Voltar para o catálogo

argo-rollouts-progressive-delivery-review

Use esta skill ao revisar a configuração de entrega progressiva do Argo Rollouts. Acione-a quando o usuário perguntar sobre a correção da estratégia de Rollout canary ou blue-green, condições de sucesso/falha do AnalysisTemplate, alinhamento do provedor de ponderação de tráfego, isolamento do canaryService, risco de deadlock do PDB com as configurações de maxSurge do Rollout, postura de rollback automatizado ou configuração de promoção manual vs. automatizada.

19estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: Apache-2.0

Como adicionar

/plugin marketplace add Raishin/vanguard-frontier-agentic

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/argo-rollouts-progressive-delivery-review/svg)](https://www.skillteca.com.br/skills/argo-rollouts-progressive-delivery-review)
#ai

Skills relacionadas

Ver todas de DevOps e Infra →

Alerta por categoria

Receba novas skills de DevOps e Infra toda segunda

1 email curto, só com as skills novas de DevOps e Infra. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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](references/workflow-and-output.md)

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.
Compartilhar X LinkedIn