Este producto no es compatible con el sitio Datadog seleccionado. ().
Join the Preview!

Deployment Gates están en vista previa. Si le interesa esta función, complete el formulario para solicitar acceso.

Request Access

Con Deployment Gates preconfigurados, los gates y reglas se conservan en Datadog y se hace referencia a ellos por servicio y entorno en el momento de la evaluación. Los gates preconfigurados son una buena opción cuando desea compartir reglas entre muchas implementaciones, administrar la configuración en Terraform o permitir que usuarios que no son de CI editen reglas en la interfaz de usuario de Datadog.

¿Busca definir reglas en línea en su configuración de implementación? Consulte Just-In-Time (JIT) Deployment Gates.

Cree una puerta

Además de usar la interfaz de usuario de Deployment Gates, puede administrar gates y reglas mediante programación con la API de Deployment Gates o el proveedor de Terraform de Datadog.
  1. Vaya a Software Delivery > Deployment Gates > Configuration.
  2. Haga clic en Create Gate.
  3. Configure los siguientes ajustes:
    • Service: El nombre del servicio (ejemplo: transaction-backend).
    • Environment: El entorno de destino (ejemplo: dev).
    • Identifier (opcional, el valor predeterminado es default): Nombre único para varias puertas en el mismo servicio/entorno. Utilice esto para:
      • Permitir diferentes estrategias de implementación (ejemplo: fast-deploy frente a default)
      • Distinguir fases de implementación (ejemplo: pre-deploy frente a post-deploy)
      • Definir etapas canary (ejemplo: pre-deploy frente a canary-20pct)
    • Evaluation Mode: Habilite Dry Run para probar el comportamiento de la puerta sin afectar las implementaciones. La evaluación de una puerta de prueba (dry-run) siempre responde con un estado de aprobación, pero el resultado en la aplicación refleja la evaluación real. Esto es útil al realizar una evaluación inicial del comportamiento de la puerta sin afectar la canalización de implementación.

Agregar reglas a una puerta

Cada puerta requiere una o más reglas para evaluar. Todas las reglas deben aprobarse para que la puerta tenga éxito. Para cada regla, especifique:

  1. Name: Una etiqueta descriptiva que aparece en la página Evaluaciones de Deployment Gates (por ejemplo, Check all P0 monitors).
  2. Type: Seleccione Monitor o Faulty Deployment Detection.
  3. Configuración adicional basada en el tipo de regla seleccionado. Consulte Tipos de reglas para ver las opciones disponibles.
  4. Evaluation Mode: Cuando una regla se establece como Dry Run, su resultado no se tiene en cuenta al calcular el resultado general de la puerta.

Tipos de regla

Para ver el esquema completo y todas las opciones disponibles, consulte la Deployment Gates API reference.

La regla de seguimiento evalúa el estado de un conjunto de seguimientos durante un período de tiempo configurable. Seleccione seguimientos con una consulta de búsqueda o una lista explícita de seguimientos. Estos métodos de selección son mutuamente excluyentes. La regla puede fallar si en cualquier momento durante el período de evaluación:

  • Ningún grupo de seguimientos coincide con la selección configurada.
  • Un ID de seguimiento explícito no existe o no está disponible para su organización.
  • Más de 300 seguimientos coinciden con la selección configurada.
  • Cualquier grupo de seguimientos coincidente está en estado ALERT o NO_DATA.
Configuración de ajustes
  • Monitors matching query: Ingrese una consulta basada en la sintaxis de búsqueda de seguimientos. Filtrar por etiquetas de seguimiento:
    • Etiquetas estáticas de seguimiento: service:transaction-backend
    • Etiquetas dentro de la consulta de seguimiento: scope:"service:transaction-backend"
    • Etiquetas dentro de una agrupación de seguimientos: group:"service:transaction-backend"
  • Specific monitors: Seleccione seguimientos individuales y, opcionalmente, los grupos exactos a evaluar para cada seguimiento. Cuando no se seleccionan grupos, se evalúan todos los grupos para ese seguimiento.
  • Duration: El período de tiempo (en segundos) durante el cual se evalúan los seguimientos seleccionados. El valor predeterminado es 0 (los seguimientos se evalúan al instante). El máximo es 7200 segundos (2 horas).
