Deploy sem medo: como um lançamento avariado numa sexta-feira se transformou em 10–15 deploys tranquilos por semana — testes automáticos, uma cópia de staging e um botão de reversão de 90 segundos.
O medo do deploy vem da incerteza, e a automação elimina a incerteza. Há dois anos, um lançamento numa sexta-feira ao fim do dia avariou o meu produto e comeu-me o fim de semana. Hoje faço deploy 10–15 vezes por semana sem medo nenhum — porque os testes, uma cópia de staging e uma reversão com um clique verificam agora tudo aquilo que antes eu só esperava que corresse bem.
Se estás a construir o teu primeiro produto, o momento que temes não é escrever código. É carregar no botão que põe o teu código à frente de utilizadores reais. Eis como esse botão se tornou aborrecido.
O deploy de sexta-feira que me estragou o fim de semana
Sexta-feira, 18h. Tinha acabado de fazer deploy de uma «pequena alteração» em produção — acrescentei um campo à base de dados, atualizei o código que o serve e pus tudo no ar.
Trinta minutos depois, o telemóvel explodiu com notificações de erro. A alteração à base de dados tinha passado, mas eu tinha-me esquecido de atualizar um endpoint que ainda esperava a estrutura antiga. Erros por todo o lado. A produção estava em baixo, numa sexta-feira à noite, com utilizadores reais a tentar usar o produto.
Passei o fim de semana inteiro a depurar. Reverti a alteração à base de dados, corrigi o código, voltei a fazer deploy no domingo à noite. Isso foi há dois anos — e foi a última vez que um deploy me estragou o fim de semana.
O medo vem da incerteza
O que mudou não foi a coragem. Foi eliminar todas as perguntas a que eu antes respondia com «provavelmente».
O deploy manual é uma pilha de esperanças: corri todos os testes? Verifiquei todos os casos extremos? Isto vai comportar-se em produção da mesma forma que no meu portátil? Não tens como saber — por isso fazes deploy raramente, em lotes grandes e arriscados, de preferência nunca à sexta-feira, e passas a noite com um olho no telemóvel.
A versão automatizada substitui cada esperança por um facto. Envio o código. Os testes correm automaticamente — se um falhar, o deploy é bloqueado antes de qualquer utilizador ser afetado. A alteração vai depois para um ambiente de staging, uma cópia idêntica da produção, onde a posso experimentar em segurança. Um clique promove-a para a produção real, e a monitorização confirma que o lançamento está saudável. Se alguma coisa parecer mal, mais um clique reverte para a versão anterior.
Os testes falham? Deploy bloqueado. O staging parte? Não promoves. Problema em produção? Reverte. Cada falha tem uma resposta aborrecida e decidida de antemão — e é exatamente por isso que já não há nada a temer.
A economia do deploy
Só a redução do stress justificaria a configuração. Os números do tempo tornam absurdo não o fazer:
| Manual, movido pelo medo | Automatizado | |
|---|---|---|
| Construir a funcionalidade | 8 horas | 30 minutos com um briefing estruturado |
| Testes | 2 horas, manuais, talvez | 5 minutos, automáticos |
| O deploy em si | 2 horas de stress, depois esperança | Verificação em staging + 1 clique, ~10 minutos |
| Quando parte | Fim de semana a depurar, 10 horas | Reversão, depois correção com calma |
| Total | ~22 horas, stress máximo | ~44 minutos, zero stress |
É cerca de 30 vezes mais rápido por funcionalidade. E acumula: o tempo de deploy feito à mão custava a quem constrói sozinho 2–4 horas por lançamento. Automatizado, não custa nada — o pipeline faz o trabalho quer lances duas vezes por mês, quer duas vezes por dia.
O teste das 2h47
Eis a configuração a provar o que vale. 2h47 da manhã, o telemóvel vibra: a taxa de erros está a disparar em produção. Meio a dormir, vou ver o painel — um endpoint está a falhar, há utilizadores afetados.
Duas opções: depurar às 2 da manhã, meio a dormir. Ou reverter para a versão anterior — dois cliques. Escolhi a reversão. Resolvido em 90 segundos. De volta à cama. De manhã depurei como deve ser, encontrei o bug, corrigi-o, voltei a fazer deploy. Tempo total de indisponibilidade: 90 segundos. Sono total perdido: três minutos.
Antes das reversões, essa noite teria sido duas horas de depuração com os olhos a fechar e o dia seguinte desperdiçado. É esta a verdadeira promessa da automação de deploys: não que nada volte a partir — cerca de um deploy em cada 50 ainda parte — mas que a avaria passe a ser um incómodo de 90 segundos em vez de uma crise.
Quanto custa a rede de segurança
Talvez esperes que isto exija um engenheiro de DevOps e um orçamento empresarial. Toda a minha stack de monitorização e deploy custa 9 € por mês.
O rastreio de erros vigia falhas e alerta-me quando a taxa de erros dispara — plano gratuito. As analytics dizem-me se o tráfego cai de repente, sinal de páginas avariadas — 9 € por mês. A minha plataforma de alojamento dá-me métricas de desempenho, pré-visualizações de cada alteração e a reversão com um clique — gratuito. A base de dados regista as consultas lentas e as que falham — gratuito. Um endpoint de verificação de saúde é contactado a cada cinco minutos, e falhas repetidas disparam um alerta.
Por menos do que uma subscrição da Netflix, durmo descansado. O senão — e há um — é que o pipeline só é tão bom quanto os testes que corre. Um pipeline automatizado sem testes só lança bugs mais depressa. É por isso que o teu SaaS precisa de testes primeiro, e é por saltá-los que acaba a armadilha do vibe coding: velocidade sem rede de segurança, até à sexta-feira em que tudo te cai em cima de uma vez.
O melhor deploy é aquele em que não pensas. Envias o código. Funciona. Segues em frente.
Perguntas frequentes
Com que frequência deve um fundador a solo fazer deploy?
Sempre que acabas alguma coisa — no meu caso são 10–15 vezes por semana. Deploys pequenos e frequentes são mais seguros do que grandes e raros: cada alteração é minúscula, por isso quando algo parte sabes exatamente o que o causou, e uma reversão custa segundos em vez de um fim de semana.
O que acontece se um deploy avariar a produção?
Com automação: a monitorização alerta-te em minutos, e reverter para a versão anterior que funcionava leva dois cliques e cerca de 90 segundos. Corriges o bug real com calma depois. Na minha experiência, cerca de um deploy em cada 50 tem um problema — e nenhum me custou um fim de semana desde então.
Preciso mesmo de um ambiente de staging?
Sim — é o passo que elimina o risco do «no meu portátil funciona». O staging é uma cópia idêntica da produção onde cada alteração chega automaticamente antes de os utilizadores reais a verem. As alterações à base de dados, sobretudo, são testadas lá primeiro, porque são o mais difícil de desfazer em produção.
Quanto custa a automação de deploys?
Quase nada à escala de uma pessoa. A minha stack de monitorização e deploy corre em planos gratuitos mais uma ferramenta de analytics de 9 €/mês. A configuração é um esforço feito uma vez, e paga-se no primeiro lançamento que, de outra forma, teria corrido mal numa sexta-feira ao fim do dia.