Usa una estrategia de implementación de versiones canary

En este documento, se describe cómo configurar y usar una estrategia de implementación de versiones canary.

¿Qué es una implementación de versiones canary?

Una implementación de versiones canary es un lanzamiento progresivo de una aplicación que divide el tráfico entre una versión ya implementada y una versión nueva, y se lanza a un subconjunto de usuarios antes de realizar el lanzamiento completo.

Tipos de destinos admitidos

La implementación de versiones canary en Cloud Deploy admite todos los tipos de destinos, incluidos los siguientes:

Canary también funciona con varios destinos.

¿Por qué usar una estrategia de implementación de versiones canary?

Una implementación de versiones canary te brinda la oportunidad de lanzar tu aplicación de forma parcial. De esta manera, puedes asegurarte de que la versión nueva de tu aplicación sea confiable antes de entregarla a todos los usuarios.

Si implementas en GKE o GKE Enterprise, por ejemplo, deberías implementar la versión nueva de tu aplicación en una cantidad limitada de Pods. La versión anterior seguiría ejecutándose, pero se enviaría más tráfico a los pods nuevos.

Si implementas en Cloud Run, este último divide el tráfico entre las revisiones anteriores y las nuevas, según los porcentajes que configures.

Tipos de versiones canary

Cloud Deploy te permite configurar los siguientes tipos de implementación de versiones canary:

  • Automatizado

    Con una implementación automática de versiones canary, configuras Cloud Deploy con una serie de porcentajes que expresan una implementación progresiva. Cloud Deploy realiza operaciones adicionales en tu nombre para distribuir porcentajes de tráfico entre la versión nueva y la anterior.

  • Personalización personalizada

    Para un Canary automatizado y personalizado, puedes proporcionar lo siguiente:

    • El nombre de la fase
    • El objetivo porcentual
    • El perfil de Skaffold que se usará para la fase
    • Indica si se debe incluir o no un trabajo de verificación

    Sin embargo, no necesitas proporcionar información de balanceo de tráfico; Cloud Deploy crea los recursos necesarios, como se describe aquí.

  • Personalizado

    Con un canary personalizado, configuras cada fase de la versión canary por separado, incluidas las siguientes:

    • El nombre de la fase
    • El objetivo porcentual
    • El perfil de Skaffold que se usará para la fase
    • Indica si se debe incluir o no un trabajo de verificación

    Además, para una versión canary completamente personalizada, debes proporcionar toda la configuración del balanceo de tráfico, como se describe aquí.

Fases de una implementación de versiones canary

Cuando creas una versión para una implementación de versiones canary, el lanzamiento se crea con una fase para cada incremento de versión canary, más una fase final stable del 100%.

Por ejemplo, si configuras una versión canary para incrementos de 25%, 50% y 75%, el lanzamiento tendrá las siguientes fases:

  • canary-25
  • canary-50
  • canary-75
  • stable

Puedes obtener más información sobre las fases de lanzamiento, los trabajos y las ejecuciones de trabajos en Administra lanzamientos.

Qué sucede durante una implementación de versiones canary automatizada o personalizada

Para admitir la implementación de versiones canary, Cloud Deploy incluye pasos de procesamiento especiales cuando renderizas el manifiesto de Kubernetes o la configuración del servicio de Cloud Run:

GKE/Enterprise

A continuación, se muestra cómo Cloud Deploy ejecuta una implementación de versiones canary en GKE y GKE Enterprise basados en la red:

  1. Proporcionas el nombre del recurso de Deployment y del recurso Service.

  2. Cloud Deploy crea un recurso de Deployment adicional con el nombre de tu Deployment actual más -canary.

  3. Cloud Deploy modifica el Service para ajustar el selector y elegir los Pods del Deployment actual y los Pods de la versión canary.

    Cloud Deploy calcula la cantidad de Pods que se usarán para la versión canary según el cálculo que se describe aquí. Ese cálculo difiere según si habilitas o inhabilitas el sobreaprovisionamiento de Pods.

    Si omitimos a la fase stable, Cloud Deploy agrega las etiquetas que se usarán para hacer coincidir los Pods, de modo que estén disponibles para ejecuciones de versiones canary posteriores.

    Cloud Deploy crea un Deployment que incluye el porcentaje de Pods específico de la fase y lo actualiza para cada fase. Para ello, se calcula la cantidad de pods como un porcentaje de la cantidad original de pods. Esto puede generar una división del tráfico inexacta. Si necesitas una división del tráfico exacta, puedes lograrlo con la API de Gateway.

    Además, los Secrets y los ConfigMaps también se copian y se les cambia el nombre con -canary.

  4. Durante la fase stable, el Deployment -canary se reduce verticalmente a cero, y el Deployment original se reemplaza por el Deployment nuevo.

    Cloud Deploy no modifica la Deployment original hasta la fase stable.

Cloud Deploy aprovisiona Pods para alcanzar el porcentaje de versiones canary solicitado lo más cerca posible. Esto se basa en la cantidad de Pods, no en el tráfico hacia los Pods. Si deseas que tu versión canary se base en el tráfico, debes usar la API de puerta de enlace.

Para la versión canary basada en la red de GKE, puedes habilitar o inhabilitar el aprovisionamiento en exceso de Pods. En las siguientes secciones, se describe cómo Cloud Deploy calcula la cantidad de Pods que se aprovisionarán para la implementación de versiones canary en cada fase de versiones canary.

Aprovisionamiento de Pods con el aprovisionamiento en exceso habilitado

Habilitar el aprovisionamiento en exceso (disablePodOverprovisioning: false) permite que Cloud Deploy cree suficientes Pods adicionales para ejecutar el porcentaje de versiones canary que desees, según la cantidad de Pods que ejecuten tu implementación existente. La siguiente fórmula muestra cómo Cloud Deploy calcula la cantidad de Pods que se aprovisionarán para la implementación de versiones canary para cada fase de versiones canary, cuando el aprovisionamiento excesivo de Pods está habilitado:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Con esta fórmula, el recuento actual de réplicas (la cantidad de Pods que ya tienes, antes de esta versión canary) se multiplica por el porcentaje de versiones canary de la fase y el resultado se divide por (100 menos el porcentaje).

Por ejemplo, si ya tienes 4 Pods y la fase de versiones canary es del 50%, el número de Pods de versión canary es de 4. (El resultado de 100-percentage se usa como un porcentaje: 100-50=50, que se trata como .50).

El aprovisionamiento en exceso de Pods es el comportamiento predeterminado.

Aprovisionamiento de Pods con aprovisionamiento en exceso inhabilitado

Puedes inhabilitar el aprovisionamiento en exceso (disablePodOverprovisioning: true) para asegurarte de que Cloud Deploy no aumente el recuento de réplicas.

La siguiente fórmula muestra cómo Cloud Deploy calcula el aprovisionamiento de Pods para la implementación de versiones canary en cada fase de versiones canary, cuando el aprovisionamiento excesivo de Pods está inhabilitado:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

En esta fórmula, ReplicaCountOfCanaryDeploymentOnCluster solo existe si ya había una fase de versión canary. Si esta es la primera fase de la versión canary, no habrá ReplicaCountOfCanaryDeploymentOnCluster.

Si comienzas con 4 Pods, esa cantidad se multiplica por el porcentaje de versiones canary (por ejemplo, 50% o .5) para obtener 2. Por lo tanto, la implementación original ahora se reduce a 2 y se crean 2 Pods nuevos para la implementación de versiones canary. Si tienes una etapa de versiones canary del 75%, tienes 2 (implementación original) +2 (primera etapa de versiones canary), *.75, para obtener 3 pods de versión canary y 1 pod que ejecutan la implementación original.

Puerta de enlace de GKE/Enterprise

A continuación, se muestra cómo Cloud Deploy ejecuta una implementación de versiones canary en GKE y GKE Enterprise con la API de puerta de enlace:

  1. Además de las referencias de Deployment y servicio, proporcionas un recurso HTTPRoute, con una regla backendRefs que hace referencia al servicio.

  2. Cloud Deploy crea una Deployment nueva con el nombre de la Deployment original más -canary y un servicio nuevo con el nombre original más -canary.

    Además, los Secrets, los ConfigMaps y los escaladores automáticos de Pods horizontales también se copian y se les cambia el nombre con -canary.

  3. En cada fase de la versión canary, Cloud Deploy modifica la HTTPRoute para actualizar la ponderación entre los Pods del Deployment original y los Pods del Deployment de versión canary, según el porcentaje de esa fase.

    Debido a que puede haber una demora en la propagación de los cambios en los recursos HTTPRoute, puedes incluir la propiedad routeUpdateWaitTime en tu configuración, de modo que el sistema espere un período específico para esta propagación.

  4. Durante la fase stable, el Deployment -canary se reduce verticalmente a cero, y el Deployment original se actualiza para usar el Deployment de la versión nueva.

    Además, la HTTPRoute se revierte a la original que proporcionaste.

    Cloud Deploy no modifica la Deployment o el servicio original hasta la fase stable.

