La vida de un producto

Esta página sigue a un producto durante toda su vida en Airframe, desde el merge request que lo crea hasta el que lo elimina. Cada paso es un merge request o un pipeline que inició un merge; nadie crea nada a mano. El ejemplo es el producto de pedidos de la organización de demostración, y los tiempos vienen del propio ensayo de la plataforma del 2026-09-20, que llevó productos por los mismos pasos de principio a fin.

1. El merge request en el catálogo

Un miembro del equipo de la tienda agrega products/shop.store.ordering.orders.yaml al catálogo: el equipo responsable, la pila, la criticidad, los objetivos de recuperación y un presupuesto mensual de 5 dólares estadounidenses. El pipeline del catálogo verifica el archivo contra su esquema y sus reglas de coherencia.

El equipo del producto, o los líderes de su contexto o de su dominio, lo aprueban. La compuerta de aprobación verifica esas aprobaciones contra el modelo de responsables del catálogo, agrega la suya, y el merge request se puede integrar.

2. La cadena

El merge inicia la cadena de reconciliadores. landing-zone crea el grupo de Google del producto, sus dos proyectos, lk-store-orders-<rnd> y lk-store-orders-np-<rnd>, y sus identidades de plan y de apply. operations crea su carpeta, sus paneles y sus reglas de alerta en Grafana. control-plane crea el repositorio projectairframe/shop/store/ordering/orders, protege su rama main y le da al equipo sus permisos.

Una nota en el merge request del catálogo sigue la cadena mientras avanza, con horarios y enlaces. En el ensayo, la cadena tardó unos treinta minutos desde el merge hasta el repositorio.

3. El primer commit del repositorio

La raíz de control-plane para el dominio genera la plantilla de golden-path con la entrada del catálogo y la salida Ready de la fábrica de proyectos como respuestas, y sube el resultado como primer commit del repositorio. Es una aplicación que funciona para la pila elegida, sus raíces de Terraform, un pipeline hecho con los componentes de la plataforma, un runbook e instrucciones para un agente de código.

Ese primer commit no tiene merge request propio: su aprobación es la del merge request del catálogo. La compuerta lo admite como el primer commit de un repositorio de producto generado desde el catálogo, la única excepción a “en main solo se ejecuta el commit de un merge request integrado”.

Desde su primer merge request, el repositorio nuevo necesita la aprobación de una persona con nombre que no escribió el cambio. La aprobación de la compuerta pasa a ser obligatoria cuando el repositorio se suma a la lista de la compuerta y al alcance de la política de aprobación, dos merge requests en control-plane y security-policies, como explica la página de la compuerta.

4. La facturación

Los proyectos de un producto nuevo existen desde el principio, con sus identidades y permisos, pero no están vinculados a la facturación. Mientras no lo estén, el pipeline del producto puede planificar de verdad y pasar el paquete de políticas, y su apply se detiene en el primer servicio que necesita facturación, como Cloud Run.

La facturación es un merge request aparte en el repositorio landing-zone, que agrega el producto a la lista de productos facturados de la fábrica de proyectos. Se mantiene aparte a propósito: una cuenta de facturación puede tener solo una cantidad limitada de proyectos facturados, así que usar esa cuota es una decisión en sí misma. Una vez que el producto tiene facturación, se habilitan sus API, sus proyectos se conectan a la red compartida, se crean sus presupuestos de Google Cloud, y el siguiente pipeline aplica. No se vuelve a crear nada.

5. El primer despliegue

El primer pipeline del producto en main ejecuta los mismos pasos que todos los siguientes: construye las imágenes en el constructor de confianza, las promueve, planifica cada raíz, ejecuta el paquete de políticas sobre los planes, y los aplica: no producción por su cuenta, y el sandbox antes de producción. Crear las bases de datos es lo que más tarda.

En el ensayo, el producto respondió en su nombre de host unos ochenta y cinco minutos después de integrarse la entrada en el catálogo.

6. El nombre de host detrás del inicio de sesión único

El producto responde en orders.store.shop.projectairframe.dev. Como todo nombre de host de la plataforma, está detrás de Identity-Aware Proxy de Google, el inicio de sesión único de la plataforma: solo pueden llegar los miembros del grupo de usuarios del producto, que llena el catálogo.

Desde aquí, el equipo cambia su producto mediante merge requests, como describe el camino de un cambio.

7. El retiro

Para retirar el producto, el equipo cambia su estado en el catálogo a retiring. El merge request necesita la etiqueta lifecycle y dos aprobadores además del autor: uno del equipo del producto, y otro de los líderes del dominio o del equipo de plataforma.

Después del merge, el propio pipeline del producto aplica primero el retiro: sus servicios salen del borde compartido y bajan a cero instancias. Se conservan sus proyectos, bases de datos, buckets y repositorio. En el ensayo, el retiro tardó menos de treinta minutos. El producto de pedidos de la organización de demostración está hoy en este estado.

8. Eliminado, y la lápida

Después de la fecha retire_after de la entrada, un último merge request de ciclo de vida cambia el estado a removed y agrega la lápida del producto en retired-names/.

El propio pipeline del producto destruye lo que el producto ejecuta, con las identidades propias del producto. Después, la cadena desconecta los proyectos de la red compartida, los elimina y programa el borrado del repositorio. Google Cloud mantiene un proyecto eliminado recuperable durante treinta días.

Google retiene algunas direcciones de red durante un tiempo después de borrar los servicios que las usaban, así que la eliminación se completa en la siguiente ejecución de la cadena después de que Google las libera: en los ensayos, entre media hora y dos horas más tarde. Solo un producto con facturación se puede eliminar así; la plataforma no factura un producto solo para eliminarlo.

El nombre no se vuelve a usar: el catálogo rechaza cualquier producto nuevo con ese nombre en todo el dominio.

Dónde está

En el repositorio landing-zone:

En el repositorio catalog:

En el repositorio control-plane:

docs/adr/0024: la nota de progreso en el merge request del catálogo