Cómo llega a existir un producto
Un equipo propone
Todo empieza como un archivo. Para crear un producto, un equipo agrega una entrada al catálogo: quién es su responsable, su pila tecnológica, su criticidad y su presupuesto mensual. Esa es toda la solicitud.
Reglas probadas juzgan el cambio
El paquete de políticas revisa el cambio con reglas probadas: nombres, etiquetas, exposición pública, los componentes del pipeline. Una regla que falla dice qué está mal, y a menudo qué hacer en su lugar, con palabras escritas para la persona o el agente de código que escribió el cambio.
Los responsables aprueban la intención
El catálogo dice quién es responsable de qué. La compuerta de aprobación aprueba el merge request solo cuando los responsables actuales lo hayan aprobado, y vincula su propia aprobación al commit que revisó; no cuenta la aprobación de nadie a su propio cambio.
El presupuesto se vuelve un límite
El presupuesto mensual de la entrada es un límite, no una nota. Una vez que el producto existe, cada merge request de su repositorio se planifica y se le calcula el costo al aprobarse, y una verificación de estado mantiene cerrado el merge mientras los planes sumen más que ese presupuesto. Para subirlo, hace falta otro merge request al catálogo.
Los pipelines lo construyen
Después del merge, una cadena de pipelines lee el catálogo y construye el producto: sus proyectos e identidades en Google Cloud, su repositorio a partir del golden path, sus paneles y sus nombres de host en el edge compartido. Ninguna persona ejecuta un comando.
El producto está en línea
Una vez que sus proyectos tienen facturación, lo que es otro merge request en landing-zone, el equipo tiene un repositorio cuyo pipeline ya despliega, un nombre de host protegido por inicio de sesión único y paneles que muestran su servicio y su costo.