Meu primeiro sistema em produção: o que funcionou e o que não funcionou
Em 2019 subi meu primeiro sistema real para produção. Sem pipeline. Sem rollback. Sem monitoramento. Aqui está o que aprendi antes de aprender do jeito certo.
Meu primeiro deploy em produção foi um copiar e colar.
Sério. Copiava os arquivos do meu computador para o servidor via FTP. Atualizava direto no servidor. Sem branch. Sem teste. Sem backup.
Funcionou por 3 semanas.
Na quarta semana, sobrescrevi um arquivo que não devia. O sistema ficou fora do ar por 40 minutos enquanto eu tentava lembrar o que tinha no arquivo original.
Naquela época, eu não sabia que existia outra forma.
Não tinha lido sobre deploy pipelines. Não sabia o que era CI/CD. Para mim, "colocar em produção" era literalmente colocar os arquivos no servidor.
O que me fez aprender não foi curso. Foi incidente. Cada vez que algo quebrava em produção — e quebrou várias vezes — eu pagava uma lição nova: backup antes de mexer, testa em ambiente separado, documenta o que mudou. Cada lição custou downtime real, usuário impactado, pedido de desculpas ao cliente.
O sistema em si era simples: API para um CRM. Recebia dados de formulários de leads, salvava no banco, disparava email de notificação. Tinha usuário real, empresa real, expectativa real de que o negócio não parasse.
Quando subi isso pela primeira vez, a sensação foi estranha. Tutorial você quebra e refaz. Produção, quando quebra, alguém lá fora sente.
Funcionou. A lógica estava certa, o banco estava limpo (cinco tabelas, sem sofisticação desnecessária), as mensagens de erro estavam em português — o cliente até elogiou isso.
O que não funcionou: sem logging, sem monitoramento, sem staging, sem rollback. Descobria que o sistema estava fora do ar quando o cliente me ligava. Quando precisei voltar uma versão, foi na mão. Dolorosamente na mão.
Produção não é um lugar. É um estado de responsabilidade.
Quando você sobe um sistema para produção, assume responsabilidade pelo que acontece. Se o sistema cai às 2h, é problema seu. Se um bug apaga dados do cliente, é problema seu. Isso não é para assustar — é para calibrar o cuidado.
Os sistemas que permanecem estáveis não são necessariamente os mais sofisticados. São os mais simples de entender quando algo dá errado.
Antes do primeiro deploy de qualquer sistema, vale responder três perguntas: como você vai saber se está funcionando? O que você vai fazer se precisar voltar? Como você vai saber o que aconteceu quando der errado?
Se a resposta for "o cliente me avisa", "vou tentar me lembrar", "vou olhar o código" — você não tem o mínimo. Um log simples em arquivo, um health check endpoint, um backup manual antes do deploy. Isso já é infinitamente melhor do que nada.
Essa semana: se você tem um sistema em produção, tenta responder essas três perguntas. Se não consegue, escolhe a mais urgente e resolve ela primeiro.