Se você trabalha com tecnologia, já deve ter ouvido que CI/CD é o mínimo esperado em times profissionais. Mas entre saber o conceito e ter um pipeline funcionando, existe uma distância que só a prática reduz.

Neste guia, vou mostrar como montar um pipeline de CI/CD do zero usando GitHub Actions - desde o build até o deploy em produção.

O que é CI/CD?

CI (Integração Contínua) é a prática de automatizar build e testes a cada push no repositório. Cada commit é verificado automaticamente.

CD (Entrega ou Deploy Contínuo) é a extensão da CI: após os testes passarem, o código é implantado automaticamente em produção.

Por que GitHub Actions?

Diferente de ferramentas como Jenkins (que exige servidor próprio) ou GitLab CI (que precisa de autohosted runners em alguns casos), o GitHub Actions oferece:

• Sem infraestrutura para gerenciar - os runners são mantidos pelo GitHub
• Ecossistema vasto - actions prontas para AWS, GCP, Docker, Slack, etc.
• Preço competitivo - 2000 minutos/mês grátis em contas gratuitas
• Integração nativa - seu código já está no GitHub

Estrutura do Pipeline

Um pipeline de CI/CD bem estruturado segue estas etapas:

Push → Lint → Testes → Build → Scan → Deploy (STG) → Deploy (PRD)

Vamos implementar cada etapa.

1. Arquivo base

Crie .github/workflows/deploy.yml no seu repositório:

name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

2. Segurança na pipeline

Adicione verificação de vulnerabilidades com npm audit e um scanner como Trivy:

      - name: Security audit
        run: npm audit --audit-level=high

      - name: Scan dependencies
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'table'
          exit-code: '1'

3. Deploy para produção

O deploy deve ser manual (via workflow_dispatch) para branches de produção:

  deploy:
    needs: ci
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        run: |
          # Seu comando de deploy aqui
          echo "Deploy realizado com sucesso!"

Boas práticas

1. Mantenha segredos no GitHub Secrets - nunca hardcode credenciais
2. Use matrix builds para testar em múltiplas versões ou ambientes
3. Cacheie dependências para acelerar execuções
4. Notifique falhas no Slack ou Discord
5. Version suas actions usando SHAs (não branches)

Exemplo real

Aqui está um pipeline completo que uso em projetos reais:

name: CI/CD

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build
          path: dist/

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      - run: echo "Deploy executado em $(date)"

Conclusão

Um pipeline de CI/CD não é luxo - é necessidade. Com GitHub Actions, você monta um fluxo profissional em minutos, sem precisar gerenciar servidores.

Quer aprender a aplicar isso em um projeto completo do zero?

Ou saber mais sobre o treinamento