Estudo de caso arquitetural · engineering intelligence

Transformar dezenas de repositórios em um portfólio observável sem criar outro backend para operar.

O Repo Control Center nasceu de um problema operacional simples: conforme o número de repositórios cresce, CI, delivery, releases, segurança, pacotes e atividade ficam espalhados demais para formar uma visão confiável do conjunto. A solução coleta essas evidências fora do navegador, explicita quando a informação está incompleta e publica um snapshot estático para consulta.

O dashboard é somente leitura. Tokens usados na coleta permanecem no GitHub Actions e nunca são enviados para a SPA publicada.

Problema

O GitHub tem os sinais, mas não entrega uma visão operacional do portfólio como um sistema.

Build, deployment, release, atividade, alertas, pacotes e itens abertos existem em superfícies e APIs diferentes. Abrir repositório por repositório funciona enquanto o conjunto é pequeno; depois disso, a própria busca por contexto vira custo operacional.

O desafio não era criar mais um dashboard visual. Era construir uma linguagem comum para interpretar o estado dos projetos sem transformar ausência de dados em falha, nem exigir infraestrutura permanente apenas para agregar sinais que mudam em baixa frequência.

Restrições e atributos de qualidade

A arquitetura parte da confiança dos dados e do custo operacional aceitável.

01

Sem backend permanente

A coleta roda no GitHub Actions e produz um snapshot JSON incluído no artifact do Pages.

02

Sem credenciais no navegador

A SPA consome apenas dados estáticos. Tokens e permissões ficam restritos ao ambiente de automação.

03

Dados incompletos são um estado válido

Cada repositório informa coleta completa, parcial ou indisponível e uma confiança derivada da cobertura das fontes.

04

Falha isolada não interrompe o conjunto

Consultas opcionais podem falhar sem impedir a publicação do restante do portfólio; a degradação permanece explícita.

OperabilidadeObservabilidadeSegurançaConfiabilidade dos dadosBaixo custoEvolutibilidade

Decisões arquiteturais

O desenho separa coleta privilegiada, contrato de dados e apresentação pública.

GitHub Actions como processo de coleta

O collector Node.js consulta as APIs durante o workflow, pagina resultados, limita concorrência e normaliza as evidências antes da publicação.

Trade-off: a atualização é periódica, não em tempo real.

Snapshot estático como fronteira

O JSON publicado desacopla a SPA das APIs autenticadas e transforma a coleta em um contrato de leitura reproduzível.

Trade-off: o estado exibido representa o último workflow bem-sucedido.

Angular SPA no GitHub Pages

A interface oferece filtros, busca, detalhe por repositório e leitura agregada sem exigir serviço de aplicação em execução.

Trade-off: rotas detalhadas usam hash e o conteúdo depende do snapshot publicado.

Confiança separada de saúde

complete, partial e unavailable descrevem a observabilidade da coleta; a saúde do repositório permanece uma classificação distinta.

Trade-off: a UI precisa comunicar incerteza em vez de resumir tudo em uma única cor.

Classificação semântica de workflows

CI, quality, security, mutation, delivery, release, Pages e maintenance têm papéis diferentes; apenas o sinal correto deve influenciar build e delivery.

Trade-off: heurísticas precisam de override quando nomes não expressam intenção.

Segurança como evidência, não score mágico

Dependabot, code scanning, workflow de segurança e OpenSSF Scorecard são apresentados separadamente. Falta de acesso reduz confiança, não vira alegação de segurança.

Trade-off: a leitura é mais honesta, porém menos simplificada.

Fluxo

Coletar, normalizar, publicar e consultar sem acoplamento runtime ao GitHub.

  1. GitHub APIssinais distribuídos por fonte
  2. Collector Node.jspaginação, regras e tolerância a falhas
  3. repositories.jsonsnapshot e contrato de leitura
  4. Angular SPAfiltros, detalhe e insights
  5. GitHub Pagespublicação estática
  6. Quality gatesCI, Lighthouse, SEO e ZAP

Trade-offs e limites

Reduzir infraestrutura desloca complexidade para o contrato de dados e para a interpretação das evidências.

Não é tempo real

O cron atualiza aproximadamente a cada hora. Isso é suficiente para manutenção de portfólio, mas não substitui monitoramento operacional de produção.

Nem toda delivery é observável

Deploys externos ao GitHub podem não aparecer; versão fica vazia quando não existe associação confiável com a entrega.

Permissões afetam cobertura

Actions, Deployments e alertas de segurança podem exigir permissões adicionais. A ausência é reportada como perda de confiança.

Snapshot não é série histórica

As métricas de 30 dias são recalculadas no estado atual. Tendência temporal exige persistência de snapshots anteriores.

Heurística tem fronteira

Nomes de workflows fora das convenções podem ficar desconhecidos. Configuração por repositório funciona como override explícito.

GitHub Pages impõe limites

Alguns headers e comportamentos de hospedagem não são controlados pela aplicação e precisam ser tratados como responsabilidade da plataforma.

Leitura arquitetural

Observabilidade de engenharia também precisa modelar incerteza.

O principal aprendizado do projeto não é “como montar um dashboard”. É que consolidar sinais de engenharia exige preservar a diferença entre ausência, falha de coleta, evidência negativa e evidência positiva. Sem isso, uma interface simples pode produzir uma interpretação incorreta do portfólio.

Ao tornar cobertura e confiança explícitas, o Repo Control Center trata a qualidade da própria observação como parte do domínio — uma decisão que reduz falsos diagnósticos e mantém a solução útil mesmo quando nem todas as fontes estão disponíveis.