CI/CD do zero: o que aprendi montando meu primeiro pipeline de verdade
Por anos eu fazia deploy na mão. Quando finalmente montei um pipeline real, entendi que a parte técnica era a menor. O desafio era confiar na máquina.
Durante anos, o processo de deploy era assim: abria o terminal, conectava no servidor via SSH, rodava git pull, rezava, e torcia para nada quebrar.
Funcionava. Na maioria das vezes.
Quando funcionava, ninguém falava nada. Quando não funcionava, eu passava a próxima hora tentando entender o que tinha mudado entre o meu ambiente e o do servidor.
A ideia de CI/CD não era nova pra mim. Eu sabia o que era, na teoria. Continuous Integration: cada mudança vai para um pipeline que roda testes automaticamente. Continuous Deployment: se os testes passam, o código vai para produção sem intervenção manual.
Parecia simples. Parecia até óbvio. Mas quando tentei montar o primeiro pipeline de verdade, percebi que eu não entendia nada além do nome.
O primeiro obstáculo foi a falta de testes. Você não pode ter CI sem testes. "Continuous Integration" sem suíte de testes é só um servidor que faz git pull automaticamente. Eu não tinha testes no projeto. Então comecei por ali: não pelo pipeline, mas pelos testes.
Três semanas depois, com uma cobertura mínima e alguns smoke tests no lugar, voltei para o pipeline.
Escolhi GitHub Actions porque era onde o código já estava. O primeiro workflow que escrevi tinha 80 linhas e não funcionava. O segundo tinha 60 linhas e não funcionava também. O terceiro, com 40 linhas, funcionou — porque eu tinha deletado a metade que eu não entendia o que fazia.
A lição: pipeline de CI não precisa de sofisticação no dia um. Precisa de clareza. O que esse pipeline faz? Roda os testes. Faz o build. Publica. Só isso.
Cada coisa extra que você adiciona sem entender é um ponto de falha que vai te custar tempo às 23h quando o deploy de sexta travar.
A parte que ninguém conta é o quanto CI/CD muda a dinâmica de equipe.
Antes do pipeline, havia um ritual implícito: "quem faz o deploy?" Alguém sempre sabia mais sobre o processo. Alguém guardava na cabeça a sequência de passos. Esse alguém virava gargalo — não por mal, mas porque o conhecimento estava na cabeça de uma pessoa, não documentado, não automatizado.
Com o pipeline no lugar, o deploy virou processo. Qualquer um que faz o merge está fazendo o deploy. Isso parece óbvio mas muda como as pessoas trabalham: o código que você sobe precisa passar nos testes do time, não só funcionar no seu ambiente.
Demorei uns dois meses até confiar completamente no pipeline. No começo, depois de cada merge, eu abria o servidor manualmente e olhava se tudo estava de pé.
Não porque o pipeline falhou. Mas porque eu não confiava que um processo automático pudesse fazer o que eu fazia manualmente.
Isso é um bias importante: a maioria das pessoas não tem medo de CI/CD técnico. Tem medo de perder o controle. Deploy manual dá a sensação de que você está no comando. Pipeline automatizado tira essa sensação. O que leva tempo não é aprender a técnica. É aprender a confiar.
Hoje, quando trabalho num projeto que ainda faz deploy manual, a primeira coisa que quero fazer é montar o pipeline. Não porque é impressionante. Mas porque a ausência de CI/CD é a presença de atrito constante — e esse atrito se acumula em meses de trabalho.
Essa semana: olha para o processo de deploy do projeto em que você está. Quantos passos são manuais? Quantos poderiam ser automatizados? Não precisa resolver tudo de uma vez — escolhe um passo e automatiza ele.