Como a FinTech X reduziu o tempo de entrega em 70% com CI/CD

“Automatizar o fluxo de entrega foi a única forma de escalar sem perder qualidade.” – Diretor de Engenharia da FinTech X

---

Introdução

A FinTech X, especializada em pagamentos instantâneos, precisava lançar novas funcionalidades a cada duas semanas para acompanhar a concorrência. Contudo, o processo de deploy ainda era manual, dependia de scripts ad‑hoc e exigia intervenção de operadores de infraestrutura. Os principais sintomas eram:

Sintoma	Impacto
Lead time de 15‑21 dias	Perda de oportunidades de mercado
30 % de releases com falhas em produção	Aumento de churn
Tempo de rollback > 4 h	Instabilidade percebida pelos clientes

A diretoria definiu como meta reduzir o lead time em 70 % e diminuir a taxa de falhas para menos de 5 % em seis meses. O desafio: criar uma pipeline de entrega contínua que fosse reprodutível, auditável e visível para toda a equipe.

Este artigo descreve, passo a passo, como a FinTech X projetou, implementou e mensurou a solução, apresentando resultados concretos e trechos de código que podem ser reutilizados em outros projetos.

---

Desenvolvimento

1. Diagnóstico e definição de metas

Antes de tocar na automação, a equipe realizou um value stream mapping para identificar gargalos. Os principais pontos críticos foram:

Compilação manual – desenvolvedores rodavam npm run build localmente e enviavam artefatos via SCP.

Teste fragmentado – apenas testes unitários eram executados; testes de integração rodavam em ambientes de staging diferentes.

Deploy sem versionamento – scripts de deploy não versionavam as imagens Docker, dificultando rollback.

Com base nesses achados, foram estabelecidas métricas‑chave (KPIs):

KPI	Valor atual	Meta
Lead time (commit → produção)	18 dias	≤ 5 dias
Taxa de falhas em produção	30 %	≤ 5 %
Tempo médio de rollback	4 h	≤ 30 min

2. Construindo a pipeline automatizada

A solução foi arquitetada em três camadas:

Containerização – todas as aplicações foram empacotadas em imagens Docker.

CI/CD – GitHub Actions orquestrou build, testes, lint e publicação.

Versionamento semântico – tags vMAJOR.MINOR.PATCH foram criadas automaticamente.

2.1 Dockerfile padrão

# Dockerfile - aplicação Node.js

FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build


FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./
RUN npm ci --only=production
EXPOSE 8080
CMD ["node", "dist/index.js"]

Pontos de atenção:

• Multistage build reduz o tamanho final da imagem em ~60 %.
• npm ci garante reproduzibilidade ao usar o package-lock.json.

2.2 Workflow GitHub Actions

# .github/workflows/ci-cd.yml

name: CI/CD Pipeline


on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]


jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3


      - name: Set up Node
        uses: actions/setup-node@v3
        with:
          node-version: '20'


      - name: Install dependencies
        run: npm ci


      - name: Lint
        run: npm run lint


      - name: Unit tests
        run: npm test -- --coverage


      - name: Build Docker image
        run: |
          IMAGE_TAG=ghcr.io/${{ github.repository }}:${{ github.sha }}
          docker build -t $IMAGE_TAG .
          echo "IMAGE_TAG=$IMAGE_TAG" >> $GITHUB_ENV


      - name: Push image to GitHub Container Registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}


      - name: Publish image
        run: |
          docker push ${{ env.IMAGE_TAG }}


  deploy:
    needs: build-test
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Trigger deployment webhook
        env:
          IMAGE: ${{ needs.build-test.outputs.IMAGE_TAG }}
        run: |
          curl -X POST -H "Content-Type: application/json" \
            -d "{\"image\":\"$IMAGE\"}" \
            ${{ secrets.DEPLOY_WEBHOOK_URL }}

Como funciona:

• Build + Test: Compila, roda lint e testes unitários.
• Docker: Cria a imagem, marca com SHA do commit e envia para o registro interno.
• Deploy: Um webhook dispara o orquestrador de containers (ex.: AWS ECS, Azure Container Apps) que puxa a imagem e realiza o rollout.

3. Implantação contínua com monitoramento avançado

Com a pipeline pronta, o próximo passo foi garantir que qualquer problema fosse detectado imediatamente. A FinTech X adotou Prometheus + Grafana para observabilidade, e definiu alertas críticos.

3.1 Regra de alerta de latência

# prometheus/rules.yml

groups:
  - name: application.rules
    rules:
      - alert: HighResponseTime
        expr: avg_over_time(http_request_duration_seconds{job="payments-service"}[5m]) > 0.5
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Latência alta no serviço de pagamentos"
          description: "A latência média ultrapassou 500 ms nos últimos 5 minutos."

3.2 Dashboard resumido (Grafana)

Métrica	Valor atual
Taxa de erro (5xx)	0.2 %
Latência 95‑percentil	210 ms
Deploys bem‑sucedidos	98 %

O dashboard foi compartilhado com todos os squads, permitindo blameless post‑mortems e ação rápida.

4. Resultados mensuráveis

Após três meses de operação, os indicadores mostraram evolução significativa:

KPI	Antes	Depois	Variação
Lead time (commit → produção)	18 dias	5,2 dias	‑71 %
Taxa de falhas em produção	30 %	4,3 %	‑85 %
Tempo médio de rollback	4 h	22 min	‑91 %
Tempo de build (CI)	—	7 min	—
Cobertura de testes unitários	62 %	84 %	+22 pp

Além dos números, a equipe ganhou confiança para lançar experimentos de forma segura, reduzindo o time‑to‑market de novas funcionalidades de 2 meses para menos de 3 semanas.

---

Exemplos Práticos

4.1 Script de rollback rápido

#!/usr/bin/env bash
rollback.sh – desfaz o último deploy no ECS

set -euo pipefail


SERVICE_NAME="payments-service"
CLUSTER="prod-cluster"

Busca a task definition anterior

PREV_REV=$(aws ecs list-task-definitions \
  --family-prefix $SERVICE_NAME \
  --sort DESC \
  --max-items 2 \
  --query "taskDefinitionArns[1]" \
  --output text)


echo "Revertendo para a task definition: $PREV"


aws ecs update-service \
  --cluster $CLUSTER \
  --service $SERVICE_NAME \
  --task-definition $PREV \
  --force-new-deployment


echo "Rollback disparado com sucesso."

O script utiliza a CLI da AWS e garante que o rollback seja concluído em menos de 30 minutos, conforme a métrica de sucesso.

4.2 Teste de integração usando Testcontainers

```java // src/test/java/com/fintech