Merge time

Pull requests parados em revisão por dias são um dos sinais mais comuns de que seu pipeline de entrega tem um gargalo escondido. Merge time mede quanto tempo um pull request leva desde a primeira solicitação de revisão até o momento em que é mergeado na branch de destino. Quando o merge time é alto, o trabalho do seu squad se acumula, o risco de integração cresce e os compromissos do sprint começam a escorregar antes que alguém perceba o motivo. Esta página cobre a definição, como medir, benchmarks, como melhorar e como o DevStats mostra tudo isso automaticamente.

Principais conclusões

• Merge time mede quanto tempo um pull request fica esperando entre a solicitação de revisão e o merge. É um dos sinais mais claros de eficiência de fluxo no seu pipeline de entrega, porque captura o tempo em que o código está pronto mas ainda não foi integrado, o que atrasa diretamente a capacidade do seu squad de entregar.
• Merge time é calculado assim: Merge time = timestamp do merge menos timestamp da primeira solicitação de revisão. Não existe um benchmark DORA publicado especificamente para merge time, mas times de elite geralmente mergem pull requests em menos de quatro horas. Qualquer coisa consistentemente acima de 24 horas merece investigação.
• O erro mais comum dos times é tratar merge time como uma medida do esforço do revisor, em vez de um sinal sobre o processo de revisão em si. Merge times longos geralmente apontam para problemas estruturais: tamanho do PR, responsabilidade pouco clara ou profundidade da fila de revisão, não a velocidade individual do revisor.
• O DevStats rastreia merge time automaticamente conectando ao seu provedor Git, com benchmarks contra mais de 1.000 times de engenharia para você ver onde seu squad está. Comece um teste gratuito e veja seus números em menos de dois minutos.

Definição de merge time

Merge time é o tempo que um pull request passa entre ser aberto para revisão e ser mergeado na branch de destino. Mede com que rapidez o código revisado sai do estado "pronto" para o estado "integrado", tornando-se um indicador direto de eficiência de fluxo no seu processo de desenvolvimento.

Tecnicamente: Merge time = timestamp do merge menos timestamp da solicitação de revisão, medido por pull request e normalmente reportado como mediana ou percentil 85 em uma janela de tempo. Ele fica dentro do PR cycle time mais amplo, que também inclui o tempo até a primeira revisão e o tempo até o deploy. Quando o merge time é alto em relação ao cycle time total, o gargalo está na etapa de revisão e aprovação, não na codificação ou no deployment. Um merge time lento se traduz diretamente em releases atrasados e risco de integração crescente, os dois afetam a confiança dos seus stakeholders na previsibilidade de entrega do squad.

Por que merge time importa para times de engenharia

Squads que não rastreiam merge time costumam descobrir os problemas tarde demais. Um PR parado por três dias antes de ser mergeado pode bloquear trabalhos dependentes, criar conflitos de merge para outros players e empurrar features para além do limite do sprint sem que nenhum ponto de falha apareça numa standup ou retrospectiva. Quando o atraso aparece em compromissos perdidos, a causa raiz já está enterrada.

Para líderes de engenharia, merge time se conecta diretamente à velocidade de entrega, previsibilidade do sprint e experiência do desenvolvedor. Players que veem seu trabalho parado em filas de revisão regularmente perdem momentum e contexto. Esse custo de troca de contexto é real e se multiplica ao longo do squad. Times com merge time consistentemente baixo tendem a entregar de forma mais previsível e mantêm um throughput maior ao longo do tempo, porque o código passa pelo pipeline sem se acumular.

Dentro do framework DORA, merge time é um componente da métrica de lead time for changes, um dos quatro indicadores-chave de desempenho de entrega de software. Medir é o ponto de partida. O engineering manager é quem interpreta o padrão e decide o que mudar.

Como medir merge time

Para calcular merge time, você precisa de timestamps do seu provedor Git: especificamente, quando um pull request foi aberto ou marcado como pronto para revisão, e quando foi mergeado. A maioria dos times busca isso do GitHub, GitLab ou Bitbucket via API ou uma ferramenta de analytics conectada. Você não precisa do seu pipeline CI/CD ou issue tracker para medir merge time isoladamente, mas combiná-lo com dados de code review dá muito mais valor diagnóstico.

