CI/CD para projetos JavaScript: GitHub Actions do A ao Z

Introdução: Por que o CI/CD é necessário para projetos JavaScript?

O desenvolvimento de aplicações JavaScript modernas em Node.js exige não apenas escrever código de qualidade, mas também sua entrega confiável aos usuários finais. Testes manuais, compilação e deploy são não apenas lentos, mas também propensos a erros humanos. É aqui que o CI/CD (Continuous Integration / Continuous Deployment) entra em cena — uma metodologia para automatizar todas as etapas do ciclo de vida do software.

CI/CD para projetos JavaScript permite executar testes automaticamente a cada push no repositório, compilar a aplicação e implantá-la em um servidor ou na nuvem. Uma das ferramentas mais populares para implementar essa metodologia é o GitHub Actions — um sistema de automação de fluxo de trabalho integrado na plataforma GitHub.

Neste artigo, vamos abordar como configurar um pipeline completo de CI/CD para um projeto JavaScript (Node.js) usando GitHub Actions: desde a escrita da configuração até o deploy. Você aprenderá como acelerar o desenvolvimento, melhorar a qualidade do código e esquecer as operações rotineiras.

Parte principal: Criando um pipeline CI/CD com GitHub Actions

1. O que é GitHub Actions e como funciona?

GitHub Actions é uma plataforma para automatizar fluxos de trabalho (workflows) que é acionada em resposta a eventos no repositório (push, pull request, criação de issue, etc.). Um workflow é um conjunto de etapas executadas em máquinas virtuais (runners). Cada etapa pode executar scripts, instalar dependências ou chamar serviços externos.

Conceitos principais:

\n
• Workflow — arquivo de configuração YAML armazenado na pasta .github/workflows/.
\n
• Event — gatilho que inicia o workflow (por exemplo, push ou pull_request).
\n
• Job — conjunto de etapas executadas em um único runner (dependências, testes, compilação).
\n
• Step — comando ou ação individual (action).
\n

Para projetos JavaScript, usaremos o runner padrão com Ubuntu, pois ele suporta Node.js nativamente.

2. Configuração básica: Testes e linting

Vamos começar criando um workflow simples para testes e linting de código. Crie o arquivo .github/workflows/ci.yml na raiz do seu repositório.

Exemplo de configuração para um projeto Node.js:

name: CI for Node.js\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n\n    strategy:\n      matrix:\n        node-version: [18.x, 20.x]\n\n    steps:\n      - name: Checkout repository\n        uses: actions/checkout@v4\n\n      - name: Setup Node.js ${{ matrix.node-version }}\n        uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.node-version }}\n          cache: 'npm'\n\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Run linter\n        run: npm run lint\n\n      - name: Run tests\n        run: npm test

Vamos analisar os pontos-chave:

\n
• Matrix strategy — permite executar testes em várias versões do Node.js (18.x e 20.x) em paralelo.
\n
• actions/checkout — ação padrão para clonar o repositório.
\n
• actions/setup-node — instala a versão necessária do Node.js e ativa o cache de node_modules para acelerar.
\n
• npm ci — instalação limpa das dependências a partir do package-lock.json (mais rápida e confiável que npm install).
\n

Após fazer push deste arquivo para o repositório, o GitHub Actions executará automaticamente os testes. Você verá o resultado na seção "Actions" do seu repositório.

3. Compilação e publicação de imagem Docker

E