Cómo un repositorio describe la organización
La organización como archivos
El catálogo es un repositorio git de archivos YAML pequeños. Los recorridos, dominios, contextos y productos forman su jerarquía, cada uno un archivo nombrado por su ruta, como contexts/shop.store.ordering.yaml, y el archivo de un producto nombra al equipo responsable de él. El archivo de un equipo nombra su contexto, su líder y sus miembros con sus roles. El archivo de una persona tiene un nombre, una dirección de correo, un estado (active, pending o departed), sus nombres de usuario de GitLab y de Grafana cuando ya tiene cuentas, y un perfil: acerca de, experiencia, enlaces y horario. Las reglas de responsables, en el mismo repositorio, dicen quién aprueba qué. En cada merge request, el lint del catálogo revisa cada archivo contra su JSON Schema, y las referencias entre archivos.
Se cambia por merge request
Nadie cambia la organización en la configuración de una herramienta: un cambio es un merge request al catálogo, y las propias reglas de responsables del catálogo deciden quién debe aprobarlo. El archivo de un equipo necesita a uno de sus líderes de equipo o de los líderes de su contexto; el propio perfil de una persona, a esa persona, que aprueba el cambio o lo abre solo con commits suyos; el resto del archivo de una persona, a un líder de uno de sus equipos; y la estructura, desde los recorridos hasta las propias reglas, a dos miembros del equipo de la plataforma. La compuerta de aprobación traduce cada regla a personas a partir de la rama main protegida del catálogo, nunca del cambio que evalúa, y el merge espera su aprobación. Así, cada cambio tiene un revisor, un historial en git y una forma de deshacerlo: otro merge request.
Una fuente, muchos lectores
Hoy lo leen: la compuerta de aprobación, para cada aprobación que da; la raíz de grupos de landing-zone, para un grupo de Google por equipo, por líderes de cada nivel y por usuarios de cada producto, el público que el nombre de host del producto admite detrás del inicio de sesión único; las raíces de GitLab de control-plane, para las membresías de grupo de cada persona y la lista de quién puede hacer merge en la rama main de cada producto; la raíz de Grafana de operations, para los miembros de la organización y un equipo por cada equipo del catálogo, con sus carpetas, su punto de contacto y su ruta de alertas; la raíz de carpetas, para una carpeta por recorrido, dominio y contexto; y el catálogo de arquitectura, para una página por equipo y por persona, con el acerca de, la experiencia y el horario de la persona. Las fábricas de proyectos le dan al grupo de un equipo acceso de lectura a los proyectos de sus productos y a sus registros; el resto de lo que deriva la entrada de un producto es la historia de autoservicio por merge request.
Nada que mantener sincronizado
Cuando cambia una persona o un equipo, los lectores lo siguen en su próxima ejecución, y un merge al catálogo la inicia. La compuerta de aprobación lee la rama main del catálogo en cada evaluación. El pipeline del catálogo en main dispara la cadena de reconciliadores: el pipeline de landing-zone, luego el de operations, luego el de control-plane y otra vez el de landing-zone, cada uno ejecutando solo las raíces que leen el catálogo. El mismo pipeline publica las páginas del catálogo en el catálogo de arquitectura. Para lo que derivan los lectores, no hay un segundo inventario ni un job de sincronización. Dos cosas siguen fuera del catálogo: la política de aprobación de todo el grupo nombra a sus aprobadores en security-policies, donde solo un merge request los cambia, y una verificación después de cada merge al catálogo advierte cuando esa lista y el catálogo no coinciden, mientras una ejecución diaria falla y mantiene un issue abierto hasta que coincidan; y los grupos de la plataforma y de emergencia se administran a mano.
La próxima automatización es un lector más
Una automatización que necesita saber quién es responsable de un producto, quién lidera un dominio o quién está en un equipo lee los mismos archivos en la rama main del catálogo, y hereda lo que ya traen: cada dato fue aprobado por sus responsables, tiene un historial y se puede deshacer. No necesita una lista, un formulario ni un job de sincronización propios. Una nueva raíz de Terraform en landing-zone, operations o control-plane que lee el catálogo lo declara en su pipeline, con la entrada reads_catalog del componente tf-apply, y la cadena la ejecuta después de cada merge al catálogo.