Pular para o conteúdo

Disponível para propostasGoiânia ou remoto

jnogxavier
Voltar aos casos

Esteira de entrega em serviços financeiros

DevOps Engineer na BCJ, fevereiro a julho de 2026

O que deveria acontecer

Um pipeline por serviço, escrito e versionado junto do código de cada time.

O que acontecia

Dezenas de arquivos quase iguais, nenhum com cache, e ninguém dono de nenhum. Subir um serviço novo levava um dia.

O que eu fiz

Seis templates compartilhados no Azure DevOps, com build em estágios e cache. Perdi flexibilidade: quem precisa de algo fora do padrão abre exceção declarada, e isso aparece no diff.

Antesserviço Aserviço Bserviço Cpipeline Apipeline Bpipeline Cproduçãotrês arquivos quase iguais, nenhum com cacheDepoisserviço Aserviço Bserviço Cseis templatescache compartilhadoprodução
O ganho não foi um pipeline melhor. Foi todo serviço passar pelo mesmo caminho, e o cache deixar de ser decisão de cada time.

6minutos de buildcontra 15 minutos antes

O que isso destravou

  • Cada pipeline passou a rodar em menos tempo. O time espera menos para saber se um commit passou, e o agente fica livre mais cedo para o próximo.
  • Publicar um serviço ficou mais rápido. O serviço novo já nasce com a esteira pronta, em vez de copiar o pipeline de outro time e ajustar na mão.
  • Os agentes passaram a ficar em pools separados por tipo de serviço: um dedicado a um dos serviços, outro ao mobile e outro aos demais. A disputa por agente diminuiu, e a esteira de um grupo deixou de travar a de outro.
  • Melhorar a esteira virou uma mudança em um template, em vez de uma mudança em dezenas de arquivos.

O que eu faria diferente

Deixei a migração opcional tempo demais. Fiquei com dois padrões rodando por semanas, o que é pior do que qualquer um dos dois sozinho. Hoje eu começaria pelos três serviços mais barulhentos e migraria sem perguntar.