Como organizar CI/CD e ambientes STG/PROD sem quebrar produção

Por que esse tema causa tantos incidentes?

Um dos problemas mais comuns em times de tecnologia não está no código — está na forma como o CI/CD e os ambientes são organizados.

Quando STG e PROD não têm uma separação clara, acontecem coisas como:

• variáveis erradas indo para produção
• deploy “na mão” com pressa
• falta de rollback
• “funciona em STG” mas quebra em PROD

Resultado: medo de deployar e incidentes recorrentes.

O erro mais comum

O erro não é falta de ferramenta.
É falta de processo.

Os sinais mais clássicos:

• pipeline única para STG e PROD sem controle de risco
• secrets compartilhados
• deploy em PROD por merge direto
• validações fracas (ou inexistentes)
• ausência de etapa manual para produção

👉 CI/CD precisa refletir o risco do ambiente.

Como eu organizo na prática (modelo simples que funciona)

1) Defina papéis claros para os ambientes

• STG (ou HML): validação e confiança
• PROD: estabilidade e segurança

STG serve para falhar sem prejuízo.
PROD serve para entregar com previsibilidade.

2) Use um fluxo de branches que reflita o risco

Um modelo comum e eficiente:

✅ STG (automático)

• merge na branch de STG
• build e testes automáticos
• deploy automático

✅ PROD (controlado)

• build de produção por tag
• deploy manual (aprovado)
• rollback possível

Produção não é lugar de automação cega.

3) Separe variáveis e secrets por ambiente

Cada ambiente precisa ter:

• variáveis próprias
• secrets próprios
• permissões próprias (IAM/ACL)

Isso evita o clássico:

“subiu com config errada e ninguém percebeu”.

4) Infra como código para manter consistência

Terraform resolve 2 pontos críticos:

• reprodutibilidade (infra nasce igual sempre)
• rastreabilidade (mudanças auditáveis)

⚠️ Importante:

• STG e PROD podem reutilizar módulos
• mas nunca reutilize o state
• e nunca compartilhe credenciais

Checklist rápido (pra você validar agora)

• Deploy STG automático via merge
• Deploy PROD via tag
• Deploy PROD manual (gate/aprovação)
• Variáveis separadas por ambiente
• Secrets separados por ambiente
• Rollback definido
• Observabilidade pós-deploy (métricas/logs/alertas)

Conclusão

CI/CD bom não é “mais ferramenta”.
É menos risco, mais previsibilidade e ambientes bem definidos.

Se você sente que:

• seu deploy é inseguro
• seu STG não confia
• produção dá medo

👉 Me chama no WhatsApp e me diga: stack + maior dor + objetivo.