DevOps, o que é CI/CD ?

by

Tux de pé num esteira de containers diante do losango laranja do Git

Nota (2026): Texto original de dezembro de 2019 — glossário de CI/CD ainda no vocabulário Jenkins/Red Hat, com a nota “vai ser melhorado em breve”. Sete anos depois o YAML no Git virou o default (GitHub Actions, GitLab CI, Forgejo), o CD em Kubernetes virou GitOps (Argo CD / Flux), e o próprio pipeline passou a ser alvo de supply chain. Conceito não mudou; a ferramenta e a ameaça, sim.

CI/CD não é produto. É o hábito de integrar, testar e soltar software em ciclo curto, com o máximo de passo automático. O “merge day” de 2019 continua sendo o anti-padrão. O que mudou é onde o YAML mora, quem roda o job e o que acontece depois do verde no pipeline.

Conteúdo ocultar
1 CI, entrega e implantação — os três CDs
2 O pipeline em 2026: YAML no Git
3 CD virou GitOps
4 O pipeline como alvo
5 Por onde começar de verdade
6 Uma volta visual
7 Referências

CI, entrega e implantação — os três CDs

CI (integração contínua): cada push/MR vira build + teste automático no tronco compartilhado. O conflito aparece hoje, não na sexta da release.

Entrega contínua: o artefato aprovado (binário, imagem OCI, pacote) vai sozinho para um registro. Produção ainda tem um humano no botão — ou um critério (tag, aprovação, janela).

Implantação contínua: o mesmo artefato sobe sozinho para produção se o teste passou. Feedback do usuário em minutos. Exige teste que você realmente confia, não um job verde oco.

Não vale brigar pelo acrônimo. Vale desenhar o pipeline: o que é automático, o que é porta, o que é rollback.

commit → CI (lint, test, build)
       → artefato no registry (entrega)
       → staging
       → produção (implantação: botão ou automática)
       → observação (métrica, log, alerta)

O pipeline em 2026: YAML no Git

Jenkins com plugin ainda existe em legado. O ponto de partida no Linux hoje é um arquivo no repositório, runner em container, artefato em registry.

GitHub Actions — o default de quem já está no GitHub. Pin de action por SHA, não por tag flutuante: o CI virou vetor (compromisso de actions populares em 2025–2026).

# .github/workflows/ci.yml
name: ci
on:
  pull_request:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make test

GitLab CI — o que o post irmão de 2019 já apontava para Terraform. Um .gitlab-ci.yml, runners próprios se quiser soberania:

# .gitlab-ci.yml
stages: [test, image]
test:
  stage: test
  image: golang:1.24
  script: [go test ./...]
image:
  stage: image
  image: docker:27
  services: [docker:27-dind]
  script:
    - docker build -t registry.example.com/app:$CI_COMMIT_SHA .
    - docker push registry.example.com/app:$CI_COMMIT_SHA
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Forgejo Actions / Gitea — o mesmo YAML do Actions, self-hosted, sem mandar o código para a nuvem alheia. Woodpecker é o outro binário leve. No homelab Linux isso compete com GitLab CE.

O curso de Docker continua sendo o pré-requisito: o job moderno é um container. Infra como código no mesmo espírito: Ansible e o pipeline de Terraform no GitLab.

CD virou GitOps

Implantar no Kubernetes em 2026 raramente é kubectl apply no job de CI. O CI constrói a imagem, assina, empurra o registry e atualiza o Git (tag, digest). O cluster puxa o estado desejado:

  • Argo CD — app-of-apps, drift detection, sync a partir do Git. 3.5 (2026) adiciona mTLS interno e verificação de assinatura de commit.
  • Flux — o outro padrão CNCF, controllers no cluster.

O Git passa a ser a fonte da verdade. O runner deixa de ter credencial de produção eterna: OIDC para a nuvem, short-lived token, admission no cluster checando Cosign/SLSA antes do pod subir. Quem ainda faz docker compose up num VPS (como no Vaultwarden) está no degrau da entrega contínua com SSH — válido, só não é GitOps.

O pipeline como alvo

Em 2019 o medo era merge quebrado. Em 2026 o medo é o job que passa e publica malware. Actions comprometidas, pacote npm sequestrado, secret no log.

  • Pin de action/container por digest, não @v3 solto.
  • Secrets no cofre (GitHub/GitLab, Vault, SOPS) — nunca no YAML.
  • SBOM + Cosign (Sigstore, OIDC keyless) na imagem.
  • Provenance SLSA Build L2/L3 quando o builder é a plataforma, não um script no repo.
  • PR de fork: não rode o workflow do branch do atacante com secret da org (pull_request_target mal usado).

Depois do deploy: o Prometheus diz se o verde mentiu.

Por onde começar de verdade

  1. Tronco compartilhado, PR pequeno, CI no PR (lint + teste). Sem isso o resto é teatro.
  2. Imagem OCI versionada por SHA, registry próprio ou GHCR/GitLab.
  3. Staging automático; produção com porta (tag ou aprovação) até o teste merecer implantação contínua.
  4. Só então GitOps, assinatura, SLSA.

Muita empresa para no 2 e chama de DevOps. Não é pecado. É honesto. Pular para Argo sem teste é pintar o avião.

Uma volta visual

Referências

CI/CD continua sendo o mesmo pipeline de 2019: integrar cedo, testar sempre, soltar em pedaço pequeno. O YAML foi para o Git, o cluster passou a puxar o estado, e o job verde agora precisa provar de onde veio o binário. O resto é ferramenta.