golden-path

El repositorio golden-path guarda la forma recomendada de construir un producto en Airframe: una plantilla que genera el repositorio de un producto nuevo, y los módulos de Terraform que ese producto usa para crear sus servicios, su base de datos y sus secretos. Un producto generado desde ella empieza con una aplicación que funciona, su infraestructura, un pipeline hecho con los componentes de la plataforma y un runbook, desplegando en Cloud Run detrás del inicio de sesión único. Es una opción por defecto, no un requisito: después del primer commit, el código es del equipo.

Para qué sirve

Todo producto necesita las mismas conexiones básicas: proyectos conectados a la plataforma, un servicio con registros estructurados y telemetría, una base de datos con copias de seguridad, secretos por nombre, un pipeline. Escribirlas otra vez para cada producto es lento y se desvía. El golden path las escribe una vez, las mantiene probadas, y le da a cada producto nuevo una copia que ya pasa todas las verificaciones.

Qué contiene

La plantilla: una plantilla de Copier (Copier genera un proyecto a partir de una plantilla y un conjunto de respuestas) con una respuesta stack para tres pilas: Node (NestJS y React), Python (la plantilla full-stack de FastAPI) y Java (Spring PetClinic). Todo lo que está fuera de la carpeta de la aplicación es común a las tres: las raíces de Terraform, el archivo de pipeline, la descripción del producto para el catálogo de arquitectura, el runbook y las instrucciones para un agente de código.
Los módulos: service-project y airframe-context, que leen lo que creó la fábrica de proyectos; cloud-run-service, cloud-sql, secrets, preview-substrate, database-seed y grafana-dashboard. Cada uno tiene sus propias pruebas contra proveedores simulados.
Los ejemplos: un producto generado para cada pila, desde el catálogo en vivo, idéntico a lo que la plantilla produce hoy.
Un caso que debe fallar: una raíz que el paquete de políticas debe rechazar, que demuestra en cada cambio que el paquete sigue funcionando.

Cómo se conecta

El catálogo y landing-zone lo alimentan. Cuando se crea un producto, la raíz de GitLab de control-plane ejecuta la plantilla con la entrada del producto en el catálogo y su salida Ready de la fábrica de proyectos como respuestas, y guarda el resultado como el primer commit del repositorio.
Los productos usan sus módulos. Las raíces de un producto llaman a los módulos, fijados a un commit, en lugar de declarar los recursos de la nube uno por uno.
Incluye los componentes de control-plane. El archivo de pipeline generado incluye solo los componentes de la plataforma, que es lo que el paquete de políticas exige a cada producto.
Es parte de cada versión. Una versión de la plataforma nombra el commit de la plantilla y de los módulos, junto con las otras partes.

Quién lo cambia, y cómo

Los cambios son merge requests aprobados por el equipo de plataforma, con la aprobación de la compuerta obligatoria. El pipeline es la compuerta de publicación de la plantilla:

cada vez que cambian la plantilla, los ejemplos o el pipeline, vuelve a generar los tres ejemplos desde el catálogo en vivo y falla si difieren de los guardados;
compila y prueba el ejemplo de una pila cada vez que cambian los archivos de plantilla de esa pila, su ejemplo o el pipeline;
ejecuta las pruebas de los módulos, valida cada ejemplo como raíz de producto, y ejecuta el paquete de políticas sobre los ejemplos y el caso que debe fallar.

Los trabajos de compilación y pruebas de la plataforma solo conocen estas tres pilas. Un producto con otra pila, con su propio Dockerfile sobre una imagen base de la plataforma, no ejecuta ninguno de ellos, y sus merge requests fallan la exigencia de cobertura de pruebas hasta que su entrada del catálogo baje la cobertura requerida, lo que debe aprobar un líder de equipo o un líder del dominio. Es una brecha conocida.

El repositorio no tiene raíces propias y no cuesta nada mientras no se usa.

Dónde está

En el repositorio golden-path: