catalog

O repositório do catálogo é a fonte da verdade de toda a plataforma: pequenos arquivos YAML que dizem quais produtos, equipes e pessoas existem e quem é responsável pelo quê. Ele não roda nada na nuvem sozinho. Seu trabalho é verificar se cada mudança nesses arquivos faz sentido e, depois que uma mudança é integrada, iniciar os pipelines que fazem o mundo real corresponder a ela. As ideias por trás estão na página do conceito de catálogo; esta página é sobre o repositório.

Para que serve

O catálogo existe para que haja um só lugar para mudar a organização, e um só registro de cada mudança. Um produto novo, um membro novo de uma equipe, um orçamento maior ou um produto aposentado é um merge request aqui, aprovado pelas pessoas que o próprio catálogo nomeia.

O que ele contém

A hierarquia: um arquivo por jornada, domínio e contexto, cada um com o nome do seu caminho e com seus líderes.
Os produtos: um arquivo por produto, com sua equipe, criticidade, classificação de dados, objetivos de recuperação, orçamento, pilha e ciclo de vida.
As equipes e as pessoas: quem pertence a qual equipe, com qual papel, e o status de cada pessoa.
O modelo de responsáveis: ownership/protected-paths.yaml, que diz quem precisa aprovar qual mudança, aqui e em cada repositório de produto.
Os serviços aprovados: um arquivo por serviço do Google Cloud que a plataforma aprovou além dos que todo produto recebe, como o Memorystore for Redis.
As lápides: um arquivo por produto removido, para que seu nome nunca seja reutilizado.
O esquema e as verificações: JSON Schemas para cada tipo de arquivo, e os scripts que verificam as regras que um esquema não consegue expressar, como “a equipe de um produto vive no contexto do produto”.

Como ele se conecta

Nada no catálogo lê outra coisa; todo o resto lê o catálogo.

Depois de um merge, o pipeline do catálogo inicia os pipelines do landing-zone, do operations e do control-plane, nessa ordem, e depois o landing-zone mais uma vez. Cada um planeja e aplica suas raízes contra o conteúdo novo do catálogo. A página de reconciliadores explica a cadeia.
O controle de aprovação lê o modelo de responsáveis a partir da branch main protegida do catálogo para decidir se um merge request em qualquer lugar tem as aprovações certas.
O template do golden-path pega os valores de um produto da sua entrada no catálogo quando gera o primeiro commit do produto.
O catálogo de arquitetura, o mapa da plataforma com cada produto, recebe do pipeline deste repositório uma página de jornadas, domínios, equipes e pessoas.

Quem o muda, e como

Qualquer pessoa com acesso ao repositório pode propor uma mudança. Quem precisa aprová-la depende do que ela toca: o arquivo de um produto precisa da sua equipe ou dos seus líderes, um aumento de orçamento de um líder do domínio, uma mudança de ciclo de vida de duas pessoas, e a estrutura de dois membros da equipe de plataforma. O controle de aprovação verifica isso em cada merge request, e sua aprovação é obrigatória para integrar.

O pipeline faz duas coisas:

Em um merge request, ele valida cada arquivo contra seu esquema, roda as verificações de coerência, confere se uma mudança de ciclo de vida tem o rótulo lifecycle e passa pelos estados em ordem, e roda os testes das próprias verificações quando elas mudam.
Na main, depois de um merge, ele primeiro deixa um produto cujo ciclo de vida mudou aplicar essa mudança pelo seu próprio pipeline, depois inicia a cadeia de reconciliadores, publica sua página do catálogo de arquitetura, e mantém uma nota no merge request integrado que acompanha a cadeia.

O catálogo não tem raízes de Terraform próprias e não tem nenhuma identidade que possa mudar um projeto na nuvem. Seu custo permanente é zero.

Onde fica

No repositório catalog: