Este estudo apresenta uma experiência profissional real de forma anonimizada. Nomes de empresas, contas, domínios, repositórios e detalhes sensíveis foram omitidos.
01 / CONTEXTO
O deploy acontecia. A plataforma precisava explicar por que, quando e a partir de qual versão.
Em um ecossistema com múltiplos microsserviços, ambientes e squads, executar comandos de deploy diretamente pelo pipeline cria dependência de permissões no cluster e dificulta separar construção de artefato de operação do ambiente.
O modelo GitOps adotou o Git como registro do estado desejado e o ArgoCD como responsável pela reconciliação. O pipeline passou a produzir uma imagem imutável e registrar sua versão; a entrega ficou a cargo de um controlador que compara continuamente repositório e cluster.
PRINCÍPIO DO PROJETOO ambiente deve ser reproduzível a partir do que está versionado, aprovado e visível no Git.
02 / DESAFIO
Cada ambiente tinha um ritmo diferente, mas precisava seguir a mesma governança.
Desenvolvimento recebe mudanças frequentes. Homologação precisa estabilizar uma release. Produção exige controle e aprovação. O desenho deveria preservar essas diferenças sem criar três modelos de entrega impossíveis de manter.
Escala
Muitos serviços precisavam seguir o mesmo padrão sem perder autonomia.
Promoção
A versão validada deveria avançar sem ser reconstruída em cada ambiente.
Governança
Branches, releases, aprovações e correções precisavam ter papéis claros.
Drift
Mudanças manuais no cluster não poderiam se tornar o estado oficial.
03 / MODELO OPERACIONAL
CI produz o artefato. Git registra a intenção. ArgoCD realiza a entrega.
O fluxo foi separado por responsabilidades. O repositório da aplicação concentra código e validações; o registro armazena a imagem versionada; o repositório GitOps define qual imagem deve rodar; e o ArgoCD aplica esse estado ao cluster.
DESENVOLVIMENTOEvolução contínua e validação rápida das integrações.
HOMOLOGAÇÃOEstabilização da release e geração de candidatos validados.
PRODUÇÃOPromoção controlada da versão já testada e aprovada.
04 / DECISÕES TÉCNICAS
O desenho do fluxo evitou que GitOps virasse apenas outro nome para deploy automático.
Imagem imutável e versão rastreável
Cada build gera uma referência única. A mesma imagem validada é promovida entre ambientes, evitando reconstruções que poderiam produzir artefatos diferentes sob um mesmo número de versão.
Branches com papéis explícitos
O fluxo distinguiu desenvolvimento contínuo, estabilização e produção. Correções em uma release partem do contexto que está sendo validado, sem misturar automaticamente código ainda em desenvolvimento.
development:
source: develop
version: commit_sha
homologation:
source: release/*
version: release_candidate
production:
source: main
version: approved_releaseApplicationSet para consistência em escala
Aplicações relacionadas foram descritas por um padrão comum, com valores específicos onde necessário. Isso facilitou a expansão entre serviços e reduziu diferenças acidentais de configuração.
- Convenções de namespace, projeto e repositório.
- Parâmetros próprios para aplicação e ambiente.
- Visibilidade central do estado de sincronização e saúde.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: brown-applications
namespace: argocd
spec:
generators:
- list:
elements:
- app: lab-test
namespace: brown
- app: brown-test
namespace: brown
template:
metadata:
name: "{{app}}-production"
spec:
project: brown
source:
repoURL: https://github.com/brown-cloud/gitops-lab.git
targetRevision: main
path: "apps/{{app}}/overlays/production"
destination:
server: https://kubernetes.default.svc
namespace: "{{namespace}}"
syncPolicy:
automated:
prune: true
selfHeal: truePipeline sem acesso administrativo ao cluster
O CI registra a intenção de mudança, mas não precisa executarkubectl apply com privilégios amplos. O ArgoCD, instalado e governado na plataforma, realiza a reconciliação dentro das fronteiras definidas.
05 / OPERAÇÃO
GitOps só funciona bem quando a equipe consegue interpretar o estado.
- 01
Padronização
Definição das convenções de repositório, branches, versões, manifests e aplicações.
- 02
Ambiente piloto
Validação do ciclo completo no desenvolvimento antes da expansão.
- 03
Homologação
Implementação do fluxo de release candidates e correções durante a estabilização.
- 04
Produção
Promoção da imagem aprovada com controles e rastreabilidade do histórico.
- 05
Sustentação
Acompanhamento de sync, health, drift e falhas de configuração junto às squads.
06 / RESULTADOS
O deploy deixou de ser uma ação isolada e passou a ser um estado explicável.
Sem métricas públicas disponíveis, os resultados são apresentados pela mudança operacional observada, sem estimar ganhos numéricos.
Rastreabilidade ponta a ponta entre código, imagem, alteração declarativa e versão em execução.
Ambientes mais consistentes por meio de padrões reaproveitáveis e configurações versionadas.
Promoção mais segura da mesma imagem validada entre homologação e produção.
Menor dependência de ações manuais com reconciliação contínua do estado desejado.
Visibilidade operacional sobre sincronização, saúde, diferenças e histórico das aplicações.
07 / APRENDIZADOS
GitOps é um modelo operacional, não somente uma ferramenta.
Instalar o ArgoCD não torna uma plataforma declarativa por si só. É preciso definir quem altera o estado desejado, como as versões são promovidas, quais mudanças exigem aprovação e como as equipes respondem a drift ou falhas de sincronização.
O valor apareceu quando o Git se tornou uma linguagem comum entre desenvolvimento e operação: a intenção ficou revisável, o histórico ficou acessível e o cluster passou a convergir para uma configuração conhecida.
william@devops:~$ echo $LESSON_LEARNED
"GitOps transforma o deploy em uma decisão versionada, revisável e continuamente reconciliada."