Desenvolvimento trunk-based vs GitFlow para entregas semanais

Por que entregas semanais ficam confusas com o modelo de branching errado

Entregar toda semana parece simples até a semana em que você perde o prazo. A build está "quase pronta" na quinta, o QA encontra problemas na sexta à tarde, e a segunda vira limpeza em vez de um começo limpo.

Um grande motor desse problema é o modelo de branching. Ele decide quando as mudanças se encontram, onde a integração acontece e quão rápido você consegue se recuperar quando algo quebra. Se a integração fica para o final da semana, você paga por isso com conflitos de merge, bugs surpresa e ambientes de teste instáveis.

Quando o fluxo de trabalho está contra você, geralmente parece assim:

• Merges demoram mais que o próprio trabalho de feature que os gerou.
• QA testa uma mistura errada de mudanças porque os branches divergem.
• Releases viram negociação em vez de rotina.
• Hotfixes disparam pânico porque ninguém tem certeza do que mais será enviado.
• As pessoas param de confiar no QA e começam a pedir exceções.

O branching também molda a estabilidade do QA. Se o QA fica pulando entre caminhos de código meio integrados, vira um alvo em movimento. Mesmo bons testadores não conseguem dar respostas claras quando o sistema sob teste muda a cada poucas horas, ou quando um merge tardio substitui silenciosamente o que testaram ontem.

Por isso equipes com frequência comparam trunk-based development e GitFlow quando mudam para uma cadência de releases semanais. A pergunta útil não é qual é mais popular. É qual reduz a dor de merge, mantém as releases previsíveis, torna hotfixes seguros e rápidos e mantém o QA significativo.

Assuma um time pequeno a médio, um repositório compartilhado, CI rodando a cada push. Talvez você entregue um web app e uma API. Ou talvez parte do time construa visualmente em uma plataforma como AppMaster enquanto ainda gerencia código gerado e deploys como qualquer outro time de produto.

Se seu processo atual cria grandes merges no fim da semana, sua cadência semanal vai continuar escorregando. Se incentiva integração pequena e frequente, as releases semanais começam a parecer sem graça (no bom sentido).

Trunk-based development e GitFlow em linguagem simples

Ambas as abordagens são apenas regras sobre como usar branches para que o trabalho vá de "em progresso" para "lançado" sem caos. A diferença real é quantos branches de vida longa você mantém e quanto tempo o trabalho fica separado antes de encontrar o código dos outros.

• Trunk-based mantém quase tudo próximo de main.
• GitFlow mantém pistas separadas para trabalho em andamento e estabilização de release.

Trunk-based development (em termos simples)

Trunk-based development trata main (o trunk) como o centro. As pessoas trabalham em branches de curta duração (horas até um dia ou dois), mesclam com frequência e mantêm main em um estado liberável.

Se algo não estiver pronto, ou você mantém pequeno o suficiente para terminar rápido, ou esconde atrás de uma feature flag para que possa ser enviado sem ficar visível.

GitFlow (em termos simples)

GitFlow normalmente usa um branch de longa duração develop onde o trabalho de feature primeiro aterrissa, mais branches de feature saindo de develop. Perto do release, você corta um branch release/* para estabilizar e testar. Se a produção quebrar, você corta um hotfix/* (geralmente a partir de main) e mescla de volta.

Esse modelo otimiza por separação: o trabalho contínuo pode seguir em develop enquanto o branch de release é testado e corrigido.

Muita dor vem de mal-entendidos comuns:

• Tratar trunk-based como "sem branches" (ele ainda usa branches, só que de vida curta).
• Usar GitFlow sem realmente criar um branch de release, fazendo develop virar uma área de staging instável.
• Deixar feature branches viverem por semanas, o que transforma qualquer modelo em problema de merge.
• Confundir "liberável" com "tudo está terminado" em vez de "seguro para deploy".

Atrito de merge: o que realmente causa

Conflitos de merge costumam vir de duas fontes: branches que vivem por muito tempo e várias pessoas mudando as mesmas áreas sem coordenação.

A maior diferença prática entre trunk-based e GitFlow é quanto tempo o trabalho fica separado antes de se encontrar com o resto.

No trunk-based, mudanças chegam à linha principal frequentemente. Pull requests são menores, diffs são menores e conflitos aparecem mais cedo enquanto o contexto ainda está fresco. Conflitos ainda acontecem, mas costumam ser mais fáceis de resolver porque você está reconciliando poucas linhas, não duas semanas de drift. A troca é disciplina: mantenha builds verdes, mudanças incrementais e trate main como o produto.

No GitFlow, o trabalho de feature pode ficar mais tempo sem afetar o dia a dia dos outros desenvolvedores. O custo aparece depois como eventos de merge maiores: feature→develop, develop→release/*, e release/*→main. Cada merge é um encontro maior de mudanças, então conflitos são mais prováveis e mais difíceis de desembaraçar. Para entregas semanais, esses grandes merges tendem a cair justamente quando o time quer estar testando.

A carga de revisão de código também muda. Trunk-based normalmente significa mais reviews, mas cada um é mais rápido de entender. GitFlow muitas vezes significa menos reviews, porém mais pesados, além de tempo extra de revisão durante os merges de release quando todo mundo está cansado.

Para reduzir atrito de merge em qualquer modelo:

• Mantenha PRs pequenos e focados (um objetivo por vez).
• Combine ownership para áreas arriscadas (migrations, config compartilhada, UI central).
• Puxe mudanças upstream diariamente para não divergir.
• Se um arquivo estiver sempre "quente", trabalhe em dupla nele em vez de correr em paralelo.

Se conflitos parecem constantes, geralmente é sinal de que você está integrando tarde demais, não que o Git seja o problema.

Previsibilidade de release para uma cadência semanal

Previsibilidade significa três coisas: você sabe quando o release sai, sabe o que está nele e sabe quais checagens devem passar antes de enviar. Times costumam perder releases semanais porque misturam decisões de escopo com correções de última hora.

No trunk-based, releases semanais ficam previsíveis quando main se mantém verde. Você mescla mudanças pequenas com frequência e controla escopo com feature flags em vez de branches de longa duração. Isso mantém o trem semanal andando mesmo se uma feature não estiver pronta. O código pode aterrissar, mas o comportamento visível fica desligado até estar pronto.

Gates de qualidade costumam ser mais simples porque há um lugar para validar:

• Testes automatizados devem passar em main.
• QA testa um candidato de build estável, não o que foi mesclado na última hora.
• Passos de rollout e rollback estão documentados.
• Há um horário claro de cutoff para o release (mesmo que commits continuem chegando).

No GitFlow, a previsibilidade vem do branch de release agindo como uma zona de freeze. Você escolhe um cutoff, cria release/* e só permite mudanças necessárias para enviar. Essa fronteira ajuda, mas adiciona coordenação porque correções geralmente precisam ser aplicadas em mais de um lugar (release e develop).

Trabalho inacabado é tratado de formas diferentes:

• Trunk-based: mescle partes seguras e mantenha o resto atrás de flags.
• GitFlow: mantenha trabalho inacabado em develop e o exclua do branch de release.

Exemplo: se melhorias no checkout estiverem pela metade na quarta, trunk-based pode mesclar refactors seguros e manter a nova UI escondida. GitFlow normalmente mantêm isso em develop, envia sem a melhoria e termina para o próximo release semanal.

Fluxo de hotfix: o caminho mais rápido e seguro para produção

Um hotfix não é trabalho normal. Precisa de velocidade, baixo risco e um caminho que traga a mudança de volta para onde o time trabalha para não corrigir o mesmo bug duas vezes.

Comece com uma pergunta: qual código está exatamente rodando em produção agora? Se você não pode responder isso em segundos, hotfixes viram palpite.

Hotfixes no trunk-based development

Hotfixes no trunk-based podem parecer mais simples porque main é tratado como fonte da verdade.

Um fluxo comum:

• Crie um branch de curta duração a partir do commit em produção (geralmente main).
• Faça a menor correção possível (adicione um teste, se puder).
• Mescle de volta em main rapidamente.
• Deploie a partir de main e marque a release com um tag.

Como o time integra frequentemente em main, o hotfix naturalmente faz parte do próximo release semanal. O principal risco é violar a regra de que main é liberável deixando trabalho pela metade em main. Feature flags ajudam, mas mantenha-as desligadas por padrão e verifique o hotfix sem habilitar features não relacionadas.

Hotfixes no GitFlow

No GitFlow, hotfixes normalmente começam em main (produção) e depois devem ser mesclados de volta em develop para que a correção não se perca.

Um fluxo seguro:

• Branch hotfix/* a partir de main no tag de produção.
• Corrija e libere (ou a partir do hotfix ou após mesclar em main).
• Mescle o hotfix em main e também em develop.
• Se existir um release/*, mescle nele também.

A falha mais comum é esquecer uma dessas mesclagens. Uma semana depois, o bug "volta" porque develop nunca recebeu o patch.

Uma regra simples evita a maioria dos problemas: um hotfix não está concluído até que tenha sido mesclado em todos os branches de longa duração que vão voltar a ser lançados.

Como manter ambientes de QA estáveis (sem bloquear o time)

Entregas semanais desandam quando "QA" significa "o que está implantado agora". Nomeie seus ambientes e dê a cada um uma função: dev para feedback rápido, QA para testes do time, staging para checagens de release, prod para clientes. Se você não consegue explicar o propósito de um ambiente em uma frase, as pessoas vão usá-lo errado.

Regras que evitam alvos em movimento

QA estável é menos sobre o modelo de branching e mais sobre o que você implanta.

No trabalho trunk-based, não implante commits aleatórios no QA. Faça o deploy de um candidato fixo (build tagueado, número de build ou um branch release-candidate de curta duração) que passe as mesmas checagens toda vez. O QA recebe algo fixo para testar, mesmo enquanto o desenvolvimento continua em main.

No GitFlow, o QA geralmente acompanha o branch de release. A armadilha é deixar o branch de release continuar mudando depois que o QA começa. Quando o QA inicia, trate o branch de release como um contrato: só aceite correções aprovadas e apenas por um processo claro.

Um conjunto pequeno de regras mantém qualquer abordagem previsível:

• Deposite no QA apenas builds que passaram.
• Prenda a versão implantada (tag, número de build ou head do branch de release) e anuncie isso.
• Limite mudanças em QA a correções de bug, não novas features.
• Reset de dados de teste em um cronograma e documente o que é limpo.
• Mantenha configuração como código (variáveis e templates) para reduzir drift de ambiente.

Se seu time usa AppMaster para parte do build, mantenha o mesmo princípio: regenere e implante um build específico para o QA, não um conjunto de edições em constante mudança.

Quando vários times compartilham o QA

Um ambiente de QA compartilhado vira gargalo quando duas equipes precisam de versões diferentes. Se não puder ter ambientes separados, adote uma regra simples de reserva: uma equipe é dona do QA por uma janela de tempo e os outros usam dev ou staging. Feature flags também ajudam porque trabalho inacabado pode ser implantado sem ficar visível para testadores.

Exemplo: Time A valida o candidato de release semanal, então o QA fica preso ao build 1842 até o sign-off. Time B pode continuar mesclando correções, mas essas mudanças aguardam o próximo candidato em vez de mudar o que o QA está testando no meio do ciclo.

Passo a passo: escolha um fluxo que seu time consiga seguir toda semana

Escreva o que "entregar semanalmente" significa para você. Escolha um dia e hora de release, decida qual nível de risco é aceitável (por exemplo, "nenhum bug P1 conhecido") e registre tamanho do time e fusos horários. Isso evita que debates de branch virem discussões de prioridade.

Escolha um modelo base e comprometa-se por um mês. Não misture modelos no dia 1. Misturar normalmente adiciona regras sem reduzir surpresas.

Um fluxo semanal simples que você pode adaptar:

• Mantenha branches curtos (horas a 1–2 dias) e mescle pelo menos diariamente.
• Adicione trilhos de segurança: CI rápido, revisão curta obrigatória e um conjunto pequeno de testes automatizados que peguem quebras reais.
• Decida como controlar escopo: feature flags, um branch de release de curta duração perto do fim da semana ou tags para o commit exato do release.
• Defina passos de hotfix: quem pode disparar, quais checagens são necessárias e como a correção volta para a linha principal.
• Mantenha o QA estável: decida o que o QA acompanha (branch de release ou candidato fixo) e não mude no meio do teste a menos que reinicie o ciclo.

Escreva o mínimo do workflow em uma página. Deve ser curto o suficiente para que um novo colega siga sem reunião. Isso importa ainda mais se parte do time trabalha visualmente (por exemplo, em AppMaster) e parte em código, porque handoffs falham quando regras vivem só na cabeça de alguém.

Exemplo: um release semanal realista em ambos os modelos

Imagine um time de produto de 6 pessoas que lança toda sexta. Dois testadores de QA compartilham um ambiente de staging, então se o staging estiver instável, os testes param para todo mundo.

Uma semana movimentada com GitFlow

Segunda: três devs terminam features e abrem PRs para develop. QA começa a testar staging construído a partir de develop.

Quarta: o time corta release/1.8 para proteger o envio de sexta. Novo trabalho continua chegando em develop, mas o QA agora foca no build de release.

Quinta à tarde: aparece um bug tardio. A correção entra em release/1.8 primeiro para o QA re-testar rápido. Depois alguém mescla essa correção de volta em develop, que é onde erros costumam acontecer.

Um ritmo típico:

• Seg-TER: features mesclam em develop, staging muda com frequência.
• Qua: cria release/1.8, staging troca para builds de release.
• Qui: correção em release/1.8, depois mesclar em develop.
• Sex: mesclar release/1.8 em main, tag e deploy.

A mesma semana com trunk-based development

A semana gira em torno de merges pequenos e frequentes em main. Features ficam por trás de flags para que trabalho incompleto possa ser mesclado sem afetar usuários.

Segunda a quinta: devs mesclam pequenas mudanças diariamente. QA testa um build candidato fixo.

Terça: aparece um problema em produção. O hotfix é um branch curto de main, mesclado de volta imediatamente após revisão, e promovido para produção. Como main é a fonte da verdade, não há passo extra de back-merge.

De qualquer forma, o time precisa de regras claras de promoção:

• Staging roda o último build candidato fixo, não todo commit novo.
• QA solicita um novo candidato quando pronto, não automaticamente.
• Só correções para o release de sexta podem mudar o candidato.
• Todo o resto espera atrás de flags ou fica fora do candidato.

Erros comuns que criam churn e QA instável

A maioria dos times não falha por escolher o modelo "errado". Falham porque hábitos diários não seguem o modelo, então o QA fica barulhento e releases parecem aleatórias.

Um problema comum é deixar branches viverem por dias porque "não está pronto." O código diverge de main, conflitos se acumulam e o QA acaba testando uma mistura de trabalho velho e novo que ninguém consegue reproduzir.

Outro é usar GitFlow sem um freeze real. Um branch de release deveria estabilizar, mas times continuam enfiando "só mais uma" mudança. Isso transforma o branch de release em uma segunda linha principal, e ninguém sabe o que o QA está aprovando.

QA também fica instável quando é tratado como um depósito para builds pela metade. Se todo commit vai para QA sem regras, testadores gastam tempo correndo atrás de alvos em movimento em vez de validar um release.

Os erros que mais geram churn:

• Feature branches de longa duração que mesclam tarde e quebram trabalho não relacionado.
• Branches de release que ainda aceitam novas features.
• Nenhum caminho claro de promoção, então o build que o QA testou não é o que vai para produção.
• Hotfixes feitos às pressas e nunca mesclados em todos os lugares.
• Ambientes sem dono, sem propósito e sem plano de reset.

Mantenha um conjunto de regras que todos possam repetir:

• QA testa apenas um candidato fixo.
• Você promove o mesmo artefato do QA para produção.
• Cada ambiente tem um dono e uma cadência de reset.
• Hotfixes voltam para a linha principal no mesmo dia.

Checklist rápido para entregas semanais sem surpresas

Entregar semanalmente funciona quando seu time consegue responder algumas perguntas chatas com confiança. Se você responder "não" para duas ou mais, espere correções de última hora e solavancos no QA.

• Existe um branch que você pode implantar com segurança hoje? Deve buildar, passar smoke tests e evitar mudanças meia-montadas.
• PRs ficam pequenos e aterrissam em um ou dois dias? PRs de longa duração costumam gerar feedbacks obsoletos e conflitos maiores.
• QA testa um build fixo, não um alvo em movimento? QA deve validar um número de build ou release candidate específico.
• Você consegue manter trabalho inacabado fora do release sem drama? Feature flags, toggles de configuração ou regra clara de corte de escopo.
• Alguém consegue rodar um hotfix e rollback sem chutar? Um runbook curto vence conhecimento tribal.

Se quiser um objetivo mensurável: prenda o QA a um release candidate e mantenha esse candidato inalterado exceto por correções intencionais.

Próximos passos: escolha uma mudança para testar na próxima semana

Se seu time está preso debatendo trunk-based vs GitFlow, não redesenhe tudo de uma vez. Escolha o problema que mais custa tempo e rode um experimento pequeno para o próximo release.

Se conflitos de merge são a maior dor, encurte imediatamente a vida dos branches. Mire em aterrissar trabalho diariamente (ou dia sim, dia não), usando feature flags quando necessário.

Se instabilidade do QA é a maior dor, comece prendendo o que o QA testa e definindo um passo simples de promoção.

Um piloto leve:

• Escolha um repositório e um time.
• Defina um limite de idade para branches (por exemplo, nenhum branch com mais de 2 dias).
• Prenda o QA a um build e só mude através de promoção explícita.
• Acompanhe três números: tempo de resolução de merges, horas de retrabalho de QA e tempo do hotfix até produção.
• Revise após 2–4 semanas e ajuste.

Se quiser reduzir pressão de release para ferramentas internas ou portais de clientes, uma plataforma no-code como AppMaster (appmaster.io) também pode ajudar gerando backend, web e apps móveis prontos para produção a partir de design visual. Ainda se beneficia dos mesmos hábitos acima: mudanças pequenas, candidatos de QA fixos e um caminho de promoção claro.