DevOpsQuest
0 XP
Módulo 5 · CI/CD com GitHub Actions

Anatomia de um workflow: triggers, jobs e steps

Intermediário 40 min+25 XPGitHub ActionsYAML

Objetivos desta aula

  • Escolher triggers adequados
  • Estruturar jobs paralelos e dependentes
  • Usar matriz de versões

Um workflow reage a eventos: push, pull_request, schedule, workflow_dispatch (manual) e release. A escolha do trigger define o custo e a utilidade: validar em pull_request protege a main; publicar em push de tag garante que só versões marcadas geram artefato.

Jobs rodam em paralelo por padrão e em máquinas separadas, o que significa que nada é compartilhado automaticamente entre eles — use needs para ordenar e artifacts para transportar arquivos. Steps dentro de um job compartilham o mesmo runner e diretório.

Matriz é a forma de testar múltiplas versões sem duplicar YAML, e concurrency cancela execuções antigas do mesmo branch, economizando minutos e evitando confusão de resultados.

1. O que é CI e o que é CD

Integração contínua: a cada push, o código é compilado e testado automaticamente. Entrega contínua: todo commit aprovado vira um artefato pronto para produção. Deploy contínuo: esse artefato vai para produção sem intervenção manual.

2. Hierarquia do GitHub Actions

Workflow (arquivo em .github/workflows) → jobs (rodam em paralelo por padrão, cada um em uma máquina nova) → steps (comandos ou actions, em sequência, compartilhando o filesystem do job).

3. Triggers

push, pull_request, workflow_dispatch (manual), schedule (cron), release. Use filtros de branches e paths para não rodar o pipeline do backend quando só o README mudou.

4. Dependência entre jobs e artefatos

needs: test cria ordem. Como jobs não compartilham disco, passe arquivos com upload-artifact/download-artifact ou valores com outputs.

5. Matrix

strategy.matrix roda o mesmo job em várias versões (Node 18/20/22) ou sistemas, em paralelo.

6. Checagem final

Você deve ler um workflow e dizer o que roda, quando, em que ordem e em que máquina.

Na prática

CI do CloudShop em PRs

yaml

name: ci

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

permissions:
  contents: read

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  qualidade:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: coverage-node${{ matrix.node }}
          path: coverage/

  shell:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: sudo apt-get install -y shellcheck
      - run: shellcheck scripts/*.sh

Nota de segurança: Declare permissions no topo. O token padrão com escrita permite que uma dependência maliciosa altere o repositório.

Workflow com filtros, matrix e dependência

yaml

name: api-ci
on:
  pull_request:
    paths: ["api/**", ".github/workflows/api-ci.yml"]
  push:
    branches: [main]
concurrency:
  group: api-ci-${{ github.ref }}
  cancel-in-progress: true          # cancela execucao antiga do mesmo branch
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix: { node: [20, 22] }
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: ${{ matrix.node }} }
      - run: npm ci && npm test
        working-directory: api
  build:
    needs: test                     # so roda se test passar
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t cloudshop-api:ci api

Por que isso importa

Pipeline é o que dá confiança para entregar várias vezes ao dia sem medo.

Erro comum

Assumir que arquivos gerados em um job estarão disponíveis em outro.

Dica de produção

Fixe actions por versão maior e evite referências a branch (@main) de terceiros.

Alerta de segurança

pull_request_target com checkout do código do PR é um vetor clássico de exfiltração de secrets.

Pergunta de entrevista

Qual a diferença entre job e step, e o que é compartilhado entre eles?

Glossário

runner
Máquina que executa um job do workflow.
concurrency
Regra que limita execuções simultâneas e pode cancelar as anteriores.
runner
Máquina que executa os jobs do workflow.
matrix
Estratégia que multiplica um job por combinações de parâmetros.
concurrency
Controle que evita execuções simultâneas do mesmo grupo.

Conexão com o CloudShop

Tornar o CI obrigatório para merge no cloudshop-app.

Quiz da aula

  1. 1. Como transportar arquivos entre dois jobs?

  2. 2. Jobs de um workflow compartilham o disco?

  3. 3. Como evitar rodar o CI da API quando só o README muda?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima