7 min leitura • Guide 817 of 877
Desenvolvimento Baseado em Trunk
Integre continuamente. O GitScrum suporta workflows de trunk-based development onde equipes integram frequentemente no branch principal para feedback e entrega mais rápidos.
Entendendo Trunk-Based Development
Conceitos Core
TRUNK-BASED DEVELOPMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ O CONCEITO: │
│ ─────────── │
│ Todos integram ao main/trunk frequentemente │
│ Branches de curta duração (horas, não semanas) │
│ Integração contínua ao codebase compartilhado │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TRUNK-BASED: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ main ─●──●──●──●──●──●──●──●──●──●──●──●──→ ││
│ │ ╲╱ ╲╱ ╲╱ ╲╱ ╲╱ ││
│ │ ─● ─● ─● ─● ─● ││
│ │ (branches curtas - horas/dia) ││
│ │ ││
│ │ • Merges pequenos e frequentes ││
│ │ • Conflitos são pequenos e fáceis ││
│ │ • Sempre entregável ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ VS GITFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ main ─●────────────────────────●────→ ││
│ │ develop ─●──●──●──●──●──●──●──●──●●───→ ││
│ │ ╲ ╱ ││
│ │ feature ──●────●────●────●────●─ ││
│ │ (semanas/meses) ││
│ │ ││
│ │ • Merges grandes no final ││
│ │ • Dor de integração ││
│ │ • "Inferno de merge" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIFERENÇA CHAVE: │
│ Trunk-based = Integre frequente, batches pequenos │
│ GitFlow = Integre no final, batches grandes │
└─────────────────────────────────────────────────────────────┘
Como Funciona
O Workflow
WORKFLOW TRUNK-BASED:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FLUXO DIÁRIO: │
│ ───────────── │
│ │
│ 1. PUXE O MAIS RECENTE │
│ git checkout main │
│ git pull │
│ │
│ 2. CRIE BRANCH CURTA │
│ git checkout -b add-login-button │
│ (Branch vive horas, não semanas) │
│ │
│ 3. FAÇA MUDANÇA PEQUENA │
│ - Implemente pedaço pequeno e completo │
│ - Adicione testes │
│ - Mantenha focado │
│ │
│ 4. PUSH E PR │
│ git push origin add-login-button │
│ - Crie PR │
│ - Consiga review rápido │
│ │
│ 5. MERGE NO MESMO DIA │
│ - Merge para main │
│ - Delete branch │
│ - Comece próximo pedaço │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ VIDA ÚTIL DA BRANCH: │
│ ──────────────────── │
│ ✅ Horas ← Ideal │
│ ✅ 1 dia ← Bom │
│ ⚠️ 2-3 dias ← Ficando longa │
│ ❌ 1 semana+ ← Não é trunk-based │
│ │
│ REGRA: "Se branch passa do fim do dia, algo está errado" │
└─────────────────────────────────────────────────────────────┘
Quebrando o Trabalho
MUDANÇAS PEQUENAS E COMPLETAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RUIM: BRANCH DE FEATURE GRANDE │
│ ────────────────────────────── │
│ │
│ "Implementar autenticação de usuário" │
│ • Formulário de login │
│ • Reset de senha │
│ • Integração OAuth │
│ • Gestão de sessão │
│ • 2FA │
│ │
│ Problema: 2 semanas de trabalho, merge gigante │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BOM: SÉRIE DE MUDANÇAS PEQUENAS │
│ ─────────────────────────────── │
│ │
│ Dia 1: Modelo User e migração (sem UI) │
│ → Merge para main │
│ │
│ Dia 1: Endpoint de login básico │
│ → Merge para main │
│ │
│ Dia 2: Formulário de login (feature flag) │
│ → Merge para main │
│ │
│ Dia 2: Validação de senha │
│ → Merge para main │
│ │
│ Dia 3: Email de reset (feature flag) │
│ → Merge para main │
│ │
│ Cada pedaço: Completo, testado, merged │
│ Feature flag: Esconde do usuário até pronto │
└─────────────────────────────────────────────────────────────┘
Feature Flags
Separando Deploy de Release
FEATURE FLAGS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONCEITO: │
│ ───────── │
│ Deploy ≠ Release │
│ │
│ Deploy: Código vai para produção │
│ Release: Usuários veem a feature │
│ │
│ Feature flags desacoplam os dois │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXEMPLO: │
│ │
│ if (featureFlags.isEnabled('novo-dashboard')) { │
│ return <NovoDashboard />; │
│ } else { │
│ return <DashboardAntigo />; │
│ } │
│ │
│ TIMELINE: │
│ │
│ Dia 1: Deploy código com flag OFF │
│ Dia 2: Deploy mais código com flag OFF │
│ Dia 3: Deploy resto do código │
│ Dia 4: Teste interno com flag ON para equipe │
│ Dia 5: Release gradual (10% usuários) │
│ Dia 6: Release completo (100% usuários) │
│ Dia 7: Remova flag e código antigo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TIPOS DE FLAGS: │
│ │
│ RELEASE FLAG: │
│ • Liga/desliga feature para usuários │
│ • Temporário (remova após rollout) │
│ │
│ EXPERIMENT FLAG: │
│ • Teste A/B │
│ • Métricas para decidir │
│ │
│ OPS FLAG: │
│ • Kill switch para emergências │
│ • Pode ser permanente │
└─────────────────────────────────────────────────────────────┘
CI/CD para Trunk-Based
Pipeline
PIPELINE CI/CD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CADA COMMIT: │
│ ───────────── │
│ │
│ Push para branch │
│ ↓ │
│ Build automático │
│ ↓ │
│ Testes unitários (~5 min) │
│ ↓ │
│ Lint e checks │
│ ↓ │
│ Preview/Staging deploy │
│ │
│ APÓS MERGE: │
│ ──────────── │
│ │
│ Merge para main │
│ ↓ │
│ Build de produção │
│ ↓ │
│ Testes de integração │
│ ↓ │
│ Deploy automático para staging │
│ ↓ │
│ Smoke tests │
│ ↓ │
│ Deploy para produção │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REQUISITOS: │
│ │
│ ✓ Build rápido (< 10 min total) │
│ ✓ Testes confiáveis (sem flaky) │
│ ✓ Rollback fácil │
│ ✓ Deploy automatizado │
│ ✓ Monitoramento em produção │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Para Ter Sucesso
MELHORES PRÁTICAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMMITS: │
│ ───────── │
│ ✓ Commits atômicos (uma coisa por commit) │
│ ✓ Mensagens descritivas │
│ ✓ Código compila e testes passam │
│ ✓ Cada commit é potencialmente deployável │
│ │
│ CODE REVIEW: │
│ ───────────── │
│ ✓ PRs pequenas (< 400 linhas idealmente) │
│ ✓ Review rápido (< 2h) │
│ ✓ Feedback construtivo │
│ ✓ Não bloqueie por detalhes │
│ │
│ TESTES: │
│ ──────── │
│ ✓ Testes automatizados obrigatórios │
│ ✓ Cobertura adequada para mudança │
│ ✓ Testes rápidos │
│ ✓ Confiança para merge frequente │
│ │
│ CULTURA: │
│ ──────── │
│ ✓ "Se dói, faça mais frequente" │
│ ✓ Integração é responsabilidade de todos │
│ ✓ Main sempre verde │
│ ✓ Confiança na equipe │
└─────────────────────────────────────────────────────────────┘