catalog

El repositorio del catálogo es la fuente de verdad de toda la plataforma: pequeños archivos YAML que dicen qué productos, equipos y personas existen y quién es responsable de qué. No ejecuta nada en la nube por sí mismo. Su trabajo es verificar que cada cambio en esos archivos tenga sentido y, una vez integrado un cambio, iniciar los pipelines que hacen que el mundo real coincida. Las ideas detrás están en la página del concepto de catálogo; esta página trata sobre el repositorio.

Para qué sirve

El catálogo existe para que haya un solo lugar donde cambiar la organización, y un solo registro de cada cambio. Un producto nuevo, un miembro nuevo de un equipo, un presupuesto más alto o un producto retirado es un merge request aquí, aprobado por las personas que nombra el propio catálogo.

Qué contiene

La jerarquía: un archivo por recorrido, dominio y contexto, cada uno con el nombre de su ruta y con sus líderes.
Los productos: un archivo por producto, con su equipo, criticidad, clasificación de datos, objetivos de recuperación, presupuesto, pila y ciclo de vida.
Los equipos y las personas: quién pertenece a qué equipo, con qué rol, y el estado de cada persona.
El modelo de responsables: ownership/protected-paths.yaml, que dice quién debe aprobar qué cambio, aquí y en cada repositorio de producto.
Los servicios aprobados: un archivo por servicio de Google Cloud que la plataforma aprobó además de los que recibe cada producto, como Memorystore for Redis.
Las lápidas: un archivo por producto eliminado, para que su nombre nunca se reutilice.
El esquema y las verificaciones: JSON Schemas para cada tipo de archivo, y los scripts que verifican las reglas que un esquema no puede expresar, como “el equipo de un producto vive en el contexto del producto”.

Cómo se conecta

Nada en el catálogo lee otra cosa; todo lo demás lee el catálogo.

Después de un merge, el pipeline del catálogo inicia los pipelines de landing-zone, operations y control-plane, en ese orden, y después landing-zone otra vez. Cada uno planifica y aplica sus raíces contra el contenido nuevo del catálogo. La página de reconciliadores explica la cadena.
La compuerta de aprobación lee el modelo de responsables desde la rama main protegida del catálogo para decidir si un merge request en cualquier lugar tiene las aprobaciones correctas.
La plantilla de golden-path toma los valores de un producto de su entrada en el catálogo cuando genera el primer commit del producto.
El catálogo de arquitectura, el mapa de la plataforma con cada producto, recibe desde el pipeline de este repositorio una página de recorridos, dominios, equipos y personas.

Quién lo cambia, y cómo

Cualquiera con acceso al repositorio puede proponer un cambio. Quién debe aprobarlo depende de lo que toca: el archivo de un producto necesita a su equipo o a sus líderes, una suba de presupuesto a un líder del dominio, un cambio de ciclo de vida a dos personas, y la estructura a dos miembros del equipo de plataforma. La compuerta de aprobación verifica esto en cada merge request, y su aprobación es obligatoria para integrar.

El pipeline hace dos cosas:

En un merge request, valida cada archivo contra su esquema, ejecuta las verificaciones de coherencia, comprueba que un cambio de ciclo de vida lleve la etiqueta lifecycle y pase por los estados en orden, y ejecuta las pruebas de las propias verificaciones cuando cambian.
En main, después de un merge, primero deja que un producto cuyo ciclo de vida cambió aplique ese cambio con su propio pipeline, después inicia la cadena de reconciliadores, publica su página del catálogo de arquitectura, y mantiene una nota en el merge request integrado que sigue la cadena.

El catálogo no tiene raíces de Terraform propias y no tiene ninguna identidad que pueda cambiar un proyecto en la nube. Su costo permanente es cero.

Dónde está

En el repositorio catalog: