Como um arquivo do catálogo se torna um produto
Um arquivo descreve o produto
A equipe adiciona products/shop.store.ordering.orders.yaml ao catálogo: a equipe responsável, a pilha tecnológica, a criticidade, os objetivos de recuperação e o orçamento mensal. O esquema e o lint do catálogo verificam o arquivo no pipeline do merge request.
Os responsáveis aprovam
O catálogo nomeia os líderes de cada jornada, domínio e contexto, e a equipe de cada produto. O controle de aprovação aprova o pedido somente quando os responsáveis atuais o tiverem aprovado, e vincula sua própria aprovação ao commit que verificou; não contam nem a aprovação do autor nem a de quem fez um commit.
A plataforma deriva o resto
Depois do merge, o pipeline do catálogo inicia uma cadeia de raízes do Terraform que o leem. A fábrica de projetos do domínio cria os dois projetos do Google Cloud do produto e suas identidades, operations cria seus painéis e a raiz do GitLab do domínio cria o repositório a partir do golden path. O nome de host chega ao edge compartilhado assim que o primeiro pipeline do produto o implanta.
O merge request acompanha o trabalho
Uma nota no merge request mesclado acompanha a cadeia enquanto ela roda: cada passagem com seu horário e seu link, o primeiro pipeline do novo repositório e o momento em que o produto responde no seu nome de host, atrás do login único. Uma falha nomeia seu job e o próximo passo. Um produto novo só roda quando seus projetos são faturados, o que é outro merge request no landing-zone, dentro da cota de projetos da conta de faturamento.
Aposentar é o mesmo arquivo
Mudar o status do produto para retiring tira seus serviços do edge e os deixa com zero instâncias, e mantém seus dados. Depois da data de aposentadoria da entrada, removed destrói o que o produto executa e exclui seus projetos e seu repositório. Cada mudança de status precisa de dois aprovadores além do autor, e um nome removido fica no catálogo como lápide, então nunca é reutilizado no seu domínio.