Capítulo 40 — DevSecOps e Entrega Contínua

Este capítulo detalha a estratégia de DevSecOps e Entrega Contínua (CI/CD) da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como código, infraestrutura e testes fluem de forma automatizada, segura e con…

40.1 Objetivo do Capítulo

DevSecOps integra segurança em cada etapa do pipeline — não como fase final de verificação. Entrega Contínua (CD) significa que todo commit validado pode ser promovido a produção, reduzindo o tempo entre desenvolvimiento e produção enquanto aumenta a confiabilidade e reduz riscos.

40.2 Papel do DevSecOps na Plataforma

DevSecOps é o mecanismo de confiança da plataforma. Ele garante que:

todo código é revisado antes de merger;
toda mudança é testada automaticamente;
segurança é verificada em cada etapa;
deployments são repetíveis e auditáveis;
rollbacks são automáticos em caso de falha;
credenciais e secrets nunca aparecem em logs ou histórico de Git;
artefatos são assinados e verificáveis.

Desenvolvedor commita código
    │
    ▼
GitHub Action triggered
    │
    ├─ Lint (ESLint, Checkstyle, Clippy)
    ├─ SAST (SonarQube, Semgrep)
    ├─ Dependency check (Snyk, Dependabot)
    ├─ Build (Docker build)
    ├─ Container scan (Trivy)
    ├─ DAST (opcional)
    └─ Push to registry
    │
    ▼
PR aprovada + CI passou
    │
    ▼
Auto-merge para main
    │
    ▼
Tag semântica
    │
    ▼
Release pipeline
    │
    ├─ Staging deployment (Argo CD)
    ├─ Smoke tests
    └─ Aprovação manual
    │
    ▼
Prod deployment (Argo CD)
    │
    ▼
Canary → Progressive rollout

40.3 Princípios de DevSecOps

Segurança antes de velocidade — uma deploy rápida mas insegura é pior que nenhuma deploy;
Automação de controles — se é importante, deve ser verificado automaticamente;
Falha rápido — problemas detectados cedo são mais baratos de corrigir;
Auditoria completa — todo deploy é rastreável a commit, quem aprovaram, quem executou;
Repetibilidade — o mesmo commit sempre produz o mesmo artefato;
Menos acesso manual — reduzir pontos de falha humana;
Observabilidade — pipelines precisam expor métricas de sucesso, falha, duração;
Rollback automático — falha em health check dispara rollback sem intervenção manual.

40.4 Controle de Código-Fonte

40.4.1 Git Workflow

main (sempre deployável)
    │
    ├─ feature/cidadao-registration (branch de feature)
    ├─ fix/critical-bug (branch de correção)
    └─ release/1.2.0 (branch de release)

Main:

Sempre reflete o estado de produção (ou candidato imediato).
Protegido por branch rules: PR obrigatória, CI deve passar, revisão obrigatória.
Commits diretos proibidos.

Feature branches:

Nomes descritivos: feature/cidadao-registration, fix/timeout-issue.
Deletadas após merge.
Nunca vivem mais de 2 semanas (design de pequenas features).

Release branches:

Criadas após feature freeze.
Patches e hotfixes apenas.
Mergeadas simultaneamente para main e staging.

40.4.2 Política de Commit

