9 min leitura • Guide 85 of 877
Implementando Workflows de Integração Contínua
Integração Contínua (CI) transforma como times validam mudanças de código executando automaticamente testes, linting e verificações de qualidade em cada commit. Quando CI integra com GitScrum através de conexões GitHub, GitLab ou Bitbucket, status de tarefas atualizam automaticamente baseados em resultados de build, dando visibilidade ao time completo sobre saúde do código. Isso cria um gate de qualidade que previne código quebrado de chegar a branches principais enquanto mantém o quadro sincronizado com estado real de desenvolvimento.
Fundamentos CI
Por Que CI Importa
SEM CI:
┌─────────────────────────────────────────────────────────────┐
│ PROBLEMAS VERIFICAÇÃO MANUAL │
├─────────────────────────────────────────────────────────────┤
│ │
│ Developer faz push código: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Funciona na minha máquina" ─────────────────────────────││
│ │ │ ││
│ │ ▼ ││
│ │ ┌───────────────────────────────────────────────────┐ ││
│ │ │ PROBLEMAS DESCOBERTOS DEPOIS: │ ││
│ │ │ │ ││
│ │ │ • Versão Node diferente no servidor CI │ ││
│ │ │ • Variável ambiente faltando │ ││
│ │ │ • Teste passa localmente, falha em isolamento │ ││
│ │ │ • Conflito merge não resolvido corretamente │ ││
│ │ │ • Dependência não no package.json │ ││
│ │ │ │ ││
│ │ │ Tempo debug: Horas a dias │ ││
│ │ │ Troca contexto: Já na próxima tarefa │ ││
│ │ │ Culpa: "Quem quebrou o build?" │ ││
│ │ └───────────────────────────────────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
COM CI:
┌─────────────────────────────────────────────────────────────┐
│ FLUXO VERIFICAÇÃO AUTOMATIZADA │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Push │───▶│ CI Executa│───▶│ Resultado │ │
│ │ Commit │ │ Checks │ │ em 5min │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ CHECKS EXECUTAM: │ │
│ │ ✓ Instalar dependências │ │
│ │ ✓ Lint código │ │
│ │ ✓ Type check │ │
│ │ ✓ Executar unit tests │ │
│ │ ✓ Executar integration tests │ │
│ │ ✓ Build artefato produção │ │
│ │ │ │
│ │ Tudo passa → ✅ Merge permitido │ │
│ │ Algo falha → ❌ Merge bloqueado │ │
│ └─────────────────────────────────────┘ │
│ │
│ Developer encontra issue: 5 minutos, não dias │
│ Contexto: Ainda na mesma tarefa │
│ Responsabilidade: Claro qual commit quebrou o que │
│ │
└─────────────────────────────────────────────────────────────┘
Estágios Pipeline CI
ESTRUTURA PIPELINE PADRÃO:
┌─────────────────────────────────────────────────────────────┐
│ ESTÁGIOS PIPELINE │
├─────────────────────────────────────────────────────────────┤
│ │
│ Estágio 1: PREPARAR (1-2 min) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Checkout código ││
│ │ • Cache dependências ││
│ │ • Instalar pacotes ││
│ │ ││
│ │ Condições falha: Issues rede, cache corrompido ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Estágio 2: VALIDAR (2-5 min) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Executar em paralelo: ││
│ │ • Lint (ESLint, Prettier, etc.) ││
│ │ • Type check (TypeScript) ││
│ │ • Auditoria segurança (npm audit, Snyk) ││
│ │ ││
│ │ Condições falha: Violações estilo, erros tipo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Estágio 3: TESTAR (5-15 min) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sequencial: ││
│ │ • Unit tests ││
│ │ • Integration tests ││
│ │ • E2E tests (opcional por-PR) ││
│ │ ││
│ │ Condições falha: Falhas testes, queda cobertura ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Estágio 4: BUILD (2-5 min) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Build artefato produção ││
│ │ • Verificar tamanho bundle ││
│ │ • Upload artefatos ││
│ │ ││
│ │ Condições falha: Erros build, limites excedidos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Estágio 5: DEPLOY (em merge para main) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Deploy para staging ││
│ │ • Executar smoke tests ││
│ │ • Notificar time ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Integração GitScrum
Conectando Provedores Git
FLUXO GITSCRUM + CI:
┌─────────────────────────────────────────────────────────────┐
│ ATUALIZAÇÕES AUTOMÁTICAS QUADRO │
├─────────────────────────────────────────────────────────────┤
│ │
│ Setup: GitScrum → Integrações → GitHub/GitLab/Bitbucket │
│ │
│ WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Developer cria branch: ││
│ │ git checkout -b feature/PROJ-123-user-auth ││
│ │ ^^^^ ││
│ │ ID Tarefa ││
│ │ ││
│ │ 2. Developer abre PR referenciando tarefa: ││
│ │ Título PR: "feat: implement user auth [PROJ-123]" ││
│ │ ││
│ │ 3. GitScrum automaticamente: ││
│ │ • Linka PR à tarefa PROJ-123 ││
│ │ • Mostra status PR no card tarefa ││
│ │ • Atualiza tarefa baseado no estado PR ││
│ │ ││
│ │ 4. CI executa, resultados visíveis no GitScrum: ││
│ │ ┌─────────────────────────────────────────────────┐ ││
│ │ │ Tarefa: PROJ-123 │ ││
│ │ │ │ ││
│ │ │ 🔗 PR #45: feat: implement user auth │ ││
│ │ │ ⏳ CI Executando: 3 de 5 checks passaram │ ││
│ │ │ │ │ ││
│ │ │ ├─ ✅ lint │ ││
│ │ │ ├─ ✅ typecheck │ ││
│ │ │ ├─ ✅ unit-tests │ ││
│ │ │ ├─ ⏳ integration-tests (executando) │ ││
│ │ │ └─ ⏸️ deploy (aguardando) │ ││
│ │ └─────────────────────────────────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Status CI visível sem sair do quadro GitScrum │
│ │
└─────────────────────────────────────────────────────────────┘
Automação Status Tarefas
REGRAS AUTOMAÇÃO STATUS:
┌─────────────────────────────────────────────────────────────┐
│ CONFIGURANDO TRANSIÇÕES AUTOMÁTICAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ EVENTO │ TRANSIÇÃO TAREFA ││
│ │───────────────────────────┼─────────────────────────────││
│ │ Branch criado com │ → "Em Progresso" ││
│ │ ID tarefa │ ││
│ │ │ ││
│ │ PR aberto (draft) │ → "Em Progresso" ││
│ │ │ ││
│ │ PR pronto para review │ → "Code Review" ││
│ │ │ ││
│ │ CI falhou │ → Ficar no status atual ││
│ │ │ (adicionar label "CI Failed")│
│ │ │ ││
│ │ CI passou, aprovado │ → "Pronto para Merge" ││
│ │ │ ││
│ │ PR merged │ → "Feito" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Por que isso importa: │
│ • Quadro sempre reflete realidade │
│ • Não precisa updates status manuais │
│ • PM pode ver progresso real sem interromper devs │
│ │
└─────────────────────────────────────────────────────────────┘
Gates de Qualidade
Checks Requeridos
CHECKS BLOQUEANTES VS NÃO-BLOQUEANTES:
┌─────────────────────────────────────────────────────────────┐
│ CONFIGURANDO GATES QUALIDADE │
├─────────────────────────────────────────────────────────────┤
│ │
│ DEVE PASSAR (bloqueia merge): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✓ Lint Sem erros sintaxe, estilo consistente││
│ │ ✓ Type check TypeScript compila sem erros ││
│ │ ✓ Unit tests Todos testes passam ││
│ │ ✓ Build Build produção com sucesso ││
│ │ ✓ Segurança Sem vulnerabilidades alta/crítica ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEVERIA PASSAR (avisar mas permitir): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ⚠ Cobertura >80% cobertura (avisar se menor) ││
│ │ ⚠ Tamanho bundle <500KB (avisar se maior) ││
│ │ ⚠ Performance Lighthouse >90 (avisar se menor) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ INFORMACIONAL (nunca bloqueia): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ℹ Updates depend. Sugestões Dependabot/Renovate ││
│ │ ℹ Complexidade código Métricas manutenibilidade ││
│ │ ℹ Documentação Avisos JSDoc faltando ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Otimização Pipeline
Melhorias de Velocidade
MELHORES PRÁTICAS CI RÁPIDO:
┌─────────────────────────────────────────────────────────────┐
│ REDUZINDO TEMPO PIPELINE │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. PARALELIZAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Antes (sequencial): 15 minutos ││
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ││
│ │ │Lint │→│Types│→│Unit │→│Integ│→│Build│ ││
│ │ │ 2m │ │ 2m │ │ 5m │ │ 4m │ │ 2m │ ││
│ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ ││
│ │ ││
│ │ Depois (paralelo): 7 minutos ││
│ │ ┌─────┐ ││
│ │ │Lint │──────────────────────┐ ││
│ │ │ 2m │ │ ││
│ │ └─────┘ ▼ ││
│ │ ┌─────┐ ┌─────────┐ ┌─────┐ ││
│ │ │Types│────────────────▶│ Test │───▶│Build│ ││
│ │ │ 2m │ │ 5m │ │ 2m │ ││
│ │ └─────┘ └─────────┘ └─────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ 2. CACHING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cachear: ││
│ │ • node_modules (chave: hash do package-lock.json) ││
│ │ • Artefatos build (para arquivos sem mudanças) ││
│ │ • Snapshots testes ││
│ │ ││
│ │ Cache hit: 2 min install → 10 seg restore ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Práticas do Time
Disciplina CI
ACORDOS CI TIME:
┌─────────────────────────────────────────────────────────────┐
│ NORMAS CI TIME │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✅ FAZER: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Executar testes localmente antes de push ││
│ │ • Arrumar builds quebrados imediatamente ││
│ │ • Manter pipeline abaixo 15 minutos ││
│ │ • Revisar mudanças config CI cuidadosamente ││
│ │ • Monitorar testes flaky semanalmente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ❌ NÃO FAZER: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Push direto para main ││
│ │ • Pular CI checks "só dessa vez" ││
│ │ • Deixar builds vermelhos durante noite ││
│ │ • Ignorar testes falhando pulando eles ││
│ │ • Merge sem review de PR ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROTOCOLO BUILD QUEBRADO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Todo trabalho para quando main branch está vermelho ││
│ │ 2. Pessoa que quebrou assume responsabilidade ││
│ │ 3. Se não arrumável em 10 min, revert e arrumar em branch│
│ │ 4. Postar em Discussions: o que aconteceu, como prevenir││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