Melhores Práticas de Integração Contínua

Integração Contínua significa mesclar código frequentemente e validar cada mescla automaticamente. Bom CI captura bugs cedo, permite refatoração confiante e mantém a branch main sempre liberável. Este guia cobre implementação prática de CI.

Estágios do Pipeline CI

Estrutura do Pipeline

Estágios Essenciais

ESTÁGIOS DO PIPELINE CI
═══════════════════════

ESTÁGIO 1: LINT & FORMATAÇÃO
─────────────────────────────────────
Propósito: Estilo de código consistente
Ferramentas: ESLint, Prettier, Black, etc.
Tempo: <1 minuto

Verificações:
├── Formatação de código
├── Regras de estilo
├── Ordenação de imports
├── Sem variáveis não usadas
└── Capturar problemas antes da revisão

ESTÁGIO 2: TESTES UNITÁRIOS
─────────────────────────────────────
Propósito: Verificação de lógica
Ferramentas: Jest, PyTest, JUnit, etc.
Tempo: <5 minutos

Executar:
├── Todos os testes unitários
├── Testes rápidos, isolados
├── Sem dependências externas
├── Áreas de alta cobertura
└── Feedback rápido

ESTÁGIO 3: BUILD
─────────────────────────────────────
Propósito: Verificar compilação
Ferramentas: Webpack, tsc, cargo, etc.
Tempo: <3 minutos

Verificar:
├── Código compila
├── Dependências resolvem
├── Assets gerados
├── Artefatos de build criados
└── Pode produzir output

ESTÁGIO 4: TESTES DE INTEGRAÇÃO
─────────────────────────────────────
Propósito: Interação de componentes
Ferramentas: Frameworks de teste + DB/servicos de teste
Tempo: <10 minutos

Testar:
├── Endpoints de API
├── Operações de banco
├── Interações de serviço
├── Fluxos chave
└── Cenários realistas

ESTÁGIO 5: VARREDURA DE SEGURANÇA
─────────────────────────────────────
Propósito: Encontrar vulnerabilidades
Ferramentas: Snyk, OWASP, npm audit, etc.
Tempo: <5 minutos

Varredura:
├── Vulnerabilidades de dependências
├── Problemas de segurança de código
├── Detecção de segredos
├── Conformidade de licença
└── Gates de segurança

Configuração do Pipeline

EXEMPLO DE CONFIGURAÇÃO CI
══════════════════════════

EXEMPLO GITHUB ACTIONS:
─────────────────────────────────────
name: CI
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm run build

  integration:
    runs-on: ubuntu-latest
    needs: [lint, test, build]
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm run test:integration

EXECUÇÃO PARALELA:
─────────────────────────────────────
├── Lint, Test, Build rodam em paralelo
├── Integração roda após todos passarem
├── Pipeline geral mais rápido
├── Falha precoce, feedback precoce
└── Otimizar para velocidade

Feedback Rápido

Velocidade Importa

OTIMIZAÇÃO DE VELOCIDADE CI
═══════════════════════════

POR QUE VELOCIDADE IMPORTA:
─────────────────────────────────────
CI lento:
├── Desenvolvedores esperam
├── Mudam para outro trabalho
├── Custo de troca de contexto
├── Agrupam mudanças
├── Encontram problemas tarde
└── Frustração

CI rápido:
├── Feedback imediato
├── Corrigem enquanto contexto fresco
├── Commits mais frequentes
├── Capturam problemas cedo
├── Felicidade do desenvolvedor
└── Qualidade maior

METAS DE VELOCIDADE:
─────────────────────────────────────
├── Lint: <1 minuto
├── Testes unitários: <5 minutos
├── Pipeline completo: <10 minutos
├── Máximo absoluto: 15 minutos
└── Mais rápido é melhor

ESTRATÉGIAS DE OTIMIZAÇÃO:
─────────────────────────────────────
Caching:
├── Cache de dependências
├── Cache de artefatos de build
├── Cache de fixtures de teste
├── Reusar o que não muda
└── Aceleração significativa

Paralelização:
├── Executar estágios independentes em paralelo
├── Dividir suítes de teste
├── Múltiplos runners
├── Reduzir tempo de relógio
└── Usar recursos disponíveis

Otimização de teste:
├── Testes unitários rápidos (maioria)
├── Menos testes de integração
├── Testes mais lentos por último
├── Pular áreas não mudadas
└── Pirâmide de teste

Mantendo Verde

Sempre Liberável

MANTENDO CI VERDE
═════════════════

REGRA: CORRIJA BUILDS QUEBRADOS IMEDIATAMENTE
─────────────────────────────────────
Quando CI falha:
├── Pare outro trabalho
├── Corrija imediatamente
├── Ou reverta a mudança
├── Prioridade máxima da equipe
└── Build quebrado = equipe bloqueada

RESPONSABILIDADE:
─────────────────────────────────────
Quem quebrou corrige:
├── Seu commit, sua correção
├── Resposta rápida
├── Não deixe para depois
├── Não ignore
└── Propriedade

