GitHub ha puesto en vista previa pública las external custom properties, una función que permite sincronizar en los repositorios información empresarial procedente de un CMDB, un portal interno de desarrolladores o cualquier otro sistema de registro. Datos como ownership, nivel de servicio, etapa del ciclo de vida o estado de compliance pueden mantenerse desde la fuente externa y aparecer como valores de solo lectura en GitHub, según el changelog oficial publicado el 29 de septiembre.
La fuente externa pasa a ser la referencia
La diferencia respecto a las custom properties tradicionales es quién controla el dato. Si una empresa usa una propiedad normal, puede administrarla desde la interfaz o las APIs de GitHub. Con external custom properties, el sistema externo conserva la propiedad exclusiva del valor y GitHub actúa como consumidor.
Eso evita que un usuario cambie manualmente en un repositorio un dato que debería venir de un CMDB o catálogo corporativo. La integración actualiza los valores mediante APIs y mantiene un namespace propio para separarlos de propiedades gestionadas por otras fuentes.
Los datos sincronizados sirven también para reglas
GitHub permite utilizar estas propiedades en los mismos lugares donde ya funcionan las custom properties: vistas de repositorios, filtros y segmentación de rulesets. Una empresa podría, por ejemplo, aplicar controles más estrictos a repositorios marcados como críticos o filtrar servicios cuyo estado de compliance requiera atención.
La utilidad crece en organizaciones con cientos de repositorios, donde mantener etiquetas manualmente termina produciendo discrepancias entre el inventario corporativo y GitHub.
Port.io es el primer partner, pero no es obligatorio
GitHub señala a Port.io como el primer partner con integración, aunque cualquier empresa puede construir su propio conector mediante las external custom properties APIs. Los permisos son granulares para limitar qué integración puede escribir cada conjunto de propiedades.
Antes de desplegarlo, conviene decidir qué sistema será fuente de verdad para cada dato y evitar duplicar conceptos. Si ownership vive en un CMDB, no tiene sentido mantener otro ownership editable manualmente con significado distinto.
Qué debería revisar una empresa
Los equipos de plataforma deberían identificar qué metadatos influyen hoy en seguridad, soporte, despliegues o auditoría y comprobar si están dispersos entre hojas, CMDB y GitHub. Después pueden elegir un pequeño conjunto de propiedades y probar la sincronización antes de utilizarlo en rulesets.
La novedad se suma a otros cambios recientes de GitHub para administración empresarial, como el validador de configuración de Copilot, runners personalizados para Dependabot, el sandbox local de agentes, CodeQL 2.27.1, las métricas de pull requests y proof of presence.
Fotografía: olia danilevich / Pexels.