Ejemplos de consultas
  • env:prod service:transaction-backend
  • env:prod (service:transaction-backend OR group:"service:transaction-backend" OR scope:"service:transaction-backend")
  • tag:"use_deployment_gates" team:payment
  • tag:"use_deployment_gates" AND (NOT group:("team:frontend"))
Ejemplo de API de seguimientos específicos
"options": {
  "monitor_ids": [
    {"id": "12345678", "groups": []},
    {"id": "87654321", "groups": ["service:api", "env:prod"]}
  ],
  "duration": 300
}

Cada id es un ID de seguimiento decimal. Los valores de grupo son nombres de grupo exactos. No envíe query con monitor_ids.

Notas:

  • group las consultas de filtro y monitor_ids[].groups evalúan solo los grupos coincidentes.
  • Un ID de seguimiento explícito que no existe o no está disponible para su organización hace que la regla falle. Si el seguimiento existe pero está excluido porque está silenciado o sus grupos seleccionados no tienen datos, la regla aplica el comportamiento de no coincidencia de grupos.
  • Los seguimientos silenciados se excluyen automáticamente de ambos modos de selección.

Este tipo de regla utiliza el análisis de APM Faulty Deployment Detection de Watchdog para comparar la versión desplegada con versiones anteriores del mismo servicio. El análisis detecta:

  • Nuevos tipos de errores.
  • Aumentos significativos en las tasas de error en comparación con versiones anteriores.

El análisis se realiza automáticamente para todos los servicios instrumentados con APM y no se requiere configuración previa.

Configuración de ajustes
  • Operation Name: Se completa automáticamente a partir de la configuración de operación principal de APM del servicio.
  • Duration: El período de tiempo (en segundos) durante el cual se ejecuta el análisis. Para una confianza de análisis óptima, este valor debe ser de al menos 900 segundos (15 minutos) después de que comience una implementación. El máximo es 7200 segundos (2 horas).
  • Allowed Resources (opcional): Una lista de recursos de APM separados por comas para incluir en el análisis. Cuando se especifica, solo se analizan los recursos enumerados. Mutualmente excluyente con Excluded Resources.
  • Excluded Resources (opcional): Una lista de recursos de APM separados por comas a ignorar (como endpoints de bajo volumen o baja prioridad). Mutualmente excluyente con Allowed Resources.

Notas:

  • La regla se evalúa para cada valor de etiqueta principal adicional, así como para un análisis agregado. Para considerar solo una etiqueta principal, especifíquela al solicitar una evaluación de puerta.
  • Se detectan nuevos errores y aumentos en la tasa de errores a nivel de recurso.
  • Este tipo de regla no admite servicios marcados como database o inferred service.

Evalúe un Deployment Gate desde su canalización

Una vez configurada la puerta, solicite una evaluación al implementar el servicio relacionado y decida si bloquear o continuar la implementación según el resultado.

El comando deployment gate de datadog-ci ejecuta la evaluación en un solo comando:

datadog-ci deployment gate --service transaction-backend --env staging --identifier default

Si la puerta de implementación contiene reglas de detección de implementaciones defectuosas de APM, especifique también la versión (por ejemplo, --version 1.0.1).

El comando:

  • Envía una solicitud para iniciar la evaluación de Deployment Gate y se bloquea hasta que se complete la evaluación.
  • Proporciona un tiempo de espera configurable para cuánto tiempo esperar una evaluación.
  • Tiene reintentos automáticos integrados para errores.
  • Acepta --fail-on-error para personalizar el comportamiento ante errores inesperados de Datadog.

El comando deployment gate está disponible en las versiones v3.17.0 y superiores de datadog-ci.

Variables de entorno requeridas:

Para obtener opciones de configuración completas y ejemplos de uso, consulte la documentación del comando deployment gate.

Llame a Deployment Gates desde un recurso de Kubernetes de Argo Rollouts creando un AnalysisTemplate o un ClusterAnalysisTemplate. La plantilla ejecuta el comando deployment gate de datadog-ci para interactuar con la API de Deployment Gates.

Utilice la siguiente plantilla como punto de partida:

apiVersion: argoproj.io/v1alpha1
kind: ClusterAnalysisTemplate
metadata:
  name: datadog-job-analysis
spec:
  args:
    - name: service
    - name: env
  metrics:
    - name: datadog-job
      provider:
        job:
          spec:
            ttlSecondsAfterFinished: 300
            backoffLimit: 0
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: datadog-check
                    image: datadog/ci:v3.17.0
                    env:
                      - name: DD_BETA_COMMANDS_ENABLED
                        value: "1"
                      - name: DD_SITE
                        value: "<YOUR_DD_SITE>"
                      - name: DD_API_KEY
                        valueFrom:
                          secretKeyRef:
                            name: datadog
                            key: api-key
                      - name: DD_APP_KEY
                        valueFrom:
                          secretKeyRef:
                            name: datadog
                            key: app-key
                    command: ["/bin/sh", "-c"]
                    args:
                      - datadog-ci deployment gate --service {{ args.service }} --env {{ args.env }} --identifier default
  • La plantilla de análisis puede recibir argumentos del recurso Rollout (como service, env y version). Para obtener más información, consulte la documentación oficial de Argo Rollouts.
  • ttlSecondsAfterFinished elimina los trabajos finalizados después de 5 minutos.
  • backoffLimit se establece en 0 porque el trabajo no debe volver a intentarse si la evaluación de Deployment Gate falla.

Después de crear la plantilla de análisis, haga referencia a ella desde la estrategia de Argo Rollouts:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
  labels:
    tags.datadoghq.com/service: transaction-backend
    tags.datadoghq.com/env: dev
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        ...
        - analysis:
            templates:
              - templateName: datadog-job-analysis
                clusterScope: true # Only needed for cluster analysis
            args:
              - name: env
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.labels['tags.datadoghq.com/env']
              - name: service
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.labels['tags.datadoghq.com/service']
              - name: version #Required for APM Faulty Deployment Detection rules
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.labels['tags.datadoghq.com/version']
        - ...

La Datadog Deployment Gate GitHub Action ejecuta la evaluación como parte de un flujo de trabajo.

Agregue un DataDog/deployment-gate-github-action paso a su flujo de trabajo de implementación existente:

name: Deploy with Datadog Deployment Gate
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy Canary
        run: |
          echo "Deploying canary release for service:'my-service' in 'production'. Version 1.0.1"
          # Your deployment commands here

      - name: Evaluate Deployment Gate
        uses: DataDog/deployment-gate-github-action@v2.1.0
        env:
          DD_API_KEY: ${{ secrets.DD_API_KEY }}
          DD_APP_KEY: ${{ secrets.DD_APP_KEY }}
        with:
          service: my-service
          env: production
          identifier: default

      - name: Deploy
        run: |
          echo "Deployment Gate passed, proceeding with deployment"
          # Your deployment commands here

Si la puerta de implementación contiene reglas de detección de implementaciones defectuosas de APM, especifique también la versión (por ejemplo, version: 1.0.1).

La acción:

  • Envía una solicitud para iniciar la evaluación de Deployment Gate y se bloquea hasta que se complete la evaluación.
  • Proporciona un tiempo de espera configurable para cuánto tiempo esperar una evaluación.
  • Tiene reintentos automáticos integrados para errores.
  • Acepta fail-on-error para personalizar el comportamiento ante errores inesperados de Datadog.

Variables de entorno requeridas:

Para obtener opciones de configuración completas y ejemplos de uso, consulte el DataDog/deployment-gate-github-action repositorio.

Utilice este script como punto de partida. Evalúa una puerta preconfigurada sin reglas en línea.

Reemplace lo siguiente:

#!/bin/sh

# Configuration
MAX_RETRIES=3
DELAY_SECONDS=5
POLL_INTERVAL_SECONDS=15
MAX_POLL_TIME_SECONDS=10800 # 3 hours
API_URL="https://api.<YOUR_DD_SITE>/api/v2/deployments/gates/evaluation"
API_KEY="<YOUR_API_KEY>"
APP_KEY="<YOUR_APP_KEY>"

PAYLOAD=$(cat <<EOF
{
  "data": {
    "type": "deployment_gates_evaluation_request",
    "attributes": {
      "service": "$1",
      "env": "$2",
      "version": "$3"
    }
  }
}
EOF
)

# Step 1: Request evaluation
echo "Requesting evaluation..."
current_attempt=0
while [ $current_attempt -lt $MAX_RETRIES ]; do
   current_attempt=$((current_attempt + 1))
   RESPONSE=$(curl -s -w "%{http_code}" -o response.txt -X POST "$API_URL" \
       -H "Content-Type: application/json" \
       -H "DD-API-KEY: $API_KEY" \
       -H "DD-APPLICATION-KEY: $APP_KEY" \
       -d "$PAYLOAD")

   HTTP_CODE=$(echo "$RESPONSE" | tail -c 4)
   RESPONSE_BODY=$(cat response.txt)

   if [ ${HTTP_CODE} -ge 500 ]  &&  [ ${HTTP_CODE} -le 599 ]; then
       echo "Attempt $current_attempt: 5xx Error ($HTTP_CODE). Retrying in $DELAY_SECONDS seconds..."
       sleep $DELAY_SECONDS
       continue
   elif [ ${HTTP_CODE} -ge 400 ] && [ ${HTTP_CODE} -le 499 ]; then
       echo "Client error ($HTTP_CODE): $RESPONSE_BODY"
       exit 1
   fi

   EVALUATION_ID=$(echo "$RESPONSE_BODY" | jq -r '.data.attributes.evaluation_id')
   if [ "$EVALUATION_ID" = "null" ] || [ -z "$EVALUATION_ID" ]; then
       echo "Failed to extract evaluation_id from response: $RESPONSE_BODY"
       exit 1
   fi

   echo "Evaluation started with ID: $EVALUATION_ID"
   break
done

if [ $current_attempt -eq $MAX_RETRIES ]; then
   echo "All retries exhausted for evaluation request, but treating 5xx errors as success."
   exit 0
fi

# Step 2: Poll for results
echo "Polling for results..."
start_time=$(date +%s)
poll_count=0

