Sin backend permanente
La recolección se ejecuta en GitHub Actions y produce un snapshot JSON incluido en el artifact de Pages.
Estudio de caso arquitectónico · engineering intelligence
Transformar decenas de repositorios en un portafolio observable sin crear otro backend que operar.
El Repo Control Center nació de un problema operativo sencillo: a medida que crece el número de repositorios, CI, delivery, releases, seguridad, paquetes y actividad quedan demasiado dispersos para formar una visión confiable del conjunto. La solución recolecta estas evidencias fuera del navegador, hace explícito cuándo la información está incompleta y publica un snapshot estático para consulta.
El dashboard es de solo lectura. Los tokens utilizados en la recolección permanecen en GitHub Actions y nunca se envían a la SPA publicada.
Problema
GitHub contiene las señales, pero no ofrece una visión operativa del portafolio como sistema.
Build, deployment, release, actividad, alertas, paquetes y elementos abiertos existen en superficies y API diferentes. Abrir cada repositorio funciona mientras el conjunto es pequeño; después, la propia búsqueda de contexto se convierte en un costo operativo.
El desafío no era crear otro dashboard visual. Era construir un lenguaje común para interpretar el estado de los proyectos sin convertir la ausencia de datos en una falla ni requerir infraestructura permanente solo para agregar señales que cambian con poca frecuencia.
Restricciones y atributos de calidad
La arquitectura parte de la confianza de los datos y del costo operativo aceptable.
Sin credenciales en el navegador
La SPA consume únicamente datos estáticos. Los tokens y permisos quedan restringidos al entorno de automatización.
Los datos incompletos son un estado válido
Cada repositorio informa una recolección completa, parcial o no disponible y una confianza derivada de la cobertura de las fuentes.
Una falla aislada no interrumpe el conjunto
Las consultas opcionales pueden fallar sin impedir la publicación del resto del portafolio; la degradación permanece explícita.
OperabilidadObservabilidadSeguridadConfiabilidad de los datosBajo costoCapacidad de evolución
Decisiones arquitectónicas
El diseño separa la recolección privilegiada, el contrato de datos y la presentación pública.
GitHub Actions como proceso de recolección
El collector Node.js consulta las API durante el workflow, pagina los resultados, limita la concurrencia y normaliza las evidencias antes de publicarlas.
Trade-off: la actualización es periódica, no en tiempo real.
Snapshot estático como límite
El JSON publicado desacopla la SPA de las API autenticadas y convierte la recolección en un contrato de lectura reproducible.
Trade-off: el estado mostrado representa el último workflow exitoso.
Angular SPA en GitHub Pages
La interfaz ofrece filtros, búsqueda, detalles por repositorio y lectura agregada sin requerir un servicio de aplicación en ejecución.
Trade-off: las rutas detalladas usan hash y el contenido depende del snapshot publicado.
Confianza separada de salud
complete, partial y unavailable describen la observabilidad de la recolección; la salud del repositorio sigue siendo una clasificación distinta.
Trade-off: la UI necesita comunicar incertidumbre en vez de resumir todo en un único color.
Clasificación semántica de workflows
CI, quality, security, mutation, delivery, release, Pages y maintenance cumplen funciones distintas; solo la señal correcta debe influir en build y delivery.
Trade-off: las heurísticas necesitan un override cuando los nombres no expresan la intención.
Seguridad como evidencia, no como score mágico
Dependabot, code scanning, el workflow de seguridad y OpenSSF Scorecard se presentan por separado. La falta de acceso reduce la confianza, no se convierte en una afirmación de seguridad.
Trade-off: la lectura es más honesta, pero menos simplificada.
Flujo
Recolectar, normalizar, publicar y consultar sin acoplamiento runtime con GitHub.
- GitHub APIsseñales distribuidas por fuente
- Collector Node.jspaginación, reglas y tolerancia a fallas
- repositories.jsonsnapshot y contrato de lectura
- Angular SPAfiltros, detalles e insights
- GitHub Pagespublicación estática
- Quality gatesCI, Lighthouse, SEO y ZAP
Trade-offs y límites
Reducir la infraestructura desplaza complejidad al contrato de datos y a la interpretación de las evidencias.
No es tiempo real
El cron actualiza aproximadamente una vez por hora. Esto es suficiente para el mantenimiento del portafolio, pero no reemplaza el monitoreo operativo de producción.
No todo delivery es observable
Los deployments externos a GitHub pueden no aparecer; la versión queda vacía cuando no existe una asociación confiable con la entrega.
Los permisos afectan la cobertura
Actions, Deployments y alertas de seguridad pueden exigir permisos adicionales. La ausencia se informa como pérdida de confianza.
Un snapshot no es una serie histórica
Las métricas de 30 días se recalculan sobre el estado actual. Una tendencia temporal exige persistir snapshots anteriores.
Las heurísticas tienen límites
Los nombres de workflows fuera de las convenciones pueden quedar como desconocidos. La configuración por repositorio funciona como override explícito.
GitHub Pages impone límites
Algunos headers y comportamientos de hosting no son controlados por la aplicación y deben tratarse como responsabilidad de la plataforma.
Evidencias públicas
El estudio puede validarse en la aplicación, en el collector y en los quality gates.
Dashboard publicadoVisión consolidada, detalles, filtros, salud, cobertura y confianza.CollectorRecolección, paginación, tolerancia a fallas y serialización del snapshot.Reglas de clasificaciónHealth, funciones de workflows, delivery y razones deterministas.AutomatizaciónRecolección, pruebas, build, publicación y validaciones continuas.RepositorioImplementación Angular, contrato del snapshot, seguridad, SEO y documentación.
Lectura arquitectónica
La observabilidad de ingeniería también necesita modelar la incertidumbre.
El principal aprendizaje del proyecto no es “cómo crear un dashboard”. Consolidar señales de ingeniería exige preservar la diferencia entre ausencia, falla de recolección, evidencia negativa y evidencia positiva. Sin eso, una interfaz sencilla puede producir una interpretación incorrecta del portafolio.
Al hacer explícitas la cobertura y la confianza, Repo Control Center trata la calidad de la propia observación como parte del dominio: una decisión que reduce diagnósticos falsos y mantiene útil la solución incluso cuando no todas las fuentes están disponibles.