Capítulo 58 — Gestão de Configuração e Custódia de Código

58.1 Objetivo do Capítulo

Este capítulo descreve como o código-fonte, os artefatos de build, as configurações de ambiente, a infraestrutura como código e os contratos de API da Plataforma de Relacionamento Digital com o Cidadão são versionados, rastreados, custodiados e disponibilizados à PRODEMGE ao longo dos sessenta meses de parceria.

A gestão de configuração é a fundação técnica sobre a qual repousa toda a cadeia de rastreabilidade da plataforma. Sem ela, não há como garantir que o código sob custódia da PRODEMGE corresponde ao que está em produção, que artefatos de ambiente podem ser reconstruídos de forma determinística, ou que mudanças em produção são auditáveis por commit, por autor e por decisão.

O capítulo também operacionaliza as diretrizes do item 5.6 do Plano de Negócio Referencial — que atribui à PRODEMGE a responsabilidade pela custódia do código-fonte da solução desenvolvida no âmbito da parceria — e o protocolo vinculado ao deploy descrito no ADR-5604 do Capítulo 56, que bloqueia releases em produção enquanto a etapa de custódia não for concluída.

58.2 Contexto

A plataforma é desenvolvida em modelo de evolução contínua: múltiplas squads, múltiplos repositórios, múltiplos ambientes simultâneos (development, integration, homologation, production) e dezenas de releases ao longo de cada ano de vigência contratual.

Nesse contexto, a gestão de configuração cumpre três funções simultâneas e interdependentes.

A primeira é a função operacional: garantir que qualquer versão da plataforma possa ser reconstruída, reimplantada ou auditada a partir dos artefatos sob controle de versão — código-fonte, manifesto de dependências, configuração de infraestrutura, valores de ambiente, contratos de API.

A segunda é a função de conformidade: garantir que a PRODEMGE detenha, a qualquer momento, a última versão homologada do código-fonte desenvolvido no âmbito da parceria, em repositório seguro e controlado, com acesso restrito e auditável — conforme os itens 5.6.1 e 5.6.2 do Plano de Negócio Referencial.

A terceira é a função de soberania: garantir que, em cenários de rescisão contratual, descontinuidade operacional ou eventos extraordinários, a PRODEMGE mantenha capacidade de evoluir, manter e suportar tecnicamente os componentes de propriedade intelectual conjunta, sem dependência da Parceira para a continuidade da oferta — conforme o item 5.6.6 do Plano de Negócio Referencial.

58.3 Escopo

Este capítulo cobre:

• modelo de organização e nomenclatura de repositórios;
• estratégia de branching e política de commits;
• versionamento semântico e rastreabilidade de releases;
• gestão de configuração de ambiente e secrets;
• infraestrutura como código (IaC) — versionamento e controle de mudanças;
• gestão de dependências — inventário, SBOM e compliance de licenças;
• protocolo de custódia de código-fonte para a PRODEMGE;
• empacotamento e preparação de release para produção;
• gestão de Configuration Items (CIs) e CMDB simplificado;
• rastreabilidade entre commit, artefato, release e deploy;
• ADRs de configuração.

Não estão no escopo deste capítulo: o pipeline de CI/CD (Capítulo 40), a estratégia de containers e imagens (Capítulo 39), o processo de gestão de mudanças em produção (Capítulo 59), nem os protocolos de backup e recuperação (Capítulo 47).

58.4 Princípios da Gestão de Configuração

A gestão de configuração da plataforma é orientada por oito princípios que guiam todas as decisões práticas descritas neste capítulo.

Tudo em código. Toda configuração relevante — da aplicação, da infraestrutura, dos ambientes, das pipelines — é descrita em código versionado em repositório Git. Configurações que existem apenas em telas de console, arquivos locais ou memória de operadores não são configurações gerenciadas: são riscos operacionais.

Um único source of truth. O repositório Git é a fonte de verdade para o estado de qualquer componente. O que está em Git é o que deve estar rodando. Divergências entre o repositório e o ambiente de produção são erros a corrigir, não variações a tolerar.

Rastreabilidade de ponta a ponta. Cada artefato em produção deve ser rastreável ao commit que o originou, ao pull request que o revisou, ao autor que o aprovou e ao deploy que o levou ao ambiente. Essa rastreabilidade é pré-condição para auditoria, conformidade contratual e resposta a incidentes.

