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 projeto não era apenas trocar uma ferramenta.
A iniciativa começou com a necessidade de migrar repositórios e pipelines do GitLab para o GitHub. Porém, uma migração direta manteria os mesmos limites do processo anterior. A oportunidade real era redesenhar a plataforma de entrega: padronizar workflows, melhorar a governança de branches, eliminar credenciais estáticas e conectar CI e GitOps de forma mais segura.
O ambiente atendia múltiplos serviços e times, com entregas destinadas a desenvolvimento, homologação e produção. Por isso, continuidade operacional, rastreabilidade e adoção gradual eram tão importantes quanto a tecnologia escolhida.
PRINCÍPIO DO PROJETOModernizar sem interromper: cada mudança precisava ser segura, observável e reversível.
02 / DESAFIO
Várias mudanças acontecendo no mesmo fluxo.
Repositórios, automações, permissões de cloud e processos de release precisavam evoluir de forma coordenada. Se uma dessas camadas fosse tratada isoladamente, a plataforma poderia funcionar tecnicamente, mas continuar difícil de operar.
Continuidade
Migrar gradualmente sem bloquear as entregas das squads.
Segurança
Retirar access keys persistentes dos pipelines e aplicar menor privilégio.
Governança
Definir branches, aprovações e releases compreensíveis para todos.
Consistência
Repetir o mesmo padrão entre aplicações e ambientes.
03 / ARQUITETURA
Responsabilidades separadas, fluxo conectado.
A arquitetura foi organizada para que o pipeline cuidasse da validação e da geração do artefato, enquanto o ArgoCD cuidava da reconciliação do estado desejado no Kubernetes. Essa separação evita que o processo de CI tenha permissões amplas diretamente no cluster.
CI valida, testa, constrói e publica a imagem versionada.
GITOPS registra a versão desejada em um repositório declarativo.
ARGOCD identifica a mudança e sincroniza o ambiente no Amazon EKS.
04 / DECISÕES TÉCNICAS
As ferramentas importam. As decisões importam mais.
Estratégia de branches alinhada aos ambientes
O fluxo foi organizado para deixar claro o papel de cada branch: desenvolvimento contínuo em develop, estabilização emrelease/* e produção em main. Correções seguem fluxos específicos, evitando alterações sem rastreabilidade durante a validação de uma release.
environments:
development:
branch: develop
homologation:
branch: release/*
production:
branch: main
release:
validation: rc-tags
approval: requiredAutenticação temporária com GitHub OIDC
Os workflows passaram a assumir roles IAM por meio de identidade federada. Assim, não foi necessário armazenar access keys da AWS como secrets de longa duração. As políticas foram separadas por finalidade e limitadas aos repositórios, branches e ações necessárias.
- Credenciais temporárias geradas somente durante a execução.
- Trust policies vinculadas ao contexto correto do repositório.
- Permissões mínimas para publicar imagens e atualizar o fluxo GitOps.
Workflows reutilizáveis e responsabilidades claras
Etapas comuns — validação, build, autenticação, publicação e versionamento — foram estruturadas em padrões reaproveitáveis. As particularidades permaneceram próximas de cada aplicação, evitando tanto duplicação excessiva quanto uma abstração difícil de manter.
Entrega declarativa com ArgoCD
O pipeline não executa comandos de implantação diretamente no cluster. Ele publica um artefato imutável e registra a versão desejada. O ArgoCD compara esse estado com o ambiente e realiza a sincronização, mantendo histórico e visibilidade do que foi implantado.
apiVersion: apps/v1
kind: Deployment
metadata:
name: lab-test
namespace: brown
spec:
replicas: 2
selector:
matchLabels:
app.kubernetes.io/name: lab-test
template:
metadata:
labels:
app.kubernetes.io/name: lab-test
spec:
serviceAccountName: lab-test
containers:
- name: lab-test
image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/lab-test:1.4.2-8f3a1c2
ports:
- name: http
containerPort: 3000
# A tag é atualizada pelo fluxo GitOps e reconciliada pelo ArgoCD.05 / EXECUÇÃO
Uma migração em ondas, com validação real.
A execução foi dividida em etapas pequenas para reduzir risco. Antes de ampliar o padrão, aplicações representativas foram usadas como piloto. Cada avanço validava não apenas o sucesso do workflow, mas o ciclo completo até a aplicação saudável no ambiente.
- 01
Inventário
Mapeamento de repositórios, pipelines, dependências, secrets e destinos de entrega.
- 02
Fundação
Criação das roles OIDC, convenções de branches, proteção e padrões de workflow.
- 03
Piloto
Migração de aplicações selecionadas e validação ponta a ponta em desenvolvimento.
- 04
Expansão
Aplicação progressiva do padrão às demais aplicações e ao ambiente de homologação.
- 05
Operação
Acompanhamento das squads, ajustes de documentação e estabilização do novo fluxo.
06 / RESULTADOS
Uma plataforma mais segura e compreensível.
Como não foram estabelecidas métricas públicas para este estudo, os resultados são apresentados de forma qualitativa, sem inventar percentuais ou ganhos.
Menor exposição de credenciais com autenticação temporária via OIDC.
Mais rastreabilidade entre alteração de código, imagem publicada e versão implantada.
Fluxos mais consistentes entre desenvolvimento, homologação e produção.
Melhor separação de responsabilidades entre CI, GitOps e operação do cluster.
Mais autonomia para as squads com padrões claros e suporte durante a adoção.
07 / APRENDIZADOS
O valor da plataforma aparece quando o time consegue usá-la.
Uma modernização de CI/CD não termina quando o novo pipeline fica verde. Ela termina quando o fluxo é seguro, compreendido pelas squads e sustentável para quem o opera.
O principal aprendizado foi tratar tecnologia, governança e adoção como partes do mesmo projeto. OIDC fortaleceu a segurança, GitOps aumentou a previsibilidade e os workflows padronizaram a execução — mas a migração gradual, a comunicação e a validação ponta a ponta foram o que transformaram essas peças em uma plataforma utilizável.
william@devops:~$ echo $LESSON_LEARNED
"Plataforma boa é aquela que entrega segurança sem criar barreiras para quem desenvolve."