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 nueva, y la distribuye a un subconjunto de usuarios antes del lanzamiento completo.
Tipos de destinos admitidos
La implementación de versiones canary en Cloud Deploy admite todos los tipos de destino, incluidos los siguientes:
- Google Kubernetes Engine
- Cloud Run (solo servicios, no trabajos)
- GKE Enterprise
Canary también funciona con objetivos múltiples.
¿Por qué usar una estrategia de implementación de versiones canary?
Una implementación de versiones canary te da la oportunidad de lanzar parcialmente tu aplicación. 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, implementarás la versión nueva de tu aplicación en una cantidad limitada de Pods. La versión anterior seguiría ejecutándose, pero el tráfico se enviaba a los pods nuevos.
Si realizas la implementación en Cloud Run, este último divide el tráfico entre la revisión anterior y la nueva, según los porcentajes que configures.
Tipos de versiones canary
Cloud Deploy te permite configurar los siguientes tipos de implementación de versiones canary:
Alertas
Con una implementación canary automatizada, configuras Cloud Deploy con una serie de porcentajes que expresan una implementación progresiva. Cloud Deploy realiza operaciones adicionales por ti para repartir los porcentajes de tráfico entre la versión anterior y la nueva.
Personalizada, automatizada
Para una versión canary personalizada y automatizada, puedes proporcionar lo siguiente:
- El nombre de la fase
- El objetivo porcentual
- El perfil de Skaffold que se usará para la fase
- Incluir o no un trabajo de verificación
Sin embargo, no es necesario que proporciones información sobre el balanceo de tráfico, ya que Cloud Deploy crea los recursos necesarios, como se describe aquí.
Personalizada
Con una versión canary personalizada, configuras cada fase de la versión canary por separado, incluida lo siguiente:
- El nombre de la fase
- El objetivo porcentual
- El perfil de Skaffold que se usará para la fase
- 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 un lanzamiento para una implementación de versiones canary, el lanzamiento se crea con una fase para cada incremento de la versión canary, además de una fase final de stable
para el 100%.
Por ejemplo, si configuras una versión canary en incrementos del 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 versión canary automatizada o personalizada
Para admitir la implementación de versiones canary, Cloud Deploy incluye pasos de procesamiento especiales cuando se renderiza tu manifiesto de Kubernetes o la configuración del servicio de Cloud Run:
GKE/GKE Enterprise (red)
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:
Debes proporcionar el nombre del recurso Deployment y el recurso Service.
Cloud Deploy crea un recurso de Deployment adicional, con el nombre de tu Deployment actual más
-canary
.Cloud Deploy modifica el Service para ajustar el selector y así elegir los Pods en la 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 en función de si habilitas o inhabilitas el aprovisionamiento en exceso de Pods.
Si estamos pasando 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 las 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 lograrla con la API de Gateway.
Además, los Secrets y los ConfigMaps también se copian y se les cambia el nombre con
-canary
.Durante la fase
stable
, la Deployment de-canary
se reduce a cero y la Deployment original se reemplaza por la Deployment nueva.Cloud Deploy no modifica la Deployment original hasta la fase
stable
.
Cloud Deploy aprovisiona Pods para lograr el porcentaje de versiones canary solicitado lo más cerca posible. 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 Gateway.
Para las versiones canary basadas en la red de GKE, puedes habilitar o inhabilitar el aprovisionamiento excesivo 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 la versión canary.
Aprovisionamiento de Pods con sobreaprovisionamiento 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 ejecutan tu implementación existente. En la siguiente fórmula, se muestra cómo Cloud Deploy calcula la cantidad de Pods que se aprovisionarán para la implementación de versiones canary en cada fase de la versión canary, cuando el aprovisionamiento en exceso de Pods está habilitado:
math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))
Con esta fórmula, el recuento de réplicas actual (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 tienes 4 Pods de versiones canary y tu fase de versiones canary es del 50%, entonces la cantidad de Pods de una versión canary es 4. (El resultado de 100-percentage
se usa como un porcentaje: 100-50=50
, que se trata como .50
).
El aprovisionamiento excesivo del Pod es el comportamiento predeterminado.
Aprovisionamiento de Pods con sobreaprovisionamiento inhabilitado
Puedes inhabilitar el aprovisionamiento en exceso (disablePodOverprovisioning: true
) para asegurarte de que Cloud Deploy no aumente el recuento de réplicas.
En la siguiente fórmula, se muestra cómo Cloud Deploy calcula el aprovisionamiento de Pods para la implementación de versiones canary en cada fase de la versión canary, cuando el aprovisionamiento en exceso 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, ese número 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 luego tienes una etapa de versiones canary del 75%, tienes 2
(implementación original) +2
(primera etapa de versión canary), *.75
, para obtener Pods de versiones canary 3
y Pods de 1
que ejecutan la implementación original.
GKE/GKE Enterprise (puerta de enlace)
Aquí se muestra cómo Cloud Deploy ejecuta una implementación de versiones canary en GKE y GKE Enterprise con la API de Gateway:
Además de las referencias de Deployment y Service, proporcionas un recurso HTTPRoute con una regla
backendRefs
que hace referencia al Service.Cloud Deploy crea una Deployment nueva, con el nombre de tu Deployment original más
-canary
, y un servicio nuevo con el nombre del servicio original más-canary
.Además, los Secrets, ConfigMaps y Horizontal Pod Autoscaler también se copian y se les cambia el nombre con
-canary
.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 del Deployment de la versión canary, según el porcentaje de esa fase.
Debido a que puede haber una demora en la propagación de los cambios a los recursos
HTTPRoute
, puedes incluir la propiedadrouteUpdateWaitTime
en tu configuración, de modo que el sistema espere un período específico para esta propagación.Durante la fase
stable
, la Deployment de-canary
se reduce a cero, y la Deployment original se actualiza para usar la Deployment de la versión nueva.Además, la HTTPRoute ahora se revierte a la original que proporcionaste.
Cloud Deploy no modifica la Deployment o el servicio originales hasta la fase
stable
.
Cloud Run
Esta es la forma en que Cloud Deploy ejecuta una implementación de versiones canary para 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ó con éxito y una revisión nueva.
Si quieres ver las diferencias entre las fases de una implementación de versiones canary, puedes ver 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 la implementación en paralelo, también puedes inspeccionar el manifiesto renderizado de cada elemento secundario.
Configura una implementación de versiones canary
En esta sección, se describe cómo configurar tu canalización de entrega y los objetivos para una implementación de versiones canary.
En estas instrucciones, solo se incluye lo que es 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 contar con 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 qué funciones disponibles 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 renderizan e implementan los manifiestos y las definiciones de servicios.
El skaffold.yaml
que creas para una implementación de versiones canary no tiene ningún requisito especial más allá de lo que se necesita para la implementación estándar.
Prepara tu manifiesto o 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 de servicio de Cloud Run.
GKE y GKE Enterprise
Para 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 elegir los Pods de la Deployment especificada.Si usas una versión canary basada en la API de puerta de enlace, el manifiesto también debe tener un HTTPRoute.
Cloud Run
Para las versiones canary en Cloud Run, el archivo normal de definición del servicio 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.
Configura una versión canary automatizada
Las siguientes instrucciones son para los objetivos de herramientas de redes basadas en servicios de Cloud Run, 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 servicio de Kubernetes, definido en tu manifiesto.
DEPLOYMENT_NAME es el nombre de tu Deployment de Kubernetes, definido en tu manifiesto.
PERCENTAGES es una lista separada por comas de valores porcentuales que representan tus incrementos Canary, por ejemplo,
[5, 25, 50]
.Además, esto no incluye
100
, porque el 100% de la implementación se asume en la versión canary y se controla mediante la fasestable
.Puedes habilitar la verificación de implementación (
verify: true
). Si lo haces, se habilitará un trabajoverify
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 porcentuales que representan tus incrementos Canary, por ejemplo,
[25, 50, 75]
. Ten en cuenta que esto no incluye100
, porque el 100% de la implementación se asume en la versión canary y se controla mediante la fasestable
. - Puedes habilitar la verificación de implementación (
verify: true
). Si lo haces, se agrega un trabajoverify
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 por completo de la automatización que proporciona Cloud Deploy. Con la configuración de versiones canary personalizada, especifica lo siguiente en la definición de tu canalización de entrega:
Nombres de las fases de lanzamiento
En una versión canary completamente automatizada, Cloud Deploy nombra las fases por ti (por ejemplo,
canary-25
,canary-75
,stable
). Sin embargo, con una versión canary personalizada, puedes asignarle a cada fase cualquier nombre, siempre que sea única entre todas las fases de esta etapa de versiones canary y respete las restricciones de nombres de recursos. Sin embargo, el nombre final de la fase (100%) debe serstable
.Objetivos porcentuales para cada fase
Especifica los porcentajes por separado, por fase.
Perfiles de Skaffold para la fase
Puedes usar un perfil de Skaffold independiente para cada fase, el mismo perfil o cualquier combinación. Cada perfil puede usar un manifiesto de Kubernetes o una definición de 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 personalizadas:
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 se usa en la etapa general.
PERCENTAGE1
Es el porcentaje que se implementará para la primera fase. Cada fase debe tener un valor porcentual único, que 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 de verificación que se especifica para la renderización y la implementación en esa fase.
stable
La fase final debe llamarse
stable
.
El porcentaje de la última fase debe ser 100
. Las fases se ejecutan según el orden en que las configuras en esta estrofa de 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 un canary automatizado y personalizado.
Configura una versión canary automatizada y personalizada
Una versión canary automatizada y personalizada es similar a una canary personalizada porque especificas las fases de versión canary separadas, con nombres de fase personalizados, valores de porcentaje, perfiles de Skaffold y verifica los trabajos. Sin embargo, con una versión canary personalizada, no proporcionas las configuraciones que definen la distribución de tráfico; Cloud Deploy lo hace por ti, pero igualmente 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í.
Configura una implementación de versiones canary con la malla de servicios de la API de Kubernetes Gateway
Aunque puedes usar una implementación de versiones canary de Cloud Deploy para implementar tu aplicación en las 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 Gateway con Istio o cualquier implementación compatible.
Configura los recursos de la API de puerta de enlace:
Estos son solo ejemplos.
En el manifiesto de Kubernetes, que se proporcionó a Cloud Deploy cuando creaste la versión, incluye lo siguiente:
Un
HTTPRoute
que haga referencia al recurso de puerta de enlaceUn objeto Deployment
Un Service
Configura tu canalización de entrega y el destino en el que realizarás la implementación de 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 para el destino específico, incluye una estrofa
gatewayServiceMesh
que hace referencia a la configuraciónHTTPRoute
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 la configuración del servicio, que Cloud Deploy requiere para las implementaciones de versiones canary en GKE y GKE Enterprise.
DEPLOYMENT es tu configuración de 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 espera a que los cambios en el recurso
HTTPRoute
terminen de propagarse para evitar que se dejen pasar solicitudes. Por ejemplo:routeUpdateWaitTime: 60s
.Si ejecutas versiones canary con la API de Gateway sin Istio y esta está conectada a un balanceador de cargas de Google Cloud, es posible que se pierda una pequeña cantidad de tráfico cuando se reduzca la escala verticalmente de la instancia canary. Si observas este comportamiento, puedes establecerlo.
Usa la implementación en paralelo con una estrategia de implementación de versiones canary
Puedes ejecutar una implementación de versiones canary con una implementación en paralelo. Esto significa que el destino en el que realizas la implementación de forma progresiva puede incluir dos o más destinos secundarios. Por ejemplo, puedes implementar de forma progresiva en clústeres en regiones separadas, al mismo tiempo.
Diferencias entre una versión canary paralela y una de destino único
Al igual que con la implementación de versiones canary de destino único, si realizas la implementación en objetivos 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 destino único, la configuración de la canalización de entrega debe incluir una estrofa
strategy.canary
dentro de la definición de la etapa correspondiente.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 (controlador y secundario) tienen fases separadas para todos los porcentajes de versiones canary configurados y una fase
stable
para el 100% de Canary.No puedes adelantar un lanzamiento secundario.
Solo puedes adelantar los lanzamientos de controladores. Cuando haces avanzar el lanzamiento del controlador a la siguiente etapa, Cloud Deploy también avanza 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 los 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 lanzamientos secundarios.
Puedes finalizar ejecuciones de trabajos solo en un lanzamiento secundario, no en un lanzamiento de controlador.
Qué hacer si falla un lanzamiento paralelo en la versión canary
Cuando falla un lanzamiento secundario, el lanzamiento del controlador puede pasar a diferentes estados, según lo que suceda con los lanzamientos secundarios:
Si uno o más lanzamientos secundarios fallan, pero al menos uno sigue siendo
IN_PROGRESS
, el lanzamiento del controlador seguirá siendoIN_PROGRESS
.Si uno o más lanzamientos secundarios fallan, pero al menos uno se realiza 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 brinda la oportunidad de ignore, reintentar los trabajos con errores dentro del lanzamiento secundario con errores o cancelar el lanzamiento del controlador y evitar que se realicen más acciones en los lanzamientos secundarios.Si el lanzamiento del controlador está en un estado
HALTED
debido a un lanzamiento secundario con errores y, además, ignoras el trabajo con errores en el lanzamiento secundario, el lanzamiento del controlador vuelve a un estadoIN_PROGRESS
.
Ejecuta la versión canary configurada
Para ejecutar la implementación de versiones canary, haz lo siguiente:
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 versión canary automatizada o personalizada para el entorno de ejecución que elijas.
Este comando supone que tus destinos están definidos en el mismo archivo o que ya se registraron. Si no es así, asegúrate de registrar tus objetivos también.
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 versión canary automatizada o personalizada que se describe en este documento.Haz avanzar la versión 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 estás avanzando 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
Haz clic en la canalización que se muestra en la lista de canalizaciones de entrega.
En la página de detalles de la canalización de entrega, se muestra una representación gráfica del progreso de tu canalización de entrega.
En la pestaña Lanzamientos, en Detalles de la canalización de entrega, haz clic en el nombre del lanzamiento.
Se mostrará la página de detalles del lanzamiento correspondiente.
Ten en cuenta que, en este ejemplo, el lanzamiento tiene una fase
canary-50
y una fasestable
. Tu lanzamiento puede tener más fases o fases diferentes.Haz clic en Avance del lanzamiento.
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 fase estable. Consulta Cómo omitir fases la primera vez para averiguar a qué se debe.
¿Qué sigue?
Prueba la guía de inicio rápido de la implementación de versiones canary.
Descubre cómo administrar el ciclo de vida de los lanzamientos de tu versión canary.
Obtén más información sobre la implementación en paralelo.