Para garantizar que los despliegues de servicios rastreados por APM contribuyan a las métricas de DORA, deben cumplirse los siguientes requisitos:
Tu servicio tiene metadatos definidos en el Catálogo de servicios.
Tu servicio tiene el etiquetado unificado de servicios activado. Los despliegues se identifican utilizando la etiqueta (tag) version.
Para obtener más información sobre cómo garantizar que los despliegues de servicios que se rastrean en APM contribuyan al tiempo de espera de cambio, consulta Fuentes de datos del despliegue.
service: El servicio que se ha desplegado. Si el servicio provisto está registrado en el Catálogo de servicios con metadatos configurados (consulta Añadir metadatos), el team del servicio se recupera automáticamente y se asocia con todas las métricas.
Los atributos repository_url y commit_sha también son necesarios para calcular la métrica del tiempo de espera de cambio. Opcionalmente, puedes especificar un atributo team para asociar un despliegue con un team diferente al que se encuentra automáticamente para el servicio. También puedes especificar el atributo env para filtrar tus métricas de DORA por entorno en la página Métricas de DORA.
La herramienta CLI datadog-ci proporciona un acceso directo para enviar eventos del despliegue en tu entorno de integración continua.
Para el siguiente ejemplo, configura la variable de entorno DD_SITE en datadoghq.com y configura la variable de entorno DD_API_KEY en tu Clave de la API Datadog:
La hora de finalización del despliegue se configura automáticamente en ahora si no se proporciona --finished-at.
Si el trabajo de CI de despliegue se está ejecutando exactamente en la misma revisión de Git que se está desplegando, git-repository-url y git-commit-sha pueden omitirse y se deducen automáticamente del contexto de CI.
Se puede proporcionar la opción --skip-git para desactivar el envío de la URL del repositorio y el SHA de la confirmación. Cuando se añade esta opción, la métrica del tiempo de espera de cambio deja de estar disponible.
La frecuencia de despliegue se calcula en función de la métrica dora.deployments.count que se genera y aumenta con cada despliegue detectado desde tu fuente de datos de despliegue seleccionada. La frecuencia se calcula dividiendo dora.deployments.count entre un periodo de tiempo específico.
Para una única confirmación de Git, el tiempo de espera de cambio (CLT) se calcula como el tiempo transcurrido desde la creación de la confirmación hasta el momento en que se ejecutó el despliegue que incluía dicha confirmación.
Para calcular el tiempo de espera de cambio de un despliegue, Datadog ejecuta git log entre el SHA del confirmación de despliegue y el SHA de confirmación de despliegue anterior para encontrar todas las confirmaciones que se están desplegando. A continuación, calcula la media de los valores de tiempo de espera de cambio relacionados para todas estas confirmaciones. Datadog no almacena el contenido real de los archivos de tu repositorio, sólo los objetos de árbol y confirmación de Git.
Para los despliegues identificados a través del Rastreo de despliegue de APM, el tiempo de espera de cambio de una confirmación se calcula desde el momento de la creación de la confirmación hasta que esa confirmación se ve por primera vez en una nueva versión. Esto significa que la métrica dora.deploy_time no está disponible.
Para que los despliegues de servicios rastreadas por APM contribuyan al tiempo de espera de cambio, asegúrate de lo siguiente:
Los metadatos de tu repositorio se sincronizan con Datadog a través de la integración de GitHub o mediante el comando datadog-ci git-metadata upload.
Para que los despliegues de servicios rastreados por la API de métricas de DORA o el comando datadog-ci dora deployment contribuyan al tiempo de espera de cambio, asegúrate de lo siguiente:
Que los metadatos de tu repositorio se sincronicen con Datadog a través de la integración de GitHub o mediante el comando datadog-ci git-metadata upload.
Para obtener más información sobre el desglose de la métrica del tiempo de espera de cambio, consulta Datos recopilados.
Los flujos de trabajo de GitHub que se ejecutan con el activador pull_requestno son compatibles actualmente con la integración de GitHub.
Si utilizas el activador pull_request, utiliza el método alternativo.
Selecciona al menos permisos de Lectura del repositorio para Contenido y Solicitudes de extracción.
Suscríbete al menos a los eventos Push, PullRequest y PullRequestReview.
Para confirmar que la configuración es válida, selecciona tu aplicación GitHub en el ícono de integración de GitHub y comprueba que, en la pestaña Features (Funciones), esté activada la función Métricas de DORA: Recopilar la métrica del tiempo de espera de cambio.
Puedes cargar los metadatos de tu repositorio de Git con el comando datadog-ci git-metadata upload.
Cuando se ejecuta este comando, Datadog recibe la URL del repositorio, el SHA de confirmación de la rama actual y una lista de rutas de archivos rastreados.
Ejecuta este comando en CI para cada nueva confirmación. Si se ejecuta un despliegue para un SHA de confirmación específico, asegúrate de que el comando datadog-ci git-metadata upload se ejecute para esa confirmación antes de que se envíe el evento del despliegue.
No proporciones la opción --no-gitsync al comando de metadatos de Datadog-ci git.
Cuando se incluye esa opción, la información de la confirmación no se envía a Datadog ni se calcula la métrica del tiempo de espera de cambio.
Puedes validar la configuración correcta del comando comprobando la salida del comando. Un ejemplo de una salida correcta es el siguiente:
Reporting commit 007f7f466e035b052415134600ea899693e7bb34 from repository git@github.com:organization/example-repository.git.
180 tracked file paths will be reported.
✅ Handled in 0.077 seconds.
Si el código fuente de varios servicios está presente en el mismo repositorio, se necesitan acciones adicionales para asegurar que el tiempo de espera de cambio se calcule teniendo en cuenta sólo las confirmaciones que afectan al servicio específico que se está desplegando.
Para filtrar las confirmaciones medidas a sólo las que afectan al servicio, especifica los patrones de las rutas de archivos glob del código fuente en la definición de servicios.
Si la definición de servicios contiene una URL completa de GitHub a la carpeta de la aplicación, se utilizará automáticamente un único patrón de ruta.
Las métricas de DORA para el servicio shopist sólo consideran las confirmaciones de Git que incluyen cambios en src/apps/shopist/**. Puedes configurar un control más granular del filtrado con extensions[datadoghq.com/dora-metrics].
Las métricas de DORA para el servicio shopist sólo tienen en cuenta las confirmaciones de Git que incluyen cambios en src/apps/shopist/** o src/libs/utils/**.
Si se definen las dos entradas de metadatos para un servicio, sólo se tiene en cuenta extensions[datadoghq.com/dora-metrics] para filtrar los confirmaciones.
Las métricas del desglose por etapas del tiempo de espera de cambio sólo están disponibles para GitHub.
El tiempo de espera de cambio no está disponible para el primer despliegue de un servicio que incluya información de Git.
El cálculo del tiempo de espera de cambio incluye un máximo de 5000 confirmaciones por despliegue.
Para las ramas recalculadas, los cálculos del tiempo de espera de cambio consideran las nuevas confirmaciones creadas durante el recálculo, no las confirmaciones originales.
Cuando se utiliza “Squash” para fusionar solicitudes de extracción:
Para GitHub: se emiten métricas para las confirmaciones originales.
Para otros proveedores de git: se emiten métricas para la nueva confirmación añadida a la rama de destino.
La tasa de fallas de cambio se calcula dividiendo dora.incidents.count entre dora.deployments.count para los mismos servicios y/o equipos asociados con un incidente y con un evento de despliegue.