Traer un sistema existente

La mayoría de las organizaciones ya tienen sistemas en funcionamiento cuando adoptan una plataforma, y esos sistemas pocas veces se parecen a un producto nuevo generado con la plantilla de Airframe. Esta página dice con claridad qué puede recibir Airframe hoy, a qué renuncia un producto que no usa la plantilla, y qué partes del camino de adopción están diseñadas pero no construidas, para que puedas planificar sin sorpresas.

En pocas palabras: el catálogo puede registrar un sistema existente, y la plataforma construye entonces su parte en la nube, pero nada de lo construido hoy lleva su código, sus datos ni su despliegue a la plataforma. El camino que funciona hoy es un producto nuevo a partir de la plantilla, al que se trae la aplicación existente.

Lo que el catálogo acepta hoy

La entrada de un producto puede decir template: none, que significa “no generen un repositorio para mí”, junto con uno de dos campos:

source_repo, la dirección del único repositorio en el que vive el sistema hoy;
repos, una lista de los repositorios del sistema, cada uno con un rol: infra, service, worker, frontend o migration.

El lint del catálogo rechaza template: none sin uno de ellos (aplicado). Una entrada también puede llevar conformance_level, de 1 a 3, qué tan avanzado está el producto en la escalera de adopción de la plataforma. El esquema lo acepta, y todavía nada lo lee.

Lo que pasa con una entrada así

Los reconciliadores la tratan como a cualquier otro producto. La fábrica de proyectos crea sus dos proyectos y sus identidades, y los factura cuando el producto aparece en billed_products de la fábrica. La raíz de GitLab del dominio crea un repositorio en la ruta del producto, dentro del grupo de su contexto, con su main protegido.

Ese repositorio queda vacío. El job de generación de la plataforma, la única cuenta que puede subir el primer commit del repositorio de un producto, genera las entradas que dicen template: fullstack y salta las demás. Todavía nada lee source_repo ni repos. Así que hoy template: none le da a un sistema un lugar en el catálogo y sus proyectos en la nube, y deja su código donde está.

Lo que la plantilla le habría dado

Un producto generado con la plantilla del golden path empieza con:

una aplicación que funciona para su pila, con logs en JSON, trazas y un endpoint de salud ya conectados a la telemetría de la plataforma;
sus raíces de Terraform, infra/np, infra/sandbox, infra/prod, infra/eph para las vistas previas e infra/grafana, compuestas con los módulos de la plataforma;
un pipeline hecho solo con los componentes de la plataforma;
.airframe/ con la lista de imágenes que compila el constructor de confianza y los datos iniciales del sandbox y de las vistas previas;
un archivo que nombra los secretos del producto y nunca guarda un valor, un runbook, un archivo CODEOWNERS que nombra al grupo del contexto como responsable de las rutas que protege el modelo de responsables, e instrucciones para un agente de código.

Un producto sin la plantilla tiene que traer cada una de estas cosas por su cuenta, y los jobs de compilación y de prueba de la plataforma solo conocen las tres pilas de la plantilla. Un producto con otra pila no ejecuta ninguno de ellos, y sus merge requests fallan el control de cobertura de pruebas hasta que su entrada pone quality.minimum_coverage en cero, un cambio que aprueba un líder del equipo o un líder del dominio.

El camino que funciona hoy

Registra el sistema como un producto nuevo con template: fullstack y la stack más parecida, siguiendo el primer producto.
Reemplaza la aplicación generada en apps/ por el código existente, con merge requests comunes en el repositorio nuevo. El equipo puede cambiar el Dockerfile o agregar otros, siempre que cada uno parta de una de las imágenes base de la plataforma y figure en .airframe/images.yaml, como explica cualquier pila.
Vuelve a crear los recursos en la nube del sistema con las raíces del producto. Los datos existentes los tiene que mover el equipo: importar bases de datos y estado de Terraform existentes en las raíces del producto es parte del diseño de adopción de abajo, y está diseñado.

Diseñado, no construido

Los ADR-0016 y ADR-0017 de landing-zone describen cómo la plataforma recibirá la forma más común de un sistema existente. Las dos decisiones siguen siendo propuestas, y el esquema del catálogo solo tiene sus primeros campos.

Productos repartidos en varios repositorios (diseñado). Un producto conserva un repositorio por aplicación, más un repositorio que cambia el esquema de su base de datos y un repositorio infra nuevo, generado por la plantilla, para lo que el producto decide. Cada repositorio tiene su propio estado de Terraform, sus imágenes y su nombre de host de vista previa, <product>-<repo>-eph-<iid>, y la identidad del repositorio de migraciones es dueña del esquema de la base de datos.
La adopción moviendo el grupo (diseñado). Un producto entra en la plataforma cuando su grupo de GitLab se transfiere debajo de projectairframe/<journey>/<domain>/<context>/<product>/, una transferencia registrada por producto con el procedimiento excepcional. La entrada llevaría source_group, la ruta anterior del grupo, hasta la mudanza.
Alias de nombres de host (diseñado). Los nombres de host que ya tiene un producto adoptado, listados en hostnames de la entrada, los serviría el borde compartido como alias de su nombre de host canónico. El esquema del catálogo todavía no acepta el campo, así que el lint rechaza una entrada que lo use.
Dependencias que se quedan afuera (diseñado). Un almacén de datos que el producto sigue operando en otro lugar, como un MongoDB, sería una entrada de dependencies: la red abre el camino hacia él, y el paquete de políticas advierte.
GKE como segundo lugar de ejecución (diseñado). Un producto podría decir runtime: gke y ejecutarse en sus propios namespaces en un clúster Autopilot compartido por edición, desplegado por Argo CD a partir de lo que aplica la raíz del producto, sin ninguna credencial del clúster en ningún pipeline. Todavía no existe ninguna raíz de clúster.
La escalera de adopción y airframe adopt (diseñado). El nivel 1 registra un producto, el nivel 2 aloja sus repositorios y su infraestructura en la plataforma, y el nivel 3 adopta la estructura de la plantilla; conformance_level registra el nivel, y todavía nada actúa sobre él. Un comando, airframe adopt, redactaría la entrada y los merge requests; está previsto para el final, después de ensayar el camino manual.

Hasta que esto se construya, un sistema existente en Airframe es un producto nuevo al que el equipo muda su aplicación.

Dónde está

En el repositorio landing-zone:

En el repositorio catalog:

schema/product.schema.json: los campos que el catálogo acepta hoy

En el repositorio golden-path:

template/: con qué empieza un producto generado

En el repositorio control-plane:

lifecycle/render.sh: el job de generación, solo para entradas fullstack