El camino de un cambio

Todo cambio en un producto de Airframe, una función nueva, una base de datos, un ajuste de configuración, recorre el mismo camino hasta producción, lo haya escrito una persona o un agente de código. Esta página recorre ese camino en nueve pasos y nombra la verificación de cada uno, para que se vea qué detiene un cambio malo y dónde. El ejemplo es un cambio en el producto de pedidos de la organización de demostración.

1. Una persona o un agente de código hace un cambio

Un desarrollador, o un agente de código que trabaja para él, cambia el repositorio del producto en una rama: la aplicación en apps/, la infraestructura en infra/, o el archivo de pipeline. Las skills de platform-skills le enseñan a un agente de código dónde va cada tipo de cambio y qué esperan las reglas.

2. La validación local

Antes de abrir un merge request, el autor ejecuta airframe validate en la laptop. No necesita credenciales y ejecuta la mayor parte de la validación del merge request: el formato y la validación de Terraform, OpenTofu y tflint donde están instalados, y el paquete de políticas sobre las raíces, el archivo de pipeline y los Dockerfiles declarados. Una regla que falla nombra el recurso y, muchas veces, qué hacer en su lugar, así que el autor lo corrige y vuelve a validar.

3. El pipeline del merge request

El pipeline del merge request se ejecuta en el runner sin confianza de la plataforma, una máquina que no tiene ninguna credencial de la nube que un trabajo pueda usar. El repositorio no puede quitar los trabajos que se le inyectan:

gate:integrity le pregunta a la compuerta de aprobación si este pipeline puede ejecutarse, y hace fallar uno que usa una versión revocada;
la validación, incluido el paquete de políticas, sobre las raíces y el archivo de pipeline del producto;
la compilación y las pruebas de la aplicación, con la cobertura de pruebas que exige la entrada del catálogo;
la detección de secretos, el análisis de dependencias y el análisis estático de GitLab.

Un rechazo o una prueba fallida hace fallar el pipeline, y GitLab no integra hasta que pase.

4. Los responsables aprueban, después la compuerta

Alguien que no escribió el cambio lo aprueba: una persona con nombre del catálogo, nunca un rol. Qué personas cuentan depende de lo que toca el cambio, según el modelo de responsables del catálogo: el equipo para infra/, el equipo o el equipo de la plataforma para el archivo de pipeline.

Cuando aprobaron, GitLab llama a la compuerta de aprobación. La compuerta verifica las aprobaciones en el último commit, agrega la suya, vinculada a ese commit, e inicia el ejecutor. Un commit nuevo subido después reinicia las aprobaciones y el ciclo empieza otra vez.

5. Los planes del ejecutor y la verificación de costo

El ejecutor se ejecuta en el runner de confianza y vuelve a verificar que el commit sea el aprobado. Después, con las identidades propias del producto:

planifica cada raíz de Terraform del producto con la identidad de plan, que no puede cambiar nada, y publica los planes en el merge request para quienes revisan;
pone precio a los planes con Infracost, y la compuerta define la verificación de estado “Airframe cost”, que falla cuando el total o cualquier raíz por sí sola supera el presupuesto mensual del producto;
hace que el constructor de confianza construya las imágenes de contenedor del commit;
despliega una vista previa del cambio con la identidad de no producción, en su propio nombre de host, que se destruye cuando el merge request se integra o se cierra, o cuando se vence su tiempo.

6. El merge

GitLab integra solo cuando el pipeline pasó, las personas correctas y la compuerta aprobaron el último commit, y la verificación de costo pasó. (La aprobación de la compuerta se exige en cada repositorio que nombra la política de aprobación, que hoy son todos menos security-policies; un repositorio de producto creado después se suma a esa lista con dos merge requests, como explica la página de la compuerta.) Cada merge es solo fast-forward, así que lo que se aprobó y se probó es exactamente lo que llega a main.

7. El pipeline de main aplica

En la rama main protegida, el pipeline se ejecuta en el runner de confianza, cada raíz con su propia identidad de apply, que solo puede obtener un trabajo de este repositorio en una rama protegida y en el entorno correcto. Primero, gate:integrity confirma que este commit es el último de un merge request integrado. Después, para cada raíz, plan:<root> la vuelve a planificar contra la infraestructura real, policy:<root> ejecuta el paquete de políticas sobre el plan, y apply:<root> la aplica solo si eso pasó. Un plan que las reglas de costo del ejecutor rechazaron también se detiene aquí.

8. Imágenes construidas, atestadas y promovidas

Las imágenes se construyeron al aprobarse el cambio, en el constructor de confianza, desde el commit aprobado. Antes de que una identidad separada firme la atestación de compilación, el ejecutor revisa el propio registro de Cloud Build sobre la compilación. En main, deploy:promote hace copiar las imágenes por digest al registro de producción, lo que agrega una segunda atestación. Producción espera ese paso.

9. Producción

Los servicios del producto se ejecutan en Cloud Run. Todo servicio desplegado con el módulo de Cloud Run del golden path se adhiere a la política de Binary Authorization de su proyecto, que en el proyecto de producción de un producto con facturación admite solo una imagen con las dos atestaciones. Todavía nada obliga a un servicio a adherirse: uno desplegado sin ese módulo se ejecuta sin la verificación, una brecha que también menciona la página de cero privilegios permanentes.

El cambio está en producción. Si algo falló en el camino, el paso que falló dice por qué, y la corrección es otro merge request por el mismo camino.

Dónde está

En el repositorio control-plane: