Deploy Automático com GitHub Actions: Guia

Galera, deploy manual é coisa do passado. Se você ainda tá fazendo upload por FTP ou rodando comandos de build na mão pra publicar seu site, esse artigo vai mudar seu fluxo de trabalho completamente.

GitHub Actions é o CI/CD gratuito do GitHub. Você configura uma vez e a partir daí cada push no repositório dispara um pipeline que builda, testa e publica seu site automaticamente. Sem tocar em nada. Vou te mostrar como configurar pras três plataformas mais usadas.

O que é deploy automático e por que usar?

Deploy automático (ou CI/CD — Continuous Integration / Continuous Deployment) é quando qualquer mudança que você faz no código vai pro ar sozinha. Você faz commit, faz push, e em 1-3 minutos o site atualizado tá no ar. Sem FTP, sem SSH, sem dashboard.

A vantagem não é só conveniência. É consistência. Você nunca esquece de rodar o build, nunca faz deploy da branch errada, nunca sobe um arquivo corrompido. O pipeline cuida de tudo — e se algo der errado, ele te avisa antes de publicar.

GitHub Actions: CI/CD gratuito e poderoso

O GitHub Actions roda workflows definidos em arquivos YAML dentro da pasta .github/workflows/ do seu repositório. Cada workflow tem triggers (quando rodar), jobs (o que fazer) e steps (cada passo do processo).

Workflow 1: Deploy pro GitHub Pages

Esse é o workflow mais comum. Vou te mostrar como configurar deploy automático de um site estático (React, Vue, Astro, qualquer um) pro GitHub Pages usando Actions.

# .github/workflows/deploy.yml
name: Deploy to GitHub Pages

on:
  push:
    branches: [main]

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: pages
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: npm run build

      - uses: actions/upload-pages-artifact@v3
        with:
          path: ./dist  # Ajuste pro diretório de output do seu framework

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@v4

Troque o ./dist pelo diretório de output do seu framework: ./out pra Next.js (com output: 'export'), ./dist pra Vite/Astro, ./build pra Create React App. O resto do workflow é padrão — não precisa mexer.

Workflow 2: Deploy pra Vercel

A Vercel já faz deploy automático quando você conecta o repo. Então por que usar GitHub Actions? Pra rodar testes antes do deploy. Se os testes falharem, o deploy não acontece — você não sobe código quebrado pra produção.

# .github/workflows/vercel-deploy.yml
name: Vercel Deploy with Tests

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: npm run lint
      - run: npm run test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

Pra configurar os secrets, vá em Settings > Secrets and variables > Actions no GitHub. O VERCEL_TOKEN você pega em vercel.com/account/tokens. Os IDs do org e projeto ficam no arquivo .vercel/project.json (rode vercel link primeiro).

Workflow 3: Deploy pra Netlify

Mesma lógica da Vercel — a Netlify faz deploy automático por padrão, mas com Actions você adiciona a camada de testes. E tem um bônus: dá pra criar preview deployments customizados por PR.

# .github/workflows/netlify-deploy.yml
name: Netlify Deploy

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

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: npm run lint
      - run: npm run build

      # Deploy de produção (só na main)
      - uses: nwtgck/actions-netlify@v3
        if: github.ref == 'refs/heads/main'
        with:
          publish-dir: ./dist
          production-deploy: true
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

      # Preview deploy (em PRs)
      - uses: nwtgck/actions-netlify@v3
        if: github.event_name == 'pull_request'
        with:
          publish-dir: ./dist
          production-deploy: false
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

O NETLIFY_AUTH_TOKEN você gera em app.netlify.com/user/applications#personal-access-tokens. O SITE_ID fica em Site Settings > General > Site ID. Cola os dois como secrets no GitHub e tá pronto.

Rodando testes antes do deploy

A parte mais importante do CI/CD não é o deploy — são os testes. Se você deployar código com bug, vai ter que correr pra fazer rollback. Se os testes rodarem antes, o bug nunca chega em produção.

# Adicione esses steps no job de test
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: 20
      cache: npm

  - run: npm ci

  # TypeScript type check
  - run: npx tsc --noEmit

  # ESLint
  - run: npm run lint

  # Testes unitários
  - run: npm run test -- --coverage

  # Build (pega erros que lint e tsc não pegam)
  - run: npm run build

Esse pipeline pega 95% dos problemas antes de chegar em produção. Type check, lint, testes e build — se passar em tudo, pode deployar tranquilo.

Preview deployments: testando antes de mergear

Preview deployment é quando cada PR gera uma versão temporária do site numa URL única. Você (ou seu time) clica, vê o resultado e só depois aprova o merge. Vercel e Netlify fazem isso nativamente. No GitHub Pages, dá pra configurar via Actions, mas é mais trabalhoso.

Dica: configure o workflow pra postar um comentário no PR com a URL do preview. As actions amondnet/vercel-action e nwtgck/actions-netlify já fazem isso automaticamente. Conveniência pura.

Rollbacks: voltando atrás quando dá errado

Se mesmo com testes algo der errado em produção, você precisa de rollback. Na Vercel e Netlify, é instantâneo — cada deploy fica salvo e você clica em 'Redeploy' numa versão anterior direto pelo dashboard. Leva 30 segundos.

No GitHub Pages com Actions, o rollback é via git: faça git revert do commit problemático, push, e o workflow roda de novo com a versão correta. Menos conveniente, mas funciona.

Dicas avançadas

O mais importante é começar simples. Um workflow que faz checkout, build e deploy já é 10x melhor que deploy manual. Conforme o projeto cresce, você vai adicionando testes, previews e validações. Não tente fazer tudo de uma vez.