Isso aconteceu de verdade, no trabalho. Tirei nomes de empresa, contas, domínios, repositórios e qualquer detalhe sensível.
01 / CONTEXTO
O projeto não era só trocar de ferramenta.
Tudo começou porque era preciso levar repositórios e pipelines do GitLab para o GitHub. Só que, copiando tudo do jeito que estava, os problemas iam junto. Então aproveitei para refazer o caminho do deploy: padronizar os workflows, organizar as branches, tirar as chaves fixas e ligar o CI ao GitOps com mais segurança.
Eram vários serviços e vários times, entregando em desenvolvimento, homologação e produção. Não dava para parar as entregas, então ir aos poucos e saber o que mudou em cada passo importava tanto quanto a ferramenta.
PRINCÍPIO DO PROJETOMudar sem parar ninguém: cada passo tinha que ser seguro, visível e fácil de desfazer.
02 / DESAFIO
Várias mudanças acontecendo no mesmo fluxo.
Repositórios, automações, permissões na AWS e o processo de release tinham que mudar juntos. Se eu mexesse em uma parte só, até podia funcionar, mas continuaria difícil de operar.
Continuidade
Migrar aos poucos, sem travar a entrega dos times.
Segurança
Tirar as access keys fixas dos pipelines e deixar só a permissão necessária.
Regras claras
Branches, aprovações e releases que todo mundo entendesse.
Consistência
O mesmo padrão em todas as aplicações e ambientes.
03 / ARQUITETURA
Cada parte com o seu papel, tudo ligado.
O pipeline ficou responsável por testar e gerar a imagem. O Argo CD ficou responsável por deixar o Kubernetes igual ao que está no Git. Separando assim, o CI não precisa de permissão grande dentro do cluster.
CI testa, faz o build e publica a imagem com a versão.
GITOPS guarda no Git qual versão deve rodar.
ARGOCD vê a mudança e atualiza o ambiente no EKS.
04 / DECISÕES TÉCNICAS
A ferramenta importa. As decisões importam mais.
Estratégia de branches alinhada aos ambientes
Cada branch ganhou um papel: o dia a dia em develop, a estabilização em release/* e produção emmain. Correção tem caminho próprio, para ninguém mexer numa release em validação sem deixar rastro.
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 entrar na AWS assumindo uma role por OIDC. Com isso, nenhuma access key ficou guardada como secret. Cada role tem uma finalidade e só aceita os repositórios, branches e ações que precisa.
- A credencial só existe enquanto o workflow roda.
- A trust policy só aceita o repositório e a branch certos.
- Permissão só para publicar a imagem e atualizar o GitOps.
Workflows reutilizáveis e responsabilidades claras
O que todo mundo repetia (testes, build, login, publicação e versão) virou workflow reutilizável. O que é específico ficou no repositório de cada aplicação. Assim não tem cópia para todo lado, nem uma abstração que ninguém consegue manter.
Entrega declarativa com ArgoCD
O pipeline não roda nenhum comando de deploy no cluster. Ele publica a imagem e anota no Git qual versão deve rodar. O Argo CD compara com o que está no cluster e sincroniza, e fica o histórico de tudo que foi para o ar.
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
Migrei em ondas, testando de verdade.
Dividi o trabalho em passos pequenos para diminuir o risco. Antes de levar o padrão para todo mundo, testei com algumas aplicações piloto. E não bastava o workflow ficar verde: eu só considerava pronto quando a aplicação estava saudável no ambiente.
- 01
Inventário
Levantei repositórios, pipelines, dependências, secrets e para onde cada um fazia deploy.
- 02
Fundação
Criei as roles OIDC, o padrão de branches, as proteções e os workflows.
- 03
Piloto
Migrei algumas aplicações e testei o caminho inteiro em desenvolvimento.
- 04
Expansão
Fui levando o padrão para as outras aplicações e para homologação.
- 05
Operação
Acompanhei os times, ajustei a documentação e deixei o fluxo novo estável.
06 / RESULTADOS
Mais segura e mais fácil de entender.
Não tenho números que possa publicar, e não vou inventar. Então conto o que mudou.
Nenhuma chave fixa: o login na AWS é temporário, por OIDC.
Dá para seguir o caminho do commit até a imagem e a versão que está no ar.
O mesmo fluxo em desenvolvimento, homologação e produção.
Cada um no seu papel: CI, GitOps e operação do cluster separados.
Times mais independentes, com padrão claro e ajuda na adoção.
07 / APRENDIZADOS
Plataforma só vale alguma coisa se o time consegue usar.
Mudar o CI/CD não acaba quando o pipeline novo fica verde. Acaba quando o fluxo é seguro, os times entendem e quem opera consegue manter.
O que mais aprendi foi tratar ferramenta, regras e adoção como um projeto só. O OIDC deixou mais seguro, o GitOps deixou mais previsível e os workflows deixaram tudo no mesmo padrão. Mas o que fez funcionar de verdade foi ir aos poucos, conversar com os times e testar o caminho inteiro a cada passo.
william@devops:~$ echo $LESSON_LEARNED
"Plataforma boa deixa seguro sem atrapalhar quem desenvolve."