SaaS fintech: cerca de 3x mais releases em produção por semana
Construímos o pipeline de releases, o portal Backstage e a observabilidade de uma plataforma SaaS de análise de portfólios.
Caminho de um release
- desenvolvimento
- 1 hora de teste
- controles
- produção
- ~3xreleases por semana
- 23% → 4%falhas de release
- 72 srollback em dev
Desenhado a partir do caso. É um sistema do cliente e não é mostrado.
O trabalho
Cliente: MPI
- Status
- Plataforma em produção, trabalho em andamento
- Cronologia
- Em andamento desde janeiro de 2025
O que mudou desde o novo pipeline de releases?
Para compradores e vendedores de fundos. Um engenheiro de plataforma da Clouditive, trabalhando com um agente de IA, atua ao lado do líder de DevOps do cliente e de cerca de 8 engenheiros.
Cada número abaixo foi medido nos sistemas do próprio cliente: GitLab, Argo CD e Kargo, e seu repositório de métricas.
As releases em produção passaram de cerca de 1 por semana para quase 4. A mediana entre o merge e a produção caiu de mais de uma semana para poucos dias, e as falhas de release caíram de 23% para 4%. A produção foi de zero regras de alerta para 275, e uma única ação substituiu sete passos manuais. Em outubro de 2026, a primeira release pelo novo pipeline rodou com as 12 imagens de serviço verificadas.
~3xreleases por semana
Cerca de 3x mais releases em produção por semana: de 1,15 por semana (abril a julho de 2026) para entre 3,7 e 4,0 por semana (últimos 30 dias)
23% → 4%falhas de release
Falhas de release em produção caíram de 23% para 4%
275regras de alerta
De zero alertas em produção para 275 regras de alerta
72 srollback em dev
Ensaiado em dev: rollback em 72 s e avanço de volta em 124 s, ambos verificados
Também registrado
- Mediana entre o merge e a produção caiu de 7 a 9,5 dias para 3,4 a 4,3 dias; a primeira release pelo novo pipeline chegou à produção em cerca de 2 horas, incluindo 1 hora de soak
- Sete passos manuais e um checklist de certificação substituídos por uma única ação
- Primeira release em produção pelo novo pipeline de promoção; as 12 imagens de serviço em execução foram verificadas e coincidem com a release (outubro de 2026)
- As verificações automáticas agora podem bloquear uma release com defeito antes da produção
- Falha de falta de memória em relatórios grandes diagnosticada e corrigida
O que fizemos, por área
Áreas de trabalho
Entrega GitOps
O código novo chega sozinho ao dev. A produção espera uma hora e precisa passar nas verificações de saúde.
Os pipelines de promoção rodam no Kargo sobre o Argo CD. Os deploys em dev são automáticos. A produção espera um soak de 1 hora, uma hora em que a release roda sob observação, e os gates de verificação.
Os gates são smoke checks na borda, verificações de reinício e readiness dos pods e um gate de proporção de erros HTTP 5xx que interrompe a release se a fatia de erros de servidor subir. As migrações de banco rodam em um hook pre-sync, antes de a nova versão entrar no ar, e o hook tira antes um snapshot do banco.
O rollback é a promoção novamente da release anterior, ensaiada em dev.
Plataforma interna de desenvolvimento
Um portal Backstage para serviços, deploys e custos
Serviços, deploys, custos, vulnerabilidades e saúde do CI ficam em um só portal.
- Catálogos de serviços e APIs gerados a partir do OpenAPI
- Mapa de dependências e status dos deploys
- Custo FinOps por serviço
- Vulnerabilidades de imagens
- Saúde do CI com estatísticas de 30 dias de testes instáveis e retentativas
- Diferenças de profiling entre deploys
Infraestrutura como código
Terraform e OpenTofu com Atlantis, migrando para Crossplane
As mudanças de infraestrutura passam por Terraform/OpenTofu com Atlantis. A migração para o Crossplane acontece em cutovers sem downtime, cada um com seu rollback.
Observabilidade e SRE
Alertas testados até disparar e falhas recorrentes corrigidas
A stack é VictoriaMetrics, Loki, Tempo, Pyroscope e Grafana. Cada alerta foi testado até disparar.
- A consolidação de nós não recria mais o armazenamento de logs cerca de três vezes por dia.
- O autoscaling não derruba mais a maioria dos pods de relatórios de uma só vez.
- De zero alertas em produção para 275 regras de alerta.
- Os jobs longos de relatórios são encerrados de forma ordenada.
- Uma falha de falta de memória em relatórios grandes foi diagnosticada e corrigida.
Custos e segurança
Auditorias de custos e uma verificação de vulnerabilidades a cada mudança de código
Auditorias de custos do cluster e da nuvem.
Um gate de vulnerabilidades orientado a SOC 2 roda em cada merge request, com exceções que expiram. Os segredos ficam em um cofre de segredos gerenciado.
Equipe
Um engenheiro de plataforma, com um agente de IA, dentro da equipe do cliente
Um engenheiro de plataforma da Clouditive trabalha com um agente de IA ao lado do líder de DevOps do cliente e de cerca de 8 de seus engenheiros. O trabalho começou em janeiro de 2025 e continua hoje.
Stack
Serviços utilizados
Os serviços por trás deste trabalho.
Do lado do cliente
Publicado sem nome e sem citação, com a aprovação do cliente.
Perguntas frequentes
O que a Clouditive faz para essa plataforma fintech?
Engenharia de plataforma, DevOps e SRE para uma plataforma SaaS de análise de portfólios: entrega GitOps, portal interno de desenvolvimento, infraestrutura como código, observabilidade, auditorias de custos e gates de segurança.
Como as releases chegam à produção?
Por pipelines de promoção do Kargo sobre o Argo CD. Os deploys em dev são automáticos. A produção espera uma hora sob observação e antes precisa passar em verificações automáticas de saúde e de taxa de erros.
Como funciona o rollback?
Promovendo novamente a release anterior. Foi ensaiado no ambiente de dev: 72 segundos para voltar e 124 segundos para avançar de novo, ambos verificados. Só o ensaio em dev foi medido.
Como as migrações de banco de dados são protegidas?
Um snapshot do banco é tirado automaticamente antes de cada migração.
O que o portal de desenvolvimento mostra?
Catálogos de serviços e APIs a partir do OpenAPI, mapa de dependências, status dos deploys, custo FinOps, vulnerabilidades de imagens, estatísticas de 30 dias de testes instáveis e retentativas do CI e diferenças de profiling entre deploys.
Qual stack de observabilidade a plataforma usa?
VictoriaMetrics, Loki, Tempo, Pyroscope e Grafana, com cada alerta testado até disparar.
De onde vêm os números de custo do portal?
Direto da API de faturamento da nuvem.
Como a segurança é verificada?
Cada merge request passa por uma verificação de vulnerabilidades orientada a SOC 2, com exceções que expiram, e os segredos ficam em um cofre de segredos gerenciado.
Qual é a stack?
AWS EKS com contas separadas de dev e prod, Argo CD, Kargo, Helm, Karpenter, Istio ambient, Kong, GitLab CI, Terraform/OpenTofu, Atlantis, Crossplane, Backstage, Node.js/TypeScript e Python.
O que você precisa resolver?
Respondemos a todo pedido em até 1 dia útil. Assinamos um NDA antes da conversa, se você pedir.