Airframe

Por que o Airframe

Qualquer pilha; o golden path é um padrão

A plataforma exige poucas coisas de um produto: uma entrada no catálogo, só componentes de CI da plataforma no arquivo de pipeline, uma imagem base da plataforma sob cada Dockerfile e um conjunto completo de rótulos em cada recurso que leva rótulos. O resto é um padrão. O template gera o primeiro commit de um produto; a partir daí, a aplicação, o seu Dockerfile e o seu Terraform são da equipe, que pode mudá-los sob as mesmas verificações.

O que é obrigatório e o que é um padrão

  1. Três pilhas prontas para usar

    O golden path parte de um template do Copier que oferece três pilhas: Java (Spring), Node e Python (FastAPI). A plataforma gera com ele o repositório de um produto novo, na pilha que a sua entrada do catálogo nomeia, com as raízes de Terraform, o Dockerfile e um pipeline feito dos componentes da plataforma. Cada mudança no template gera de novo os três exemplos e os compara com os que estão no repositório; o exemplo de cada pilha é compilado e testado sempre que a sua parte do template ou o pipeline muda.

  2. Ou o seu próprio Dockerfile

    Depois do primeiro commit, a aplicação é da equipe: ela pode mudar o Dockerfile ou adicionar outro, listado em .airframe/images.yaml. Cada FROM precisa nomear uma das imagens base da plataforma, fixada: hoje Node, Python, Java, Bun, PostgreSQL e Redis, e uma pilha que não tem a sua pede à plataforma que a adicione. O compilador confiável compila cada imagem listada na aprovação e a atesta, como faz com as do template. Os jobs de compilação e de testes da plataforma conhecem só as três pilhas do template: outra pilha não roda nenhum deles, e os seus merge requests não passam no controle de cobertura até que a sua entrada do catálogo reduza quality.minimum_coverage, o que um líder de equipe ou um líder de domínio aprova.

  3. Os módulos ajudam; recursos diretos são permitidos

    Os módulos de Terraform do golden path codificam os padrões, e uma raiz de produto pode declarar recursos próprios no lugar deles. O pacote de políticas avisa sobre cada recurso que uma raiz de produto declara fora de um módulo e pede um motivo no merge request; um aviso não impede nada. O que o pacote nega, ele nega seja qual for o jeito como o recurso foi escrito: um conjunto incompleto de rótulos, o acesso público, ou uma rede ou um projeto, que são da plataforma.

  4. Um serviço é aprovado uma vez

    Um serviço do Google Cloud além dos que todo projeto de produto recebe é aprovado uma vez, como uma entrada na lista de serviços aprovados do catálogo, pela equipe de plataforma. Depois, qualquer produto pode declará-lo na sua entrada: um líder de domínio aprova a declaração (a equipe de plataforma o substitui quando o líder não tem conta), e a fábrica de projetos habilita a API do serviço nos projetos faturados do produto e concede os seus papéis só às identidades de apply desse produto. O Memorystore for Redis é o primeiro.

Obrigatório e opcional

O que a plataforma exige de um produto, ao lado do que oferece por padrão, linha a linha
ObrigatórioOpcional
Uma entrada no catálogoA pilha: Java, Node ou Python com a compilação e os testes da plataforma, ou outra sobre uma imagem base da plataforma sem eles
Inclui só componentes de CI da plataforma; os jobs próprios da equipe não podem implantarOs módulos de Terraform do golden path
Uma imagem base da plataforma, fixada, em cada FROMA aplicação do template, que a equipe pode mudar depois do primeiro commit
Os rótulos da plataforma em cada recurso que leva rótulosUm banco de dados, tópicos, um sandbox, serviços aprovados

O que torna isso verdade

Cada pilha é compilada e testada quando a sua parte do template muda.
O pipeline do golden-path gera de novo os três exemplos a partir do catálogo vivo e exige que sejam iguais aos que estão no repositório sempre que o template, os exemplos ou o pipeline mudam (template:render). Ele compila e testa o exemplo de uma pilha (template:test, template:test-python, template:test-java) quando os arquivos do template dessa pilha, o seu exemplo ou o pipeline mudam. O catálogo da demo declara um produto ativo em cada pilha: tracking em Java, invoicing em Python, tax-rules em Node.
O seu próprio Dockerfile é compilado sobre uma imagem base da plataforma.
As regras de Dockerfile do pacote negam um FROM ou um COPY --from fora das imagens base da plataforma, um não fixado e um calculado a partir de um argumento de compilação, nos Dockerfiles que o .airframe/images.yaml lista. A partir da versão da plataforma 2026.10.01-1, a validação injetada as roda em todo merge request que muda um Dockerfile listado chamado Dockerfile, Dockerfile.* ou *.Dockerfile, e o airframe validate as roda localmente. O compilador confiável compila e atesta exatamente essa lista na aprovação.
Recursos diretos são permitidos, com um aviso.
O pacote avisa sobre cada recurso gerenciado que uma raiz de produto declara fora de um módulo e pede um motivo no merge request, e um aviso não faz falhar nada. As suas regras de negação valem para cada recurso, direto ou não, e os tipos que são da plataforma, como as redes, os projetos e os perímetros, são negados numa raiz de produto.