Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Cloud Deploy é um serviço gerenciado que automatiza a entrega de aplicativos para uma série de ambientes de destino em uma sequência de promoções definida. Quando você quiser implantar seu
aplicativo atualizado, será necessário criar uma versão, cujo ciclo de vida
é gerenciado por um pipeline de entrega.
Como funciona um pipeline do Cloud Deploy
O pipeline de entrega do Cloud Deploy contém as seguintes informações:
Um nome, que você usa ao se referir ao pipeline de entrega, e uma descrição.
A sequência de promoção, que descreve a ordem de implantação dos destinos configurados.
Os destinos podem ser definidos no
mesmo arquivo de configuração do pipeline de entrega ou em
um ou mais arquivos separados. Vários pipelines de entrega podem usar os mesmos
destinos, mas um determinado destino pode ser usado apenas uma vez em um determinado pipeline
de entrega.
O processo de entrega do Cloud Deploy
Veja a seguir uma descrição do que acontece em um cenário simples de entrega contínua do
Cloud Deploy.
Esse arquivo de configuração define a sequência de promoção na qual implantar seu aplicativo em uma série de destinos.
Você também precisa de uma configuração
para o Skaffold, que o Cloud Deploy precisa para
realizar operações de renderização e implantação.
Defina os destinos no arquivo de configuração do pipeline ou em um arquivo ou arquivos separados.
Você registra seu pipeline com o serviço do Cloud Deploy.
Agora que conhece o aplicativo, o serviço gerencia a implantação para os destinos de acordo com a sequência de promoção definida.
A saída do processo de CI inclui uma chamada para o Cloud Deploy para iniciar o pipeline de entrega.
Essa chamada cria um recurso release, que representa o manifesto renderizado para cada destino, cada um dos quais é gerado usando a origem de renderização fornecida, skaffold.yaml e as referências a imagens de contêiner específicas a serem implantadas.
Nessa primeira chamada para criar uma versão,
o Cloud Deploy cria automaticamente um recurso rollout, que associa a versão ao primeiro ambiente de destino.
Com base nesse lançamento, seu aplicativo será implantado no primeiro destino.
É possível usar qualquer ferramenta de CI, desde que gere uma ou mais imagens de contêiner para
fornecer ao pipeline de entrega do Cloud Deploy.
Além disso, a chamada para criar uma versão e invocar um pipeline de entrega não precisa ser proveniente da ferramenta de CI. Ele pode vir de um script ou de qualquer
sistema que responda à conclusão do processo de CI.
Quando estiver pronto para implantar o aplicativo no próximo destino, chame
o Cloud Deploy para promovê-lo.
Em cada caso, a chamada para invocar a promoção faz com que o Cloud Deploy
crie um novo lançamento.
A promoção continua em todas as segmentações da sequência de promoções, sendo a última
da prod (ou qualquer nome usado na meta final para colocar o
aplicativo em produção).
Durante a execução do pipeline, o Cloud Deploy coleta detalhes e a auditoria.
Promoção
Para promover uma versão,
você precisa implantá-la no próximo destino na sequência de promoção definida no
pipeline. A primeira chamada para o Cloud Deploy cria um release e, em seguida, um
recurso rollout usado para implantar no primeiro destino na sequência de
promoção. Cada chamada subsequente para promover a versão resulta em um lançamento para a próxima meta.
Aprovações
Você pode especificar que uma aprovação é necessária para promover qualquer destino. Por
exemplo, talvez você queira exigir a aprovação de uma promoção em um destino de
produção. Para exigir aprovação de um destino, defina a property requireApproval na definição de destino.
Quando um destino requer aprovação, o Cloud Deploy gera uma mensagem do Pub/Sub que pode ser consumida por um sistema integrado.
Por exemplo, um sistema de tíquetes pode assinar a mensagem para iniciar um fluxo de trabalho de aprovação.
Consulte Exigir aprovação para mais informações sobre promoções e como gerenciar a aprovação delas.
Notificações
O Cloud Deploy fornece notificações do Pub/Sub para os seguintes eventos:
Renderização: início, sucesso e falha
Implantação: início, sucesso e falha
Aprovação necessária
Aprovação aprovada
Aprovação rejeitada
O Cloud Deploy usa um tópico do Pub/Sub para enviar essas
notificações.
O Cloud Deploy é compatível com a reversão do aplicativo implantado em qualquer destino. Uma reversão no Cloud Deploy consiste em acionar uma implantação
na última versão implantada. A nova implantação usa os mesmos
parâmetros usados na implantação bem-sucedida.
O Cloud Deploy usa o Skaffold para renderização, implantação e verificação. Com o Skaffold, também é fácil conectar seu loop de desenvolvimento
local a um pipeline de entrega contínua do Cloud Deploy.
Para saber mais sobre como o Cloud Deploy se integra ao Skaffold, consulte
a visão geral do Skaffold.
Cloud Deploy com outras ferramentas Google Cloud
O Cloud Deploy é compatível com quase todas as ferramentas upstream em um pipeline de CI/CD.
Ou seja, é possível usar qualquer ambiente de desenvolvimento e repositório de código-fonte, qualquer
sistema de integração contínua (CI) e qualquer repositório de artefatos.
Downstream, o Cloud Deploy implanta no Google Kubernetes Engine, no Cloud Run e no GKE Enterprise.
Se você usasse principalmente ferramentas Google Cloud , seu fluxo de origem para produção seria assim:
Use o Cloud Code para criar a origem do aplicativo.
O Cloud Code estende vários ambientes de desenvolvimento integrado conhecidos (VS Code, IntelliJ,
Cloud Shell) para facilitar a criação de aplicativos para implantação e execução no
Google Cloud.
Use o Skaffold para gerenciar seu loop de desenvolvimento local.
O Cloud Deploy usa o Skaffold, por meio do Cloud Build, para renderizar e implantar seus manifestos. Essa integração significa que você precisa
manter um arquivo skaffold.yaml, mas não significa que precisa tornar o
Skaffold parte do fluxo de desenvolvimento local. Mas você pode aproveitar
isso para desenvolvimento contínuo.
Crie o aplicativo usando o Cloud Build.
O Cloud Build permite configurar um pipeline de CI que possa ser
acionado a partir de uma confirmação no seu repositório de código-fonte. A saída do Cloud Build será artefatos, incluindo imagens de contêiner implantáveis. É possível adicionar uma chamada ao Cloud Deploy para criar uma versão
e invocar o pipeline de entrega.
Armazene seus artefatos no Artifact Registry.
O Cloud Deploy recupera as imagens do contêiner do Artifact Registry, que permite armazenar de maneira centralizada artefatos e dependências.
Configure o pipeline de entrega no Cloud Deploy para usar a
imagem do contêiner e implantá-la em uma progressão de n destinos.
Cada um dos destinos identificados no pipeline de entrega representa um
cluster do GKE, o Cloud Run ou
um cluster do GKE em que o aplicativo é totalmente implantado.
Gerenciar seu aplicativo no GKE, Cloud Run
ou GKE Enterprise.
O GKE é o
ambiente gerenciado doGoogle Cloud para executar aplicativos em contêineres
no Kubernetes.
Com o Cloud Run, é possível executar contêineres em um ambiente sem servidor.
O GKE Enterprise oferece uma experiência consistente de desenvolvimento
e operações para ambientes na nuvem e no local.
Monitore o desempenho do seu aplicativo usando o Google Cloud Observability.
O Google Cloud Observability oferece monitoramento e geração de registros integrados para seu aplicativo.
A seguir
Para uma visão rápida e fácil de criar um pipeline de entrega e usá-lo para implantar um aplicativo, consulte os guias de início rápido.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-17 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)."]]
