Código da Aplicação vs Manifests do Kubernetes em Repositórios Separados

Por padrão, use repositórios separados. O repositório de código da aplicação guarda Go, Python, Node, o que for. Um segundo repositório de manifests guarda as Applications do Argo CD, os overlays do Kustomize e qualquer configuração de cluster. Esse é o padrão que a maioria dos setups de GitOps em produção acaba adotando, e existem quatro boas razões para isso. Primeiro, raio de impacto e permissões. Devs fazem commit de código livremente. Mudanças de manifests para produção geralmente precisam de code owners, branch protection e um conjunto menor de revisores. Separar os repositórios permite configurar essas regras de forma limpa. Segundo, ruído. O Argo CD observa o repositório de manifests. Se os manifests dividem repositório com o código da aplicação, cada edição de README aparece como uma mudança que o Argo CD precisa decidir o que fazer. Terceiro, loops de promoção de imagem. O CI builda uma imagem a partir do repositório de código e escreve a nova tag no repositório de manifests. Se os dois vivem no mesmo repositório, o commit de bump dispara outra execução de CI, que pode buildar, fazer push e dar bump de novo. Você acaba adicionando tags de skip-ci em todo lugar para parar o loop. Quarto, manifests geralmente são compartilhados. Uma stack de monitoramento, um ingress controller e três aplicações moram todos em um único repositório de manifests. Eles não pertencem ao código de nenhuma aplicação específica. Quando o monorepo é aceitável: um time, uma aplicação, sem separação por compliance. Não superengenharize esse caso.