Imutabilidade de artefatos. Uma imagem de container publicada no registry não é modificada. Um artefato de build não é alterado após a publicação. Se uma correção é necessária, um novo artefato é produzido a partir de um novo commit. Artefatos mutáveis invalidam a rastreabilidade.

Separação entre código e configuração de ambiente. O código da aplicação é separado dos valores de configuração específicos de cada ambiente (URLs, credenciais, feature flags, limites de recursos). A mesma imagem de container é promovida de integration a homologation a production com configurações diferentes, nunca reconstruída por ambiente.

Secrets nunca em repositório. Credenciais, tokens, certificados e demais segredos nunca são commitados em repositório — nem em branches privadas, nem em histórico que pode ser expurgado. Segredos são gerenciados exclusivamente por cofre de segredos com acesso auditável e rotação automatizada.

Custódia como etapa de pipeline. A submissão do código-fonte à PRODEMGE não é uma atividade manual pós-release — é uma etapa obrigatória do pipeline de deploy em produção. O pipeline bloqueia a promoção ao ambiente produtivo enquanto a custódia não for concluída com sucesso e confirmada.

Documentação como artefato de configuração. Contratos de API (OpenAPI), contratos de eventos (AsyncAPI), Decision Records (ADRs) e runbooks são artefatos de configuração sob controle de versão com a mesma disciplina que o código. Documentação desatualizada é documentação incorreta.

58.5 Organização de Repositórios

58.5.1 Topologia de Repositórios

A plataforma é organizada em múltiplos repositórios Git hospedados em organização centralizada, com controle de acesso por equipe e por repositório. A topologia segue o padrão de repositórios por domínio, com separação clara entre código de aplicação, infraestrutura, configuração de ambiente e documentação.

org/plataforma-cidadao/
│
├── apps/                          # Código de aplicação por serviço
│   ├── api-gateway/
│   ├── svc-crm/
│   ├── svc-bpm/
│   ├── svc-ecm/
│   ├── svc-omnichannel/
│   ├── svc-agendamentos/
│   ├── svc-ouvidoria/
│   ├── svc-ia-gateway/
│   ├── svc-notificacoes/
│   ├── portal-web/
│   └── app-mobile/
│
├── infra/                         # Infraestrutura como Código
│   ├── terraform/
│   │   ├── modules/
│   │   └── envs/
│   │       ├── integration/
│   │       ├── homologation/
│   │       └── production/
│   └── helm/
│       ├── charts/
│       └── values/
│
├── config/                        # Configuração de ambiente (sem secrets)
│   ├── integration/
│   ├── homologation/
│   └── production/
│
├── contracts/                     # Contratos de API e eventos
│   ├── openapi/
│   └── asyncapi/
│
├── platform-docs/                 # Documentação técnica versionada
│   ├── adrs/
│   ├── runbooks/
│   └── architecture/
│
└── custody/                       # Repositório de custódia (PRODEMGE)
    └── [gerenciado pela PRODEMGE]

58.5.2 Repositório de Custódia

O repositório custody é gerenciado diretamente pela PRODEMGE em sua infraestrutura controlada. A Parceira não tem acesso de escrita a esse repositório após a submissão do pacote de custódia. A PRODEMGE mantém controle exclusivo de acesso, integridade e auditoria do acervo custodiado.

58.5.3 Nomenclatura e Padrões

Todos os repositórios seguem convenções de nomenclatura padronizadas:

• serviços de backend: svc-{dominio} (ex.: svc-crm, svc-bpm);
• frontends: portal-web, app-mobile;
• módulos de infraestrutura: infra/{tecnologia} (ex.: infra/terraform, infra/helm);
• repositórios de configuração: config/{ambiente};
• contratos: contracts/{tipo} (ex.: contracts/openapi).

Repositórios sem padrão de nomenclatura não são aceitos na organização. Novos repositórios requerem aprovação do Arquiteto Técnico e registro no inventário de repositórios.

58.6 Estratégia de Branching

58.6.1 Modelo de Branch

A plataforma adota Trunk-Based Development com branches de feature de vida curta, complementado por branches de release para gestão de versões em produção.

main (trunk — sempre em estado potencialmente deployável)
│
├── feature/TICKET-ID-descricao-curta    (máx. 5 dias de vida)
├── fix/TICKET-ID-descricao-curta
├── hotfix/TICKET-ID-descricao-curta     (máx. 24 horas de vida)
│
└── release/v{MAJOR}.{MINOR}            (branch de release — somente patches)

