Pipelines CI/CD Explicados com GitHub Actions

Você acabou de fazer um commit e agora está executando testes manualmente, compilando o aplicativo e enviando arquivos para um servidor. Funciona, mas é lento, propenso a erros e não escala. É aí que entram os pipelines CI/CD.

Neste guia, vamos explicar os conceitos de CI/CD e mostrar como construir um pipeline real com GitHub Actions. No final, você entenderá como automatizar testes, compilação e implantação para qualquer projeto.

O que é CI/CD?

CI (Integração Contínua) é a prática de testar e mesclar automaticamente alterações de código em um branch compartilhado. Cada push dispara uma compilação e execução de testes, detectando problemas de integração precocemente.

CD (Entrega/Implantação Contínua) estende a CI preparando (e opcionalmente implantando) automaticamente seu aplicativo em produção. Entrega Contínua significa que o código está sempre pronto para implantar; Implantação Contínua significa que ele é implantado automaticamente.

Juntos, CI/CD forma um pipeline: uma série de etapas automatizadas que levam seu código do commit à produção.

Por que usar GitHub Actions para CI/CD?

GitHub Actions é uma plataforma de CI/CD integrada ao GitHub. É gratuita para repositórios públicos e oferece minutos generosos para repositórios privados. Principais benefícios:

• Integrado: Nenhum serviço externo é necessário; os fluxos de trabalho ficam no seu repositório.
• Orientado a eventos: Dispare fluxos de trabalho em push, pull request, agendamento ou execução manual.
• Extensível: Milhares de ações pré-construídas no GitHub Marketplace.
• Compilações em matriz: Teste em vários sistemas operacionais e versões de linguagem facilmente.

Conceitos principais do GitHub Actions

Antes de escrever seu primeiro fluxo de trabalho, entenda estes termos:

Construindo seu primeiro pipeline de CI

Vamos criar um fluxo de trabalho básico de CI para um projeto Node.js. Ele executará testes em cada push e pull request para o branch principal.

Crie .github/workflows/ci.yml:

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test

Este fluxo de trabalho:

1. Dispara em pushes e PRs para main.
2. Executa um job chamado test no runner Ubuntu mais recente.
3. Usa uma matriz para testar com Node.js 18 e 20.
4. Faz checkout do código, configura o Node, instala dependências e executa testes.

Envie este arquivo e observe a aba Actions. Você verá dois jobs paralelos (um por versão do Node). Se algum teste falhar, o fluxo de trabalho falha e o GitHub notifica você.

Adicionando implantação contínua

CI é ótimo, mas CD é onde a automação brilha. Vamos estender o fluxo de trabalho para implantar em um servidor após os testes passarem no branch principal.

Adicionaremos um job deploy que depende de test e é executado apenas em pushes para main.

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Deploy to server
      uses: appleboy/ssh-action@v1.0.0
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USER }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          cd /var/www/myapp
          git pull origin main
          npm ci --production
          pm2 restart myapp

Pontos-chave:

• needs: test garante que a implantação só seja executada se os testes passarem.
• A condição if restringe a implantação a pushes em main.
• Segredos (SSH_HOST, SSH_USER, SSH_KEY) são armazenados nas configurações do repositório GitHub e injetados com segurança.

Este padrão funciona para muitos destinos de implantação: SSH, registros Docker, plataformas de nuvem (AWS, Vercel, Netlify) ou Kubernetes.

Melhores práticas para CI/CD com GitHub Actions

• Mantenha os fluxos de trabalho rápidos: Faça cache de dependências (por exemplo, actions/cache) para reduzir os tempos de compilação.
• Falhe rápido: Execute verificações rápidas (linting) antes de testes mais lentos.
• Use ambientes: Configure regras de proteção para implantações em produção.
• Proteja segredos: Nunca codifique credenciais; use GitHub Secrets.
• Monitore e alerte: Configure notificações para fluxos de trabalho com falha.

Depurando fluxos de trabalho com falha

Quando um fluxo de trabalho falha, o GitHub mostra logs para cada etapa. Problemas comuns incluem:

• Dependências ausentes: garanta que npm ci ou equivalente seja executado antes dos testes.
• Segredos incorretos: verifique novamente nomes e valores.
• Erros de permissão: verifique as permissões do runner e as chaves SSH.

Você também pode habilitar o log de depuração definindo o segredo do repositório ACTIONS_STEP_DEBUG como true.

FAQ

Qual é a diferença entre CI e CD?

CI automatiza o teste e a integração de alterações de código. CD automatiza a entrega ou implantação dessas alterações em um ambiente. CI garante a qualidade do código; CD garante que ele chegue aos usuários de forma rápida e confiável.

O GitHub Actions é gratuito?

O GitHub Actions é gratuito para repositórios públicos. Para repositórios privados, você recebe uma cota mensal de minutos gratuitos (por exemplo, 2.000 minutos para contas gratuitas) e paga pelo uso adicional. Runners auto-hospedados também são uma opção.

Posso usar o GitHub Actions para projetos que não estão no GitHub?

Sim, o GitHub Actions pode executar qualquer ferramenta de linha de comando. Você pode usá-lo para compilar e implantar projetos hospedados em outros lugares, desde que o código esteja no GitHub ou você use ações para buscá-lo.

Pronto para otimizar seu CI/CD? Comece automatizando seus testes com GitHub Actions. Para uma maneira rápida de analisar logs de implantação, experimente nosso Analisador de Logs Nginx para identificar erros e problemas de desempenho após cada implantação.