CI/CD e automação de pipelines

Do zero

Imagine uma fábrica em que cada peça só é testada no fim do mês, quando o carro inteiro é montado. Se algo não encaixa, ninguém sabe qual das mil peças causou o problema. Agora imagine que cada peça é testada no minuto em que sai da máquina. O defeito aparece cedo, perto de quem o causou, e é barato de corrigir.

Em software, isso é a integração contínua (CI): cada mudança enviada ao repositório dispara automaticamente a compilação e os testes. Se algo quebra, o aviso chega em minutos.

A entrega contínua (CD) leva a ideia adiante: toda mudança que passa nos testes vira um pacote pronto para ir à produção, com um clique. Na implantação contínua, nem o clique é preciso: passou em tudo, vai para produção sozinho.

O caminho automatizado, da mudança no código até o sistema no ar, é o pipeline. Ferramentas como GitHub Actions, GitLab CI/CD e Jenkins executam esse caminho a partir de um arquivo de configuração guardado junto com o código.

Frase para guardar: CI testa cada mudança; entrega contínua deixa tudo pronto para implantar; implantação contínua implanta sozinha.

Em 1 minuto

• Integração contínua: integrar mudanças pequenas várias vezes ao dia; cada uma dispara build e testes automatizados.
• Entrega contínua (continuous delivery): o software está sempre implantável; a ida para produção depende de uma aprovação.
• Implantação contínua (continuous deployment): passou em todas as etapas, vai para produção automaticamente.
• Pipeline como código: a definição do pipeline fica num arquivo versionado com o projeto: .github/workflows/*.yml (GitHub Actions), .gitlab-ci.yml (GitLab CI/CD) e Jenkinsfile (Jenkins).
• Boas práticas: falhar rápido (testes mais rápidos primeiro), gerar o artefato uma vez e promovê-lo pelos ambientes, segredos no cofre da ferramenta e nunca no código.

Exemplo concreto: o pipeline do portal

1. O desenvolvedor abre um pull request.
2. O pipeline compila e roda os testes unitários (em minutos).
3. Roda a análise estática de segurança (SAST), a análise de dependências e a varredura de segredos.
4. Gera a imagem do container uma única vez e a publica no registro.
5. Implanta essa imagem em homologação e roda os testes de integração.
6. Uma pessoa aprova (entrega contínua) e a mesma imagem vai para produção, primeiro para uma pequena parte dos usuários (canário).
7. O monitoramento confirma que está tudo bem; se não, o rollback volta a versão anterior.

A etapa de build e testes desse pipeline, em GitHub Actions (arquivo .github/workflows/ci.yml):

name: CI
on:
  pull_request:
  push:
    branches: [main]
jobs:
  testes:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

Em GitLab CI/CD (arquivo .gitlab-ci.yml, na raiz do projeto):

stages: [test, deploy]

testes:
  stage: test
  image: node:22
  script:
    - npm ci
    - npm test

producao:
  stage: deploy
  script: ./implantar.sh
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual      # entrega contínua: alguém aprova

Em Jenkins (arquivo Jenkinsfile, pipeline declarativo):

pipeline {
  agent any
  stages {
    stage('Build') { steps { sh 'npm ci' } }
    stage('Testes') { steps { sh 'npm test' } }
    stage('Implantar') {
      when { branch 'main' }
      steps { input 'Implantar em produção?'; sh './implantar.sh' }
    }
  }
}

Comparação: as três ferramentas

Ferramentas correlatas: Azure Pipelines (Azure DevOps), Bitbucket Pipelines, CircleCI e Tekton, além do Argo CD para implantação GitOps no Kubernetes (o estado desejado fica no Git e a ferramenta sincroniza o cluster). Todas seguem a ideia de pipeline como código.

Estratégias de implantação

Como a FCC cobra

• Entrega contínua × implantação contínua (há ou não aprovação manual).
• Etapas típicas de um pipeline e a ordem delas.
• Arquivos e conceitos de cada ferramenta (workflow, job, runner, stage, Jenkinsfile).
• Estratégias de implantação (blue-green, canário, rolling).
• Segurança no pipeline (segredos, SAST, dependências).

Pegadinhas

Explique com suas palavras

Explique a um gestor a diferença entre integração contínua, entrega contínua e implantação contínua, usando o exemplo de uma correção no portal do Tribunal.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Na integração contínua, quando o programador envia a correção, um robô compila o sistema e roda todos os testes automaticamente. Se algo quebrar, ele fica sabendo em minutos, não semanas depois.

Na entrega contínua, a correção que passou nos testes vira um pacote pronto para ir ao ar, já testado também em homologação. Falta só alguém autorizar. Na implantação contínua, nem isso: passou em todas as verificações, o próprio pipeline publica em produção. A diferença entre as duas é se há ou não um clique humano antes da produção.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

O espelho-modelo do guia pede “controles no pipeline de CI/CD para o código produzido pelo agente de IA”. Descreva o pipeline em etapas: testes automatizados como portão, SAST, análise de dependências, varredura de segredos e da imagem, revisão humana obrigatória no pull request, aprovação antes da produção (entrega contínua) e implantação canário com rollback.

Fontes da lição

• Edital nº 01/2026, Anexo II, DevOps, Plataforma de Desenvolvimento e Engenharia de Entrega (fontes/edital-01-2026.txt).
• Jez Humble e David Farley, Entrega contínua (pipeline de implantação, entrega × implantação contínua).
• Documentação do GitHub Actions
• Documentação do GitLab CI/CD
• Documentação do Jenkins Pipeline