Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
Cloud Deploy es un servicio gestionado que automatiza el envío de tus aplicaciones a una serie de entornos de destino en una secuencia de promoción determinada. Cuando quieras implementar la aplicación actualizada, crea una versión, cuyo ciclo de vida se gestiona mediante una pipeline de lanzamiento.
Cómo funciona una canalización de Cloud Deploy
El flujo de trabajo de entrega de Cloud Deploy contiene la siguiente información:
Un nombre, que se usa para hacer referencia a la canalización de entrega, y una descripción.
La secuencia de promoción, que describe el orden en el que se debe implementar en los destinos configurados.
También puede incluir las definiciones de los objetivos.
Los destinos se pueden definir en el mismo archivo de configuración de la canalización de entrega o en uno o varios archivos independientes. Varias canalizaciones de distribución pueden usar el mismo objetivo u objetivos, pero un objetivo determinado solo se puede usar una vez en una canalización de distribución.
Proceso de entrega de Cloud Deploy
A continuación, se describe lo que ocurre en un escenario de entrega continua sencillo de Cloud Deploy.
Este archivo de configuración define la secuencia de promoción en la que se desplegará tu aplicación en una serie de destinos.
También necesitas una configuración de Skaffold, que Cloud Deploy necesita para realizar operaciones de renderización y despliegue.
Puedes definir los objetivos en el archivo de configuración de la canalización o en uno o varios archivos independientes.
Registras tu canal de procesamiento en el servicio Cloud Deploy.
Ahora que el servicio conoce tu aplicación, gestiona la implementación en los destinos según la secuencia de promoción que hayas definido.
La salida de tu proceso de integración continua incluye una llamada a Cloud Deploy para iniciar tu flujo de procesamiento de entrega.
Esta llamada crea un recurso release que representa el manifiesto renderizado de cada destino. Cada uno de ellos se genera mediante la fuente de renderización proporcionada, skaffold.yaml y referencias a imágenes de contenedor específicas que se van a desplegar.
En esta primera llamada para crear una versión, Cloud Deploy crea automáticamente un recurso rollout, que asocia la versión con el primer entorno de destino.
En función de ese lanzamiento, tu aplicación se desplegará en el primer destino.
Puedes usar cualquier herramienta de integración continua siempre que genere una o varias imágenes de contenedor para proporcionárselas a tu canal de distribución de Cloud Deploy.
Además, la llamada para crear una versión e invocar una canalización de lanzamiento no tiene por qué proceder de la herramienta de integración continua. Puede proceder de una secuencia de comandos o de cualquier sistema que responda a la finalización del proceso de integración continua.
Cuando quieras desplegar la aplicación en el siguiente destino, llama a Cloud Deploy para promocionarla.
En cada caso, la llamada para invocar la promoción hace que Cloud Deploy cree un nuevo lanzamiento.
La promoción continúa en todos los objetivos de la secuencia de la promoción. El último es prod (o el nombre que uses para el objetivo final para poner la aplicación en producción).
Durante la ejecución de la canalización, Cloud Deploy recoge métricas y detalles de auditoría.
Promoción
Promocionar una versión significa implementarla en el siguiente destino de la secuencia de promoción definida en tu canalización. La primera llamada a Cloud Deploy crea un release y, a continuación, un recurso rollout que se usa para implementar en el primer destino de la secuencia de promoción. Cada llamada posterior para promocionar la versión da como resultado un lanzamiento a la siguiente versión de destino.
Aprobaciones
Puede especificar que se necesite una aprobación para promocionar cualquier destino. Por ejemplo, puede que quieras requerir aprobación para promocionar contenido en un destino de producción. Para requerir aprobación para un objetivo, define la propiedad requireApproval en la definición del objetivo.
Cuando un destino requiere aprobación, Cloud Deploy genera un mensaje de Pub/Sub que puede consumir un sistema integrado.
Por ejemplo, un sistema de incidencias podría suscribirse al mensaje para iniciar un flujo de trabajo de aprobación.
Consulte Requerir aprobación para obtener más información sobre las promociones y cómo gestionar su aprobación.
Notificaciones
Cloud Deploy proporciona notificaciones de Pub/Sub para los siguientes eventos:
Renderización: inicio, éxito y error
Implementación: inicio, éxito y error
Aprobación obligatoria
Aprobación aprobada
Aprobación rechazada
Cloud Deploy usa un tema de Pub/Sub para enviar estas notificaciones.
Cloud Deploy admite la reversión de la aplicación desplegada en cualquier destino. Una restauración en Cloud Deploy consiste en activar un lanzamiento en la última versión desplegada correctamente. La nueva implementación usa los mismos parámetros que se usaron en esa implementación correcta.
Cloud Deploy usa Skaffold para las operaciones de renderizado, despliegue y verificación. Con Skaffold, también puedes conectar fácilmente tu bucle de desarrollo local a una canalización de entrega continua de Cloud Deploy.
Cloud Deploy admite casi cualquier herramienta upstream en una canalización de CI/CD.
Es decir, puedes usar cualquier entorno de desarrollo y repositorio de código fuente, cualquier sistema de integración continua y cualquier repositorio de artefactos.
Más adelante, Cloud Deploy se despliega en Google Kubernetes Engine, Cloud Run y GKE Enterprise.
Si has usado principalmente Google Cloud herramientas, tu flujo de origen a producción sería el siguiente:
Usa Cloud Code para crear el origen de tu aplicación.
Cloud Code amplía varios IDEs populares (VS Code, IntelliJ y Cloud Shell) para facilitar la creación de aplicaciones que se puedan desplegar y ejecutar enGoogle Cloud.
Usa Skaffold para gestionar tu bucle de desarrollo local.
Cloud Deploy usa Skaffold a través de Cloud Build para renderizar y desplegar tus archivos de manifiesto. Esta integración significa que debes mantener un archivo skaffold.yaml, pero no implica que tengas que incluir Skaffold en tu flujo de desarrollo local. Sin embargo, puedes aprovecharla para desarrollar continuamente.
Compila tu aplicación con Cloud Build.
Cloud Build te permite configurar una canalización de integración continua que se puede activar a partir de una confirmación en tu repositorio de código fuente. El resultado de Cloud Build serán artefactos, incluidas imágenes de contenedor implementables. Puedes añadir una llamada a Cloud Deploy para crear una versión e invocar tu canalización de distribución.
Almacena tus artefactos en Artifact Registry.
Cloud Deploy obtiene la imagen o las imágenes de contenedor de Artifact Registry, que te permite almacenar de forma centralizada artefactos y dependencias.
Configura tu flujo de procesamiento de entrega en Cloud Deploy para que tome la imagen de contenedor y la despliegue en una progresión de n destinos.
Cada uno de los destinos identificados en tu canal de distribución representa un clúster de GKE, Cloud Run o un clúster de GKE en el que se despliega tu aplicación.
Gestiona tu aplicación en GKE, Cloud Run o GKE Enterprise.
GKE es el
Google Cloud entorno gestionado para ejecutar aplicaciones en contenedores
en Kubernetes.
Con Cloud Run, puedes ejecutar contenedores en un entorno sin servidor.
GKE Enterprise ofrece una experiencia de desarrollo y operaciones coherente para entornos en la nube y on-premise.
Monitoriza el rendimiento de tu aplicación con Google Cloud Observability.
Para ver de forma rápida y sencilla cómo crear una canalización de entrega y usarla para implementar una aplicación, consulta las guías de inicio rápido.
Consulta Google Cloud Well-Architected Framework: Operational excellence
(Marco de trabajo Well-Architected: excelencia operativa) para leer artículos sobre cómo usar los principios de la excelencia operativa para crear una base de entrega automatizada.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-21 (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)."]]
