DevOps: Pipeline de CI/CD, Governança de Mudança e Segurança do Barramento Confluent Kafka¶
Projeto: DSB26201 — Avaliação de arquitetura de integração ADMS (Energisa) Fonte: Reunião DevOps — "Assessment Integração ADMS - Devops (Consultoria Syntropy)" (VTT, 06/08/2026, ~24min) Status: Rascunho para validação — sem Ata consolidada correspondente (sessão mais recente do assessment; ainda não incorporada ao Assessment Consolidado, que hoje termina na Ata 14) Elaborado por: Consultoria Syntropy
Aviso metodológico¶
Assim como o artefato de DR (03/08), este documento foi construído exclusivamente a partir da transcrição (VTT), sem uma Ata consolidada para cruzamento de fidelidade e sem rótulos de falante confiáveis. A seção de achados abaixo chama-se "Achados de transcrição": não há segunda fonte independente para corroborar nomes e afirmações. Trechos com identificação de participante ambígua ou termos foneticamente incertos estão marcados como tal. Tratar como insumo para a futura Ata, não como substituto dela.
Por que este artefato existe¶
Todo o processo de integrações do ADMS depende do Barramento Confluent Kafka, e toda a infraestrutura do Barramento — hoje rodando dentro do OpenShift — é provisionada e publicada via pipeline de CI/CD. Nenhum artefato anterior deste ciclo documenta esse pipeline em si: como ele é estruturado, quem aprova o quê, e onde ficam os pontos de exceção. Esta sessão cobriu justamente isso, com interlocutores (Guilherme da Silva Lima, com apoio de Cláudio Ferreira Carneiro) que atuaram diretamente na configuração das pipelines e na publicação dos componentes do Kafka no OpenShift.
O valor concreto da sessão está em dois achados operacionais: primeiro, a existência de uma governança de mudança em duas camadas (aprovação de PR pela Infra, separada da aprovação de execução em produção pela Gestão de Mudanças, com janela de expiração de build); segundo, e mais relevante para o assessment, a confirmação explícita de que o ksqlDB é o único componente do Barramento cuja criação de streams e queries não passa pelo pipeline automatizado — é feita manualmente, direto no Confluent Control Center.
Diagrama 1 — Pipeline de CI/CD do Barramento: do commit ao deploy em produção¶
A infraestrutura do Barramento roda inteiramente no OpenShift on-premises, publicada pelo Azure DevOps — não há outra ferramenta de CI/CD envolvida no processo principal. O modelo é trunk-based, com scripts próprios por ambiente (desenvolvimento, homologação, produção) e um pipeline separado por componente do Kafka (brokers, Connect, ksqlDB, Schema Registry, Control Center). O acesso da equipe de desenvolvimento ao ambiente, historicamente via Citrix/VDI, migrou recentemente para ZTNA.
O ponto mais específico da governança: a aprovação de Pull Request (feita pela Infra, revisando o código) é separada da aprovação de execução da pipeline em produção (feita pelo time de Gestão de Mudanças). Um participante fez questão de esclarecer isso explicitamente na sessão — não é o mesmo aprovador nem o mesmo tipo de aprovação. Builds pendentes têm uma janela de expiração configurada até que a Gestão de Mudanças aprove a execução. Fora da janela semanal padrão, existe um processo formal de mudança emergencial para correções urgentes, incluindo vulnerabilidades — descrito como uma "dor" pelos participantes não pela mecânica em si, mas pelo tempo do processo de governança corporativo em torno dela.
Diagrama 2 — Exceção do ksqlDB: única peça fora do pipeline automatizado¶
Esse é o achado central da sessão do ponto de vista do assessment. A infraestrutura do serviço ksqlDB — o pod, o componente em si — é provisionada como qualquer outro componente do Barramento, via pipeline. Mas a criação de uma stream ou query nova dentro do ksqlDB não passa por esse processo: é feita diretamente no Confluent Control Center, sem Pull Request, sem revisão de código, sem aprovação de Gestão de Mudanças e, por consequência, sem histórico de versionamento nem trilha de auditoria equivalente à dos demais componentes.
O motivo apontado não é falta de disciplina da equipe, e sim ausência de solução suportada pela própria Confluent para automatizar esse tipo de objeto — situação que, segundo o interlocutor na sessão, era verdadeira até o final de 2026, com dúvida se uma versão mais nova já endereçaria o gap. Confirmado por Castellani em 08/08/2026: o gap persiste na versão da Confluent atualmente utilizada pela Energisa — não foi resolvido por atualização.
Um segundo ponto, de escopo menor, foi citado como exceção adicional já endereçada: a instalação de operators no OpenShift também não passa por pipeline com acesso direto, por decisão deliberada de segurança — não uma lacuna não percebida. Está prevista para ser resolvida pela frente de IaC (Terraform) mencionada abaixo, junto com o restante dos passos hoje manuais.
Iniciativa de IaC em andamento¶
Existe uma frente paralela, ainda em maturação, para levar o provisionamento a Infrastructure as Code usando Terraform ("e outras ferramentas"), cobrindo o que hoje ainda é manual — o exemplo citado foi justamente a instalação de operators no OpenShift, hoje feita manualmente "por questões de segurança" (acesso restrito deliberadamente, não uma etapa esquecida). Não há prazo declarado; a expectativa verbalizada foi "até que o projeto vem mais maduro". Este achado converge, em espírito, com o R27 já registrado na matriz de riscos ("ciclo de versões do OpenShift e do operador Confluent defasado... sem processo institucionalizado") — ambos apontam para a mesma lacuna de maturidade de automação da camada de plataforma, ainda que por ângulos diferentes (versionamento vs. provisionamento).
Scanning de segurança na esteira¶
A esteira de CI/CD roda análise de segurança a cada entrada de versão, cobrindo não só os componentes do Confluent Kafka, mas também os microsserviços consumidores/produtores que integram com o ADMS — ou seja, a cadeia de suprimento de software completa das aplicações publicadas nesse contexto:
- SAST (análise estática de código) via SonarQube — on-premises.
- SCA (análise de componentes/dependências) via JFrog X-Ray — on-premises.
- DAST (análise dinâmica) via Qualys WAS — SaaS/nuvem, aplicado apenas às aplicações com perfil web ou API.
Não há artefato anterior neste ciclo que documentasse esse controle de segurança do pipeline — é informação nova para o assessment, relevante como evidência de que existe controle de cadeia de suprimento de software, ainda que a automação do ksqlDB (achado acima) fique de fora dele por construção, já que não passa pelo pipeline.
Fronteira com o DevOps do domínio de dados (EDP)¶
O time de dados (EDP — Energisa Data Platform, também referido na sessão como "Data Office") opera uma esteira de CI/CD totalmente separada da do Barramento: uma instância própria de Azure DevOps, dedicada exclusivamente ao time de dados, usando Databricks e Data Factory como ferramentas principais, com publicação via GitFlow e os conceitos próprios da plataforma (bundles, workflows). A fronteira organizacional e técnica entre as duas esteiras é clara: tudo que entra no Databricks ou no Data Factory passa a ser responsabilidade do time de engenharia de dados, não do DevOps do Barramento.
Isso é consistente com — e reforça — o achado já registrado na Ata 14 (D12) sobre o conector de gravação em Go enviado ao Data Lake, mantido em produção sem propriedade formal (R41): a sessão confirma que esse componente vive organizacionalmente do lado do EDP, fora do escopo de governança de mudança e pipeline descrito neste artefato para o Barramento.
Achados de transcrição¶
1. Resolvido (08/08/2026): identificação completa dos participantes. A transcrição não tem rótulos de falante, mas Castellani confirmou os quatro participantes internos: Guilherme da Silva Lima e Cláudio Ferreira Carneiro (DevOps do Barramento, falas técnicas sobre o pipeline), Norberto da Silva Prado (fala atribuída na transcrição como "Roberto" — "é dessa estrutura aí que o Roberto tá mostrando", no momento em que o diagrama de arquitetura está sendo compartilhado) e Rômulo Maini Pinto (a pessoa capturada como "Cláudia kisê", perto do fim da sessão, explicando a esteira de DevOps do EDP). A ocorrência de "Roberto" confirma, pela segunda vez, o mesmo padrão de erro de ASR já documentado na Ata 04 para o nome de Norberto.
2. Resolvido (08/08/2026): "Cláudia kisê" era Rômulo Maini Pinto. Ver item 1 — não fica mais como questão em aberto.
3. "Já foram 15" — referência não detalhada. No encerramento (~22:47), é dito que "menos das diversas áreas que eles passaram, já foram 15" — não fica claro no contexto se isso se refere a sessões do assessment, áreas visitadas, ou outra contagem. Sem impacto no conteúdo técnico registrado acima; citado aqui só para não ficar perdido caso vire relevante em validação futura.
4. Sem inconsistências numéricas identificadas. Os elementos técnicos citados (arquitetura do pipeline, camadas de aprovação, stack de scanning de segurança, exceção do ksqlDB) não apresentam contradição interna dentro da própria sessão. Não há, porém, uma segunda fonte independente para confirmá-los — mesma ressalva já registrada no artefato de DR.
Próximo passo¶
Como não existe ainda uma Ata consolidada para esta sessão, o primeiro próximo passo é metodológico: incorporar este levantamento à consolidação formal (Ata 16, presumivelmente, seguindo a sessão de DR como Ata 15) — identificação dos participantes já resolvida (ver achados 1 e 2 acima). Do ponto de vista de conteúdo, com a confirmação de que o gap do ksqlDB persiste na versão atual da Confluent usada pela Energisa, o achado se mantém como lacuna estrutural (não débito técnico de atualização pendente). Fica como encaminhamento concreto mapear, junto à frente de IaC já em andamento, se e quando o cronograma de migração para Terraform (hoje focado em operator install) passará a cobrir também os objetos do ksqlDB.