Trazer um sistema existente

A maioria das organizações já tem sistemas rodando quando adota uma plataforma, e esses sistemas raramente se parecem com um produto novo gerado pelo template do Airframe. Esta página diz com clareza o que o Airframe consegue receber hoje, do que um produto abre mão quando não usa o template, e quais partes do caminho de adoção estão projetadas mas não construídas, para que você possa planejar sem surpresas.

Em resumo: o catálogo consegue registrar um sistema existente, e a plataforma então constrói a parte dele na nuvem, mas nada do que está construído hoje leva o código, os dados ou a implantação dele para a plataforma. O caminho que funciona hoje é um produto novo a partir do template, para dentro do qual se traz a aplicação existente.

O que o catálogo aceita hoje

A entrada de um produto pode dizer template: none, que significa “não gerem um repositório para mim”, junto com um de dois campos:

source_repo, o endereço do único repositório em que o sistema vive hoje;
repos, uma lista dos repositórios do sistema, cada um com um papel: infra, service, worker, frontend ou migration.

O lint do catálogo recusa template: none sem um deles (aplicado). Uma entrada também pode trazer conformance_level, de 1 a 3, o quanto o produto avançou na escada de adoção da plataforma. O esquema aceita o campo, e nada o lê ainda.

O que acontece com uma entrada assim

Os reconciliadores a tratam como qualquer outro produto. A fábrica de projetos cria os dois projetos e as identidades dele, e os fatura quando o produto aparece em billed_products da fábrica. A raiz do GitLab do domínio cria um repositório no caminho do produto, dentro do grupo do seu contexto, com o main protegido.

Esse repositório fica vazio. O job de geração da plataforma, a única conta que pode enviar o primeiro commit do repositório de um produto, gera as entradas que dizem template: fullstack e pula as outras. Nada lê source_repo nem repos ainda. Então hoje template: none dá a um sistema um lugar no catálogo e os projetos dele na nuvem, e deixa o código onde está.

O que o template teria dado

Um produto gerado pelo template do golden path começa com:

uma aplicação funcionando para a sua pilha, com logs em JSON, traces e um endpoint de saúde já ligados à telemetria da plataforma;
as raízes do Terraform, infra/np, infra/sandbox, infra/prod, infra/eph para as prévias e infra/grafana, compostas com os módulos da plataforma;
um pipeline feito só com os componentes da plataforma;
.airframe/ com a lista de imagens que o construtor confiável gera e os dados iniciais do sandbox e das prévias;
um arquivo que nomeia os segredos do produto e nunca guarda um valor, um runbook, um arquivo CODEOWNERS que nomeia o grupo do contexto como responsável pelos caminhos que o modelo de responsáveis protege, e instruções para um agente de código.

Um produto sem o template precisa trazer cada uma dessas coisas por conta própria, e os jobs de build e de teste da plataforma só conhecem as três pilhas do template. Um produto em outra pilha não roda nenhum deles, e os merge requests dele falham na verificação de cobertura de testes até que a entrada defina quality.minimum_coverage como zero, uma mudança que um líder da equipe ou um líder do domínio aprova.

O caminho que funciona hoje

Registre o sistema como um produto novo com template: fullstack e a stack mais parecida, seguindo o primeiro produto.
Troque a aplicação gerada em apps/ pelo código existente, com merge requests comuns no repositório novo. A equipe pode mudar o Dockerfile ou adicionar outros, desde que cada um parta de uma das imagens base da plataforma e esteja listado em .airframe/images.yaml, como explica qualquer pilha.
Recrie os recursos de nuvem do sistema pelas raízes do produto. Os dados existentes precisam ser movidos pela equipe: importar bancos de dados e estado do Terraform existentes nas raízes do produto faz parte do projeto de adoção abaixo, e está projetado.

Projetado, não construído

Os ADR-0016 e ADR-0017 do landing-zone descrevem como a plataforma vai receber a forma mais comum de um sistema existente. As duas decisões ainda são propostas, e o esquema do catálogo tem só os primeiros campos delas.

Produtos espalhados por vários repositórios (projetado). Um produto mantém um repositório por aplicação, mais um repositório que muda o esquema do banco de dados e um repositório infra novo, gerado pelo template, para o que o produto decide. Cada repositório tem o próprio estado do Terraform, as próprias imagens e o próprio nome de host de prévia, <product>-<repo>-eph-<iid>, e a identidade do repositório de migrações é dona do esquema do banco de dados.
A adoção movendo o grupo (projetado). Um produto entra na plataforma quando o grupo dele no GitLab é transferido para baixo de projectairframe/<journey>/<domain>/<context>/<product>/, uma transferência registrada por produto pelo procedimento excepcional. A entrada traria source_group, o caminho antigo do grupo, até a mudança.
Apelidos de nomes de host (projetado). Os nomes de host que um produto adotado já tem, listados em hostnames da entrada, seriam servidos pela borda compartilhada como apelidos do seu nome de host canônico. O esquema do catálogo ainda não aceita o campo, então o lint recusa uma entrada que o use.
Dependências que ficam de fora (projetado). Um armazenamento de dados que o produto continua operando em outro lugar, como um MongoDB, seria uma entrada de dependencies: a rede abre o caminho até ele, e o pacote de políticas avisa.
GKE como segundo lugar de execução (projetado). Um produto poderia dizer runtime: gke e rodar em namespaces próprios em um cluster Autopilot compartilhado por edição, implantado pelo Argo CD a partir do que a raiz do produto aplica, sem nenhuma credencial do cluster em nenhum pipeline. Ainda não existe nenhuma raiz de cluster.
A escada de adoção e o airframe adopt (projetado). O nível 1 registra um produto, o nível 2 hospeda os repositórios e a infraestrutura dele na plataforma, e o nível 3 adota a estrutura do template; conformance_level registra o nível, e nada age sobre ele ainda. Um comando, airframe adopt, redigiria a entrada e os merge requests; ele está previsto para o fim, depois que o caminho manual for ensaiado.

Até que isso seja construído, um sistema existente no Airframe é um produto novo para dentro do qual a equipe muda a sua aplicação.

Onde fica

No repositório landing-zone:

No repositório catalog:

schema/product.schema.json: os campos que o catálogo aceita hoje

No repositório golden-path:

template/: com o que um produto gerado começa

No repositório control-plane:

lifecycle/render.sh: o job de geração, só para entradas fullstack