Deploy na sexta-feira: quando evitar e quando vale

TL;DR - O medo de deploy na sexta faz sentido sem observabilidade e rollback. Com os dois, o que define é o tamanho da mudança e evitar migration de banco.

Sexta à tarde, pipeline verde, deploy no ar. Em toda equipe que passei, alguém sempre soltava: “hoje não, segunda”. Eu entendo. Também já vi fim de semana virado em caça a bug. A diferença entre “deploy na sexta é roleta russa” e “deploy na sexta é risco calculado” está em duas coisas: observabilidade e rollback.

Sem isso, a regra “nunca na sexta” faz sentido. Você pode passar o fim de semana no escuro, sem saber onde quebrou nem como voltar. Com métricas e logs em que eu confio, e um rollback claro e testado, sexta vira só mais um dia para decidir com critério.

Quando eu faço deploy na sexta

• Observabilidade em dia: sei na hora se algo quebrou, onde e por quê.
• Rollback documentado e já usado em produção.
• Mudança pequena ou de impacto controlado.
• Nada de migration de banco nesse deploy.

Quando eu deixo para segunda

• Mudança grande ou primeira vez de uma feature em produção.
• Qualquer deploy que inclua migration de banco. Migration que dá errado no sábado é outro nível de dor.
• Dúvida sobre o tamanho do impacto: na dúvida, adio.

O diagrama abaixo resume a lógica que eu uso:

flowchart TB
  Deploy[Deploy na sexta?] --> Obs{Observabilidade e rollback ok?}
  Obs --> Nao[Não] --> Evitar[Evitar]
  Obs --> Sim[Sim] --> Migracao{Tem DB migration?}
  Migracao --> Sim2[Sim] --> Evitar
  Migracao --> Nao2[Não] --> Impacto{Tamanho / impacto controlado?}
  Impacto --> Sim3[Sim] --> Vale[Vale]
  Impacto --> Nao3[Não] --> Evitar