Questo documento descrive come configurare e utilizzare una strategia di deployment canary.
Che cos'è un deployment canary?
Un deployment canary è l'implementazione progressiva di un'applicazione che suddivide il traffico tra una versione di cui è già stato eseguito il deployment e una nuova versione, implementandola per un sottoinsieme di utenti prima dell'implementazione completa.
Tipi di target supportati
Il deployment canary in Cloud Deploy supporta tutti i tipi di destinazione, tra cui:
- Google Kubernetes Engine
- Cloud Run (solo servizi, non job).
- GKE Enterprise
La versione Canary funziona anche con i target multipli.
Perché utilizzare una strategia di deployment canary?
Un deployment canary ti offre la possibilità di rilasciare l'applicazione parzialmente. In questo modo, puoi assicurarti che la nuova versione della tua applicazione sia affidabile prima di distribuirla a tutti gli utenti.
Ad esempio, se stai eseguendo il deployment su GKE o GKE Enterprise, devi eseguire il deployment della nuova versione dell'applicazione su un numero limitato di pod. La versione precedente continuerà a essere eseguita, ma più traffico veniva inviato ai nuovi pod.
Se esegui il deployment in Cloud Run, Cloud Run suddivide autonomamente il traffico tra la vecchia e la nuova revisione, in base alle percentuali configurate.
Tipi di canary
Cloud Deploy consente di configurare i seguenti tipi di deployment canary:
Automatizzata
Con un deployment canary automatizzato, configuri Cloud Deploy con una serie di percentuali che esprimono un deployment progressivo. Cloud Deploy esegue operazioni aggiuntive per tuo conto al fine di distribuire le percentuali di traffico tra la versione precedente e la nuova versione.
Automatico personalizzato
Per una versione canary automatica personalizzata, puoi fornire quanto segue:
- Il nome della fase
- L'obiettivo percentuale
- Il profilo Skaffold da utilizzare per la fase
- Se includere o meno un job di verifica
Tuttavia, non è necessario fornire informazioni sul bilanciamento del traffico; Cloud Deploy crea le risorse necessarie, come descritto qui.
Personalizzata
Con una versione canary personalizzata, puoi configurare separatamente ogni fase canary, tra cui:
- Il nome della fase
- L'obiettivo percentuale
- Il profilo Skaffold da utilizzare per la fase
- Se includere o meno un job di verifica
Inoltre, per una versione canary completamente personalizzata, devi fornire tutta la configurazione di bilanciamento del traffico, come descritto qui.
Fasi di un deployment canary
Quando crei una release per un deployment canary, l'implementazione viene creata con una fase per ogni incremento canary, più una fase stable
finale per il 100%.
Ad esempio, se configuri una versione canary per incrementi del 25%, 50% e 75%, l'implementazione avrà le seguenti fasi:
canary-25
canary-50
canary-75
stable
Per saperne di più sulle fasi dell'implementazione, sui job e sulle esecuzioni dei job, consulta Gestire le implementazioni.
Che cosa succede durante una versione canary automatizzata o personalizzata
Per supportare il deployment canary, Cloud Deploy include passaggi di elaborazione speciali durante il rendering del manifest Kubernetes o della configurazione del servizio Cloud Run:
GKE/GKE Enterprise (rete)
Ecco come Cloud Deploy esegue un deployment canary in GKE e GKE Enterprise basati sulla rete:
Dovrai specificare il nome della risorsa Deployment e della risorsa Servizio.
Cloud Deploy crea un'ulteriore risorsa di deployment, con il nome del deployment attuale più
-canary
.Cloud Deploy modifica il servizio per regolare il selettore e selezionare i pod nel deployment attuale e i pod canary.
Cloud Deploy calcola il numero di pod da utilizzare per la versione canary in base al calcolo descritto qui. Il calcolo varia a seconda che tu abiliti o disabiliti il provisioning eccessivo dei pod.
Se siamo alla fase
stable
, Cloud Deploy aggiunge le etichette da utilizzare per associare i pod, in modo che siano disponibili per le esecuzioni canary successive.Cloud Deploy crea un deployment che include la percentuale di pod specifica per la fase, aggiornandola per ogni fase. Per farlo, viene calcolato il numero di pod come percentuale del numero originale di pod. Ciò può comportare una suddivisione del traffico inesatta. Se hai bisogno di una suddivisione del traffico esatta, puoi ottenerla utilizzando l'API Gateway.
Inoltre, anche gli oggetti Secret e ConfigMap vengono copiati e rinominati con
-canary
.Durante la fase
stable
, viene fatto lo scale down del deployment-canary
a zero e il deployment originale viene sostituito con quello nuovo.Cloud Deploy non modifica il deployment originale fino alla fase
stable
.
Cloud Deploy esegue il provisioning dei pod per raggiungere il più vicino possibile la percentuale canary. e si basa sul numero di pod, non sul traffico verso i pod stessi. Se vuoi che la versione canary sia basata sul traffico, devi utilizzare l'API Gateway.
Per i canary basati sulla rete GKE, puoi abilitare o disabilitare l'overprovisioning dei pod. Le sezioni seguenti descrivono in che modo Cloud Deploy calcola il numero di pod di cui eseguire il provisioning per il deployment canary per ogni fase canary.
Provisioning dei pod con overprovisioning abilitato
L'abilitazione dell'overprovisioning (disablePodOverprovisioning: false
) consente a Cloud Deploy di creare un numero sufficiente di pod aggiuntivi per eseguire la percentuale canary desiderata in base al numero di pod che eseguono il deployment esistente. La seguente formula mostra in che modo Cloud Deploy calcola il numero di pod di cui eseguire il provisioning per il deployment canary per ogni fase canary, quando è abilitato il provisioning eccessivo dei pod:
math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))
Con questa formula, l'attuale numero di repliche (il numero di pod già presenti prima della versione canary) viene moltiplicato per la percentuale canary per la fase e il risultato viene diviso per (100 meno la percentuale).
Ad esempio, se hai già 4 pod e la tua fase canary è al 50%, il numero di pod canary è 4. (Il risultato di 100-percentage
viene utilizzato come
percentuale: 100-50=50
, trattato come .50
.)
Il comportamento predefinito è il provisioning eccessivo dei pod.
Provisioning dei pod con overprovisioning disabilitato
Puoi disabilitare l'overprovisioning (disablePodOverprovisioning: true
) per assicurarti che Cloud Deploy non aumenti il numero di repliche.
La seguente formula mostra in che modo Cloud Deploy calcola il provisioning dei pod per il deployment canary per ogni fase canary, quando il provisioning eccessivo dei pod è disabilitato:
math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)
In questa formula, ReplicaCountOfCanaryDeploymentOnCluster
esiste solo se
era già presente una fase canary. Se si tratta della prima fase canary, non è presente ReplicaCountOfCanaryDeploymentOnCluster
.
Se inizi con 4 pod, questo numero viene moltiplicato per la percentuale canary
(ad esempio, 50% o .5
) per ottenere 2
. Quindi, il deployment originale è ora ridotto a 2 e vengono creati due nuovi pod per il deployment canary. Se
hai una fase canary del 75%, hai 2
(deployment originale) +2
(prima fase canary), *.75
, per ottenere 3
pod canary e 1
pod che eseguono il deployment originale.
GKE/GKE Enterprise (gateway)
Ecco come Cloud Deploy esegue un deployment canary in GKE e GKE Enterprise utilizzando l'API Gateway:
Oltre ai riferimenti al deployment e al servizio, devi fornire una risorsa HTTPRoute con una regola
backendRefs
che fa riferimento al servizio.Cloud Deploy crea un nuovo deployment, con il nome del deployment originale più
-canary
e un nuovo servizio con il nome del servizio originale più-canary
.Inoltre, anche i servizi Secret, ConfigMap e Horizontal Pod Autoscaler vengono copiati e rinominati con
-canary
.Per ogni fase canary, Cloud Deploy modifica la HTTPRoute per aggiornare la ponderazione tra i pod del deployment originale e i pod del deployment canary, in base alla percentuale per quella fase.
Poiché potrebbe verificarsi un ritardo nella propagazione delle modifiche alle risorse
HTTPRoute
, puoi includere la proprietàrouteUpdateWaitTime
nella configurazione, in modo che il sistema attende un periodo di tempo specificato per questa propagazione.Durante la fase
stable
, viene fatto lo scale down del deployment-canary
a zero e il deployment originale viene aggiornato in modo da utilizzare il deployment della nuova release.Inoltre, viene ripristinato lo stato originale di HTTPRoute che hai fornito.
Cloud Deploy modifica il deployment o il servizio originale solo alla fase
stable
.
Cloud Run
Ecco come Cloud Deploy esegue un deployment canary per Cloud Run:
Per un deployment canary in Cloud Run, non fornire una stanza
traffic
nel servizio YAML.Quando crei una nuova implementazione per la versione canary, Cloud Deploy suddivide il traffico tra la revisione precedente di cui è stato eseguito il deployment da parte di Cloud Deploy e una nuova revisione.
Se vuoi vedere le differenze tra le fasi di un deployment canary, puoi visualizzare le modifiche nel manifest visualizzato per fase, disponibile nello strumento di ispezione delle release. Puoi farlo anche prima dell'inizio dell'implementazione. Inoltre, se utilizzi il deployment parallelo, puoi anche ispezionare il manifest visualizzato di ogni elemento figlio.
Configura un deployment canary
Questa sezione descrive come configurare la pipeline di distribuzione e i target per un deployment canary.
Le istruzioni riportate in questo articolo includono solo i dati specifici della configurazione canary. Il documento Esegui il deployment dell'applicazione contiene le istruzioni generali per la configurazione e l'esecuzione della pipeline di deployment.
Assicurati di disporre delle autorizzazioni richieste
Oltre alle altre autorizzazioni di Identity and Access Management necessarie per l'utilizzo di Cloud Deploy, sono necessarie le autorizzazioni seguenti per eseguire azioni aggiuntive che potrebbero essere necessarie per un deployment canary:
clouddeploy.rollouts.advance
clouddeploy.rollouts.ignoreJob
clouddeploy.rollouts.cancel
clouddeploy.rollouts.retryJob
clouddeploy.jobRuns.get
clouddeploy.jobRuns.list
clouddeploy.jobRuns.terminate
Per ulteriori informazioni su quali ruoli disponibili includono queste autorizzazioni, consulta Ruoli e autorizzazioni IAM.
Prepara il tuo skaffold.yaml
Come per un deployment standard, la tua versione canary ha bisogno di un file skaffold.yaml
, che definisce le modalità di rendering e deployment di manifest e definizioni di servizi.
L'elemento skaffold.yaml
che crei per un deployment canary non ha requisiti
speciali oltre a quello necessario per il deployment
standard.
Prepara il manifest o la definizione del servizio
Come per un deployment standard, la versione canary richiede un manifest Kubernetes o una definizione del servizio Cloud Run.
GKE e GKE Enterprise
Per la versione canary, il manifest deve avere quanto segue:
Un deployment e un servizio.
Il servizio deve definire un selettore
app
e selezionare i pod del deployment specificato.Se utilizzi una versione canary basata sull'API Gateway, il manifest deve avere anche un elemento HTTPRoute.
Cloud Run
Per la versione canary su Cloud Run, è sufficiente il normale file di definizione del servizio Cloud Run, ma senza una stanza traffic
. Cloud Deploy gestisce la suddivisione del traffico tra l'ultima revisione riuscita e la nuova revisione.
Configura una versione canary automatico
Le seguenti istruzioni si riferiscono ai target di networking basati su servizi Cloud Run, GKE e GKE Enterprise. Se utilizzi l'API Kubernetes Gateway con GKE o GKE Enterprise, consulta questa documentazione.
Puoi configurare la versione canary automatica nella definizione della pipeline di distribuzione:
GKE e GKE Enterprise
Nella fase della pipeline, includi una proprietà strategy
, come segue:
serialPipeline:
stages:
- targetId: prod
profiles: []
strategy:
canary:
runtimeConfig:
kubernetes:
serviceNetworking:
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
canaryDeployment:
percentages: [PERCENTAGES]
verify: true|false
In questa configurazione...
SERVICE_NAME è il nome del servizio Kubernetes, definito nel manifest.
DEPLOYMENT_NAME è il nome del deployment Kubernetes, definito nel tuo manifest.
PERCENTAGES è un elenco separato da virgole di valori percentuali che rappresentano gli incrementi canary, ad esempio
[5, 25, 50]
.Inoltre, questo non include
100
, perché il 100% del deployment è presunto nella versione canary ed è gestito dalla fasestable
.Puoi abilitare la verifica del deployment (
verify: true
). In questo caso, viene abilitato un jobverify
in ogni fase.
Cloud Run
Nella fase della pipeline, includi una proprietà strategy
, come segue:
serialPipeline:
stages:
- targetId: prod
profiles: []
strategy:
canary:
runtimeConfig:
cloudRun:
automaticTrafficControl: true
canaryDeployment:
percentages: [PERCENTAGES]
verify: true|false
In questa configurazione...
- PERCENTAGES è un elenco separato da virgole di valori percentuali
che rappresentano gli incrementi canary, ad esempio
[25, 50, 75]
. Tieni presente che non è incluso100
, perché il 100% del deployment è presunto nella versione canary ed è gestito dalla fasestable
. - Puoi abilitare la verifica del deployment (
verify: true
). In questo caso, viene aggiunto un jobverify
a ogni fase canary.
Configura una versione canary personalizzata
Puoi configurare la versione canary manualmente anziché fare affidamento completamente sull'automazione fornita da Cloud Deploy. Con la configurazione canary personalizzata, nella definizione della pipeline di distribuzione specifichi quanto segue:
Nomi delle fasi di implementazione
In una versione canary completamente automatica, Cloud Deploy assegna un nome alle fasi (
canary-25
,canary-75
,stable
, ad esempio). Tuttavia, con una fase canary personalizzato puoi assegnare un nome a ogni fase, purché sia univoco tra tutte le fasi della fase canary e che rispetti le limitazioni relative ai nomi delle risorse. Tuttavia, il nome della fase (100%) finale deve esserestable
.Obiettivi percentuali per ogni fase
Specifica le percentuali separatamente, per fase.
Profili Skaffold da utilizzare per la fase
Puoi utilizzare un profilo Skaffold separato per ogni fase, lo stesso profilo o qualsiasi combinazione. Ogni profilo può utilizzare un manifest Kubernetes o una definizione del servizio Cloud Run differente. Puoi anche usare più di un profilo per una determinata fase. Cloud Deploy le combina.
Se esiste un job di verifica per la fase
Tieni presente che, se abiliti la verifica, devi configure anche
skaffold.yaml
per la verifica.
Sono supportati tutti i tipi di target per la versione canary personalizzata.
Elementi di configurazione canary personalizzati
Il seguente codice YAML mostra la configurazione per le fasi del deployment canary completamente personalizzato:
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
In questo file YAML,
PHASE1_NAME
È il nome della fase. Ogni nome di fase deve essere univoco.
[ "PROFILE_NAME" ]
È il nome del profilo da utilizzare per la fase. Puoi usare lo stesso profilo per ogni fase, uno diverso per ciascuna o qualsiasi combinazione. Inoltre, puoi specificare più di un profilo. Cloud Deploy utilizza tutti i profili specifici, più il profilo o il manifest utilizzati dalla fase generale.
PERCENTAGE1
È la percentuale di deployment per la prima fase. Ogni fase deve avere un valore percentuale univoco, che deve essere una percentuale intera (ad esempio non
10.5
) e le fasi devono essere in ordine crescente.verify: true|false
Indica a Cloud Deploy se includere un job di verifica per la fase. Tieni presente che, per ogni fase in cui utilizzare la verifica, Skaffold utilizza lo stesso profilo specificato per il rendering e il deployment per quella fase.
stable
Il nome della fase finale deve essere
stable
.
La percentuale dell'ultima fase deve essere 100
. Le fasi vengono eseguite nell'ordine in cui le configuri in questa stanza customCanaryDeployment
, ma se i valori percentuali non sono in ordine crescente, il comando per registrare la pipeline di distribuzione non va a buon fine e genera un errore.
Tieni presente che la configurazione per una canary personalizzata non include una stanza runtimeConfig
. Se includi runtimeConfig
, viene considerato un
canary automatizzato personalizzato.
Configura una versione canary automatica personalizzata
Un canary automatizzato personalizzato è simile a uno canary personalizzato perché specifichi le fasi canary separate, con nomi di fase, valori percentuali e profili Skaffold personalizzati e verifica i job. Tuttavia, con una versione canary personalizzata, non devi fornire le configurazioni che definiscono la distribuzione del traffico: Cloud Deploy lo fa al posto tuo, ma devi comunque fornire i profili Skaffold da utilizzare per ogni fase.
Per configurare una stanza canary personalizzata, includi una stanza runtimeConfig
, come mostrato qui, e la stanza customCanaryDeployment
, come mostrato qui.
Configura un deployment canary utilizzando il mesh di servizi dell'API Kubernetes Gateway
Anche se puoi utilizzare un deployment canary di Cloud Deploy per eseguire il deployment dell'applicazione nel networking basato su servizi Kubernetes, un'alternativa è utilizzare il mesh di servizi API gateway di Kubernetes. In questa sezione viene descritto come eseguire questa operazione.
Puoi utilizzare l'API Gateway con Istio o qualsiasi implementazione supportata.
Configura le risorse dell'API Gateway:
Si tratta solo di esempi.
Nel manifest Kubernetes fornito a Cloud Deploy al momento della creazione della release, includi quanto segue:
Un elemento
HTTPRoute
che fa riferimento alla risorsa GatewayUn deployment
Un servizio
Configura la pipeline di distribuzione e il target in cui eseguirai il deployment canary:
La configurazione del target è la stessa di qualsiasi target.
La configurazione della pipeline di distribuzione, nella sequenza di avanzamento per il target specifico, include una stanza
gatewayServiceMesh
per fare riferimento alla configurazioneHTTPRoute
dell'API Kubernetes Gateway, nonché al deployment e al servizio.strategy: canary: runtimeConfig: kubernetes: gatewayServiceMesh: httpRoute: "ROUTE" service: "SERVICE" deployment: "DEPLOYMENT" routeUpdateWaitTime: "WAIT_TIME" canaryDeployment: percentages: - 50
Dove...
ROUTE è la configurazione httpRoute che definisce il comportamento di routing desiderato.
SERVICE è la configurazione del tuo servizio, che Cloud Deploy richiede per i deployment canary in GKE e GKE Enterprise.
DEPLOYMENT è la configurazione del deployment, che Cloud Deploy richiede per i deployment canary in GKE e GKE Enterprise.
WAIT_TIME indica il tempo di attesa da parte di Cloud Deploy per le modifiche alla risorsa
HTTPRoute
al fine di completare la propagazione, per evitare la perdita di richieste. Ad esempio:routeUpdateWaitTime: 60s
.Se esegui canary utilizzando l'API Gateway senza Istio e l'API Gateway è connessa a un bilanciatore del carico Google Cloud, una piccola quantità di traffico potrebbe andare persa con lo scale down dell'istanza canary. Puoi configurare questa impostazione se osservi questo comportamento.
Usa il deployment parallelo con una strategia di deployment canary
Puoi eseguire un deployment canary utilizzando il deployment parallelo. Ciò significa che il target in cui stai progressivamente il deployment può comprendere due o più target figlio. Ad esempio, puoi eseguire il deployment progressivamente in cluster in aree geografiche separate, contemporaneamente.
Qual è la differenza tra una versione canary parallela e le versioni canary a target singolo
Come per il deployment canary a target singolo, se esegui il deployment in destinazioni GKE, il manifest deve contenere una configurazione del deployment Kubernetes e una configurazione del servizio Kubernetes.
Come nel caso del deployment canary a target singolo, la configurazione della pipeline di distribuzione deve includere una stanza
strategy.canary
all'interno della definizione della fase per la fase applicabile.Inoltre, devi configurare un target multiplo e configurare le destinazioni figlio a cui fa riferimento il target multiplo.
Quando crei una release, vengono create un'implementazione del controller e le implementazioni secondarie.
Entrambi i tipi di implementazione, controller e figlio, hanno fasi separate per tutte le percentuali canary configurate e una fase
stable
per il 100% della versione canary.Non puoi avanzare nell'implementazione figlio.
Puoi solo avanzare le implementazioni del controller. Quando avanza l'implementazione del controller alla fase successiva, anche le implementazioni figlio vengono avanzate da Cloud Deploy.
Non puoi riprovare con i job non riusciti nell'implementazione del controller.
Puoi riprovare un job solo nelle implementazioni figlio.
Non puoi ignore i job non riusciti nell'implementazione del controller.
Puoi ignorare i job non riusciti solo nelle implementazioni figlio.
Puoi annullare l'implementazione di un controller, ma non puoi annullare le implementazioni secondarie.
Puoi terminare le esecuzioni dei job solo nell'implementazione figlio, non in un'implementazione del controller.
Cosa fare se un'implementazione parallela non va a buon fine in una versione canary
Quando un'implementazione figlio non va a buon fine, l'implementazione del controller può passare a diversi stati, a seconda di cosa succede con le implementazioni figlio:
Se una o più implementazioni figlio non riescono, ma almeno un'implementazione figlio è ancora
IN_PROGRESS
, l'implementazione del controller rimaneIN_PROGRESS
.Se una o più implementazioni figlio non vanno a buon fine, ma almeno un'implementazione figlio ha esito positivo, l'implementazione del controller sarà
HALTED
se sono presenti più fasi dopo quella attuale.Se questa è la fase
stable
, l'implementazione del controller èFAILED
.HALTED
ti offre la possibilità di ignore, riprovare i job non riusciti nell'implementazione figlio non riuscita o annullare l'implementazione del controller e impedire ulteriori azioni sulle implementazioni figlio.Se l'implementazione del controller è in stato
HALTED
a causa di un'implementazione figlio non riuscita e ignori il job non riuscito nell'implementazione figlio, l'implementazione torna allo statoIN_PROGRESS
.
Esegui il comando canary configurato
Per eseguire il deployment canary:
Registra la pipeline di distribuzione e i target configurati.
gcloud deploy apply --file=PIPELINE
La pipeline di distribuzione include la configurazione canary automatizzata o personalizzata per il runtime scelto.
Questo comando presuppone che i target siano definiti nello stesso file o che siano già stati registrati. In caso contrario, assicurati di registrare anche i tuoi obiettivi.
Crea una release:
gcloud deploy releases create RELEASE_NAME \ --delivery-pipeline=PIPELINE_NAME \ --region=REGION
La pipeline di distribuzione identificata da
PIPELINE_NAME
contiene la configurazione canary automatizzata o personalizzata descritta in questo documento.Passa alla versione canary:
Interfaccia a riga di comando gcloud
gcloud deploy rollouts advance ROLLOUT_NAME \ --release=RELEASE_NAME \ --delivery-pipeline=PIPELINE_NAME \ --region=REGION
Dove:
ROLLOUT_NAME
è il nome dell'implementazione attuale che stai avanzando alla fase successiva.RELEASE_NAME
è il nome della release di cui fa parte l'implementazione.PIPELINE_NAME
è il nome della pipeline di distribuzione che utilizzi per gestire il deployment di questa release.REGION
è il nome della regione in cui è stata creata la release, ad esempious-central1
. Campo obbligatorio.Per ulteriori informazioni sul comando
gcloud deploy rollouts advance
, consulta il riferimento di Google Cloud SDK.Console Google Cloud
Fai clic sulla pipeline mostrata nell'elenco delle pipeline di distribuzione.
La pagina dei dettagli della pipeline di distribuzione mostra una rappresentazione grafica dell'avanzamento della pipeline di distribuzione.
Nella scheda Implementazioni, in Dettagli pipeline di pubblicazione, fai clic sul nome dell'implementazione.
Viene visualizzata la pagina dei dettagli dell'implementazione.
Tieni presente che in questo esempio l'implementazione ha una fase
canary-50
e una fasestable
. L'implementazione potrebbe prevedere più fasi o fasi diverse.Fai clic su Avanzamento dell'implementazione.
L'implementazione passa alla fase successiva.
Fasi ignorate
Se esegui il deployment di una versione canary di cui non è stato ancora eseguito il deployment dell'applicazione in quel runtime, Cloud Deploy salta la fase canary ed esegue la fase stabile. Consulta l'articolo Saltare le fasi la prima volta per scoprire perché succede.
Passaggi successivi
Prova la guida rapida al deployment canary.
Scopri come gestire il ciclo di vita delle implementazioni canary.
Scopri di più sul deployment parallelo.