Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Cloud Deploy è un servizio gestito che automatizza la distribuzione delle applicazioni in una serie di ambienti target in una sequenza di promozione definita. Quando vuoi eseguire il deployment dell'applicazione aggiornata, crei una release, il cui ciclo di vita è gestito da una pipeline di distribuzione.
Come funziona una pipeline Cloud Deploy
La pipeline di distribuzione di Cloud Deploy contiene le seguenti informazioni:
Un nome, che utilizzi quando fai riferimento alla pipeline di pubblicazione, e una
descrizione.
La sequenza di promozione, che descrive l'ordine di deployment nei target configurati.
Inoltre, facoltativamente, le definizioni dei target.
I target possono essere definiti nel
file di configurazione della stessa pipeline di distribuzione oppure in
uno o più file separati. Più pipeline di distribuzione possono utilizzare lo stesso
target o gli stessi target, ma un determinato target può essere utilizzato una sola volta in una determinata pipeline di distribuzione.
Procedura di distribuzione di Cloud Deploy
Di seguito è riportata una descrizione di ciò che accade in uno scenario di distribuzione continua semplice di Cloud Deploy.
Questo file di configurazione definisce la sequenza di promozione in cui eseguire il deployment dell'applicazione in una serie di destinazioni.
Hai anche bisogno di una configurazione
per Skaffold, che Cloud Deploy richiede per
eseguire le operazioni di rendering e deployment.
Definisci i target nel file di configurazione della pipeline o in uno o più file separati.
Registri la pipeline con il servizio Cloud Deploy.
Ora che il servizio conosce la tua applicazione, gestisce il deployment
nei target in base alla sequenza di promozione definita.
L'output del processo CI include una chiamata a Cloud Deploy per
avviare la pipeline di distribuzione.
Questa chiamata crea una risorsa release, che rappresenta il manifest sottoposto a rendering
per ogni target, ognuno dei quali viene generato utilizzando l'origine di rendering fornita, skaffold.yaml e i riferimenti a immagini container specifiche da eseguire il deployment.
Per questa prima chiamata per creare una release,
Cloud Deploy crea automaticamente una risorsa rollout, che associa la release al primo ambiente di destinazione.
In base a questo rollout, l'applicazione viene implementata nel primo target.
Puoi utilizzare qualsiasi strumento CI, purché restituisca una o più immagini container da
fornire alla pipeline di distribuzione Cloud Deploy.
Inoltre, la chiamata per creare una release e richiamare una pipeline di distribuzione
non deve necessariamente provenire dallo strumento CI. Può provenire da uno script o da qualsiasi
sistema che risponde al completamento della proceduraCIa.
Quando è tutto pronto per il deployment dell'applicazione nel target successivo, chiami Cloud Deploy per promuoverla.
In ogni caso, la chiamata per richiamare la promozione fa sì che Cloud Deploy
crei un nuovo rollout.
La promozione continua in tutti i target della sequenza di promozione, l'ultimo
dei quali è prod (o qualsiasi nome utilizzi per il target finale per mettere
l'applicazione in produzione).
Durante l'esecuzione della pipeline, Cloud Deploy raccoglie metriche e dettagli di audit.
Promozione
Promuovere una release significa eseguirne il deployment nel target successivo nella sequenza di promozione definita nella pipeline. La prima chiamata a Cloud Deploy crea un release, poi una risorsa
rollout che viene utilizzata per il deployment nella prima destinazione della sequenza di promozione. Ogni chiamata successiva per promuovere la release comporta un'implementazione
nel target successivo.
Approvazioni
Puoi specificare che è necessaria un'approvazione per la promozione a qualsiasi target. Ad esempio, potresti voler richiedere l'approvazione per la promozione in un target di produzione. Per richiedere l'approvazione per una destinazione, imposta la proprietà requireApproval nella definizione della destinazione.
Quando un target richiede l'approvazione, Cloud Deploy genera un messaggio Pub/Sub che può essere utilizzato da un sistema integrato.
Ad esempio, un sistema di emissione di biglietti potrebbe abbonarsi al messaggio per avviare un workflow di approvazione.
Per ulteriori informazioni sulle promozioni e sulla gestione dell'approvazione delle promozioni, consulta la sezione Richiedi approvazione.
Notifiche
Cloud Deploy fornisce notifiche Pub/Sub per i seguenti eventi:
Rendering: inizio, esito positivo ed errore
Deployment: inizio, esito positivo e negativo
È necessaria un'approvazione
Approvazione approvata
Approvazione rifiutata
Cloud Deploy utilizza un argomento Pub/Sub per inviare queste
notifiche.
Cloud Deploy supporta il rollback dell'applicazione di cui hai eseguito il deployment in qualsiasi destinazione. Un rollback in Cloud Deploy consiste nell'attivazione di un'implementazione
rispetto all'ultima release di cui è stato eseguito il deployment. Il nuovo rollout utilizza gli stessi
parametri utilizzati in quell'implementazione riuscita.
Cloud Deploy utilizza Skaffold per il rendering, il deployment e la verifica. Con Skaffold, puoi anche connettere facilmente il tuo ciclo di sviluppo locale a una pipeline di distribuzione continua di Cloud Deploy.
Per scoprire di più su come Cloud Deploy si integra con Skaffold, consulta la panoramica di Skaffold.
Cloud Deploy con altri Google Cloud strumenti
Cloud Deploy supporta quasi tutti gli strumenti upstream in una pipeline CI/CD.
ovvero puoi utilizzare qualsiasi ambiente di sviluppo e repository di codice sorgente, qualsiasi sistema di integrazione continua (CI) e qualsiasi repository di artefatti.
A valle, Cloud Deploy esegue il deployment su Google Kubernetes Engine, Cloud Run e GKE Enterprise.
Se hai utilizzato principalmente strumenti Google Cloud , il flusso di origine-produzione
avrebbe il seguente aspetto:
Utilizza Cloud Code per creare l'origine dell'applicazione.
Cloud Code estende diversi IDE popolari (VS Code, IntelliJ, Cloud Shell) per semplificare la creazione di applicazioni da eseguire il deployment e l'esecuzione suGoogle Cloud.
Utilizza Skaffold per gestire il ciclo di sviluppo locale.
Cloud Deploy utilizza Skaffold, tramite Cloud Build, per
eseguire il rendering e il deployment dei manifest. Questa integrazione significa che devi
gestire un file skaffold.yaml, ma non significa che devi
integrare Skaffold nel tuo flusso di sviluppo locale. ma puoi sfruttarlo per lo sviluppo continuo.
Crea l'applicazione utilizzando Cloud Build.
Cloud Build ti consente di configurare una pipeline CI che può essere
attivata da un commit al repository del codice sorgente. L'output di
Cloud Build saranno artefatti, incluse immagini container
deployable. Puoi aggiungere una chiamata a Cloud Deploy per creare una release
e richiamare la pipeline di distribuzione.
Archivia gli artefatti in Artifact Registry.
Cloud Deploy recupera l'immagine o le immagini container da
Artifact Registry, che ti consente di archiviare centralmente
artefatti e dipendenze.
Configura la pipeline di distribuzione in Cloud Deploy in modo che prenda l'immagine container ed esegua il deployment in una progressione di n target.
Ognuno di questi target identificati nella pipeline di distribuzione rappresenta un cluster GKE, Cloud Run o un cluster GKE in cui viene eseguito il deployment finale dell'applicazione.
Gestisci la tua applicazione su GKE, Cloud Run
o GKE Enterprise.
GKE è l'Google Cloud ambiente gestito per l'esecuzione di applicazioni containerizzate su Kubernetes.
Con Cloud Run, puoi eseguire i container in un ambiente serverless.
GKE Enterprise offre un'esperienza operativa e di sviluppo coerente per ambienti cloud e on-premise.
Monitora le prestazioni della tua applicazione utilizzando Google Cloud Observability.
Per una panoramica rapida e semplice su come creare una pipeline di distribuzione e utilizzarla per distribuire un'applicazione, prova le guide rapide.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-03 UTC."],[[["\u003cp\u003eCloud Deploy automates application delivery to multiple target environments through a defined promotion sequence managed by a delivery pipeline.\u003c/p\u003e\n"],["\u003cp\u003eA Cloud Deploy pipeline includes a name, promotion sequence, and optional labels, annotations, and target definitions, with targets being configurable within the pipeline or in separate files.\u003c/p\u003e\n"],["\u003cp\u003eThe delivery process involves defining the pipeline and targets, registering the pipeline, initiating the pipeline via a CI tool, and promoting the application through subsequent targets, each generating a new rollout.\u003c/p\u003e\n"],["\u003cp\u003eCloud Deploy supports approvals for promotion to any target, which triggers a notification process that integrated systems can use to manage the approval workflow.\u003c/p\u003e\n"],["\u003cp\u003eCloud Deploy uses Skaffold for rendering, deployment, and verification, integrates with various CI/CD tools, and works with Google Cloud services like GKE, Cloud Run, GKE Enterprise, Cloud Build, and Artifact Registry.\u003c/p\u003e\n"]]],[],null,["# Overview of Cloud Deploy\n\nCloud Deploy is a managed service that automates delivery of your\napplications to a series of [target](/deploy/docs/terminology#target)\nenvironments in a defined promotion sequence. When you want to deploy your\nupdated application, you create a [release](/deploy/docs/terminology#release),\nwhose [lifecycle](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release)\nis managed by a [delivery pipeline](/deploy/docs/terminology#delivery_pipeline).\n\nHow a Cloud Deploy pipeline works\n---------------------------------\n\nThe Cloud Deploy delivery pipeline contains the following information:\n\n- A name, which you use when referring to the delivery pipeline, and a\n description.\n\n- The promotion sequence, describing the order in which to deploy to the\n configured [targets](/deploy/docs/terminology#target).\n\n- Optionally, [labels and annotations](/deploy/docs/labels-annotations).\n\n- Also optionally, the target definitions themselves.\n\nTargets can be [defined](/deploy/docs/config-files#target_definitions) in the\nsame delivery pipeline [configuration file](/deploy/docs/config-files), or in\none or more separate files. Multiple delivery pipelines can use the same\ntarget or targets, but a given target can be used only once in a given delivery\npipeline.\n\n### The Cloud Deploy delivery process\n\nThe following is a description of what happens in a simple Cloud Deploy\ncontinuous delivery scenario.\n\n1. You define your [delivery pipeline](/deploy/docs/terminology#delivery_pipeline)\n in a [YAML configuration file](/deploy/docs/config-files#structure_of_a_delivery_pipeline_configuration_file).\n\n This configuration file defines the promotion sequence in which to deploy\n your application to a series of [targets](/deploy/docs/terminology#target).\n\n You also need a [configuration](https://skaffold.dev/docs/references/yaml/)\n for [Skaffold](/skaffold), which Cloud Deploy needs in order to\n perform render and deploy operations.\n2. You define your targets, either in the pipeline configuration file or in a\n separate file or files.\n\n3. You register your pipeline with the Cloud Deploy service.\n\n Now that the service knows about your application, it manages the deployment\n to targets according to your defined promotion sequence.\n4. The output of your CI process includes a call to Cloud Deploy to\n initiate your delivery pipeline.\n\n This call creates a `release` resource, representing the rendered manifest\n for each target, each of which is generated using the provided rendering\n source, skaffold.yaml, and references to specific container images to deploy.\n For this first call to create a [release](/deploy/docs/terminology#release),\n Cloud Deploy automatically creates a [`rollout`](/deploy/docs/terminology#rollout)\n resource, which associates the release with the first target environment.\n Based on that rollout, your application is deployed to the first target.\n\n You can use any CI tool as long as it outputs one or more container images to\n provide to your Cloud Deploy delivery pipeline.\n\n Furthermore, the call to create a release and invoke a delivery pipeline\n doesn't have to come from the CI tool. It can come from a script or any\n system responding to the completion of the CI process.\n5. When you're ready to deploy your application to the next target, you call\n Cloud Deploy to promote it.\n\n In each case, the call to invoke the promotion causes Cloud Deploy\n to create a new rollout.\n6. Promotion continues through all targets in your promotion sequence, the last\n of which is `prod` (or whatever name you use for your final target to put the\n application into production).\n\n The process of release creation and promotion is described in more detail in\n [Cloud Deploy service architecture](/deploy/docs/architecture#how_they_fit_together_to_deliver_your_release).\n\nThroughout pipeline execution, Cloud Deploy collects metrics and\n[audit](/deploy/docs/audit-logs) details.\n\n### Promotion\n\nTo [promote a release](/deploy/docs/promote-release)\nis to deploy it to the next target in the promotion sequence defined in your\npipeline. The first call to Cloud Deploy creates a `release`, then a\n`rollout` resource that's used to deploy to the first target in the promotion\nsequence. Each subsequent call to promote the release results in a rollout to\nthe next target.\n\n### Approvals\n\nYou can specify that an approval is needed for promotion to any target. For\nexample, you might want to require approval for promotion into a production\ntarget. To require approval for a target, set the `requireApproval` property in\nthe [target definition](/deploy/docs/config-files#target_definitions).\n\nWhen a target requires approval, Cloud Deploy generates a\nPub/Sub message that can be consumed by an integrated system.\nFor example, a ticketing system could subscribe to the message to kick off an\napproval workflow.\n\nSee [Require approval](/deploy/docs/promote-release#require_approval) for more\ninformation on promotions and managing approval for promotions.\n\n### Notifications\n\nCloud Deploy provides Pub/Sub notifications for the following\nevents:\n\n- Render: start, success, and failure\n- Deploy: start, success, and failure\n- Approval required\n- Approval approved\n- Approval rejected\n\nCloud Deploy uses a Pub/Sub topic to send these\nnotifications.\n\nSee [Using Cloud Deploy notifications](/deploy/docs/subscribe-deploy-notifications) for more details.\n\n### Rollbacks\n\nCloud Deploy supports rolling back your deployed application in any\ntarget. A rollback in Cloud Deploy consists of triggering a rollout\nagainst the last successfully deployed release. The new rollout uses the same\nparameters that were used in that successful deployment.\n\nSee [Rolling back a deployment](/deploy/docs/roll-back) for more details.\n\nAbout Skaffold and Cloud Deploy\n-------------------------------\n\nCloud Deploy uses [Skaffold](/skaffold) for rendering, deployment,\nand verification. With Skaffold, you can also easily connect your local\ndevelopment loop to a Cloud Deploy continuous delivery pipeline.\n\nTo learn more about how Cloud Deploy integrates with Skaffold, see\nthe [Skaffold overview](/deploy/docs/using-skaffold).\n\nCloud Deploy with other Google Cloud tools\n------------------------------------------\n\nCloud Deploy supports almost any tool upstream in a CI/CD pipeline.\nThat is, you can use any development environment and source code repository, any\ncontinuous integration (CI) system, and any artifact repository.\n\nDownstream, Cloud Deploy deploys to Google Kubernetes Engine,\nCloud Run, and GKE Enterprise.\n\nIf you used mostly Google Cloud tools, your source-to-prod flow\nwould look like this:\n\n1. Use [Cloud Code](/code/docs) to create your application source.\n\n Cloud Code extends several popular IDEs (VS Code, IntelliJ,\n Cloud Shell) to make it easier to build applications to deploy and run on\n Google Cloud.\n2. Use [Skaffold](https://skaffold.dev) to manage your local development loop.\n\n Cloud Deploy uses Skaffold, through Cloud Build, to\n render and deploy your manifests. This integration means that you need to\n maintain a `skaffold.yaml` file, but does not otherwise mean you need to make\n Skaffold part of your local development flow. But you can take advantage of\n it for [continuous development](https://skaffold.dev/docs/workflows/dev/).\n3. Build your application using Cloud Build.\n\n [Cloud Build](/build/docs) lets you set up a CI pipeline that can be\n triggered from a commit to your source code repository. The output from\n Cloud Build will be artifacts including deployable container\n images. You can add a call to Cloud Deploy to create a release\n and invoke your delivery pipeline.\n4. Store your artifacts in Artifact Registry.\n\n Cloud Deploy retrieves the container image or images from\n [Artifact Registry](/artifact-registry/docs), which lets you centrally store\n artifacts and dependencies.\n5. Configure your delivery pipeline in Cloud Deploy to take the\n container image and deploy it in a progression of *n* targets.\n\n Each of those targets identified in your delivery pipeline represents a\n GKE cluster, Cloud Run, or\n GKE cluster where your application is ultimately deployed.\n6. Manage your application on GKE, Cloud Run\n or GKE Enterprise.\n\n [GKE](/kubernetes-engine/docs) is the\n Google Cloud managed environment for running containerized\n applications on Kubernetes.\n\n With [Cloud Run](/run/docs), you can run containers in a\n serverless environment.\n\n [GKE Enterprise](/anthos/docs) provides a consistent development\n and operations experience for cloud and on-premises environments.\n7. Monitor the performance of your application using Google Cloud Observability.\n\n [Google Cloud Observability](/stackdriver/docs) offers integrated monitoring and\n logging for your application.\n\nWhat's next\n-----------\n\n- For a quick-and-easy look at how to create a delivery pipeline and use it to\n deploy an application, try the [quickstarts](/deploy/docs/quickstarts).\n\n- Try out one of the [Cloud Deploy walkthroughs](/deploy/docs/tutorials).\n\n- Learn more about [how Cloud Deploy components work together](/deploy/docs/architecture).\n\n- Review [Google Cloud Well-Architected Framework: Operational excellence](/architecture/framework/operational-excellence)\n for articles on how to use the principles of operational excellence to build an\n automated delivery foundation.\n\n- [Learn how to combine Google Cloud CI/CD tools to develop and deliver\n software effectively to GKE](https://cloud.google.com/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke)."]]
