Utilizza una strategia di deployment canary

Questo documento descrive come configurare e utilizzare una strategia di deployment canary.

Che cos'è un deployment canary?

Un deployment canary è un'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 di implementarla completamente.

Tipi di target supportati

Il deployment canary in Cloud Deploy supporta tutti i tipi di destinazione, tra cui:

Canary funziona anche con più target.

Perché utilizzare una strategia di deployment canary?

Un deployment canary ti offre la possibilità di rilasciare parzialmente l'applicazione. In questo modo puoi assicurarti che la nuova versione dell'applicazione sia affidabile prima di renderla disponibile a tutti gli utenti.

Ad esempio, se esegui il deployment in GKE o GKE Enterprise, eseguirai il deployment della nuova versione dell'applicazione su un numero limitato di pod. La versione precedente continuerà a essere eseguita, ma con più traffico inviato ai nuovi pod.

Se esegui il deployment in Cloud Run, Cloud Run stesso suddivide 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, puoi configurare Cloud Deploy con una serie di percentuali che esprimono un deployment progressivo. Cloud Deploy esegue operazioni aggiuntive per tuo conto per distribuire le percentuali di traffico tra la versione precedente e quella nuova.

  • Automatica personalizzata

    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.

  • Personalizzato

    Con una versione canary personalizzata, puoi configurare ciascuna fase canary separatamente, inclusi 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

    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 includerà le seguenti fasi:

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

Puoi scoprire di più sulle fasi di implementazione, sui job e sulle esecuzioni dei job nella pagina Gestire le implementazioni.

Che cosa succede durante un processo canary automatizzato o personalizzato

Per supportare il deployment canary, Cloud Deploy include passaggi di elaborazione speciali per 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:

  1. Dovrai fornire il nome della risorsa Deployment e della risorsa Servizio.

  2. Cloud Deploy crea una risorsa Deployment aggiuntiva, con il nome del deployment attuale più -canary.

  3. Cloud Deploy modifica il servizio per regolare il selettore e selezionare i pod nel deployment attuale e nei pod canary.

    Cloud Deploy calcola il numero di pod da utilizzare per il canary in base al calcolo descritto qui. Il calcolo varia a seconda che venga abilitato o disabilitato il provisioning eccessivo dei pod.

    Se siamo alla fase stable, Cloud Deploy aggiunge le etichette da utilizzare per la corrispondenza dei pod, in modo che siano disponibili per le esecuzioni canary successive.

    Cloud Deploy crea un deployment che include la percentuale di pod specifica della 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 esatta del traffico, puoi farlo utilizzando l'API Gateway.

    Inoltre, anche i volumi Secret e ConfigMap vengono copiati e rinominati con -canary.

  4. Durante la fase stable, il deployment -canary viene ridotto 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ù possibile la percentuale canary richiesta. Si basa sul numero di pod, non sul traffico verso i pod. Se vuoi che la versione canary sia basata sul traffico, devi utilizzare l'API Gateway.

Per il canary basato sulla rete di GKE, puoi abilitare o disabilitare il provisioning eccessivo 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 provisioning eccessivo abilitato

L'abilitazione del provisioning eccessivo (disablePodOverprovisioning: false) consente a Cloud Deploy di creare un numero sufficiente di pod aggiuntivi per eseguire la percentuale di canary desiderata, in base al numero di pod che eseguono il tuo deployment esistente. La formula seguente 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, il numero di repliche attuale (il numero di pod esistenti 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 è pari al 50%, il numero di pod canary è 4. (Il risultato di 100-percentage viene utilizzato come percentuale: 100-50=50, considerato come .50).

Il provisioning eccessivo dei pod è il comportamento predefinito.

Provisioning dei pod con provisioning eccessivo disabilitato

Puoi disabilitare il provisioning eccessivo (disablePodOverprovisioning: true) per assicurarti che Cloud Deploy non aumenti il numero di repliche.

La formula seguente 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 esiste già una fase canary. Se questa è la prima fase canary, non c'è ReplicaCountOfCanaryDeploymentOnCluster.

Se inizi con 4 pod, quel numero viene moltiplicato per la percentuale canary (ad esempio, 50% o .5) per ottenere 2. Di conseguenza, il deployment originale è ora ridimensionato a 2 e vengono creati due nuovi pod per il deployment canary. Se hai una fase canary al 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:

  1. Oltre ai riferimenti a deployment e servizio, fornisci una risorsa HTTPRoute con una regola backendRefs che fa riferimento al servizio.

  2. Cloud Deploy crea un nuovo deployment, con il nome del tuo deployment originale più -canary e un nuovo servizio con il nome del servizio originale più -canary.

    Inoltre, anche i volumi Secret, ConfigMap e Horizontal Pod Autoscaler vengono copiati e rinominati con -canary.

  3. 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.

  4. Durante la fase stable, il deployment -canary viene ridotto a zero e il deployment originale viene aggiornato in modo da utilizzare il deployment della nuova release.

    Inoltre, la HTTPRoute viene ora ripristinata all'originale che hai fornito.

    Cloud Deploy non modifica il deployment o il servizio originale fino 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 codice YAML del tuo servizio.

  • Quando crei una nuova implementazione per la versione canary, Cloud Deploy suddivide il traffico tra la revisione precedente di cui è stato eseguito il deployment con successo da 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 controllo delle release. Puoi farlo anche prima dell'implementazione. Inoltre, se utilizzi il deployment parallelo, puoi anche ispezionare il manifest di cui è stato eseguito il rendering di ogni elemento figlio.

