rm-prod-mais-uma-vez #279
Description
rm-prod-mais-uma-vez
Slack vibes de café frio:
Quem nunca rodou um script achando que tava num SQLite perdido no /tmp e na real tava com a connection string apontando pro dev deployado na nuvem, que atire o primeiro DROP TABLE users;.
A cena do crime:
Você queria só brincar de CRUD no quintal de casa, mas esqueceu de trocar a URL no .env. Resultado: o quintal virou Hiroshima. O BD de dev foi limpo mais rápido do que docker system prune -a. Zero problema “pra você”, claro, mas metade da galera que usava o ambiente acordou sem seus registros.
E sim, a justificativa “era só dev” é tipo aquele bug que só dá em staging: até dá pra rir… até o dia que não dá mais.
A filosofia do desastre:
Colocar lógica de “limpar banco” na aplicação é o equivalente dev de dirigir carro sem freio porque “fica mais leve”. Funciona até a primeira curva.
O que você fez foi abrir a porta pro caos entrar e o caos entrou com sapato sujo. É a famosa engenharia do atalho: poupa um migration, mas custa uma restauração.
A real é que a gente sempre acredita que o sanity check vai estar na nossa memória RAM. Spoiler: não está. Nosso cérebro é igual Docker container: volátil, morre, e o estado some.
Soluções que salvam vidas (e empregos):
Ephemeral containers: subiu, testou, morreu, e o banco vai junto. Nenhum script de auto-destruição no app.
Migrações manuais e controladas: ORM só pra brincar. Em produção, quem mexe na schema é DBA ou script supervisionado.
Backups automáticos: não backupou? Então não existiu.
Dois pares de olhos: avião tem dois motores, PR tem dois revisores, deploy em prod precisa de mais de uma mão culpada.
Pull request de vida:
Toda vez que você pensar “vou só limpar o banco rapidinho” lembre-se: trabalho perdido é barato, dado perdido é dívida técnica com juros compostos.
Ou, como diria o Feynman versão dev: “o cara que você mais deve desconfiar é você mesmo com permissão de DROP.”