while true; do
  poll_count=$((poll_count + 1))
  current_time=$(date +%s)
  elapsed_time=$((current_time - start_time))

  if [ $elapsed_time -ge $MAX_POLL_TIME_SECONDS ]; then
      echo "Evaluation polling timeout after ${MAX_POLL_TIME_SECONDS} seconds"
      exit 1
  fi

  RESPONSE=$(curl -s -w "%{http_code}" -o response.txt -X GET "$API_URL/$EVALUATION_ID" \
      -H "DD-API-KEY: $API_KEY" \
      -H "DD-APPLICATION-KEY: $APP_KEY")

  HTTP_CODE=$(echo "$RESPONSE" | tail -c 4)
  RESPONSE_BODY=$(cat response.txt)

  if [ ${HTTP_CODE} -eq 404 ]; then
      echo "Evaluation not ready yet (404), retrying in $POLL_INTERVAL_SECONDS seconds... (attempt $poll_count, elapsed: ${elapsed_time}s)"
      sleep $POLL_INTERVAL_SECONDS
      continue
  elif [ ${HTTP_CODE} -ge 500 ]  &&  [ ${HTTP_CODE} -le 599 ]; then
      echo "Server error ($HTTP_CODE) while polling, retrying in $POLL_INTERVAL_SECONDS seconds... (attempt $poll_count, elapsed: ${elapsed_time}s)"
      sleep $POLL_INTERVAL_SECONDS
      continue
  elif [ ${HTTP_CODE} -ge 400 ] && [ ${HTTP_CODE} -le 499 ]; then
      echo "Client error ($HTTP_CODE) while polling: $RESPONSE_BODY"
      exit 1
  fi

  GATE_STATUS=$(echo "$RESPONSE_BODY" | jq -r '.data.attributes.gate_status')

  if [ "$GATE_STATUS" = "pass" ]; then
      echo "Gate evaluation PASSED"
      exit 0
  elif [ "$GATE_STATUS" = "fail" ]; then
      echo "Gate evaluation FAILED"
      exit 1
  else
      echo "Evaluation still in progress (status: $GATE_STATUS), retrying in $POLL_INTERVAL_SECONDS seconds... (attempt $poll_count, elapsed: ${elapsed_time}s)"
      sleep $POLL_INTERVAL_SECONDS
      continue
  fi
done

El script:

  • Recibe tres entradas: service, environment y version. version es obligatorio si la puerta tiene reglas de Detección de implementaciones defectuosas de APM. También puede agregar identifier y primary_tag si es necesario.
  • Envía una solicitud para iniciar la evaluación y registra el evaluation_id. Maneja códigos de respuesta HTTP:
    • 5xx: error del servidor, reintenta con retraso.
    • 4xx: error del cliente, la evaluación falla.
    • 2xx: evaluación iniciada.
  • Consulta el punto de conexión de estado de evaluación con el evaluation_id hasta que la evaluación se complete:
    • 5xx: error del servidor, reintenta con retraso.
    • 404: evaluación aún no iniciada, reintenta con retraso.
    • 4xx (excepto 404): error del cliente, la evaluación falla.
    • 2xx: verificación gate_status y vuelva a intentar con retraso si no se ha completado.
  • Consulta cada 15 segundos hasta que la evaluación se complete o se alcance el tiempo máximo de consulta (10800 segundos = 3 horas por defecto).
  • Si se agotan todos los reintentos para la solicitud inicial (respuestas 5xx), el script trata esto como un éxito para ser resiliente ante fallas de la API.

Adapte el script a su caso de uso. Utiliza curl (para realizar la solicitud) y jq (para procesar el JSON devuelto). Si esos comandos no están disponibles, instálelos al principio del script (por ejemplo, con apk add --no-cache curl jq).

Las evaluaciones de Deployment Gate son asíncronas. Cuando activa una evaluación, esta se inicia en segundo plano y la API devuelve un ID de evaluación que puede usar para seguir su progreso:

  • Primero, solicite una evaluación de Deployment Gate, lo cual inicia el proceso y devuelve un ID de evaluación.
  • Luego, consulte periódicamente el punto de conexión de estado de evaluación con el ID de evaluación para recuperar el resultado cuando la evaluación se complete. Se recomienda consultar cada 10-20 segundos.

Reemplace lo siguiente:

Solicite una evaluación para una puerta que ya existe en Datadog:

curl -X POST "https://api.<YOUR_DD_SITE>/api/v2/deployments/gates/evaluation" \
-H "Content-Type: application/json" \
-H "DD-API-KEY: <YOUR_API_KEY>" \
-H "DD-APPLICATION-KEY: <YOUR_APP_KEY>" \
-d @- << EOF
{
  "data": {
    "type": "deployment_gates_evaluation_request",
    "attributes": {
      "service": "transaction-backend",
      "env": "staging",
      "identifier": "my-custom-identifier",
      "version": "v123-456",
      "primary_tag": "region:us-central-1"
    }
  }
}
EOF