Configura un deployment canary

Questa sezione descrive come configurare la pipeline di distribuzione e le destinazioni per un deployment canary.

Le istruzioni riportate qui includono solo le informazioni specifiche 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 necessarie

Oltre alle altre autorizzazioni di Identity and Access Management necessarie per l'utilizzo di Cloud Deploy, sono necessarie le seguenti autorizzazioni 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

Consulta Autorizzazioni e ruoli IAM per ulteriori informazioni su quali ruoli disponibili includono queste autorizzazioni.

Prepara il tuo skaffold.yaml

Come per un deployment standard, la tua versione canary ha bisogno di un file skaffold.yaml, che definisce il modo in cui vengono visualizzati e distribuiti i manifest e le definizioni di servizio.

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 ha bisogno di un manifest Kubernetes o di una definizione del servizio Cloud Run.

GKE e GKE Enterprise

Per la versione canary, il file 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 un canary basato sull'API Gateway, il manifest deve avere anche una HTTPRoute.

Cloud Run

Per la versione canary su Cloud Run, è sufficiente il tuo 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 un canary automatizzato

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.

Configura lo strumento canary automatizzato 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 tuo manifest.

  • DEPLOYMENT_NAME è il nome del deployment Kubernetes definito nel manifest.

  • PERCENTAGES è un elenco separato da virgole di valori percentuali che rappresentano gli incrementi canary, ad esempio [5, 25, 50].

    La versione canary automatica supporta percentuali fino a 50, ma non superiori. Se hai bisogno di una fase canary con una percentuale superiore al 50%, devi utilizzare l'API Gateway o un canary personalizzato.

    Inoltre, non include 100, perché il deployment del 100%% è presunto nella versione canary ed è gestito dalla fase stable.

  • Puoi abilitare la verifica del deployment (verify: true). In questo caso, viene abilitato un job verify 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 è incluso 100, perché il deployment del 100%% è presunto nella versione canary ed è gestito dalla fase stable.
  • Puoi abilitare la verifica del deployment (verify: true). In questo caso, viene aggiunto un job verify 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, devi specificare quanto segue nella definizione della pipeline di distribuzione:

  • Nomi delle fasi di implementazione

    In un canary completamente automatizzato, Cloud Deploy assegna un nome alle fasi (canary-25, canary-75, stable, ad esempio). Tuttavia, con una versione canary personalizzata puoi assegnare un nome a ogni fase, purché sia univoco tra tutte le fasi della fase canary e rispetti le limitazioni relative ai nomi delle risorse. Tuttavia, il nome della fase (100%) finale deve essere stable.

  • 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 oppure lo stesso profilo o qualsiasi combinazione. Inoltre, ogni profilo può utilizzare un manifest Kubernetes o una definizione del servizio Cloud Run diversi. Puoi anche utilizzare più di un profilo per una determinata fase. Cloud Deploy li 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.

Per la versione canary personalizzata sono supportati tutti i tipi di target.

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. Il nome di ogni fase deve essere univoco.

  • [ "PROFILE_NAME" ]

    È il nome del profilo da utilizzare per la fase. Puoi utilizzare 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 specificati da te, più il profilo o il manifest utilizzato dalla fase generale.

  • PERCENTAGE1

    È la percentuale di cui eseguire il 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 di utilizzo della verifica, Skaffold utilizza per la verifica lo stesso profilo specificato per il rendering e il deployment per quella fase.

  • stable

    Il nome della fase finale deve essere stable.

La percentuale per l'ultima fase deve essere 100. Le fasi vengono eseguite in base all'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 riesce e genera un errore.

Tieni presente che la configurazione di una versione canary personalizzata non include una stanza runtimeConfig. Se includi runtimeConfig, viene considerato un canary con automazione personalizzata.

Configurazione di un file canary automatizzato personalizzato

Un canary automatizzato personalizzato è simile a uno canary personalizzato perché consente di specificare le fasi canary separate, con nomi di fase personalizzati, valori percentuali, profili Skaffold e di verifica dei job. Tuttavia, con una versione canary personalizzata, non devi fornire le configurazioni che definiscono la distribuzione del traffico: Cloud Deploy se ne occupa automaticamente, ma devi comunque fornire i profili Skaffold da utilizzare per ogni fase.

Per configurare una stanza canary con automazione personalizzata, includi una stanza runtimeConfig, come mostrato qui, e includi la stanza customCanaryDeployment, come mostrato qui.

Configura un deployment canary utilizzando il mesh di servizi API Kubernetes Gateway

Anche se puoi utilizzare un deployment canary di Cloud Deploy per eseguire il deployment della tua applicazione sul 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.

  1. Configura le risorse dell'API Gateway:

    Si tratta solo di esempi.

  2. Nel manifest Kubernetes, fornito a Cloud Deploy al momento della creazione della release, includi quanto segue:

    • Un elemento HTTPRoute che fa riferimento alla risorsa Gateway

    • Un deployment

    • Un servizio

  3. 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 configurazione HTTPRoute dell'API Kubernetes Gateway, nonché a deployment e 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 tuo deployment, che Cloud Deploy richiede per i deployment canary in GKE e GKE Enterprise.

      • WAIT_TIME rappresenta il tempo necessario a Cloud Deploy per attendere che le modifiche alla risorsa HTTPRoute terminino la propagazione, per evitare l'eliminazione di richieste. Ad esempio: routeUpdateWaitTime: 60s.

        Se esegui la versione 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 la destinazione in cui stai progressivamente eseguendo il deployment può comprendere due o più target secondari. Ad esempio, puoi eseguire il deployment progressivamente in cluster in aree geografiche distinte, contemporaneamente.

Qual è la differenza tra uno canary parallelo e le versioni canary con target singolo

  • Come per il deployment canary a target singolo, se esegui il deployment nelle destinazioni GKE, devi disporre di una configurazione di Kubernetes Deployment e di una configurazione di Kubernetes Service nel manifest.

  • Come per il 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 una destinazione multipla e configurare le destinazioni figlio a cui fa riferimento più destinazioni.

  • Quando crei una release, vengono create un'implementazione del controller e le implementazioni secondarie.

    Entrambi i tipi di implementazione (controller e secondaria) prevedono fasi distinte per tutte le percentuali canary configurate e una fase stable per il 100% canary.

  • Non puoi avanzare un'implementazione figlio.

    Puoi avanzare solo nelle implementazioni del controller. Quando porti avanti l'implementazione del controller alla fase successiva, anche le implementazioni secondarie vengono avanzate da Cloud Deploy.

  • Non puoi provare a eseguire i job non riusciti nell'implementazione del controller.

    Puoi riprovare un job solo nelle implementazioni secondarie.

  • Non puoi ignore i job non riusciti nell'implementazione del controller.

    Puoi ignorare i job non riusciti solo nelle implementazioni secondarie.

  • Puoi annullare l'implementazione di un controller, ma non puoi annullare le implementazioni secondarie.

  • Puoi terminare le esecuzioni dei job solo in un'implementazione figlio, non in un'implementazione del controller.

Cosa fare se un'implementazione parallelo non va a buon fine in 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 secondarie:

  • Se una o più implementazioni secondarie non vanno a buon fine, ma almeno un'implementazione figlio è ancora IN_PROGRESS, l'implementazione del controller rimane IN_PROGRESS.

  • Se una o più implementazioni secondarie 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 corrente.

    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 oppure annullare l'implementazione del controller e impedire ulteriori azioni sulle implementazioni secondarie.

  • 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 del controller torna allo stato IN_PROGRESS.

Esegui il modello canary configurato

Per eseguire il deployment canary:

  1. 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 le destinazioni siano definite nello stesso file o che siano già state registrate. In caso contrario, assicurati di registrare anche i tuoi target.

  2. 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.

  3. 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 corrente 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 stai utilizzando per gestire il deployment di questa release.

    REGION è il nome della regione in cui è stata creata la release, ad esempio us-central1. Campo obbligatorio.

    Per ulteriori informazioni sul comando gcloud deploy rollouts advance, consulta il riferimento di Google Cloud SDK.

    Console Google Cloud

    1. Apri la pagina Pipeline di pubblicazione.

    2. Fai clic sulla pipeline visualizzata nell'elenco delle pipeline di distribuzione.

      La pagina dei dettagli della pipeline di distribuzione mostra una rappresentazione grafica dell'avanzamento della pipeline di distribuzione.

    3. Nella scheda Implementazioni, in Dettagli pipeline di distribuzione, fai clic sul nome dell'implementazione.

      Viene mostrata la pagina dei dettagli dell'implementazione.

      dettagli dell'implementazione nella console Google Cloud

      Nota che in questo esempio l'implementazione ha una fase canary-50 e una fase stable. L'implementazione potrebbe prevedere più fasi o fasi diverse.

    4. Fai clic su Prosegui con implementazione.

      L'implementazione passa alla fase successiva.

Fasi ignorate

Se esegui il deployment di una versione canary e la tua applicazione non è ancora stata sottoposta a deployment in quel runtime, Cloud Deploy salta la fase canary ed esegue la fase stabile. Consulta la sezione Saltare le fasi la prima volta per scoprire il motivo.

Passaggi successivi