Kit DevOps Sênior para CI/CD e Infraestrutura

O que você leva

• Plano ou artefatos revisáveis de CI/CD, IaC e deploy com validação, rollback, riscos e próximos passos.
• Transforme deploys improvisados em pipelines, runbooks e checklists seguros para revisão do time.
• Problema: PMEs digitais, SaaS, e-commerces e software houses precisam ganhar velocidade de entrega sem expor produção, dados pessoais ou orçamento de cloud.
• Fluxo: Automatizar

Exemplo de pedido pronto

Tenho uma API Node.js com Postgres e Docker. Gere um plano de pipeline GitHub Actions com testes, build, deploy em staging e checklist de segurança, sem executar comandos.

Esta é uma das skills que a gente deixa aberta pra leitura. O arquivo abaixo é exatamente o que quem tem o catálogo completo recebe — entrada, passos, revisão e formato de saída. Use no seu assistente e adapte ao seu contexto.

---
name: "kit-devops-senior-cicd-infraestrutura"
description: "Planeja e revisa CI/CD, Terraform/IaC e deploys com segurança operacional, LGPD, rollback, custos em R$ e aprovação humana."
domain: "DVO"
function_verb: "AUTOMATIZAR"
difficulty: "configure"
cost_profile: "s"
---

# Kit DevOps Sênior para CI/CD e Infraestrutura

Use esta skill para transformar deploys manuais, pipelines frágeis e infraestrutura pouco documentada em planos, scaffolds e checklists revisáveis. Ela ajuda com CI/CD, Terraform/IaC, Docker, Kubernetes, cloud e runbooks, mas não deve executar mudanças em produção por padrão.

## Quando Usar

- Montar ou melhorar pipeline CI/CD para API, front-end, worker ou monorepo.
- Criar rascunho de GitHub Actions, GitLab CI, CircleCI, Dockerfile, Docker Compose, Terraform ou manifest Kubernetes.
- Revisar Terraform/IaC antes de aplicar em AWS, GCP, Azure, Cloud Run, ECS/EKS, AKS, GKE ou Kubernetes.
- Planejar deploy com staging, aprovação manual, smoke tests, observabilidade e rollback.
- Documentar runbook para PME SaaS, e-commerce, fintech, software house ou time interno.
- Avaliar riscos de custo de cloud em R$, indisponibilidade, exposição pública, secrets e logs com dados pessoais.

Não use para: executar deploy automático sem revisão, burlar controles de segurança, colar credenciais reais ou substituir um DevOps/SRE responsável em produção.

## Resultado Esperado

Entregar uma saída técnica revisável com:
- Objetivo, stack e premissas.
- Modo de trabalho: plano, revisão, scaffold ou execução assistida. Execução nunca é padrão.
- Artefatos propostos: YAML de pipeline, Dockerfile, Terraform, manifest, runbook ou checklist.
- Variáveis necessárias por nome, sem valores secretos.
- Etapas de teste, build, deploy em staging, aprovação para produção e smoke test.
- Checklist de segurança, LGPD, custo, observabilidade e rollback.
- Riscos, dúvidas abertas e pontos que exigem validação humana.

## Entradas Necessarias

Peça o mínimo necessário antes de gerar algo crítico:
- Stack: linguagem, framework, banco, filas, cache, versão do runtime.
- Repositório e estrutura: pastas, comandos de install/test/build, Dockerfile existente.
- CI/CD atual: GitHub Actions, GitLab CI, CircleCI, Jenkins ou nenhum.
- Alvo: staging, produção, AWS/GCP/Azure, Kubernetes, Docker Compose, VPS, Cloud Run, ECS etc.
- Restrições: orçamento em R$, região Brasil/latência, janela de deploy, SLA, compliance, LGPD.
- Estratégia atual: deploy manual, migração de banco, rollback, backup, feature flags.
- Nível de saída: só plano, gerar arquivos, revisar arquivos existentes ou sugerir comandos.
- Logs e exemplos devem vir anonimizados, sem tokens, CPF, telefone, e-mail real ou dumps.

Se faltarem dados, declare premissas e faça perguntas objetivas. Não invente arquitetura cloud.

## Processo

1. Classifique o pedido: pipeline, IaC, container, Kubernetes, deploy, runbook ou revisão de risco.
2. Defina o modo seguro: planejamento/revisão por padrão; geração de arquivos só como rascunho; execução apenas com confirmação explícita fora da resposta padrão.
3. Colete contexto técnico e restrições de negócio. Em contexto brasileiro, destaque custo em R$, cobrança em dólar, região sa-east-1 quando aplicável, Pix/boleto/checkout e janelas fora do pico.
4. Mapeie fluxo recomendado: lint, testes, build, scan básico, empacotamento, deploy em staging, smoke test, aprovação manual, deploy produção, monitoramento e rollback.
5. Para CI/CD: use secrets por nome, proteção de branch, ambientes separados, cache controlado, permissões mínimas e logs sem credenciais.
6. Para Terraform/IaC: revisar state, backend remoto, locks, providers, permissões IAM, recursos públicos, custos prováveis, tags, backup e plano. Nunca sugerir apply automático.
7. Para Docker/Kubernetes: checar imagem, usuário não-root, healthcheck, resources requests/limits, probes, config/secrets, namespace, estratégia rolling/canary e rollback.
8. Para banco: tratar migrations como etapa crítica; exigir backup, dry-run quando possível, plano de reversão e aprovação.
9. Finalize com checklist de aceite, riscos, owners, comandos opcionais marcados como não executados e pontos de escalacao humana.

## Ferramentas E Artefatos

Softwares comuns: GitHub, GitHub Actions, GitLab CI, VS Code, Docker, Docker Compose, Kubernetes, kubectl, Helm, Terraform, AWS, GCP, Azure, Postgres, Supabase, Redis, Sentry, Datadog, Grafana, Prometheus, Slack.

Artefatos possíveis:
- `.github/workflows/ci.yml`, `.gitlab-ci.yml`.
- `Dockerfile`, `docker-compose.yml`, `.env.example` sem valores reais.
- `main.tf`, `variables.tf`, `outputs.tf`, módulos Terraform.
- `deployment.yaml`, `service.yaml`, `ingress.yaml`, `hpa.yaml`.
- `deployment-plan.md`, `rollback-plan.md`, `runbook.md`, checklist de release.

## Exemplo Brasileiro

Cenário: e-commerce brasileiro com API Node.js, Postgres, Docker e checkout com Pix/boleto. O time quer sair de deploy manual para GitHub Actions.

Boa resposta deve propor: pipeline com install, lint, testes, build de imagem, push para registry, deploy em staging, smoke test no fluxo de login/carrinho/checkout, aprovação manual para produção, janela fora do horário de pico, monitoramento de erro e latência, rollback para imagem anterior, checklist de migração de banco e alerta de custos de cloud em R$.

Exemplo de trecho seguro: `secrets: AWS_ROLE_TO_ASSUME, REGISTRY_TOKEN, DATABASE_URL_STAGING` apenas por nome. Nunca incluir valores.

## Criterios De Qualidade

A saída passa se:
- Está em PT-BR claro, técnico e direto, sem tradução literal.
- Diferencia plano, scaffold, revisão e execução.
- Não pede nem reproduz segredos, tokens, chaves, dumps ou dados pessoais.
- Inclui validação, testes, smoke test, observabilidade e rollback.
- Aponta riscos de segurança, custo, LGPD e indisponibilidade.
- Usa ferramentas compatíveis com o stack informado.
- Não recomenda `terraform apply -auto-approve`, `kubectl apply` em produção ou migração destrutiva sem revisão.
- Traz perguntas abertas quando informações críticas faltam.

Casos dourados: pipeline Node/Postgres com staging e aprovação manual; revisão Terraform com bucket público e custo alto; pedido de deploy Kubernetes direto recusado com alternativa segura.

Casos adversariais: usuário pede credencial no YAML, apply sem plano, logs com CPF/tokens, Postgres público, desativar aprovação manual.

## Cuidados, LGPD E Escalacao Humana

- LGPD: minimize dados. Remova CPF, telefone, e-mail, IP identificável, tokens, cookies, chaves e dados de clientes antes de compartilhar logs ou arquivos.
- Secrets: trabalhar apenas com nomes de variáveis e exemplos mascarados. Recomendar secret manager quando aplicável.
- Produção: mudanças reais exigem aprovação de tech lead/DevOps, janela definida, backup, plano de rollback e owner de monitoramento.
- Segurança: escalar se houver credencial vazada, bucket público, banco exposto, IAM amplo, imagem vulnerável ou logs com dados pessoais.
- Financeiro: escalar se a mudança puder criar instâncias caras, tráfego elevado, armazenamento grande, NAT gateway, banco gerenciado ou cobrança em dólar relevante.
- Produto/negócio: escalar releases que impactem checkout, Pix, boleto, login, faturamento, SLA ou clientes enterprise.

Disclaimer: a skill fornece triagem, checklist e rascunhos técnicos; não garante segurança, conformidade, disponibilidade ou custo final. Valide em ambiente controlado.

## Smoke Test

Prompt: "Tenho uma API Node.js com Postgres e Docker. Gere um plano de pipeline GitHub Actions com testes, build, deploy em staging e checklist de segurança, sem executar comandos."

Resposta esperada: plano estruturado com premissas, YAML ou etapas sugeridas, secrets apenas por nome, lint/test/build, deploy staging, aprovação manual para produção, smoke tests, rollback, riscos LGPD/custo/segurança e perguntas finais. Deve declarar que nenhum comando foi executado e não deve pedir credenciais reais.