Cloud Run

A continuación, se muestra cómo Cloud Deploy ejecuta una implementación de versiones canary en Cloud Run:

  • Para una implementación de versiones canary en Cloud Run, no proporciones una estrofa traffic en el YAML del servicio.

  • Cuando se crea un lanzamiento nuevo para la versión canary, Cloud Deploy divide el tráfico entre la revisión anterior que Cloud Deploy implementó de forma correcta y una revisión nueva.

Si quieres ver las diferencias entre las fases de una implementación de versiones canary, puedes consultar los cambios en el manifiesto renderizado por fase disponible en el Inspector de versiones. Puedes hacer esto incluso antes de que comience el lanzamiento. Además, si usas una implementación paralela, también puedes inspeccionar el manifiesto renderizado de cada elemento secundario.

Configurar una implementación de versiones canary

En esta sección, se describe cómo configurar tu canalización de entrega y destinos para una implementación de versiones canary.

En estas instrucciones, solo se incluye lo específico de la configuración de versiones canary. El documento Implementa tu aplicación contiene las instrucciones generales para configurar y ejecutar tu canalización de implementación.

Asegúrate de tener los permisos necesarios

Además de otros permisos de Identity and Access Management que necesitas para usar Cloud Deploy, necesitas los siguientes permisos a fin de realizar acciones adicionales que podrían ser necesarias en una implementación de versiones canary:

  • clouddeploy.rollouts.advance
  • clouddeploy.rollouts.ignoreJob
  • clouddeploy.rollouts.cancel
  • clouddeploy.rollouts.retryJob
  • clouddeploy.jobRuns.get
  • clouddeploy.jobRuns.list
  • clouddeploy.jobRuns.terminate

Consulta Funciones y permisos de IAM para obtener más información sobre las funciones disponibles que incluyen estos permisos.

Prepara tu skaffold.yaml

Al igual que con una implementación estándar, tu versión canary necesita un archivo skaffold.yaml, que define cómo se implementan y procesan los manifiestos y las definiciones del servicio.

El skaffold.yaml que creas para una implementación de versiones canary no tiene ningún requisito especial más allá de lo necesario para la implementación estándar.

Prepara el manifiesto o la definición del servicio

Al igual que con una implementación estándar, tu versión canary necesita un manifiesto de Kubernetes o una definición del servicio de Cloud Run.

GKE y GKE Enterprise

En el caso de la versión canary, tu manifiesto debe tener lo siguiente:

  • Un objeto Deployment y un Service.

  • El Service debe definir un selector app y debe seleccionar los Pods de la Deployment especificada.

  • Si usas un Canary basado en la API de puerta de enlace, el manifiesto también debe tener una HTTPRoute.

Cloud Run

Para la versión canary en Cloud Run, tu archivo de definición del servicio normal de Cloud Run es suficiente, pero sin una estrofa traffic. Cloud Deploy administra la división del tráfico entre la última revisión exitosa y la nueva revisión.

Configura una versión canary automatizada

Las siguientes instrucciones son para los objetivos de red basados en servicios de Cloud Run y GKE y GKE Enterprise. Si usas la API de Kubernetes Gateway con GKE o GKE Enterprise, consulta esta documentación.

Configura la versión canary automatizada en la definición de tu canalización de entrega:

GKE y GKE Enterprise

En la etapa de canalización, incluye una propiedad strategy, de la siguiente manera:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

En esta configuración...

  • SERVICE_NAME es el nombre del Service de Kubernetes, definido en tu manifiesto.

  • DEPLOYMENT_NAME es el nombre de tu Deployment de Kubernetes, definida en el manifiesto.

  • PERCENTAGES es una lista separada por comas de valores de porcentaje que representan los incrementos de la versión canary, por ejemplo, [5, 25, 50].

    Además, esto no incluye 100, ya que el 100% de la implementación se asume en la versión canary y se controla mediante la stable fase.

  • Puedes habilitar la verificación de implementación (verify: true). Si lo haces, se habilitará un trabajo verify en cada fase.

Cloud Run

En la etapa de canalización, incluye una propiedad strategy, de la siguiente manera:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

En esta configuración...

  • PERCENTAGES es una lista separada por comas de valores de porcentaje que representan los incrementos de la versión canary, por ejemplo, [25, 50, 75]. Ten en cuenta que esto no incluye 100, ya que el 100% de la implementación se asume en la versión canary y se controla mediante la stable fase.
  • Puedes habilitar la verificación de implementación (verify: true). Si lo haces, se agrega un trabajo verify a cada fase de la versión canary.

Configura una versión canary personalizada

Puedes configurar la versión canary de forma manual en lugar de depender completamente de la automatización que proporciona Cloud Deploy. Con la configuración de versiones canary personalizada, debes especificar lo siguiente en la definición de la canalización de entrega:

  • Nombres de las fases de lanzamiento

    En una versión canary completamente automatizada, Cloud Deploy nombra las fases por ti (canary-25, canary-75, stable, por ejemplo). Sin embargo, con una versión canary personalizada, puedes asignar cualquier nombre a cada fase, siempre que sea única entre todas las fases de esta etapa de la versión canary y cumpla con las restricciones de nombre de recurso. Sin embargo, el nombre final de la fase (100%) debe ser stable.

  • Objetivos porcentuales para cada fase

    Especifica los porcentajes por separado, por fase.

  • Perfiles de Skaffold para usar en la fase

    Puedes usar un perfil de Skaffold distinto para cada fase, el mismo perfil o cualquier combinación. Y cada perfil puede usar un manifiesto de Kubernetes o una definición del servicio de Cloud Run. También puedes usar más de un perfil para una fase determinada. Cloud Deploy los combina.

  • Si hay un trabajo de verificación para la fase

    Recuerda que, si habilitas la verificación, también debes configure tu skaffold.yaml para la verificación.

Todos los tipos de destino son compatibles con las versiones canary personalizadas.

Elementos de configuración de versiones canary personalizados

En el siguiente YAML, se muestra la configuración de las fases de la implementación de versiones canary completamente personalizada:

strategy:
  canary:
    # Custom configuration for each canary phase
    ​customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false

En este archivo YAML

  • PHASE1_NAME

    Es el nombre de la fase. Cada nombre de fase debe ser único.

  • [ "PROFILE_NAME" ]

    Es el nombre del perfil que se usará para la fase. Puedes usar el mismo perfil para cada fase, uno diferente para cada una o cualquier combinación. Además, puedes especificar más de un perfil. Cloud Deploy usa todos los perfiles que especifiques, además del perfil o manifiesto que usa la etapa general.

  • PERCENTAGE1

    Es el porcentaje que se debe implementar en la primera fase. Cada fase debe tener un valor porcentual único, y ese valor debe ser un porcentaje entero (no 10.5, por ejemplo), y las fases deben estar en orden ascendente.

  • verify: true|false

    Le indica a Cloud Deploy si debe incluir un trabajo de verificación para la fase. Ten en cuenta que, en cada fase, Skaffold usa el mismo perfil para la verificación que se especifica para la renderización y la implementación de esa fase.

  • stable

    La fase final debe llamarse stable.

El porcentaje de la última fase debe ser 100. Las fases se ejecutan de acuerdo con el orden en que las configuras en esta estrofa ​customCanaryDeployment, pero si los valores porcentuales no están en orden ascendente, el comando para registrar la canalización de entrega falla con un error.

Ten en cuenta que la configuración para una versión canary personalizada no incluye una estrofa runtimeConfig. Si incluyes runtimeConfig, se considera una canary automatizada personalizada.

Configura una versión canary automatizada personalizada

Una versión canary personalizada y automatizada es similar a una canary personalizada porque especificas las fases de versiones canary separadas, con nombres de fase personalizados, valores porcentuales, perfiles de Skaffold y trabajos de verificación. Sin embargo, con una versión canary personalizada, no proporcionas las configuraciones que definen la distribución del tráfico. Cloud Deploy lo hace por ti, pero aún proporcionas los perfiles de Skaffold que se usarán en cada etapa.

