A vida de um produto

Esta página acompanha um produto durante toda a sua vida no Airframe, do merge request que o cria ao que o remove. Cada passo é um merge request ou um pipeline que um merge iniciou; ninguém cria nada à mão. O exemplo é o produto de pedidos da organização de demonstração, e os tempos vêm do próprio ensaio da plataforma de 2026-09-20, que levou produtos pelos mesmos passos do começo ao fim.

1. O merge request no catálogo

Um membro da equipe da loja adiciona products/shop.store.ordering.orders.yaml ao catálogo: a equipe responsável, a pilha, a criticidade, os objetivos de recuperação e um orçamento mensal de 5 dólares americanos. O pipeline do catálogo verifica o arquivo contra seu esquema e suas regras de coerência.

A equipe do produto, ou os líderes do seu contexto ou do seu domínio, o aprovam. O controle de aprovação verifica essas aprovações contra o modelo de responsáveis do catálogo, adiciona a sua, e o merge request pode ser integrado.

2. A cadeia

O merge inicia a cadeia de reconciliadores. O landing-zone cria o grupo do Google do produto, seus dois projetos, lk-store-orders-<rnd> e lk-store-orders-np-<rnd>, e suas identidades de plan e de apply. O operations cria sua pasta, seus painéis e suas regras de alerta no Grafana. O control-plane cria o repositório projectairframe/shop/store/ordering/orders, protege sua branch main e dá à equipe suas permissões.

Uma nota no merge request do catálogo acompanha a cadeia enquanto ela roda, com horários e links. No ensaio, a cadeia levou cerca de trinta minutos do merge até o repositório.

3. O primeiro commit do repositório

A raiz do control-plane para o domínio gera o template do golden-path com a entrada do catálogo e a saída Ready da fábrica de projetos como respostas, e envia o resultado como o primeiro commit do repositório. É uma aplicação funcionando para a pilha escolhida, suas raízes do Terraform, um pipeline feito com os componentes da plataforma, um runbook e instruções para um agente de código.

Esse primeiro commit não tem merge request próprio: sua aprovação é a do merge request do catálogo. O controle de aprovação o admite como o primeiro commit de um repositório de produto gerado a partir do catálogo, a única exceção a “na main só roda o commit de um merge request integrado”.

Desde o seu primeiro merge request, o repositório novo precisa da aprovação de uma pessoa nomeada que não escreveu a mudança. A aprovação do controle passa a ser exigida quando o repositório entra na lista do controle e no alcance da política de aprovação, dois merge requests no control-plane e no security-policies, como explica a página do controle.

4. O faturamento

Os projetos de um produto novo existem desde o início, com suas identidades e permissões, mas não estão vinculados ao faturamento. Enquanto não estiverem, o pipeline do produto pode planejar de verdade e passar pelo pacote de políticas, e seu apply para no primeiro serviço que precisa de faturamento, como o Cloud Run.

O faturamento é um merge request separado no repositório landing-zone, que adiciona o produto à lista de produtos faturados da fábrica de projetos. Ele fica separado de propósito: uma conta de faturamento só pode ter um número limitado de projetos faturados, então usar essa cota é uma decisão por si só. Depois que o produto tem faturamento, suas APIs são habilitadas, seus projetos entram na rede compartilhada, seus orçamentos do Google Cloud são criados, e o próximo pipeline aplica. Nada é recriado.

5. A primeira implantação

O primeiro pipeline do produto na main roda os mesmos passos de todos os seguintes: constrói as imagens no construtor confiável, as promove, planeja cada raiz, roda o pacote de políticas sobre os planos, e os aplica: a não produção por conta própria, e o sandbox antes da produção. Criar os bancos de dados é o que mais demora.

No ensaio, o produto respondeu no seu nome de host cerca de oitenta e cinco minutos depois que a entrada no catálogo foi integrada.

O produto responde em orders.store.shop.projectairframe.dev. Como todo nome de host da plataforma, ele fica atrás do Identity-Aware Proxy do Google, o login único da plataforma: só os membros do grupo de usuários do produto, que o catálogo preenche, conseguem chegar até ele.

A partir daqui, a equipe muda seu produto por merge requests, como descreve o caminho de uma mudança.

7. A aposentadoria

Para aposentar o produto, a equipe muda seu status no catálogo para retiring. O merge request precisa do rótulo lifecycle e de dois aprovadores além do autor: um da equipe do produto, e outro dos líderes do domínio ou da equipe de plataforma.

Depois do merge, o próprio pipeline do produto aplica primeiro a aposentadoria: seus serviços saem da borda compartilhada e vão a zero instâncias. Seus projetos, bancos de dados, buckets e repositório são todos mantidos. No ensaio, a aposentadoria levou menos de trinta minutos. O produto de pedidos da organização de demonstração está nesse estado hoje.

8. Removido, e a lápide

Depois da data retire_after da entrada, um último merge request de ciclo de vida muda o status para removed e adiciona a lápide do produto em retired-names/.

O próprio pipeline do produto destrói o que o produto roda, com as identidades do próprio produto. Depois, a cadeia desconecta os projetos da rede compartilhada, os exclui e agenda a exclusão do repositório. O Google Cloud mantém um projeto excluído recuperável por trinta dias.

O Google segura alguns endereços de rede por um tempo depois que os serviços que os usavam são excluídos, então a remoção termina na próxima execução da cadeia depois que o Google os libera: nos ensaios, entre meia hora e duas horas depois. Só um produto com faturamento pode ser removido assim; a plataforma não fatura um produto só para removê-lo.

O nome nunca mais é usado: o catálogo recusa qualquer produto novo com ele em todo o domínio.

Onde fica

No repositório landing-zone:

No repositório catalog:

No repositório control-plane:

docs/adr/0024: a nota de progresso no merge request do catálogo