GUIA
Deployment Frequency (Frequência de Deploy): O Que É e Como Calcular
Uma das 4 métricas DORA — com que frequência seu time entrega código pra produção.
O que mede
Frequência de deploy é com que frequência o código chega em produção — diária, semanal, ou algo entre isso. É a mais simples de explicar das quatro métricas DORA, mas importa por um motivo mais sutil do que "mais deploy é melhor": frequência é um indicador de tamanho de lote. Um time que faz deploy várias vezes ao dia está, quase por definição, entregando mudanças pequenas e de baixo risco. Um time que faz deploy uma vez por mês está empacotando semanas de trabalho num release só, o que aumenta a chance de qualquer uma dessas mudanças causar problema.
Por que importa
Fazer deploy com mais frequência não é uma métrica de vaidade — muda como um deploy de fato se sente. Um time que entrega uma vez por mês trata cada release como um evento: freeze de mudança antes, sala de guerra durante, retro depois, porque acumulou tanta coisa que qualquer coisa pode dar errado. Um time que entrega várias vezes por dia trata um deploy como rotina, quase chato, porque cada um carrega tão pouco que um problema é fácil de perceber e barato de reverter. Essa mudança — de "deploy dá medo" pra "deploy é terça-feira" — é o verdadeiro prêmio por trás do número, e também é por isso que a frequência de deploy se correlaciona tão fortemente com as outras 3 métricas DORA em vez de trocar uma pela outra.
Também se acumula com o lead time de um jeito específico: um time que só entrega uma vez por semana, não importa quão rápido uma mudança única passe pela revisão, está limitado a entregar uma vez por semana. Frequência é o teto que o lead time esbarra — melhorar um sem o outro só leva o time até certo ponto.
Como calcular
Conte o número de deploys em produção num período, e expresse como uma taxa — deploys por dia, ou por semana. A parte que exige uma decisão de verdade é o que conta como um deploy: um merge na branch principal, uma execução bem-sucedida do pipeline de CI/CD, ou um artefato de fato chegando num ambiente de produção. Escolher a última opção — um artefato vivo em produção — dá o sinal mais honesto, já que as outras duas podem acontecer sem a mudança nunca chegar num usuário.
Um exemplo rápido: um time faz merge de 40 pull requests num mês, roda 35 pipelines de CI/CD com sucesso (alguns merges são agrupados num deploy só), e 32 desses de fato chegam em produção (alguns ficam presos por uma feature flag ou uma janela de release bloqueada). A frequência de deploy honesta desse mês é 32 — não 40, e não 35 — porque esse é o número de vezes que uma mudança de fato chegou num usuário.
Performance elite vs. típica
A pesquisa da DORA agrupa times em faixas de performance aproximadas. Times de elite fazem deploy sob demanda, muitas vezes várias vezes ao dia. Times no meio costumam fazer deploy entre uma vez por semana e uma vez por mês. Times de performance mais baixa fazem deploy menos de uma vez por mês. Trate isso como uma noção geral de onde um time está, não um placar rígido — as faixas exatas mudaram um pouco entre diferentes anos do State of DevOps Report.
Uma armadilha comum
Quebrar uma mudança relevante em vários deploys pequenos e majoritariamente cosméticos é um jeito de inflar o número sem de fato entregar mais valor ou reduzir risco — uma contagem de deploy subindo enquanto lead time e change failure rate ficam parados vale uma segunda olhada. Frequência deveria ser um efeito colateral de lotes pequenos, não uma meta perseguida sozinha.
Como o moasy.tech calcula isso
O moasy.tech recalcula a frequência de deploy automaticamente a partir do que já sincroniza do GitHub Actions, ArgoCD, Vercel, Azure Pipelines e Waroom — somente leitura, sem contagem manual. O que conta como deploy de produção é configurável por time, com um padrão da empresa como fallback, então a pergunta de "o que conta" é respondida explicitamente uma vez, em vez de assumida de um jeito diferente por cada time. Conectar mais de uma ferramenta de CI/CD no mesmo time também faz o moasy.tech detectar o risco de contar o mesmo deploy duas vezes, em vez de inflar o número silenciosamente.
Veja as outras 3 métricas DORA no guia completo, ou a implementação inteira na página de DORA Metrics.
Dado ilustrativo, apenas para demonstração.
Perguntas sobre frequência de deploy
E se não tivermos pipeline de CI/CD?
Dá pra contar transição de board em vez disso — mover um ticket pra "Concluído", por exemplo — como o sinal de deploy. É um evento de origem diferente, mas a mesma métrica por baixo.
Um rollback conta como deploy?
A maioria dos times conta, já que ainda é uma mudança chegando em produção — mas é uma decisão que vale a pena deixar explícita e aplicar de forma consistente, do mesmo jeito que "o que conta como deploy" precisa de uma resposta explícita em geral.
Fazer deploy mais é sempre melhor?
Só junto com as outras 3 métricas DORA. Fazer deploy com frequência com um change failure rate subindo só significa que falha acontece com mais frequência, não que a entrega de fato melhorou — frequência é uma peça do quadro, não o placar inteiro.
Veja sua própria frequência de deploy
Começar grátis