Reporte merge time como mediana de todos os PRs em um período, e rastreie separadamente o percentil 85 para capturar outliers. Uma mediana de duas horas com p85 de 48 horas conta uma história diferente de uma mediana de seis horas com p85 de oito horas. Não existe um benchmark DORA oficial para merge time como métrica isolada, mas padrões de times de alto desempenho sugerem as faixas abaixo. Benchmarks variam por tamanho do time, complexidade da codebase e modelo de release, então use como sinais direcionais, não metas rígidas. O recurso de benchmarks do DevStats permite comparar o merge time do seu squad com times de tamanho e estágio similares.

Merge time na prática: um exemplo real

Uma VP of Engineering em uma empresa SaaS de 40 pessoas percebeu que as taxas de conclusão do sprint vinham caindo por dois trimestres consecutivos, mas as estimativas individuais de tarefas pareciam razoáveis. Depois de puxar os dados de merge time, ela viu que a mediana era de 18 horas, com p85 de quatro dias. Analisando a distribuição, descobriu que PRs com mais de 400 linhas de diff representavam quase 70% dos atrasos na cauda longa. Os revisores não eram lentos. Eles estavam despriorizando PRs grandes e complexos em favor dos menores, que conseguiam resolver rapidamente.

Ela introduziu uma norma no squad: PRs com mais de 300 linhas exigiam um breve comentário de resumo assíncrono do autor antes da revisão. Ela também estabeleceu um limite flexível de tamanho de PR e acompanhou isso semanalmente na sprint review do time. Em seis semanas, o merge time mediano caiu para menos de oito horas e as taxas de conclusão do sprint se recuperaram. Ela usou os dados para identificar o padrão. A decisão e a norma foram inteiramente dela.

Como melhorar merge time

1. Reduza o tamanho do PR. PRs grandes são o maior driver individual de merge times longos. Estabeleça uma norma no squad de 200 a 400 linhas de diff por PR. PRs menores são mais rápidos de revisar, mais fáceis de entender e geram menos comentários de ida e volta. Observe o volume de comentários de revisão como indicador antecipado: contagens altas de comentários em PRs grandes são um sinal de alerta precoce confiável.
2. Defina SLAs de revisão explícitos. Se o seu squad não tem uma expectativa compartilhada sobre a rapidez com que uma revisão deve acontecer, os atrasos se tornam invisíveis. Defina uma meta, por exemplo, primeira resposta em quatro horas durante o horário de trabalho, e torne-a visível no acordo de trabalho do time. Rastreie usando seus dados de code review para ver se a norma está sendo cumprida.
3. Atribua revisores na criação do PR. PRs sem atribuição ficam parados. Regras de atribuição automática no GitHub ou GitLab eliminam a ambiguidade de quem é responsável. Combine isso com uma visão de colaboração para entender se a carga de revisão está distribuída uniformemente no squad ou concentrada em poucos players.
4. Revise seus requisitos de aprovação. Aprovações obrigatórias de múltiplos engenheiros seniores em cada PR criam gargalos estruturais. Revise suas regras de proteção de branch e pergunte se cada gate de aprovação realmente reduz risco ou apenas adiciona latência. Reserve requisitos de múltiplos aprovadores para caminhos de alto risco como mudanças de infraestrutura ou segurança.
5. Exponha PRs parados nas standups. PRs abertos há mais de 24 horas sem atividade devem ser um item fixo da agenda. O activity heatmap do DevStats ajuda a identificar períodos de baixa atividade de revisão no squad, dando dados para uma conversa focada em vez de uma genérica.

Merge time vs. PR cycle time

Merge time e PR cycle time são relacionados, mas medem intervalos diferentes do processo de revisão. PR cycle time captura a jornada completa de um pull request do primeiro commit ao merge, enquanto merge time cobre apenas a fase de revisão e aprovação.

Use merge time quando quiser isolar se o processo de revisão é o gargalo. Use PR cycle time quando quiser entender o custo total de entregar uma unidade de trabalho pelo seu pipeline.