Deploy manual — aquele fluxo de fazer build local, subir arquivo por FTP ou SSH, cruzar os dedos — ainda é mais comum do que deveria em time pequeno. Funciona até o dia em que alguém esquece um passo às 18h de sexta e o site fica fora do ar no fim de semana. Pipeline de CI/CD existe justamente pra tirar essa incerteza da equação. Vou explicar aqui como montar um pipeline funcional, sem exagerar em ferramenta que sua equipe ainda não precisa.
CI e CD são coisas diferentes (e isso confunde gente)
Integração Contínua (CI) é a parte que roda automaticamente a cada push de código: build, testes automatizados, checagem de qualidade de código. Entrega Contínua (CD) é o que acontece depois — empacotar e disponibilizar essa versão testada pra ser implantada, seja automaticamente (deployment contínuo) ou com um clique manual de aprovação (entrega contínua, no sentido mais restrito do termo). Muita gente trata os dois como sinônimo e isso gera confusão na hora de explicar o processo pro time.
Montando um pipeline básico com GitHub Actions
Pra quem já usa GitHub, GitHub Actions é o caminho de menor atrito porque já vem integrado, sem precisar de servidor de CI separado. Um workflow básico fica assim, num arquivo .github/workflows/deploy.yml:
on: push (branch main) → jobs: build (instala dependências, roda testes) → deploy (só executa se o job build passar)
O detalhe que costuma passar despercebido: configure o deploy pra rodar só depois que os testes passarem, nunca em paralelo. Já vi pipeline mal configurado que fazia deploy e teste ao mesmo tempo — bastava um teste falhar um segundo depois do deploy já ter ido pro ar pra colocar código quebrado em produção mesmo com “CI configurado”.
Ambientes de staging: não pule essa etapa
O erro mais caro que vejo em equipe pequena é fazer deploy direto de main pra produção sem passar por um ambiente de staging (ou homologação) intermediário. Staging deveria espelhar produção o mais próximo possível — mesma versão de banco de dados, mesmas variáveis de ambiente relevantes — pra pegar problema de configuração antes que o cliente veja. Pular staging economiza tempo até o dia em que uma migração de banco quebra em produção porque o ambiente de teste local tinha dado diferente.
Containers tornam o deploy mais previsível
Empacotar a aplicação em container (com Docker, por exemplo) resolve boa parte do clássico “funciona na minha máquina” — o ambiente de execução vai junto com o código, com as mesmas versões de dependência testadas. Isso combina bem com pipeline de CI/CD porque a imagem gerada e testada no CI é exatamente a mesma que sobe em produção, sem nenhuma variável de ambiente escondida diferente entre os dois lugares.
Rollback: o plano B que todo pipeline precisa ter
Pipeline de CI/CD bem montado facilita o deploy, mas também precisa facilitar desfazer um deploy problemático rapidamente. Manter versionamento de imagem de container por tag (não usar sempre “latest”) permite voltar pra versão anterior com um comando, em vez de tentar reverter código manualmente sob pressão enquanto o sistema está fora do ar. Isso é o tipo de detalhe que só quem já passou por um deploy ruim em produção valoriza de verdade.
Secrets e variáveis sensíveis
Nunca coloque senha de banco, chave de API ou token de acesso direto no arquivo de configuração do pipeline. Toda ferramenta de CI/CD séria (GitHub Actions, GitLab CI, Jenkins) tem um sistema de secrets criptografados separado do código-fonte — use sempre esse mecanismo, mesmo que o repositório seja privado. Já vi chave de API vazar em repositório privado que depois virou público sem ninguém perceber, e nesse momento qualquer secret hardcoded no código vira um problema retroativo.
Perguntas frequentes
Preciso de Kubernetes pra ter CI/CD?
Não. CI/CD é sobre automação de teste e entrega, independente de onde a aplicação roda depois. Muita empresa pequena tem pipeline de CI/CD maduro fazendo deploy direto num servidor único, sem orquestrador nenhum.
Qual ferramenta de CI/CD começar a aprender?
Se seu código já está no GitHub, comece por GitHub Actions — a curva de aprendizado é menor por já estar integrado. GitLab CI é equivalente pra quem usa GitLab. Jenkins ainda é muito usado em empresa grande, mas exige mais configuração de infraestrutura própria.
CI/CD vale a pena pra projeto pequeno ou só faz sentido em empresa grande?
Vale a pena mesmo em projeto pequeno ou solo. O ganho não é só velocidade — é reduzir erro humano no processo de deploy, que acontece independente do tamanho da equipe.
Quanto tempo leva pra montar um pipeline básico funcional?
Pra um projeto simples com GitHub Actions, algumas horas já dão um pipeline funcional de build, teste e deploy. O tempo maior vai pra ajustar detalhes de ambiente e secrets, não pra estrutura básica do workflow.
Se você está estruturando sua infraestrutura de desenvolvimento, também vale conferir nosso guia sobre como configurar um ambiente Docker do zero e sobre o que é Kubernetes e quando você realmente precisa dele.
Testes automatizados: sem eles o CI vira só “build automático”
Um erro que reduz bastante o valor de um pipeline de CI/CD é ter a etapa de build automatizada mas nenhum teste real rodando antes do deploy. Nesse caso você automatizou o “compilar e enviar”, não o “garantir qualidade” — que é o ponto principal de ter CI. Comece com testes simples (unitários nas partes críticas do sistema, como cálculo de preço ou autenticação) antes de tentar cobertura completa; um pipeline com poucos testes bem escolhidos já pega boa parte dos erros bobos antes de chegar em produção.
