La Frecuencia de Despliegue (Deployment Frequency) mide cada cuánto ocurren los despliegues a producción en un período seleccionado. Es una de las cuatro métricas DORA y el indicador más simple de la cadencia de release.
Qué mide
El total de despliegues a producción por unidad de tiempo, normalmente por día, semana o mes. Una frecuencia más alta suele indicar lotes más chicos, mejor automatización y ciclos de feedback más cortos.
De dónde viene la señal de despliegue
Leanmote puede contar los despliegues de dos formas, y eliges cuál usa tu organización:
Pull requests mergeados (por defecto) — cada pull request mergeado a un repositorio seguido cuenta como un despliegue. El merge es un sustituto del shipeo: no necesita configuración de CI/CD, funciona desde el día en que conectas GitHub y, en los equipos que despliegan al mergear, sigue tu cadencia real de release bastante de cerca.
Despliegues de GitHub (opcional) — Leanmote cuenta los despliegues a producción registrados en GitHub para tus repositorios. Esto mide la release en sí y no el merge que la precedió, así que también ve los despliegues que ningún pull request explica: un rollback, un re-despliegue del mismo commit, un commit pusheado directo a tu rama principal.
¿Ya despliegas en cada merge? Entonces las dos fuentes van a reportar números parecidos, y quedarte con la opción por defecto es una respuesta perfectamente buena. Cambiar igual modifica dos cosas: un merge cuyo despliegue falló deja de contar como algo que shipeaste, y la Tasa de Fallos de Cambios empieza a leer el estado que tu pipeline le reportó a GitHub en lugar de inferir la falla desde los títulos de los pull requests. Los equipos que ven la mayor diferencia son los que juntan varios merges en una sola release, los que despliegan en horarios programados o los que despliegan sin pull request.
La opción afecta solo a la Frecuencia de Despliegue y a la Tasa de Fallos de Cambios. El Tiempo de Entrega de Cambios y el Tiempo Medio de Recuperación siguen basados en el merge.
Cómo lo calcula Leanmote
Con la fuente por defecto de PRs mergeados:
deployment_frequency = merged_pull_requests / days_in_selected_range
Con los despliegues de GitHub activados:
deployment_frequency = production_deployments / days_in_selected_range
El denominador es la duración en días del rango de fechas seleccionado, así las líneas de tendencia quedan comparables entre rangos.
Los despliegues se agrupan por día (UTC) usando la hora de creación del despliegue en GitHub — eso es lo que grafica el gráfico.
Solo se cuentan los despliegues a un entorno que GitHub marca como producción. Si tu organización nunca marca ningún entorno como producción, Leanmote cuenta todos los despliegues en lugar de mostrar cero.
Ver detalles lista lo que se contó: los PRs mergeados o, en modo despliegue, el repositorio, el entorno, la ref, el estado y la hora de despliegue de cada uno.
Vistas disponibles: por equipo, por repositorio y de toda la organización.
Cambiar a los despliegues de GitHub
Ve a
Configuración → Módulos → Desempeño de Entregas.Activa Medir despliegues desde GitHub.
La opción está disponible solo para el propietario de la organización, y aparece únicamente cuando GitHub está conectado con al menos un repositorio activo: hoy los datos de despliegue son exclusivos de GitHub.
Qué lee Leanmote como un despliegue:
Los despliegues creados a través de la API de Deployments de GitHub — el caso habitual de GitHub Actions, Argo CD, Heroku y herramientas similares.
Si tu pipeline despliega sin crear objetos de despliegue de GitHub, Leanmote puede leer en su lugar un check run de producción con nombre específico sobre tus tags de release. Pídele a tu contacto de Leanmote que configure el nombre del check para tu organización.
Al activar la opción arranca un backfill automático de hasta un año de historial de despliegues (solo trae el historial que te falta). Mientras corre, la pestaña Rendimiento de Entrega de Software muestra un aviso de «Estamos trayendo tu historial de despliegues» que desaparece en cuanto llegan los datos, y que nunca queda más de 24 horas. Volver a desactivar la opción devuelve la métrica a contar pull requests mergeados de inmediato; el historial de despliegues capturado se conserva.
Cómo interpretarla
En alza — normalmente sano. Suele venir junto con un Tiempo de Entrega más corto.
En baja mientras el backlog se mantiene alto — una señal de alarma de cuello de botella en la entrega.
Plana con la tasa de fallos en alza — llegaste a un techo de calidad. Investiga la cobertura de tests o el proceso de release.
Un salto justo después de cambiar de fuente — es lo esperado, no un bug. Los merges y los despliegues cuentan eventos distintos, así que no compares el antes y el después del cambio.
Qué hacer al respecto
Lotes más chicos (menos commits por PR, menos features por release) suelen levantar esta métrica rápido.
Reduce los pasos de aprobación manual. Cada compuerta tiene un costo multiplicativo.
Mejora la confiabilidad de los tests para que los despliegues no queden bloqueados por checks inestables.
Métricas relacionadas
Tiempo de Entrega de Cambios
Tasa de Fallos de Cambios
Tiempo Medio de Recuperación
Panorama de métricas DORA