Atributos opcionales:

  • identifier: Opcional, el valor predeterminado es default.
  • version: Requerido para las reglas de Detección de Implementación Defectuosa de APM.
  • primary_tag: Opcional, limita el análisis de Detección de Implementación Defectuosa de APM a la etiqueta principal seleccionada.

Nota: Una respuesta HTTP 404 puede significar que la puerta no se encontró, o que la puerta se encontró pero no tiene reglas.

Si la evaluación de la puerta se inició correctamente, se devuelve un código de estado HTTP 202:

{
   "data": {
       "id": "<random_response_uuid>",
        "type": "deployment_gates_evaluation_response",
        "attributes": {
            "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9"
        }
    }
}

El campo data.attributes.evaluation_id contiene el identificador único para esta evaluación de puerta.

Obtenga el estado de una evaluación de puerta consultando el punto de conexión de estado con el ID de evaluación:

curl -X GET "https://api.<YOUR_DD_SITE>/api/v2/deployments/gates/evaluation/<evaluation_id>" \
-H "DD-API-KEY: <YOUR_API_KEY>" \
-H "DD-APPLICATION-KEY: <YOUR_APP_KEY>"

Nota: Si llama a este punto de conexión demasiado pronto después de solicitar la evaluación, es posible que se devuelva una respuesta HTTP 404 porque la evaluación aún no ha comenzado. Vuelva a intentarlo unos segundos después.

Cuando se devuelve una respuesta HTTP 200, tiene el siguiente formato:

{
   "data": {
       "id": "<random_response_uuid>",
       "type": "deployment_gates_evaluation_result_response",
       "attributes": {
           "dry_run": false,
           "evaluation_id": "e9d2f04f-4f4b-494b-86e5-52f03e10c8e9",
           "evaluation_url": "https://app.datadoghq.com/ci/deployment-gates/evaluations?index=cdgates&query=level%3Agate+%40evaluation_id%3Ae9d2f14f-4f4b-494b-86e5-52f03e10c8e9",
           "gate_id": "e140302e-0cba-40d2-978c-6780647f8f1c",
           "gate_status": "pass",
           "rules": [
               {
                   "name": "Check service monitors",
                   "status": "fail",
                   "reason": "One or more monitors in ALERT state: https://app.datadoghq.com/monitors/34330981",
                   "dry_run": true
               }
           ]
       }
   }
}

El campo data.attributes.gate_status contiene el resultado de la evaluación, con uno de estos valores:

  • in_progress: La evaluación de Deployment Gate aún está en curso; continúe consultando.
  • pass: La evaluación de Deployment Gate fue aprobada.
  • fail: La evaluación de Deployment Gate falló.

Nota: Si el campo data.attributes.dry_run es true, el campo data.attributes.gate_status siempre es pass.

Recomendación para la incorporación por primera vez

Al integrar Deployment Gates en su flujo de trabajo de Continuous Delivery, una fase de evaluación ayuda a confirmar que el producto funciona como se espera antes de que afecte las implementaciones. Utilice el modo de evaluación de prueba (Dry Run) y la página Deployment Gates Evaluations:

  1. Cree una puerta para un servicio y establezca Evaluation Mode en Dry Run.
  2. Agregue la evaluación de la puerta a su proceso de implementación. Mientras la puerta esté en modo de prueba, la API siempre devuelve pass y las implementaciones no se ven afectadas por el resultado de la puerta.
  3. Después de un período de tiempo (por ejemplo, 1-2 semanas), realice la verificación de las ejecuciones de la puerta y las reglas en la página Deployment Gates Evaluations. La interfaz de usuario muestra el estado real, por lo que puede ver cuándo habría fallado la puerta y la razón detrás de esto.
  4. Cuando esté seguro de que el comportamiento de la puerta es el esperado, edite la puerta y cambie el modo de evaluación de Dry Run a Active. Después, la API comienza a devolver el estado real y las implementaciones comienzan a promoverse o revertirse según el resultado de la puerta.

Lecturas adicionales