Commits pequenos e atômicos (uma mudança lógica por commit).
Mensagens descritivas (não "fix bug" — "Fix timeout in citizen request validation").
Referência a issue/ticket (#1234) quando aplicável.
Assinatura GPG em commits (verifikasjon de autoria — opcional em dev, obrigatória em prod).

40.4.3 Política de Pull Request

Um PR = uma feature ou correção isolada.
Descrição explicando o "quê" e o "porquê".
Checklist de verificação (testes locais, sem console.log, sem secrets).
Mínimo de 1 aprovação (configurável por repository).
CI deve passar completamente.
Merge é feito por Squash ou Rebase (não Fast-Forward) para manter histórico limpo.

40.5 Continuous Integration (CI)

40.5.1 Trigger

CI é triggerada por:

Push para feature branch (validação contínua).
Pull Request aberta ou atualizada.
Merge para main (build de release).
Manual trigger (rebuild de commit específico).

40.5.2 Etapas do Pipeline CI

Stage 1 — Checkout & Setup

- Checkout código
- Setup runtime (Node.js, Java, Python)
- Cache de dependências

Stage 2 — Lint & Format

- ESLint / Checkstyle (sintaxe e estilo)
- Prettier (formatação)
- Fail se houver violações

Stage 3 — SAST (Static Analysis)

- SonarQube análise de qualidade
- Semgrep (regras de segurança)
- Falha se security issues críticos

Stage 4 — Dependency Check

- Snyk (vulnerabilidades de dependências)
- Dependabot (CVEs conhecidas)
- Fail se vulnerabilidade crítica

Stage 5 — Build

- Compilar / bundle (maven clean package, npm run build)
- Gerar artefatos
- Registrar hash do build

Stage 6 — Unit & Integration Tests

- Executar suite de testes
- Coverage report (threshold: 80%)
- Fail se cobertura abaixo do threshold
- Registrar tempo de execução

Stage 7 — Container Build

- Docker build (multi-stage)
- Tag com commit SHA short
- Push para staging registry (não para prod ainda)

Stage 8 — Container Scan

- Trivy scanning
- Snyk container analysis
- Fail se vulnerabilidade crítica em imagem

Stage 9 — Notify

- Sucesso: comment no PR
- Falha: notificação ao autor + Slack
- Artefatos linkados

40.5.3 Exemplo: GitHub Actions

name: CI

on:
  push:
    branches: [main, 'feature/**']
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run format:check

  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      - run: npx semgrep --config=p/security-audit

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --coverage
      - uses: codecov/codecov-action@v3

  build:
    needs: [lint, security, test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: docker/setup-buildx-action@v2
      - uses: docker/login-action@v2
        with:
          registry: ${{ secrets.REGISTRY }}
          username: ${{ secrets.REGISTRY_USER }}
          password: ${{ secrets.REGISTRY_PASSWORD }}
      - uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: |
            ${{ secrets.REGISTRY }}/api-solicitacoes:${{ github.sha }}
            ${{ secrets.REGISTRY }}/api-solicitacoes:latest
          cache-from: type=registry
          cache-to: type=inline
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ secrets.REGISTRY }}/api-solicitacoes:${{ github.sha }}
          format: 'sarif'
          output: 'trivy-results.sarif'
      - uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: 'trivy-results.sarif'

40.6 Continuous Delivery (CD) & Deployment

40.6.1 Estratégia de Deployment

A plataforma adota Progressive Delivery com multiple estratégias conforme o risco:

Blue-Green:

Versão atual (Blue) + versão nova (Green) rodam em paralelo.
Switch de tráfego é instantâneo.
Rollback = switch para Blue.
Custo: 2x recursos.

Canary:

Nova versão recebe X% do tráfego (ex: 5%).
Se métricas são saudáveis, aumenta progressivamente.
Se problema detectado, rollback automático.
Menor custo, detecção de problemas reais.

Rolling Update:

Substitute pods um por vez.
Zero downtime.
Mais lento para reverter.

A escolha de estratégia é definida por ADR-701.

40.6.2 Argo CD para GitOps

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-solicitacoes-prod
  namespace: argocd
spec:
  project: platform
  source:
    repoURL: https://git.example.com/platform-gitops
    targetRevision: main
    path: apps/api-solicitacoes/overlays/prod
    plugin:
      name: kustomize-with-secrets
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: false  # Manual approval para prod
    syncOptions:
    - CreateNamespace=false
  revisionHistoryLimit: 10

Argo CD reconcilia Git com cluster. Mudanças em Git são automaticamente deployadas (com aprovação se configurado).

40.6.3 Approval Gates

Feature pronta (CI passou)
    │
    ▼
Merge para main
    │
    ▼
Staging deployment (automático)
    │
    ▼
Tester executa smoke tests
    │
    ▼
Aprovação manual no Argo CD ou GitHub
    │
    ▼
Prod deployment (canary 5%)
    │
    ▼
Monitorar por 30 minutos
    │
    ▼
    ├─ Métricas OK → rollout 100%
    └─ Anomalia detectada → rollback automático

40.7 Secrets Management

40.7.1 Princípios

Nenhum secret em Git (nem .env, nem configurações).
Secrets rotacionados periodicamente.
Cada ambiente tem secrets próprios.
Acesso a secrets auditado.
Fallback seguro quando secret indisponível.

40.7.2 External Secrets Operator

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets
  namespace: prod
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: api-solicitacoes-secrets
  namespace: prod
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets
    kind: SecretStore
  target:
    name: api-solicitacoes-env
    creationPolicy: Owner
  data:
  - secretKey: DB_PASSWORD
    remoteRef:
      key: prod/db/password
  - secretKey: API_KEY
    remoteRef:
      key: prod/external-api/key

External Secrets sincroniza secrets de AWS Secrets Manager, Vault, ou similar para Kubernetes Secrets sem expor valores em manifests.

40.7.3 Rotação de Secrets

Cron job diário
  │
  ├─ Gerar novo secret
  ├─ Armazenar em Secrets Manager
  ├─ Trigger External Secrets sync
  ├─ Validar nova credencial
  ├─ Revogar credencial antiga
  └─ Registrar em auditoria

40.8 Observabilidade do Pipeline

40.8.1 Métricas Críticas

