Como um produto passa a existir
Uma equipe propõe
Tudo começa como um arquivo. Para criar um produto, uma equipe adiciona uma entrada ao catálogo: quem é o responsável, sua pilha tecnológica, sua criticidade e seu orçamento mensal. Esse é o pedido inteiro.
Regras testadas julgam a mudança
O pacote de políticas verifica a mudança com regras testadas: nomes, rótulos, exposição pública, os componentes do pipeline. Uma regra que falha diz o que está errado, e muitas vezes o que fazer no lugar, em palavras escritas para a pessoa ou o agente de código que escreveu a mudança.
Os responsáveis aprovam a intenção
O catálogo diz quem é responsável pelo quê. O controle de aprovação aprova o merge request somente quando os responsáveis atuais o tiverem aprovado, e vincula a própria aprovação ao commit que verificou; a aprovação de alguém à própria mudança não conta.
O orçamento vira um limite
O orçamento mensal da entrada é um limite, não uma anotação. Depois que o produto existe, cada merge request do seu repositório é planejado e tem o custo calculado na aprovação, e uma verificação de status mantém o merge fechado enquanto os planos somarem mais que esse orçamento. Aumentá-lo é outro merge request no catálogo.
Os pipelines o constroem
Depois do merge, uma cadeia de pipelines lê o catálogo e constrói o produto: seus projetos e identidades no Google Cloud, seu repositório a partir do golden path, seus painéis e seus nomes de host no edge compartilhado. Nenhuma pessoa executa um comando.
O produto está no ar
Assim que seus projetos são faturados, o que é outro merge request no landing-zone, a equipe tem um repositório cujo pipeline já implanta, um nome de host protegido por login único e painéis que mostram seu serviço e seu custo.