Pipeline CI/CD para JavaScript: configuração do zero em 10 passos

Como parar de fazer deploy manualmente e não ter medo de commits

Você já se sentou numa sexta-feira à noite, olhou para a produção e pensou: "Bem, parece que está tudo funcionando, e se eu rodar o build agora — nada vai quebrar?" Familiar? Deploy manual é como pular de paraquedas sem instrutor: até dá adrenalina, mas muitas vezes acaba mal.

O pipeline CI/CD é o seu cabo de segurança automático. Ele mesmo constrói o projeto, executa os testes, verifica o código e, se estiver tudo ok — publica a atualização no servidor. Nada de "ai, esqueci de rodar o build" ou "por que os testes falharam, se funcionava localmente?".

Neste artigo, vamos configurar do zero um pipeline CI/CD completo para um projeto JavaScript. Sem enrolação, com exemplos reais de código e configurações prontas. Vamos nessa!

O que é um pipeline CI/CD e por que ele é necessário para um desenvolvedor JavaScript

Vamos logo esclarecer os termos para não nos confundirmos.

Continuous Integration (CI) — integração contínua. É quando cada commit seu é verificado automaticamente: o código passa por linters, testes, build. Se algo quebrou — você fica sabendo em 2 minutos, não em uma semana.

Continuous Delivery (CD) — entrega contínua. Implantação automática do código pronto no servidor depois que todas as verificações de CI passaram com sucesso.

Para projetos JavaScript, o CI/CD é especialmente importante. Por quê? Porque o ecossistema JS tem milhares de dependências que podem ser atualizadas a qualquer momento e quebrar seu código. A automação salva dessas surpresas.

O que vamos configurar

\n
• GitHub Actions — ferramenta gratuita para CI/CD (suficiente para a maioria dos projetos)
\n
• Linter — verificação de estilo de código (ESLint)
\n
• Testes — execução automática do Jest
\n
• Build — compilação do projeto (Webpack ou Vite)
\n
• Deploy — envio automático para o servidor ou hospedagem
\n

Passo 1: Preparando o projeto

Suponha que você já tenha um projeto JavaScript (React, Vue, Node.js — não importa). Se não tiver, crie um projeto simples para teste:

mkdir my-ci-cd-project\ncd my-ci-cd-project\nnpm init -y\nnpm install --save-dev jest eslint

Vamos adicionar um script básico no package.json:

{\n  "scripts": {\n    "test": "jest",\n    "lint": "eslint src/",\n    "build": "webpack --mode production",\n    "deploy": "rsync -avz dist/ user@server:/var/www"\n  }\n}

Agora temos comandos locais que o CI/CD executará automaticamente.

Passo 2: Criando o workflow do GitHub Actions

GitHub Actions é o cérebro do nosso pipeline. Tudo é gerenciado por arquivos YAML na pasta .github/workflows/.

Crie o arquivo .github/workflows/ci-cd.yml:

name: CI/CD Pipeline\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n    \n    steps:\n    - uses: actions/checkout@v3\n    \n    - name: Setup Node.js\n      uses: actions/setup-node@v3\n      with:\n        node-version: '18'\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\n      \n    - name: Build project\n      run: npm run build

O que acontece aqui? A cada push no main ou develop, o GitHub inicia uma máquina virtual com Ubuntu, instala o Node.js 18, instala as dependências (instalação limpa com npm ci — mais rápida e confiável que npm install), verifica o código com linter, executa os testes e compila o projeto.

Se qualquer etapa falhar — o pipeline para e você recebe uma notificação.

Passo 3: Adicionando linter e testes

ESLint e Jest são o padrão para JavaScript. Vamos configurá-los ta