Frequência de Deploy: deploys por dia (meta: 1-3).
Lead Time: tempo de commit a produção (meta: <4 horas).
Deployment Success Rate: % de deploys sem incident (meta: >95%).
MTTR (Mean Time To Recovery): tempo médio para rollback/fix (meta: <15 min).
Change Failure Rate: % de mudanças que resultam em incident (meta: <15%).

40.8.2 Dashboards

[Frequency] [Lead Time] [Success Rate]
[MTTR] [Change Failure Rate]

Recent Deployments:
1. api-solicitacoes 1.2.3 → Prod (2026-07-16 14:30 UTC) ✓
2. frontend-portal 2.1.0 → Prod (2026-07-16 13:45 UTC) ✓
3. auth-service 0.8.5 → Prod (2026-07-16 12:00 UTC) ✓

Pipeline Duration:
- api-solicitacoes: 15 min (checkout: 1m, lint: 2m, test: 8m, build: 4m)

40.8.3 Alertas

Pipeline failure: notificação imediata ao #incidents Slack.
Deployment delay: se pending > 30 min, notificação ao on-call.
High change failure rate: relatório semanal ao tech lead.

40.9 Runbooks de Operação

40.9.1 Incident: Deploy falhou em Prod

1. Argo CD detecta erro de health check
2. Rollback automático para versão anterior
3. Notificação enviada: #incidents, on-call, autor do change
4. On-call investiga:
   - kubectl logs -f deployment/api-solicitacoes
   - Conferir métricas em Prometheus
   - Conferir alteração recente em Git
5. Se bug simples: fix + revert de mudança ruim + novo deploy
6. Se problema maior: create incident ticket, escalate

40.9.2 Manual Rollback

# Via Argo CD UI ou CLI
argocd app rollback api-solicitacoes-prod <revision>

# Versões anteriores
argocd app history api-solicitacoes-prod

# Confirmação
argocd app get api-solicitacoes-prod

40.9.3 Emergency Deploy (Hotfix)

Hotfix branch criado de main
  │
  ├─ Fix implementado
  ├─ CI pipeline executa (tests, scan, build)
  ├─ PR revisada + aprovada URGENTE (mesmo em horário noturno)
  ├─ Merge para main
  ├─ Tag hotfix criada (ex: v1.2.1)
  ├─ Argo CD sincroniza automaticamente
  └─ Canary deployment com acompanhamento reforçado

40.10 Rastreabilidade com o Anexo III

Item ANX-III	Atendimento
6.1	CI/CD pipeline implementa entrega segura e confiável
6.2	Controle de acesso ao pipeline e aprovações formais
6.3	Auditoria completa de deployments e mudanças

40.11 Benefícios do DevSecOps

deployments frequentes reduzem risco de cada mudança;
automação elimina erros manuais;
detecção cedo de problemas reduz custo de correção;
auditoria completa suporta conformidade;
rollback automático reduz tempo de indisponibilidade;
feedback rápido acelera aprendizado do time.

40.12 Riscos e Mitigações

Risco	Mitigação
Secret em Git	Pre-commit hooks, scanning de repositório
Bypass de aprovação	Branch rules, CODEOWNERS
Falha silenciosa de test	Threshold de coverage obrigatório
Deployment em produção sem testes	Staging deployment obrigatório
Rollback manual lento	Rollback automático por health check

40.13 Decisões Arquiteturais

ADR	Tema
ADR-701	Estratégia de deployment (canary vs. blue-green)
ADR-702	GitOps com Argo CD vs. alternativas
ADR-703	Secrets manager (AWS Secrets vs. Vault)
ADR-704	Frequência de CI triggers
ADR-705	Threshold de code coverage e security scan

40.14 Próximo Capítulo

O Capítulo 41 detalha a Observabilidade e Monitoramento, completando a PARTE V — Tecnologia.

40.15 Controle de Versão

Campo	Valor
Documento	Documento Mestre — Plataforma de Relacionamento Digital com o Cidadão
Capítulo	40 — DevSecOps e Entrega Contínua
Versão	1.0
Situação	Concluído
Última atualização	16/07/2026

40.16 Rastreabilidade PRODEMGE

[ANX-III] Bloco 6 — Segurança: itens 6.1, 6.2, 6.3 cobertos conforme seção 40.10.
[ANX-IV] — Capacidades técnicas de CI/CD, automação, segurança no pipeline.
[ANX-V] Item 2.1 — Manutenibilidade: pipeline como código, versionado em Git, reproducível.
[PNR] — Plano de Negócio: entrega rápida e confiável de funcionalidades.
[EDITAL] — Edital CP001/2026: DevSecOps integrado desde o design.

Capítulo 40 — DevSecOps e Entrega Contínua

Nesta página