O que é CI/CD e Por Que Importa
CI/CD significa Integração Contínua (CI) e Entrega/Implantação Contínua (CD). A ideia central é automatizar o caminho do código — desde o commit até a produção — eliminando tarefas manuais repetitivas e reduzindo erros humanos. Como desenvolvedor experiente, posso afirmar que times que implementam CI/CD bem conseguem fazer deploy 10 vezes por dia com confiança, enquanto times sem essas práticas levam semanas e vivem com medo de quebrar produção.
A Integração Contínua garante que toda mudança de código passe por testes automatizados antes de entrar na branch principal. A Entrega Contínua leva esse código testado até um ambiente pronto para produção. A Implantação Contínua vai além: publica automaticamente em produção sem intervenção humana. A maioria dos times implementa CI + CD parcial, e está tudo bem.
Por que começar agora?
Feedback rápido é ouro em desenvolvimento. Quando seu código quebra, você descobre em minutos, não em semanas. Além disso, documentação fica viva (os passos estão no pipeline), onboarding melhora (novatos veem exatamente como tudo funciona), e você dorme melhor sabendo que cada deploy foi validado por máquinas.
Configurando seu Primeiro Pipeline com GitHub Actions
GitHub Actions é grátis, integrado ao GitHub, e perfeito para começar. Vou mostrar um exemplo real com Node.js que testa e faz deploy automático.
Estrutura do repositório
Crie a pasta .github/workflows/ na raiz do projeto:
seu-projeto/
├── .github/workflows/
│ └── ci-cd.yml
├── src/
│ └── app.js
├── tests/
│ └── app.test.js
├── package.json
└── README.md
Exemplo funcional: Pipeline completo
name: CI/CD Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [18.x, 20.x]
steps:
- uses: actions/checkout@v4
- name: Usar Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- name: Instalar dependências
run: npm ci
- name: Rodar testes
run: npm test
- name: Verificar cobertura
run: npm run coverage
deploy:
needs: test
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
steps:
- uses: actions/checkout@v4
- name: Deploy para produção
env:
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
run: |
mkdir -p ~/.ssh
echo "$DEPLOY_KEY" > ~/.ssh/deploy_key
chmod 600 ~/.ssh/deploy_key
ssh-keyscan -H seu-servidor.com >> ~/.ssh/known_hosts
ssh -i ~/.ssh/deploy_key user@seu-servidor.com 'cd /app && git pull && npm install && npm run build && pm2 restart app'
Neste exemplo, a seção test roda em múltiplas versões do Node (matriz), enquanto deploy só executa após sucesso dos testes e apenas na branch main. Os secrets (DEPLOY_KEY) ficam seguros, nunca no código.
Qualidade de Código no Pipeline
Testes são apenas um pilar. Code linting, análise estática e relatórios de segurança transformam seu pipeline de simples "rode os testes" para "garanta código profissional".
Integrando ESLint, Prettier e SonarQube
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20.x
cache: 'npm'
- run: npm ci
- name: Lint
run: npm run lint
- name: Formatar (Prettier)
run: npx prettier --check src/
- name: SonarQube Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONARCLOUD_TOKEN: ${{ secrets.SONARCLOUD_TOKEN }}
No package.json, adicione:
{
"scripts": {
"lint": "eslint src/ --max-warnings 0",
"test": "jest --coverage",
"coverage": "jest --coverage --coveragePathIgnorePatterns=/node_modules/"
},
"devDependencies": {
"eslint": "^8.50.0",
"prettier": "^3.0.0",
"jest": "^29.0.0"
}
}
Isso garante que nenhum código com warnings ou má formatação entra em main. SonarQube detecta code smells e vulnerabilidades — é overkill para projetos pequenos, mas essencial em empresas.
Estratégias de Deploy e Rollback
Nem todo deploy é igual. Blue-Green e Canary são estratégias que reduzem risco drasticamente.
Blue-Green: Segurança em Troca de Recursos
Você mantém dois ambientes idênticos: Blue (atual) e Green (novo). Deploy vai para Green, testes rodam lá, e só depois você aponta o load balancer para Green. Se algo quebrar, volta para Blue em segundos.
#!/bin/bash
# deploy-blue-green.sh
CURRENT=$(curl -s http://api.seu-site.com/version)
if [ "$CURRENT" = "blue" ]; then
TARGET="green"
else
TARGET="blue"
fi
# Deploy na versão alvo
docker build -t seu-app:latest .
docker run -d -p 8080:3000 --name seu-app-$TARGET seu-app:latest
# Testes de smoke
if ! curl -f http://localhost:8080/health; then
echo "Deploy falhou nos testes de saúde"
docker stop seu-app-$TARGET
exit 1
fi
# Switch de tráfego
sed -i "s/upstream backend {.*}/upstream backend { server 127.0.0.1:8080; }/" /etc/nginx/nginx.conf
nginx -s reload
echo "Deploy de $TARGET concluído com sucesso"
Blue-Green é caro (precisa de 2x recursos), mas é o padrão em fintechs e saúde. Para startups, Canary (liberar para 5% dos usuários primeiro) é mais prático.
Conclusão
Dominar CI/CD não é sobre ser um "expert em ferramentas" — é sobre mentalidade. Três pontos que levarei com você:
-
Automatizar reduz fricção: Cada tarefa manual que entra no pipeline é uma chance de erro eliminada. Seu código fica mais confiável porque máquinas não se distraem.
-
Feedback rápido muda tudo: Saber em 5 minutos que sua mudança quebrou algo é incomparável. Você corrige ainda com o contexto fresco na cabeça, não duas semanas depois.
-
Comece simples, evolua depois: Não precisa de SonarQube, Kubernetes e 15 estágios no dia um. Comece com testes e GitHub Actions. Adicione segurança, análise estática e canary deploys conforme sua aplicação cresce.
CI/CD é um investimento que se paga rapidamente. A primeira semana é setup, a segunda mês, e depois você faz em 2 horas o que levaria dias antes.