03-04, CI/CD
1. Problema de Engenharia
CI/CD é onde projetos perdem mais tempo do que admitem. Pipelines de 30 min em projetos pequenos. Builds que falham flaky aleatoriamente. Deploy manual disfarçado de "automated" porque alguém precisa apertar botão. Rollback que demora 20 min. Secrets em logs. Branches sem proteção. Devs que esperam CI verde e empurram outra vez sem entender o que falhou.
Este módulo é CI/CD profissional: pipeline rápido (paralelizado, cached), deploys reprodutíveis, rollback em segundos, segurança (supply chain, secrets), padrões modernos (trunk-based, GitFlow, deploy strategies, feature flags). Você sai com pipeline que confia.
2. Teoria Hard
2.1 CI vs CD
Continuous Integration : código integra em mainline frequente, com testes automated rodando.Continuous Delivery : cada commit verde é deployable a qualquer momento (mas deploy é manual).Continuous Deployment : cada commit verde é automatically deployed em prod.
Continuous Deployment exige maturidade alta: testes confiáveis, observability forte, rollback automático, feature flags. Em projetos novos, comece em Continuous Delivery (deploy automático em staging, manual em prod) e suba.
GitHub Actions : tightly integrado ao GitHub. Marketplace gigante. Default da maioria dos projetos novos.GitLab CI/CD : integrado ao GitLab, runners flexíveis.CircleCI, Buildkite, Drone : alternativas com strengths.Jenkins : clássico, ainda pesa em enterprise.Argo Workflows / Tekton : K8s-native.
Em 2026, GitHub Actions domina nos projetos open-source e médios. GitLab forte em enterprise self-hosted.
2.3 Pipeline anatomy
Estrutura típica:
PR opened → install → lint → typecheck → unit → integration → build → e2e → deploy preview
PR merge → install → lint → typecheck → unit → integration → build → e2e → deploy staging → smoke → deploy prod (gated) → notify
Copy Ou separado por workflows.
Princípios:
Fail fast : lint antes de testes; cheap antes de caro.Paralelizar quando independente.Cache deps, build, Playwright browsers, Docker layers.Steps idempotentes .Determinístico : mesmo input = mesmo output.
2.4 Caching
Lockfiles (pnpm, yarn) → cache de node_modules ou ~/.pnpm.
Build artifacts (.next/cache, dist/).
Test runners (Vitest cache, Playwright browsers download).
Docker layers (docker/build-push-action com cache-from/cache-to em GHCR ou registry).
GitHub Actions:
- uses: actions/cache@v4
with:
path: ~/.pnpm-store
key: pnpm-${{ hashFiles('pnpm-lock.yaml') }}
yaml Copy Restore parcial é problema sutil. Use restore-keys com prefix.
2.5 Matrix builds
Rodar mesma suite em múltiplas combinações:
strategy:
matrix:
node: [20, 22]
os: [ubuntu-latest, macos-latest]
yaml Copy Útil pra libs cross-platform/cross-version. Em apps específicos a 1 stack, matrix é overhead.
2.6 Reusable workflows e composite actions
DRY pra pipelines com múltiplos repos ou múltiplos jobs similares:
Composite action : pasta com action.yml, agrupa steps.Reusable workflow : arquivo .github/workflows/reusable.yml, called via uses:.
Em monorepo: 1 workflow base parametrizado, jobs por package.
2.7 Secrets management
GitHub Secrets : encrypted, scoped (repo, env, org).Environment-specific (production, staging): exigem reviewer approval pra deploy.OIDC com cloud : melhor que long-lived secrets, runner trade GH OIDC token por AWS/GCP/Azure cred temporário. Sem chaves estáticas em GH.External secret stores : Vault, AWS Secrets Manager + External Secrets Operator (em K8s). Em CI, OIDC + secret manager.
Nunca logue secrets. CI mascara automaticamente, mas evite echo $SECRET.
2.8 Branch protection
GitHub Settings:
Require PR review (1+ approvers).
Require status checks (linha verde).
Restrict pushes em main.
Sign commits com GPG/sigstore.
Padrão: nada chega em main sem CI verde + revisão.
2.9 Branching strategies
Trunk-based : feature flags + commit direto em main após review. Releases frequentes.GitHub Flow : branch curta → PR → merge em main → deploy. Simples. Padrão pra maioria.GitFlow : develop, release, hotfix branches. Pesado, projetos com release cadência longa.Release branches : cut N semanas, hotfix vira de volta. Apps mobile com release na store.
Em 2026, trunk-based + feature flags + deploys frequentes é dominante em SaaS. GitFlow ainda em projetos com binários distribuídos.
2.10 Versioning e changelog
SemVer : MAJOR.MINOR.PATCH.CalVer : YYYY.MM.x. Pra apps com release contínuo.Conventional Commits (feat:, fix:, chore:): habilita auto-generation.changesets , semantic-release : bump version + changelog + tag automaticamente.
Pra serviços (não publicados como pkg), versioning ainda importa pra rastreabilidade, tag git por release.
2.11 Deploy strategies
Recreate : down → up. Downtime.Rolling : gradual. Default em K8s. Sem downtime se readiness ok.Blue/Green : dois ambientes; switch traffic. Rollback instantâneo. Custo 2x.Canary : % de tráfego pra versão nova; aumenta se métricas ok.Shadow : tráfego espelhado pra versão nova sem afetar resposta.
Ferramentas: Argo Rollouts , Flagger (K8s). Manual via Service mesh weights ou Ingress canary annotations (Nginx).
2.12 Feature flags
LaunchDarkly , Statsig , Unleash , GrowthBook , Flagsmith .Self-hosted (Unleash, GrowthBook) vs SaaS.
Targeting por user, percent rollout, attribute-based.
Decoupling deploy de release. "Ship dark", ativa quando pronto. Reverter sem redeploy.
Cuidado com tech debt de flags antigas. Monitore staleness.
2.13 Build artifacts e registries
Container images → registry (GHCR, ECR).
Static sites → 04-03/CloudFront, Vercel, Netlify.
npm packages → npm registry (público) ou GitHub Packages.
Docs → GitHub Pages.
Imutabilidade: tag com SHA do commit. Promoção de staging pra prod deve usar mesma image , não rebuild.
2.14 Supply chain security
Dependency scanning : Dependabot, Renovate.Image scanning : Trivy, Docker Scout, Snyk.SBOM (Software Bill of Materials): inventário de tudo que está na imagem. syft gera; CISA promove.Signing : cosign assina images; consumers verificam.SLSA (Supply-chain Levels for Software Artifacts): framework de níveis. SLSA 3+ exige reproducible builds e provenance.OIDC + keyless signing : cosign sem long-lived key.
Em 2026, supply chain virou regulado em algumas jurisdições. SBOM + signing é mainstream.
2.15 Monorepo CI
Monorepo (pnpm workspaces, Turborepo, Nx, Bazel) precisa skipar tarefas em packages não afetados:
Turborepo : hashes de dependency graph; cacheia outputs por hash.Nx : similar com affected:* commands.Bazel : build system mais rigoroso, hermetic, sandbox.
Em CI: detectar mudanças por path (paths-filter) e disparar jobs só pros packages afetados.
2.16 Observability do CI
Pipeline performance:
Tempo total e por step.
Flakiness rate (falha aleatória).
Cache hit rate.
Tempo de fila do runner.
DORA metrics: deployment frequency, lead time, MTTR, change failure rate.
CI lento é dívida de produtividade. < 15 min ideal pra PR; < 5 min pro essencial.
2.17 Self-hosted runners
GitHub free runners (ubuntu-latest) limitados em concorrência e specs. Self-hosted:
VMs próprias (EC2, fly machines).
K8s com actions-runner-controller.
BuildJet, Cirrus pra runners managed mais rápidos.
Self-hosted resolve cost em volume alto e specs específicas (GPUs, builds Mac iOS). Adiciona ops.
2.18 Pipeline pra mobile
iOS:
macOS runner (caro).
Provisioning, certs, code signing.
TestFlight upload via fastlane ou EAS Submit.
Android:
Linux ok.
Keystore (secret), APK/AAB, Play Console upload.
EAS Build (Expo) terceriza tudo.
2.19 Release automation
GoReleaser : pra binários (Go, Rust com plug-in).changesets : monorepo, pkg publish.Release Please (Google): conventional commits → release PR.semantic-release : full automation, opinionated.
3. Threshold de Maestria
Você precisa, sem consultar:
Distinguir CI, Continuous Delivery e Continuous Deployment.
Listar 4 caches que valem em pipeline e estratégia de chave.
Justificar trunk-based vs GitFlow pra contextos diferentes.
Comparar 4 deploy strategies em risco e custo.
Argumentar feature flags vs branch-per-feature.
Explicar OIDC entre GH Actions e AWS, sem long-lived creds.
Diferenciar SBOM e signing e por que ambos importam.
Estratégia pra monorepo CI selectivo.
Definir DORA metrics e por que importam.
Plano pra reduzir pipeline de 25 min pra ≤ 10 min.
4. Desafio de Engenharia
Construir o pipeline CI/CD do Logística v1 , com promoção até produção em K8s.
Especificação
Plataforma :
GitHub Actions.
Monorepo (apps/api, apps/web, apps/mobile, packages/*).
Turborepo ou pnpm filters.
Workflow PR :
Trigger: PR pra main.
Jobs (paralelizar quando possível): install → lint → typecheck → unit → integration (matrix por package afetado).
Cache: pnpm store, Turborepo cache, Playwright browsers.
Skip de package não tocado.
Comment no PR com status e tempo por job.
Workflow main merge :
Trigger: push em main.
Build images (api, web) → push GHCR com tag git-sha + main-latest.
Sign com cosign keyless via OIDC.
Generate SBOM com syft, attach via cosign attest.
Trivy scan; gate em CRITICAL.
Deploy staging :
Após push image, GitOps: Argo CD detecta nova tag em staging chart values.
Smoke test job roda contra staging URL após sync.
Falha → rollback automático (Argo).
Deploy prod :
Manual approval em GitHub Environment "production".
Promote: bump tag em prod values, commit, Argo sync.
Canary via Argo Rollouts: 10% por 5 min → 50% por 5 min → 100%. Métricas observadas (HTTP 5xx rate); abort se violar.
Feature flag :
Integre GrowthBook self-hosted ou SaaS.
Pelo menos 1 feature em rollout gradual (ex: novo dashboard).
Mobile :
Workflow pra app courier: lint, test, EAS Build profile staging em PR; profile production em release tag.
EAS Update pra OTA em hotfix (com restrição: só JS/asset).
Versioning e changelog :
Conventional commits enforced (lint via commitlint pre-commit hook).
Release Please ou changesets gerando changelog em release.
DORA metrics :
Em README, demonstre como você capturaria as 4 métricas (manual ou via lib específica).
Proponha targets realistas pra Logística.
Restrições
Sem secrets long-lived em GH Secrets pra cloud (use OIDC).
Sem latest em deploy prod.
Sem branch local pra pre-prod (use envs como gate).
Sem job > 10 min sem caching strategy explícita.
Threshold
README documenta:
Diagrama do pipeline completo (PR → main → staging → prod).
Tempos de cada step antes e depois de optimization.
Cache hit rate.
Demo de canary deployment com métrica abortando rollout (force erro 500 e mostre).
Demo de feature flag toggling sem redeploy.
Output cosign verify + sbom attest em image.
Stretch
Self-hosted runners em K8s com ARC (actions-runner-controller).
Reproducible builds (mesmo input → mesma image, byte a byte).
SLSA Level 3 provenance attestation.
Bisect automation: script que dispara CI em N commits pra achar quando uma regressão entrou.
Hermetic build via Bazel ou Nix.
5. Extensões e Conexões
Liga com 01-09 (Git): branch protection, signing, conventional commits.
Liga com 03-01 (testes): suite roda em CI; flakiness é problema CI.
Liga com 03-02 (Docker): build, scan, sign, push.
Liga com 03-03 (K8s): GitOps com Argo CD; canary com Argo Rollouts.
Liga com 03-05 (AWS): OIDC GH → AWS, ECR, deploy targets.
Liga com 03-06 (IaC): infra deployed via mesmo pipeline (com gates extras).
Liga com 03-07 (observability): release annotations em Grafana, DORA dashboards.
Liga com 03-08 (security): supply chain, secrets, gating em vulnerabilities.
Liga com 04-08 (services vs monolith): monorepo CI; selective deploy.
Liga com 04-12 (tech leadership): DORA, processo, deployment culture.
6. Referências