Main (trunk): representa o estado atual do desenvolvimento. Todos os commits em main devem ser potencialmente promovíveis a produção — a qualidade é garantida pelo pipeline de CI que bloqueia merges com falha. Commits diretos em main são bloqueados tecnicamente por branch protection rules.

Feature branches: criadas a partir de main para cada item de backlog. Vivem no máximo cinco dias úteis — itens maiores são decompostos em histórias menores integráveis com feature flags. Deletadas após merge aprovado.

Fix branches: mesma política das feature branches, para correções de bugs não emergenciais.

Hotfix branches: criadas a partir da branch de release correspondente ao ambiente em produção para correções emergenciais. Têm vida máxima de 24 horas. São mergeadas simultaneamente para a branch de release e para main.

Release branches: criadas no momento do feature freeze de cada release minor ou major. Recebem apenas patches e hotfixes. São a fonte dos pacotes de custódia enviados à PRODEMGE.

58.6.2 Branch Protection

Regras de proteção aplicadas à branch main e às branches release/*:

58.6.3 Política de Commit

• commits são atômicos: uma mudança lógica por commit;
• mensagens seguem o padrão Conventional Commits: tipo(escopo): descrição (ex.: feat(crm): adicionar filtro por CPF na listagem de solicitações);
• referência a ticket obrigatória para feature branches: feat(bpm): adicionar step de validação #TICKET-1234;
• commits de WIP (work in progress) são permitidos em feature branches mas devem ser consolidados por squash antes do merge para main;
• assinatura GPG é obrigatória para todos os commits que chegam a main via merge de release branch.

58.7 Versionamento Semântico

58.7.1 Esquema de Versão

A plataforma adota Semantic Versioning 2.0.0 (semver.org) para todos os componentes: MAJOR.MINOR.PATCH[-PRE_RELEASE][+BUILD_METADATA].

Exemplos: 2.5.0, 2.5.1-rc.1, 2.5.1+a1b2c3d, 3.0.0-beta.2.

58.7.2 Tags Git

Cada release é marcado com tag semântica assinada (signed tag GPG) no repositório correspondente:

# Criar tag assinada
git tag -s v2.5.0 -m "Release v2.5.0 — Novo módulo de agendamentos

Changelog:
- feat(agendamentos): criação de agenda por serviço e por localidade
- feat(agendamentos): confirmação automática via WhatsApp
- fix(crm): correção de paginação em listagens com filtro ativo
- chore(deps): atualização do Spring Boot para 3.3.1

Custódia: pacote submetido à PRODEMGE em 2026-07-17T14:30:00Z
Pipeline: https://ci.example.com/runs/4821
"

# Verificar assinatura
git verify-tag v2.5.0

Tags assinadas fornecem garantia criptográfica de que a versão não foi alterada após a sua criação — evidência auditável relevante tanto para a PRODEMGE quanto para auditorias de segurança.

58.7.3 Versão dos Contratos de API

Contratos de API seguem versionamento independente do código de aplicação, mas rastreável a ele. Arquivos OpenAPI incluem campo info.version com semver, e o histórico de mudanças é mantido em CHANGELOG.md por contrato.

Mudanças de MAJOR em contrato de API geram notificação obrigatória aos tenants com antecedência mínima definida no Capítulo 55, conforme a tabela de comunicação de descontinuação.

58.8 Gestão de Configuração de Ambiente

58.8.1 Separação de Código e Configuração

Seguindo o princípio da Twelve-Factor App, configurações específicas de ambiente — URLs de serviços dependentes, limites de rate, parâmetros de feature flags, valores de timeout — são externalizadas do código e injetadas como variáveis de ambiente em tempo de execução.

O repositório config/ armazena, por ambiente, os arquivos de configuração não-sensíveis em formato YAML estruturado, versionados e revisáveis por pull request como qualquer outro código.

# config/production/svc-crm.yaml
service:
  name: svc-crm
  version: "2.5.0"

database:
  pool_min: 5
  pool_max: 20
  connection_timeout_ms: 5000

cache:
  ttl_solicitacoes_seconds: 300
  ttl_cidadao_profile_seconds: 600

rate_limiting:
  requests_per_minute_per_tenant: 1000
  requests_per_minute_global: 50000

feature_flags:
  novo_fluxo_agendamento: true
  assistente_ia_v2: false
  relatorio_consolidado: true

58.8.2 Gestão de Secrets

Secrets — senhas de banco, tokens de API, certificados, chaves de criptografia — nunca residem em repositório Git. São gerenciados exclusivamente por cofre de segredos (HashiCorp Vault ou equivalente aprovado pela PRODEMGE), com as seguintes garantias:

• acesso por identidade de workload (Kubernetes Service Account), não por credencial humana em tempo de runtime;
• rotação automática configurada por tipo de secret e política de segurança;
• auditoria completa de cada acesso: quem acessou, quando, qual secret, qual versão;
• secrets entregues aos containers via External Secrets Operator, sem materialização em arquivos versionados;
• alertas de expiração iminente e falha de rotação.

O inventário de secrets é mantido como metadado (nome, tipo, política de rotação, responsável) — sem os valores — em repositório de configuração da PRODEMGE com acesso controlado.

58.8.3 Feature Flags

Feature flags são gerenciadas como configuração de ambiente, não como código compilado. Isso permite ativar ou desativar funcionalidades em produção sem novo deploy — recurso crítico para rollout gradual por tenant, A/B testing e rollback rápido de funcionalidades com problema.

O estado de cada feature flag é:

• versionado no repositório config/ por ambiente;
• auditável — mudanças de feature flag em produção são registradas com autor e motivo;
• rastreável ao ticket de backlog que originou a funcionalidade correspondente.

Flags de longa duração (mais de dois ciclos sem remoção) são tratadas como dívida técnica e priorizadas para remoção no backlog de evolução.

58.9 Infraestrutura como Código

58.9.1 Terraform para Infraestrutura de Nuvem

Toda infraestrutura de nuvem é provisionada exclusivamente via Terraform, sem recursos criados manualmente no console do provedor. O diretório infra/terraform/ organiza os módulos e os estados por ambiente:

infra/terraform/
├── modules/
│   ├── tenant/           # Módulo de provisionamento de tenant
│   ├── kubernetes/       # Configuração de cluster Kubernetes
│   ├── database/         # Provisioning de banco PostgreSQL
│   ├── network/          # VPC, subnets, security groups
│   └── observability/    # Stack de observabilidade por ambiente
│
└── envs/
    ├── integration/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── terraform.tfvars    # Valores não-sensíveis
    ├── homologation/
    └── production/
        ├── main.tf
        ├── variables.tf
        └── terraform.tfvars

O estado do Terraform (terraform.tfstate) é armazenado em backend remoto criptografado com locking distribuído, nunca em repositório Git. Mudanças de infraestrutura seguem o mesmo fluxo de pull request que mudanças de código: terraform plan é executado automaticamente no CI e o diff é revisado antes da aprovação.

58.9.2 Helm para Configuração de Workloads Kubernetes

Workloads Kubernetes são gerenciados via Helm charts versionados no diretório infra/helm/. A separação entre chart (template) e values (valores por ambiente) garante que o mesmo template é reutilizado em todos os ambientes com configuração específica por contexto.

infra/helm/
├── charts/
│   ├── svc-crm/
│   │   ├── Chart.yaml          # versão do chart
│   │   ├── templates/
│   │   └── values.yaml         # valores default
│   └── ...
│
└── values/
    ├── integration/
    │   └── svc-crm.yaml        # overrides para integration
    ├── homologation/
    └── production/
        └── svc-crm.yaml        # overrides para production

58.9.3 GitOps com Argo CD

A sincronização entre o estado declarado no repositório e o estado efetivo nos clusters Kubernetes é gerenciada pelo Argo CD (conforme descrito no Capítulo 40). A ferramenta monitora continuamente o repositório e aplica automaticamente mudanças aprovadas — eliminando a necessidade de intervenção manual em deploys regulares e tornando o histórico Git a única fonte de verdade sobre o que foi implantado e quando.

Mudanças aplicadas manualmente nos clusters (kubectl apply sem passagem pelo pipeline) são detectadas como drift e sinalizadas ao time de operação como incidente de conformidade de configuração.

58.10 Gestão de Dependências

58.10.1 Inventário de Dependências

Cada repositório de aplicação mantém manifesto de dependências explícito e versionado:

Versões de dependências são sempre pinadas explicitamente. Ranges abertos (>=, ^, ~) são permitidos apenas em arquivo de manifesto, mas não no arquivo de lock — o lock sempre contém a versão exata resolvida.

58.10.2 Software Bill of Materials (SBOM)

O pipeline de build gera automaticamente um SBOM no formato CycloneDX para cada artefato publicado. O SBOM inclui:

• todas as dependências diretas e transitivas com versões exatas;
• identificadores de pacote (PURL — Package URL) para rastreabilidade em bases de CVE;
• licenças identificadas por dependência;
• hash de verificação de cada componente.

O SBOM é armazenado junto ao artefato no registry de containers e incluído no pacote de custódia enviado à PRODEMGE a cada release. Isso permite à PRODEMGE, de forma independente, auditar a composição de qualquer versão da plataforma — incluindo a identificação de vulnerabilidades descobertas após o release em componentes incluídos na versão custodiada.

58.10.3 Compliance de Licenças

O pipeline de CI verifica automaticamente a compatibilidade de licenças de todas as dependências com os termos do projeto. Dependências com licenças incompatíveis (ex.: GPL em contexto proprietário, licenças com restrições de uso governamental) bloqueam o pipeline e requerem avaliação do Arquiteto Técnico antes de prosseguir.

O relatório de licenças é produzido por release e incluído no pacote de custódia, complementando o inventário de dependências exigido pelo item 5.6 do Plano de Negócio Referencial para viabilizar o empacotamento pela PRODEMGE.

58.10.4 Gestão de Vulnerabilidades em Dependências

Vulnerabilidades em dependências são detectadas continuamente por três mecanismos:

• SCA no pipeline CI (Snyk, OWASP Dependency Check): a cada pull request e a cada merge em main;
• Scanning de imagem de container (Trivy, Grype): a cada build de imagem;
• Monitoramento de boletins (GitHub Dependabot, NVD, CISA KEV): em tempo contínuo, com alertas automáticos quando nova CVE afeta dependência em uso.

O processo de remediação segue os prazos definidos no Capítulo 51 (Operação e Gestão de Serviços) conforme a severidade CVSS da vulnerabilidade.

58.11 Rastreabilidade de Releases

58.11.1 Cadeia de Rastreabilidade

Cada artefato em produção é rastreável de forma determinística através da seguinte cadeia:

Ticket de Backlog (TICKET-ID)
    │
    └── Pull Request (PR #N — commit SHA)
            │
            └── Pipeline CI (run ID — status, testes, scans)
                    │
                    └── Artefato de Build (imagem Docker — tag semântica + SHA)
                            │
                            └── Manifesto Kubernetes (Argo CD revision)
                                    │
                                    └── Deploy em Produção (timestamp, operador)
                                            │
                                            └── Change Request (CR-ID — aprovação CAB)
                                                    │
                                                    └── Pacote de Custódia (hash SHA-256 — PRODEMGE)

Essa cadeia é mantida pelo conjunto de ferramentas: sistema de tickets (Jira ou equivalente), Git, GitHub Actions (pipeline CI), registry de containers, Argo CD (GitOps) e o sistema de gestão de mudanças.

58.11.2 Release Notes Técnicos

Para cada release, além dos release notes funcionais descritos no Capítulo 55, são produzidos release notes técnicos destinados à PRODEMGE e ao time de operação:

• versão semântica e hash do commit de corte (tag SHA);
• lista de pull requests incluídos no release com link e título;
• componentes modificados com identificação de módulo e serviço;
• dependências atualizadas (adicionadas, atualizadas ou removidas);
• mudanças de infraestrutura incluídas (se houver);
• mudanças de configuração requeridas no deploy;
• procedimento de rollback específico para o release;
• link para o SBOM gerado;
• hash SHA-256 do pacote de custódia enviado à PRODEMGE.

Os release notes técnicos são gerados parcialmente de forma automatizada a partir do histórico de commits e do diff de dependências, com complementação manual pelo Tech Lead.

58.11.3 Registro de Configuração em Produção

O estado de configuração vigente em produção é registrado como artefato versionado após cada deploy bem-sucedido:

# production-state/2026-07-17T14:30:00Z.yaml
timestamp: "2026-07-17T14:30:00Z"
release_version: "2.5.0"
commit_sha: "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8"
deployed_by: "pipeline/release-2.5.0"
approved_by: ["tech.lead@parceira.com.br", "gestor.tecnico@prodemge.gov.br"]
change_request: "CR-2026-0847"

services:
  svc-crm:
    image: "registry.example.com/svc-crm:2.5.0"
    image_digest: "sha256:..."
    config_version: "production/svc-crm@a1b2c3d"
  svc-bpm:
    image: "registry.example.com/svc-bpm:2.4.3"
    image_digest: "sha256:..."
    config_version: "production/svc-bpm@b2c3d4e"
  # ... demais serviços

infrastructure:
  terraform_workspace: "production"
  terraform_state_version: "serial:142"
  helm_release_revisions:
    svc-crm: 47
    svc-bpm: 31

custody:
  package_hash: "sha256:..."
  submitted_at: "2026-07-17T14:25:00Z"
  confirmed_by: "prodemge-custody-system"

Esse artefato é commitado no repositório de configuração e serve como evidência auditável do estado de produção em qualquer ponto no tempo.

58.12 Protocolo de Custódia de Código-Fonte

58.12.1 Escopo da Custódia

Conforme o item 5.6 do Plano de Negócio Referencial e a Cláusula 11.2 da Minuta de Contrato, o acervo sob custódia da PRODEMGE compreende os componentes de propriedade intelectual conjunta — customizações, integrações, módulos e funcionalidades desenvolvidos especificamente no âmbito da parceria.

O acervo não compreende:

• componentes pré-existentes da Parceira que constituem sua plataforma-base, cujos direitos de propriedade intelectual permanecem exclusivamente da Parceira;
• dependências de terceiros licenciadas, que permanecem regidas por seus termos de licenciamento próprios;
• código de infraestrutura de cloud providers (providers Terraform do provedor), que é documentado por referência de versão, não incluído diretamente.

O inventário de ativos pré-existentes, produzido no momento da assinatura do contrato conforme o ADR-5605 do Capítulo 56, é o documento que delimita formalmente a fronteira entre o que é pré-existente e o que é PI conjunta.

58.12.2 Conteúdo do Pacote de Custódia

Cada pacote de custódia entregue à PRODEMGE por release homologado inclui:

58.12.3 Processo de Submissão

O processo de submissão do pacote de custódia é etapa obrigatória do pipeline de release, executada automaticamente antes do deploy em produção:

Release branch congelada (feature freeze)
    │
    ├── Build final de todos os componentes PI conjunta
    │
    ├── Coleta de artefatos: código-fonte + SBOM + contratos + docs
    │
    ├── Geração do MANIFEST.json com hashes SHA-256
    │
    ├── Criptografia e assinatura do pacote
    │   (chave pública da PRODEMGE)
    │
    ├── Transmissão para repositório de custódia da PRODEMGE
    │   (canal seguro, protocolo autenticado)
    │
    ├── Confirmação de recebimento e integridade
    │   (hash do pacote confirmado pela PRODEMGE)
    │
    ├── Registro de custódia no production-state (Seção 58.11.3)
    │
    └── Pipeline desbloqueado para deploy em produção
         (sem confirmação → pipeline bloqueado)

O bloqueio do pipeline enquanto a custódia não é confirmada é o mecanismo técnico que garante a observância do ADR-5604 — nenhum release pode atingir produção sem que a PRODEMGE tenha recebido e confirmado o pacote correspondente.

58.12.4 Frequência e Periodicidade

A frequência de submissão de pacotes de custódia é determinada pela cadência de releases em produção:

Para hotfixes emergenciais em que o prazo de submissão em ciclo normal não é viável, a Parceira submete o pacote em até duas horas após o deploy em produção, com registro formal no sistema de gestão de mudanças. O pacote de custódia do hotfix é revisado pela PRODEMGE na próxima janela de operação.

58.12.5 Infraestrutura de Custódia da PRODEMGE

A PRODEMGE é responsável pela infraestrutura do repositório de custódia, que observa as seguintes características:

Segurança: acesso restrito a servidores e usuários autorizados da PRODEMGE com autenticação multifator. Logs de acesso completos com rastreabilidade de cada operação de leitura, escrita ou deleção.

Integridade: verificação automática de integridade dos pacotes recebidos por hash SHA-256. Alertas para qualquer divergência entre hash informado pela Parceira e hash verificado no recebimento.

Disponibilidade: o repositório de custódia é mantido com alta disponibilidade e backup regular. A perda do acervo de custódia é tratada como incidente crítico pela PRODEMGE.

Imutabilidade: pacotes de custódia uma vez aceitos não são modificados ou sobrescritos. Versões corrigidas são adicionadas como novos pacotes com referência à versão anterior que substituem.

Retenção: o acervo de custódia é mantido pelo período de vigência do contrato acrescido de no mínimo cinco anos, conforme políticas de retenção de documentos da PRODEMGE.

58.12.6 Proteção da Plataforma-Base

A custódia do código-fonte não se estende à plataforma-base pré-existente da Parceira. Conforme o item 56.10.4 do Capítulo 56, a PRODEMGE reconhece que o licenciamento, a exploração comercial e a remuneração correspondente à plataforma pré-existente permanecem regidos pelas condições definidas pela Parceira.

Em caso de rescisão contratual ou eventos extraordinários, a PRODEMGE manterá, por meio do acervo sob custódia, a capacidade de evoluir, manter e suportar os componentes de PI conjunta. A continuidade de operação dos componentes que dependem da plataforma-base será disciplinada por cláusulas contratuais específicas de transição — incluindo o aviso prévio mínimo de doze meses previsto no item 5.4 do Plano de Negócio Referencial.

58.13 Empacotamento para Produção

58.13.1 Responsabilidade de Empacotamento

Conforme o item 5.6.4 do Plano de Negócio Referencial, os procedimentos de empacotamento e preparação da versão final para publicação em ambiente produtivo — o processo técnico de transformação e compilação do software — são realizados exclusivamente pela PRODEMGE, sob protocolos de segurança, auditoria e conformidade previamente definidos.

Esse modelo garante:

• que todos os componentes da aplicação são reunidos de forma íntegra, testada e segura antes de serem disponibilizados em produção;
• rastreabilidade completa do processo de build final;
• redução de riscos operacionais pela execução em ambiente controlado da PRODEMGE;
• aderência às normas de segurança da informação exigidas na Administração Pública.

58.13.2 Processo de Empacotamento pela PRODEMGE

A Parceira documenta e disponibiliza à PRODEMGE as instruções técnicas detalhadas de empacotamento, atualizadas a cada release que modifique o processo. As instruções incluem:

• requisitos de ambiente de build (versões de JDK, Node.js, ferramentas de build);
• sequência de comandos de build por componente;
• variáveis de ambiente e configurações necessárias para o build;
• procedimento de verificação de integridade do artefato gerado;
• procedimento de assinatura digital do artefato final;
• procedimento de publicação no registry de produção da PRODEMGE;
• checklist de validação pré-publicação.

58.13.3 Testes de Segurança Antes da Publicação

Conforme o item 5.6.2 do Plano de Negócio Referencial, o código-fonte é submetido a testes de segurança especializados pela Parceira antes da publicação em produção — testes que integram o pipeline de CI/CD (SAST, SCA, container scanning, DAST) e são evidenciados nos artefatos do pipeline incluídos no pacote de custódia.

A PRODEMGE pode, adicionalmente, realizar seus próprios testes de segurança sobre o pacote custodiado antes do empacotamento final, conforme seus protocolos de segurança da informação.

58.14 CMDB — Inventário de Configuration Items

58.14.1 Escopo do CMDB

A plataforma mantém um Configuration Management Database (CMDB) simplificado que rastreia os Configuration Items (CIs) relevantes para a operação e para a custódia. O CMDB não é uma ferramenta ITSM completa — é um inventário estruturado e versionado mantido no repositório de configuração, atualizado automaticamente pelo pipeline de deploy.

58.14.2 Categorias de Configuration Items

58.14.3 Consulta e Auditoria do CMDB

O CMDB é acessível à PRODEMGE via painel de administração com permissões de leitura. Mudanças em CIs são auditáveis pelo histórico Git do repositório de configuração — cada alteração tem autor, timestamp e motivo registrados.

A PRODEMGE pode solicitar, a qualquer momento, um relatório snapshot do estado de todos os CIs em produção. O relatório é gerado automaticamente pelo sistema em formato estruturado (JSON ou CSV) e assinado digitalmente.

58.15 Controle de Mudanças de Configuração

58.15.1 Mudanças de Configuração como Mudanças de Sistema

Toda mudança em arquivo de configuração versionado (valores de ambiente, manifesto Kubernetes, módulo Terraform) é tratada como mudança técnica e segue o processo descrito no Capítulo 59 — com classificação de risco, aprovação correspondente e janela de execução.

Mudanças de configuração não passam pelo mesmo processo de build de código, mas passam obrigatoriamente pelo mesmo processo de revisão (pull request) e são auditadas com o mesmo rigor.

58.15.2 Mudanças de Feature Flag em Produção

Mudanças de feature flag em produção são um caso especial: têm impacto imediato em produção sem necessidade de novo deploy, mas com risco de alterar comportamento perceptível pelos usuários. Por isso, seguem um processo simplificado mas formal:

• abertura de ticket descrevendo a mudança e o motivo;
• aprovação do Tech Lead e do Gestor Técnico da PRODEMGE;
• execução registrada no sistema de gestão de mudanças;
• monitoramento intensivo nas primeiras duas horas após a mudança;
• registro da alteração no CMDB e no repositório config/.

58.15.3 Drift de Configuração

Divergências entre o estado declarado no repositório e o estado efetivo nos ambientes (configuration drift) são detectadas automaticamente:

• Argo CD detecta drift em manifesto Kubernetes e alerta o time de operação;
• Terraform drift detection verifica diariamente a consistência do estado provisionado com o código IaC;
• alertas de drift são tratados como incidentes de conformidade de configuração — não como anomalias operacionais opcionais.

Todo drift detectado tem um responsável, um prazo de remediação e um registro de encerramento. Drift persistente por mais de 24 horas em produção é escalado ao Comitê de Gestão da Parceria.

58.16 Rastreabilidade com o Chamamento Público

58.17 Riscos e Mitigações

58.18 Indicadores de Saúde da Gestão de Configuração

Desvios nos indicadores de gestão de configuração são tratados como itens de pauta obrigatória no Comitê de Gestão da Parceria e registrados com plano de ação e responsável.

58.19 Decisões Arquiteturais — ADR

58.20 Referências Internas

• Capítulo 39 — Containers e Empacotamento: estratégia de build de imagens e scanning de vulnerabilidades
• Capítulo 40 — DevSecOps e Entrega Contínua: pipeline de CI/CD onde o protocolo de custódia se insere como etapa obrigatória
• Capítulo 41 — Observabilidade e Monitoramento: monitoramento do drift de configuração e alertas de compliance
• Capítulo 45 — Auditoria e Rastreabilidade: rastreabilidade de operações que complementa a rastreabilidade de configuração
• Capítulo 46 — Criptografia e Controles: protocolos criptográficos aplicados ao pacote de custódia
• Capítulo 51 — Operação e Gestão de Serviços: prazos de remediação de vulnerabilidades em dependências
• Capítulo 55 — Gestão da Evolução: ciclo de releases que determina a frequência de submissão de custódia
• Capítulo 56 — Governança da Parceria: protocolo ADR-5604 (custódia vinculada ao deploy) e ADR-5605 (inventário de PI)
• Capítulo 57 — Gestão de Projetos e Entregas: rastreabilidade de tickets e pull requests que alimenta a cadeia de rastreabilidade
• Capítulo 59 — Gestão de Mudanças: processo de aprovação de mudanças de configuração em produção

58.21 Resumo

A gestão de configuração e custódia de código é o mecanismo técnico que transforma a rastreabilidade em garantia verificável. Não é suficiente que o código exista em algum lugar — é necessário que seja versionado de forma determinística, que cada artefato em produção seja rastreável ao commit que o originou, e que a PRODEMGE detenha, de forma ininterrupta, o acervo de código sob custódia segura e auditável.

O modelo descrito neste capítulo implementa esse conjunto de garantias em três camadas complementares. A camada de versionamento — Git com branching disciplinado, tags semânticas assinadas e rastreabilidade full-chain commit-to-deploy — garante que o estado de qualquer versão é determinístico e auditável. A camada de configuração — separação entre código e valores de ambiente, IaC por Terraform e Helm, GitOps com Argo CD, secrets em cofre — garante que ambientes são reproduzíveis e que mudanças são rastreáveis. A camada de custódia — pacote estruturado com código, SBOM, contratos, runbooks e instruções de empacotamento, transmitido antes de cada deploy em produção e confirmado pela PRODEMGE antes do pipeline avançar — garante a soberania digital e a continuidade operacional mesmo em cenários extraordinários.

Os três princípios do item 5.6 do Plano de Negócio Referencial — integridade, confidencialidade e rastreabilidade — são operacionalizados aqui não como declarações de intenção, mas como controles técnicos verificáveis: hashes SHA-256 que comprovam integridade, criptografia com chave pública da PRODEMGE que garante confidencialidade, e cadeia de rastreabilidade que vincula cada byte em produção à decisão técnica que o originou.

58.22 Próximo Capítulo

O Capítulo 59 — Gestão de Mudanças — descreve o processo pelo qual mudanças técnicas planejadas e emergenciais são classificadas, aprovadas, executadas e documentadas em produção, incluindo o funcionamento do Change Advisory Board (CAB), os critérios de aprovação por nível de risco e o protocolo de rollback.

58.23 Controle de Versão