EVITE BUILDS QUEBRADOS:
─────────────────────────────────────
Prevenção:
├── Rode testes localmente primeiro
├── Commits pequenos, frequentes
├── Revisão de código thorough
├── Hooks pre-commit
└── Capture antes do push

Pre-commit:
├── Verificação de lint
├── Verificação de formatação
├── Testes unitários rápidos
├── Capture problemas óbvios
└── Feedback mais rápido

VERDE = LIBERÁVEL:
─────────────────────────────────────
Branch main deve sempre ser:
├── Buildável
├── Testes passando
├── Implantável
├── Pronto para produção
└── Pode enviar qualquer hora

Frequência de Integração

Mesclar Frequentemente

INTEGRAÇÃO FREQUENTE
════════════════════

MESCLAR DIARIAMENTE (PELO MENOS):
─────────────────────────────────────
Melhor prática:
├── Múltiplas mesclas por dia
├── Mudanças pequenas cada vez
├── Nunca mais que 1 dia sem mescla
├── Branches longos = problemas de integração
└── Contínuo significa contínuo

MUDANÇAS PEQUENAS:
─────────────────────────────────────
Benefícios do pequeno:
├── Mais fácil de revisar
├── Menos propenso a conflitos
├── Problemas isolados
├── Fácil de reverter
├── Feedback mais rápido
└── Risco menor

FEATURE FLAGS:
─────────────────────────────────────
Mesclar recursos incompletos:
├── Código implantado mas inativo
├── Flag controla visibilidade
├── Integre continuamente
├── Habilite quando pronto
└── Desacople deploy de release

Exemplo:
├── Mesclar código de auth (flag off)
├── Continue desenvolvimento
├── Mantenha integrando
├── Habilite flag quando completo
├── Usuários nunca veem incompleto

Gates de Qualidade

Verificações Necessárias

GATES DE QUALIDADE CI
═════════════════════

NECESSÁRIO PARA MESCLA:
─────────────────────────────────────
☐ Todos os testes passando
☐ Lint limpo
☐ Build sucede
☐ Threshold de cobertura atingido
☐ Varredura de segurança limpa
☐ Revisão de código aprovada
└── Todos devem passar para mesclar

PROTEÇÃO DE BRANCH:
─────────────────────────────────────
Configurações GitHub:
├── Requer verificações de status
├── Requer branches atualizadas
├── Requer aprovação de revisão
├── Sem force push para main
├── Sem commits diretos para main
└── Reforce qualidade

THRESHOLDS DE COBERTURA:
─────────────────────────────────────
Defina mínimo:
├── 80% cobertura geral
├── Sem diminuição da baseline
├── Novo código deve ser coberto
├── Falhe build se abaixo
└── Mantenha qualidade ao longo do tempo

GATES DE SEGURANÇA:
─────────────────────────────────────
├── Sem vulnerabilidades críticas
├── Sem alto sem exceção
├── CVE conhecido bloqueando
├── Detecção de segredos
└── Segurança não-negociável

Integração GitScrum CI

Fluxo de Trabalho Conectado

INTEGRAÇÃO GITSCRUM + CI
════════════════════════

LINK PARA TAREFAS:
─────────────────────────────────────
PR vinculado a tarefa:
├── Status CI visível na tarefa
├── Auto-atualização na conclusão CI
├── Mescla → atualização de status da tarefa
└── Contexto conectado

TRANSIÇÕES AUTOMATIZADAS:
─────────────────────────────────────
Eventos CI gatilham:
├── PR mesclado → Tarefa para "Concluído"
├── CI falhou → Alerta na tarefa
├── Deploy completo → Notificar
└── Automação de fluxo de trabalho

VISIBILIDADE:
─────────────────────────────────────
Dashboard:
├── Widget de status CI
├── Builds falhados visíveis
├── Status de deploy
├── Consciência da equipe
└── Problemas surgem rápido

VINCULAÇÃO DE COMMIT:
─────────────────────────────────────
Mensagem de commit: "GS-123: Adicionar login"
├── Vincula à tarefa automaticamente
├── Progresso visível
├── Histórico rastreado
└── Rastreabilidade

Melhores Práticas

Para CI

1. Pipelines rápidos — Abaixo de 10 minutos
2. Corrija imediatamente — Builds quebrados são prioridade 1
3. Mescle frequentemente — Mínimo diário
4. Gates de qualidade — Verificações necessárias antes da mescla
5. Sempre verde — Main é sempre liberável

Anti-Padrões

ERROS DE CI:
✗ Pipelines lentos (30+ minutos)
✗ Ignorando falhas
✗ Branches de longa duração
✗ Pulando testes
✗ Sem proteção de branch
✗ Deployments manuais
✗ Testes instáveis tolerados
✗ "Funciona na minha máquina"

Soluções Relacionadas

• Simplificando processos de revisão de código
• Melhores práticas de garantia de qualidade
• Automação de fluxo de trabalho no GitScrum