Vibecoding
Como subir pra produção numa sexta sem medo
A regra de não subir na sexta existe porque o processo é ruim, não porque sexta é perigosa. Com quatro coisas no lugar, o dia da semana para de importar.
Tem uma regra folclórica em tecnologia: não sobe na sexta.
Ela existe por um motivo real. Só que o motivo não é a sexta.
O que a regra está dizendo de verdade
Quando alguém tem medo de subir na sexta, está dizendo três coisas sem perceber:
- não sei se vai quebrar
- se quebrar, não vou saber
- se eu souber, não vou conseguir voltar rápido
Repara que nenhuma das três tem a ver com dia da semana. A sexta só transforma um problema de duas horas num problema de fim de semana inteiro.
Consertar o dia não resolve nada. Consertar as três resolve.
1. Saber voltar em minutos
É a mais importante. Se você consegue restaurar a versão anterior em minutos, o risco de qualquer deploy cai brutalmente.
Não é conserto às pressas com o cliente ligando. É voltar ao estado que funcionava e consertar com calma depois.
Na maioria das hospedagens modernas isso é um botão. O problema é que quase ninguém testou esse botão. Testa uma vez, num dia calmo. Descobrir que o retorno não funciona no meio de um incidente é a pior forma possível de descobrir.
2. Ser avisado antes do cliente
A segunda pergunta é: se quebrar, quem te conta?
Se a resposta é "o cliente", você não tem processo, tem sorte. E sorte costuma acabar no pior momento.
Captura de erro e alerta chegando onde você realmente olha. Isso é uma tarde de trabalho e muda a natureza do risco: você deixa de descobrir problema por reclamação. Escrevi o passo a passo em como monitorar seu app.
3. Subir pedaço pequeno
Aqui está o contraintuitivo: subir mais vezes é mais seguro que subir menos vezes.
Parece o contrário. Mais deploy, mais chance de quebrar.
Só que quando quebra depois de uma mudança pequena, a causa é evidente. Foi a única coisa que mudou. Quando quebra depois de uma semana acumulada, você procura entre vinte alterações, sob pressão.
Deploy grande é raro e assustador. Deploy pequeno é rotina, e rotina é o que tira o medo.
4. Checar o que dói antes
Não precisa de suíte de testes automatizada pra melhorar muito. Cinco minutos na mão resolvem a maior parte:
- o caminho principal ainda funciona
- campo vazio não derruba
- entrar com outra conta não mostra dado errado
- a parte que você mexeu funciona nos dois extremos
É a camada 4 do Protocolo de 5 Camadas, na versão mínima. Muito melhor que a versão zero, que é o padrão da maioria.
O teste da sexta
Com as quatro no lugar, faz a pergunta de novo: dá pra subir na sexta às 17h?
Se você consegue voltar em minutos, é avisado quando quebra, subiu uma mudança pequena e checou o básico, o pior cenário é: quebra, você recebe alerta, volta a versão, vai pro fim de semana e conserta segunda.
Isso não é heroísmo. É processo.
E se a resposta ainda é não, ótimo: você acabou de descobrir qual das quatro está faltando. Isso vale mais que a decisão sobre o dia.
O que isso revela
Medo de subir é diagnóstico, não personalidade. É o sistema avisando que falta rede de proteção.
Quem trabalha com medo constante de deploy trabalha pior em tudo: adia, acumula, sobe pacote grande, e o pacote grande aumenta o medo. O ciclo se alimenta.
Sexta não é perigosa. Processo ruim é perigoso, de segunda a domingo.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Então posso subir em qualquer dia?
Pode, desde que você consiga voltar rápido e seja avisado quando algo quebra. Sem essas duas coisas, o problema não é a sexta: é que qualquer dia é arriscado, e a sexta só torna o prejuízo mais longo.
+O que é voltar rápido, na prática?
Conseguir restaurar a versão anterior em minutos, sem depender de memória nem de conserto às pressas. Na maioria das hospedagens modernas isso é um botão, e vale testar uma vez em ambiente de teste antes de precisar de verdade.
+Como ser avisado quando algo quebra?
Com captura de erro e alerta configurados, mandando aviso para onde você realmente olha. Sem isso, quem te avisa é o cliente, e aí o problema já custou reputação além do conserto.
+Subir pedaço pequeno não dá mais trabalho?
Dá mais deploys e muito menos investigação. Quando algo quebra depois de uma mudança pequena, a causa é óbvia. Quando quebra depois de uma semana acumulada, você procura em vinte alterações.
Continue lendo
O agente de código entrou no canal do time. Ver não é revisar
O Slack lançou canais onde agentes de IA programam na frente de todo mundo, com Claude, Copilot, Devin, ChatGPT e Vercel. É a melhor notícia de governança do ano e a maior armadilha de teatro de revisão.
VibecodingComo estruturar um projeto antes de pedir a primeira linha pra IA
Trinta minutos decidindo cinco coisas antes de abrir o chat economizam semanas de retrabalho. É a parte que todo mundo pula porque parece que não está produzindo.
VibecodingComo não virar refém de uma ferramenta de IA
A ferramenta que você ama hoje pode dobrar de preço, mudar de dono ou fechar amanhã. Não construa em cima de uma só.