Airframe

Por qué Airframe

Autoservicio por merge request

Un producto existe porque un archivo del catálogo lo dice. Un equipo lo crea con un merge request y lo retira con otro, y cada paso queda registrado.

Cómo un archivo del catálogo se convierte en un producto

  1. Un archivo describe el producto

    El equipo agrega products/shop.store.ordering.orders.yaml al catálogo: el equipo responsable, la pila tecnológica, la criticidad, los objetivos de recuperación y el presupuesto mensual. El esquema y el lint del catálogo revisan el archivo en el pipeline del merge request.

  2. Los responsables aprueban

    El catálogo nombra a los líderes de cada recorrido, dominio y contexto, y al equipo de cada producto. La compuerta de aprobación aprueba la solicitud solo cuando los responsables actuales la hayan aprobado, y vincula su propia aprobación al commit que revisó; no cuenta la aprobación del autor ni la de quien haya hecho un commit.

  3. La plataforma deriva el resto

    Después del merge, el pipeline del catálogo inicia una cadena de raíces de Terraform que lo leen. La fábrica de proyectos del dominio crea los dos proyectos de Google Cloud del producto y sus identidades, operations crea sus paneles y la raíz de GitLab del dominio crea el repositorio a partir del golden path. El nombre de host llega al edge compartido una vez que el primer pipeline del producto lo ha desplegado.

  4. El merge request sigue el trabajo

    Una nota en el merge request fusionado sigue la cadena mientras corre: cada pasada con su hora y su enlace, el primer pipeline del nuevo repositorio y el momento en que el producto responde en su nombre de host detrás del inicio de sesión único. Un fallo nombra su job y el paso siguiente. Un producto nuevo se ejecuta solo cuando sus proyectos tienen facturación, lo que es otro merge request en landing-zone, dentro de la cuota de proyectos de la cuenta de facturación.

  5. Retirar es el mismo archivo

    Poner el estado del producto en retiring saca sus servicios del edge y los deja en cero instancias, y conserva sus datos. Después de la fecha de retiro de la entrada, removed destruye lo que el producto ejecuta y elimina sus proyectos y su repositorio. Cada cambio de estado necesita dos aprobadores además del autor, y un nombre eliminado queda en el catálogo como lápida, así que nunca se reutiliza en su dominio.

Pruébalo

Escribe una entrada del catálogo. Esto es lo que la plataforma deriva de ella, con los nombres que le dan las fábricas en la versión de la plataforma que describe este sitio.

Etiqueta de criticidad
criticality: 2
Proyectos
lk-store-returns-xxxx
lk-store-returns-np-xxxx
Identidades de pipeline
returns-apply@lk-store-returns-xxxx.iam.gserviceaccount.com
returns-plan@lk-store-returns-xxxx.iam.gserviceaccount.com
returns-np-apply@lk-store-returns-np-xxxx.iam.gserviceaccount.com
returns-plan@lk-store-returns-np-xxxx.iam.gserviceaccount.com
Repositorio
projectairframe/shop/store/ordering/returns
Grupos
lk-shop-store-ordering-returns-users@projectairframe.dev
lk-team-store-core@projectairframe.dev
Nombres de host
returns.store.shop.projectairframe.dev
returns-np.store.shop.projectairframe.dev
returns-sandbox.store.shop.projectairframe.dev
returns-eph-<iid>.store.shop.projectairframe.dev
Carpetas y paneles de Grafana
shop › store › ordering › returns
returns service
returns SLO
Prefijos de estado
shop/store/ordering/returns/prod/
shop/store/ordering/returns/grafana/
shop/store/ordering/returns/np/
shop/store/ordering/returns/sandbox/
shop/store/ordering/returns/eph/
Presupuestos
USD 7 / USD 3, alertas al 80 % y al 100 %

Qué lo hace cierto

Un producto se crea sin que nadie ejecute un comando.
El pipeline del catálogo inicia la cadena de raíces de Terraform después del merge, y cada raíz aplica con una identidad de pipeline que solo puede obtener un job de su propio repositorio, en una ref protegida y en su entorno.
Solo los responsables actuales pueden aprobar.
La compuerta de aprobación lee el modelo de responsables del main protegido del catálogo, nunca del cambio que evalúa, y vincula su propia aprobación al commit que revisó; una política de aprobación hace de esa aprobación una condición para el merge.
El merge request muestra cuánto ha avanzado el producto.
Después del merge, el job de avance del catálogo sigue la cadena, y la compuerta de aprobación mantiene una nota en el merge request fusionado hasta que el producto responde en su nombre de host, falla un job o pasan tres horas.
Retirar un producto requiere dos aprobaciones además de la del autor.
La regla de ciclo de vida de la compuerta de aprobación pide dos aprobadores distintos, ninguno de ellos el autor: uno del equipo del producto y otro de los líderes del dominio o del equipo de plataforma. El job de ciclo de vida del catálogo exige la etiqueta lifecycle y los estados en orden.
Un nombre eliminado nunca se reutiliza.
El catálogo guarda una lápida en su lista de nombres retirados, y su lint rechaza cualquier otro producto con ese nombre en el dominio.