Para configurar una versión canary automatizada personalizada, incluye una estrofa runtimeConfig, como se muestra aquí, y la estrofa customCanaryDeployment, como se muestra aquí.

Configurar una implementación de versiones canary con la malla de servicios de la API de Kubernetes Gateway

Si bien puedes usar una implementación de versiones canary de Cloud Deploy para implementar tu aplicación en redes basadas en servicios de Kubernetes, una alternativa es usar la malla de servicios de la API de Gateway de Kubernetes. En esta sección, se describe cómo hacerlo.

Puedes usar la API de puerta de enlace con Istio o cualquier implementación compatible.

  1. Configura tus recursos de la API de puerta de enlace:

    Estos son solo ejemplos.

  2. En tu manifiesto de Kubernetes, que se proporcionó a Cloud Deploy cuando creaste la versión, incluye lo siguiente:

    • Un HTTPRoute que haga referencia a tu recurso de puerta de enlace

    • Un objeto Deployment

    • Un servicio

  3. Configura tu canalización de entrega y el destino en el que implementarás las versiones canary:

    • La configuración del destino es la misma que la de cualquier destino.

    • La configuración de la canalización de entrega, en la secuencia de progreso del destino específico, incluye una estrofa gatewayServiceMesh para hacer referencia a la configuración HTTPRoute de la API de puerta de enlace de Kubernetes, así como a la Deployment y el servicio.

      strategy:
 canary:
   runtimeConfig:
     kubernetes:
       gatewayServiceMesh:
         httpRoute: "ROUTE"
         service: "SERVICE"
         deployment: "DEPLOYMENT"
         routeUpdateWaitTime: "WAIT_TIME"
   canaryDeployment:
     percentages:
     - 50

      En el ejemplo anterior, se ilustra lo siguiente:

      • ROUTE es tu configuración de httpRoute que define el comportamiento de enrutamiento que deseas.

      • SERVICE es tu configuración del servicio, que Cloud Deploy requiere para implementaciones de versiones canary en GKE y GKE Enterprise.

      • DEPLOYMENT es la configuración de tu Deployment, que Cloud Deploy requiere para las implementaciones de versiones canary en GKE y GKE Enterprise.

      • WAIT_TIME es la cantidad de tiempo que Cloud Deploy debe esperar a que terminen de propagarse los cambios en el recurso HTTPRoute para evitar que se dejen pasar solicitudes. Por ejemplo: routeUpdateWaitTime: 60s.

        Si ejecutas una versión canary con la API de puerta de enlace sin Istio y esta está conectada a un balanceador de cargas de Google Cloud, se puede perder una pequeña cantidad de tráfico cuando se reduzca la escala de la instancia canary. Puedes definir esta configuración si observas este comportamiento.

Usa la implementación paralela con una estrategia de implementación de versiones canary

Puedes ejecutar una implementación de versiones canary con una implementación paralela. Esto significa que el destino en el que implementas de forma progresiva puede comprender dos o más objetivos secundarios. Por ejemplo, puedes implementar de forma progresiva en clústeres en regiones distintas, al mismo tiempo.

¿En qué se diferencia una versión canary paralela de una canary de un solo objetivo?

  • Al igual que con la implementación de versiones canary de un solo destino, si realizas la implementación en destinos de GKE, necesitas una configuración de implementación de Kubernetes y una configuración de servicio de Kubernetes en tu manifiesto.

  • Al igual que con la implementación de versiones canary de un solo destino, la configuración de tu canalización de entrega debe incluir una estrofa strategy.canary dentro de la definición de la etapa para la etapa aplicable.

  • Además, debes configurar un destino múltiple y configurar los destinos secundarios a los que hace referencia.

  • Cuando creas una versión, se crean un lanzamiento del controlador y los lanzamientos secundarios.

    Ambos tipos de lanzamiento (de controlador y secundario) tienen fases separadas para todos los porcentajes de versiones canary configurados y una fase stable para el 100% de la versión canary.

  • No puedes adelantar un lanzamiento secundario.

    Solo puedes adelantar los lanzamientos de controles. Cuando avanzas el lanzamiento del controlador a la siguiente etapa, Cloud Deploy también hace avanzar los lanzamientos secundarios.

  • No puedes reintentar trabajos con errores en el lanzamiento del controlador.

    Solo puedes reintentar un trabajo en lanzamientos secundarios.

  • No puedes ignore trabajos con errores en el lanzamiento del controlador.

    Solo puedes ignorar trabajos con errores en lanzamientos secundarios.

  • Puedes cancelar el lanzamiento de un controlador, pero no puedes cancelar los lanzamientos secundarios.

  • Puedes finalizar ejecuciones de trabajos solo en un lanzamiento secundario, no en un lanzamiento de controlador.

