Item01
PR com descrição: problema, o que mudou, como testar, riscos e plano de rollback.
Checklist
O checklist de deploy que evita quebrar produção na sexta.
24 itens em 5 blocos: antes do merge, no pipeline, no release, depois do deploy e rollback. Deploy seguro: CI verde + freio (flag/canary) + smoke + rollback escrito + alguém acordado.
Deploy seguroCI verdeflag ou canarysmokerollback escritoalguém acordado
Deploy seguro protege o usuário e a sua reputação. Na mentoria, eu monto o plano de estudo para a vaga que você quer.
Item02
CI verde: lint, testes unitários e pelo menos 1 teste de integração do fluxo crítico.
Item03
Review de alguém que conhece a área (não só “LGTM” do colega do lado).
Item04
Sem segredo hardcoded; variáveis de ambiente e secrets no cofre certo.
Item05
Diff revisado por você: sem debug, console.log, TODO esquecido ou arquivo gerado.
Item06
Build reproduzível (lockfile, imagem versionada, sem “latest” em produção).
Item07
Testes automatizados no pipeline, não só na máquina local.
Item08
Scan básico de dependência / imagem (ou acordo explícito de quando rodar).
Item09
Artefato versionado: tag semântica ou commit SHA rastreável.
Item10
Ambiente de staging (ou preview) sobe a mesma artefato que vai para produção.
Item11
Feature flag ou canary para mudança de risco (pagamento, auth, migração).
Item12
Migração de banco no padrão expand/contract: nunca DROP no mesmo release do código novo.
Item13
Compatibilidade com a versão anterior (deploy blue/green ou rolling sem downtime).
Item14
Janela de deploy acordada: horário com time acordado e on-call definido.
Item15
Comunicação no canal do time: o que sobe, quem está de plantão, link do dashboard.
Item16
Health check e smoke no endpoint crítico (login, checkout, ingestão — o que for o negócio).
Item17
Olho no dashboard 15–30 min: erro 5xx, latência p95, fila, saturação.
Item18
Alerta acionável ligado (não só dashboard bonito).
Item19
Log de release anotado (commit, autor, horário) para o próximo incidente.
Item20
Confirmar com quem pediu a mudança que o comportamento esperado apareceu.
Item21
Plano de rollback escrito: voltar versão, desligar flag ou forward-fix com owner.
Item22
Testou o rollback em staging pelo menos uma vez neste trimestre.
Item23
Evite deploy de risco na sexta à tarde sem cobertura de on-call.
Item24
Se subiu e algo oscila: pare o rollout, não “espera mais um pouco” sem critério.
Checklist rápido antes de subir
□ CI verde + review feito
□ Flag/canary definido (ou justificativa de 100%)
□ Migração expansível (sem DROP no mesmo release)
□ Smoke do caminho crítico depois do deploy
□ Rollback escrito e alguém de plantão
□ Dashboard aberto nos primeiros 30 minutos
Júnior sobe e torce. Sênior sobe com freio e rollback.
O júnior sobe e torce. O sênior sobe com freio, métrica e rollback.
No próximo release, escreva o plano de rollback antes de clicar em deploy.
Para ir além: The Twelve-Factor App (metodologia de apps em produção) ↗ · Release Engineering — livro SRE do Google (em inglês) ↗ · Canarying Releases — SRE Workbook do Google (em inglês) ↗ · Blue-Green Deployment — Martin Fowler (em inglês) ↗ · Feature Toggles — Martin Fowler (em inglês) ↗
Conteúdo sobre carreira dev, todo dia: @lucasadvice ↗
Mentoria
Suba com segurança e vire a referência do time
Quem sobe com checklist vira a pessoa em quem o time confia — e é essa confiança que abre promoção e as melhores oportunidades. A mentoria acelera esse caminho: plano de estudo para a vaga que você quer, LinkedIn que mostra o seu trabalho e as empresas certas para conversar.