Deployment frequency

Times que fazem deploy com pouca frequência não apenas andam mais devagar. Eles acumulam risco. Cada dia que o código fica sem ser deployado é um dia a mais para bugs se acumularem, o feedback atrasar e o pipeline de entrega perder visibilidade. Deployment frequency mede com que frequência seu squad coloca código em produção com sucesso. É uma das quatro DORA metrics e um dos sinais mais claros de como seu sistema de engenharia está funcionando de verdade. Esta página cobre a definição, como medir em relação aos benchmarks publicados, o que uma frequência baixa costuma indicar e como agir com base nos dados.

Key takeaways

• Deployment frequency mede com que frequência um squad coloca código em produção com sucesso. Importa porque é um proxy direto para throughput de entrega, velocidade do loop de feedback e risco de release. Times que fazem deploy com mais frequência tendem a enviar mudanças menores, o que significa menor impacto quando algo dá errado e iteração mais rápida sobre o que os usuários realmente precisam.
• Deployment frequency é calculada como o número de deployments bem-sucedidos em produção dividido pelo período de tempo medido. Por exemplo, 20 deployments em 30 dias equivalem a uma média diária de 0,67 deployments por dia. De acordo com o DORA State of DevOps Report de 2023, times de elite fazem deploy sob demanda ou várias vezes por dia, enquanto times de baixo desempenho fazem deploy menos de uma vez por mês.
• O erro mais comum dos times é confundir deployment frequency com tamanho do deployment. Fazer deploy uma vez por mês não é necessariamente mais seguro do que fazer deploy diariamente. Na prática, releases grandes e pouco frequentes concentram risco. Se sua frequência está baixa, a primeira pergunta é se seus batches estão grandes demais, não se o time está se movendo rápido demais.
• O DevStats rastreia deployment frequency automaticamente conectando ao seu provedor Git e ao CI/CD pipeline, com benchmarks comparados a mais de 1.000 times de engenharia. Você vê a deployment frequency do seu squad junto com sinais relacionados como PR cycle time e throughput em menos de dois minutos. Comece um teste gratuito para ver seus números.

Definição de deployment frequency

Deployment frequency é a medida de com que frequência um time de engenharia faz deploy de código em produção com sucesso. Conta apenas deployments bem-sucedidos, não tentativas, e costuma ser expressa como deployments por dia, semana ou mês, dependendo da cadência de release do time.

A fórmula é simples: Deployment Frequency = Número de deployments bem-sucedidos em produção / Período de tempo medido. As fontes de dados incluem seu CI/CD pipeline, ferramentas de deployment (como GitHub Actions, CircleCI ou ArgoCD) e seu provedor Git. Times que usam DevStats podem puxar esses dados automaticamente pelo deploy feature, que exibe a atividade de deployment sem precisar revisar logs manualmente.

Do ponto de vista de negócio, deployment frequency é um indicador antecipado da capacidade do time de responder ao feedback do mercado, corrigir defeitos rapidamente e entregar itens do roadmap no prazo. É uma das quatro DORA metrics principais, ao lado de lead time for changes, change failure rate e mean time to restore. Se você quer um único número que mostre como seu sistema de entrega está funcionando de ponta a ponta, deployment frequency é um bom ponto de partida.

Por que deployment frequency importa para times de engenharia

Quando squads não rastreiam deployment frequency, muitas vezes não percebem com que pouca frequência estão fazendo deploy até que um stakeholder pergunta por que uma feature comprometida três sprints atrás ainda não está no ar. O acúmulo invisível de batch é uma das causas mais comuns de datas de release perdidas, e raramente aparece nos relatórios de velocidade do sprint. Quando o problema vem à tona, já virou uma crise de entrega em vez de um gargalo gerenciável.

Para líderes de engenharia, deployment frequency se conecta diretamente a KPIs que importam para o negócio: entrega no prazo, mean time to recover de incidentes e capacidade de responder à pressão competitiva com agilidade. Times que fazem deploy com frequência tendem a ter PR cycle times mais curtos, loops de feedback mais precisos e resultados de sprint mais previsíveis. Deployment frequency baixa costuma ser sintoma de atrito em algum ponto anterior do processo, seja em code review, testes ou aprovação de release, e medir é o que torna esse atrito visível.

Deployment frequency está no centro do framework DORA e se alinha à dimensão Flow do SPACE framework. Mede o processo de entrega, não os contribuidores individualmente. Medir é o primeiro passo. O que você faz com os dados é onde seu julgamento como líder de engenharia mais importa.

Como medir deployment frequency

Para calcular deployment frequency, conte cada deployment bem-sucedido no seu ambiente de produção em uma janela de tempo definida e divida pelo número de dias, semanas ou meses nessa janela. "Bem-sucedido" significa que o deployment foi concluído sem rollback imediato. Deployments parciais, feature flags e canary releases devem ser contados de forma consistente entre os períodos para que a métrica permaneça comparável ao longo do tempo.

Fontes de dados que você vai precisar: logs do CI/CD pipeline (GitHub Actions, CircleCI, Jenkins, ArgoCD), seu provedor Git para eventos de merge e tag e, opcionalmente, sua ferramenta de rastreamento de incidentes para distinguir deployments bem-sucedidos dos que falharam. O DevStats puxa esses dados automaticamente e os exibe no deploy dashboard, junto com benchmarks comparados a mais de 1.000 times de engenharia para você contextualizar seus números sem precisar adivinhar.

A tabela abaixo usa benchmarks do DORA State of DevOps Report de 2023.

Deployment frequency na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que o squad estava concluindo o trabalho do sprint no prazo, mas as features ainda chegavam aos clientes semanas depois do planejado. Depois de puxar três meses de dados de deployment, ela viu que o squad estava fazendo em média menos de dois deployments em produção por mês, apesar de fazer deploy para staging com frequência. O gargalo não era velocidade. Era um processo manual de aprovação de release que exigia sign-off de dois engenheiros sênior que já estavam sobrecarregados em vários squads.

Ela reestruturou o processo de release: automatizou a promoção de staging para produção nos serviços com cobertura de testes completa e moveu a aprovação de release para uma revisão assíncrona leve nos serviços de menor risco. Em seis semanas, a deployment frequency passou de aproximadamente 1,5 por mês para três a quatro por semana. Ela acompanhou a mudança usando dados de deployment junto com throughput e taxas de conclusão de sprint para confirmar que a mudança no processo estava produzindo o resultado esperado sem aumentar as taxas de incidentes.

Como melhorar deployment frequency

1. Reduza o tamanho do batch. A forma mais eficaz de aumentar deployment frequency é fazer deploy de mudanças menores com mais frequência. Quebre features em incrementos deployáveis de forma independente. Se seus pull requests estão ultrapassando regularmente 400 linhas de código alterado, é sinal de que o squad está acumulando batch demais antes da revisão. PRs menores passam pelo code review mais rápido e são mais seguros para fazer deploy.
2. Automatize seu release pipeline. Etapas manuais de deployment são o gargalo mais comum para squads presos no nível médio de desempenho. Identifique cada gate humano no caminho para produção e avalie se pode ser substituído por uma verificação automatizada. Comece com gates de cobertura de testes e smoke tests. Aprovação manual deve ser reservada para mudanças que realmente exigem julgamento humano.
3. Reduza seu PR cycle time. Deployment frequency é consequência da velocidade com que o código vai de PR aberto para merged. Se as revisões estão levando mais de 24 horas em média, os deployments vão se acumular. Analise seus dados de PR cycle time para encontrar onde as revisões estão travando, seja no tempo até a primeira revisão, no tempo até a aprovação ou no tempo para o merge após a aprovação.
4. Use feature flags para separar deploy de release. Feature flags permitem que o squad faça deploy de código em produção sem expô-lo aos usuários. Isso separa o ato técnico de fazer deploy do ato de negócio de fazer release, removendo uma grande barreira psicológica e de processo para deployment frequente. Também permite reverter uma feature sem um deployment completo.
5. Meça indicadores antecipados, não só o resultado. Deployment frequency é a métrica de resultado. Os indicadores antecipados são PR cycle time, issue cycle time e taxa de sucesso de build. O DevStats exibe todos eles em uma única visão para você identificar qual sinal upstream está limitando sua cadência de deployment antes que apareça como um sprint perdido.

Deployment frequency vs. cadência de release

Deployment frequency e cadência de release são frequentemente usados como sinônimos, mas medem coisas diferentes. Deployment frequency conta com que frequência o código é enviado com sucesso para produção. Cadência de release descreve com que frequência novas funcionalidades são disponibilizadas para os usuários finais. Um time pode fazer deploy em produção 20 vezes por semana usando feature flags e ainda assim fazer release de novas funcionalidades para os clientes apenas uma vez por sprint.

Use deployment frequency para diagnosticar seu processo de engenharia. Use cadência de release ao comunicar compromissos de entrega para stakeholders de produto e negócio. Rastrear os dois dá uma visão completa de onde o código está no sistema em qualquer momento.