Qué hacer si un lanzamiento paralelo falla en la versión canary

Cuando falla un lanzamiento secundario, el lanzamiento del controlador puede cambiar a diferentes estados, según lo que ocurra con los lanzamientos secundarios:

  • Si uno o más lanzamientos secundarios fallan, pero al menos un lanzamiento secundario sigue siendo IN_PROGRESS, el lanzamiento del controlador permanece como IN_PROGRESS.

  • Si uno o más lanzamientos secundarios fallan, pero al menos uno secundario funciona correctamente, el lanzamiento del controlador será HALTED si hay más fases después de la actual.

    Si esta es la fase stable, el lanzamiento del controlador será FAILED.

    HALTED te permite ignore, reintentar los trabajos con errores dentro del lanzamiento secundario con errores o cancelar el lanzamiento del controlador y evitar acciones adicionales en los lanzamientos secundarios.

  • Si el lanzamiento del controlador está en un estado HALTED debido a un lanzamiento secundario con errores y se ignora el trabajo con errores en el lanzamiento secundario, el lanzamiento del controlador vuelve a un estado IN_PROGRESS.

Ejecuta la versión canary configurada

Para ejecutar la implementación de versiones canary, sigue estos pasos:

  1. Registra la canalización de entrega y los destinos configurados.

    gcloud deploy apply --file=PIPELINE

    La canalización de entrega incluye la configuración de versiones canary automatizada o personalizada para el entorno de ejecución que elegiste.

    Este comando supone que los destinos están definidos en el mismo archivo o que ya se registraron. Si no es así, asegúrate de registrar también tus destinos.

  2. Crea una versión:

    gcloud deploy releases create RELEASE_NAME \
                              --delivery-pipeline=PIPELINE_NAME \
                              --region=REGION

    La canalización de entrega identificada por PIPELINE_NAME contiene la configuración de versiones canary automatizada o personalizada que se describe en este documento.

  3. Avance de las versiones canary:

    gcloud CLI 

    gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION

    Aquí:

    ROLLOUT_NAME es el nombre del lanzamiento actual, que pasas a la siguiente fase.

    RELEASE_NAME es el nombre de la versión de la que forma parte este lanzamiento.

    PIPELINE_NAME es el nombre de la canalización de entrega que usas para administrar la implementación de esta versión.

    REGION es el nombre de la región en la que se creó la versión, por ejemplo us-central1. Este campo es obligatorio.

    Consulta la referencia del SDK de Google Cloud para obtener más información sobre el comando gcloud deploy rollouts advance.

    Consola de Google Cloud

    1. Abre la página Canalizaciones de entrega.

    2. Haz clic en la canalización que se muestra en la lista de canalizaciones de entrega.

      En la página Detalles de la canalización de entrega, se muestra una representación gráfica del progreso de tu canalización de entrega.

    3. En la pestaña Lanzamientos, en Detalles de canalización de entrega, haz clic en el nombre del lanzamiento.

      Se muestra la página de detalles del lanzamiento para ese lanzamiento.

      detalles del lanzamiento en la consola de Google Cloud

      Ten en cuenta que, en este ejemplo, el lanzamiento tiene una fase canary-50 y una fase stable. El lanzamiento puede tener más fases o fases diferentes.

    4. Haz clic en Lanzamiento avanzado.

      El lanzamiento avanza a la siguiente fase.

Fases omitidas

Si implementas una versión canary y tu aplicación aún no se implementó en ese entorno de ejecución, Cloud Deploy omite la fase de versión canary y ejecuta la estable. Consulta Cómo omitir fases la primera vez para averiguar por qué sucede esto.

¿Qué sigue?