Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Cloud Deploy adalah layanan terkelola yang mengotomatiskan pengiriman aplikasi Anda ke serangkaian lingkungan target dalam urutan promosi yang ditentukan. Saat ingin men-deploy aplikasi yang telah diupdate, Anda membuat rilis, yang siklus prosesnya dikelola oleh pipeline pengiriman.
Cara kerja pipeline Cloud Deploy
Pipeline pengiriman Cloud Deploy berisi informasi berikut:
Nama, yang Anda gunakan saat merujuk ke pipeline pengiriman, dan deskripsi.
Urutan promosi, yang menjelaskan urutan deployment ke target yang dikonfigurasi.
Selain itu, secara opsional, definisi target itu sendiri.
Target dapat ditentukan dalam
file konfigurasi pipeline pengiriman yang sama, atau dalam
satu atau beberapa file terpisah. Beberapa pipeline pengiriman dapat menggunakan target yang sama, tetapi target tertentu hanya dapat digunakan satu kali dalam pipeline pengiriman tertentu.
Proses pengiriman Cloud Deploy
Berikut adalah deskripsi tentang apa yang terjadi dalam skenario pengiriman berkelanjutan Cloud Deploy sederhana.
File konfigurasi ini menentukan urutan promosi untuk men-deploy
aplikasi Anda ke serangkaian target.
Anda juga memerlukan konfigurasi
untuk Skaffold, yang diperlukan Cloud Deploy untuk
melakukan operasi rendering dan deployment.
Anda menentukan target, baik dalam file konfigurasi pipeline maupun dalam
file atau file terpisah.
Anda mendaftarkan pipeline dengan layanan Cloud Deploy.
Setelah mengetahui aplikasi Anda, layanan ini akan mengelola deployment
ke target sesuai dengan urutan promosi yang Anda tentukan.
Output proses CI Anda mencakup panggilan ke Cloud Deploy untuk memulai pipeline pengiriman Anda.
Panggilan ini membuat resource release, yang merepresentasikan manifes yang dirender
untuk setiap target, yang masing-masing dibuat menggunakan sumber rendering
yang disediakan, skaffold.yaml, dan referensi ke image container tertentu yang akan di-deploy.
Untuk panggilan pertama ini guna membuat rilis,
Cloud Deploy akan otomatis membuat resource rollout, yang mengaitkan rilis dengan lingkungan target pertama.
Berdasarkan peluncuran tersebut, aplikasi Anda di-deploy ke target pertama.
Anda dapat menggunakan alat CI apa pun selama alat tersebut menghasilkan satu atau beberapa image container untuk diberikan ke pipeline pengiriman Cloud Deploy.
Selain itu, panggilan untuk membuat rilis dan memanggil pipeline pengiriman tidak harus berasal dari alat CI. Hal ini dapat berasal dari skrip atau sistem apa pun yang merespons penyelesaian proses CI.
Saat Anda siap men-deploy aplikasi ke target berikutnya, Anda memanggil Cloud Deploy untuk mempromosikannya.
Dalam setiap kasus, panggilan untuk memanggil promosi menyebabkan Cloud Deploy
membuat peluncuran baru.
Promosi berlanjut melalui semua target dalam urutan promosi Anda, yang terakhir adalah prod (atau nama apa pun yang Anda gunakan untuk target akhir guna menempatkan aplikasi ke dalam produksi).
Selama eksekusi pipeline, Cloud Deploy mengumpulkan metrik dan detail audit.
Promosi
Mempromosikan rilis
adalah men-deploy-nya ke target berikutnya dalam urutan promosi yang ditentukan di
pipeline Anda. Panggilan pertama ke Cloud Deploy membuat release, lalu resource
rollout yang digunakan untuk men-deploy ke target pertama dalam urutan
promosi. Setiap panggilan berikutnya untuk mempromosikan rilis akan menghasilkan peluncuran ke target berikutnya.
Approvals
Anda dapat menentukan bahwa persetujuan diperlukan untuk promosi ke target mana pun. Misalnya, Anda mungkin ingin meminta persetujuan untuk promosi ke target produksi. Untuk mewajibkan persetujuan untuk target, tetapkan properti requireApproval di
definisi target.
Jika target memerlukan persetujuan, Cloud Deploy akan membuat pesan Pub/Sub yang dapat digunakan oleh sistem terintegrasi.
Misalnya, sistem penjualan tiket dapat berlangganan pesan untuk memulai alur kerja persetujuan.
Lihat Mewajibkan persetujuan untuk mengetahui informasi selengkapnya tentang promosi dan cara mengelola persetujuan untuk promosi.
Notifikasi
Cloud Deploy menyediakan notifikasi Pub/Sub untuk peristiwa berikut:
Render: mulai, berhasil, dan gagal
Men-deploy: mulai, berhasil, dan gagal
Diperlukan persetujuan
Persetujuan disetujui
Persetujuan ditolak
Cloud Deploy menggunakan topik Pub/Sub untuk mengirim notifikasi ini.
Cloud Deploy mendukung rollback aplikasi yang di-deploy di semua
target. Rollback di Cloud Deploy terdiri dari memicu peluncuran
terhadap rilis terakhir yang berhasil di-deploy. Peluncuran baru menggunakan parameter yang sama dengan yang digunakan dalam deployment yang berhasil tersebut.
Cloud Deploy menggunakan Skaffold untuk rendering, deployment, dan verifikasi. Dengan Skaffold, Anda juga dapat dengan mudah menghubungkan loop pengembangan lokal ke pipeline continuous delivery Cloud Deploy.
Untuk mempelajari lebih lanjut cara Cloud Deploy berintegrasi dengan Skaffold, lihat
Ringkasan Skaffold.
Cloud Deploy dengan alat Google Cloud lainnya
Cloud Deploy mendukung hampir semua alat di upstream dalam pipeline CI/CD.
Artinya, Anda dapat menggunakan lingkungan pengembangan dan repositori kode sumber apa pun, sistem continuous integration (CI) apa pun, dan repositori artefak apa pun.
Di hilir, Cloud Deploy men-deploy ke Google Kubernetes Engine, Cloud Run, dan GKE Enterprise.
Jika Anda sebagian besar menggunakan alat Google Cloud , alur source-to-prod Anda akan terlihat seperti ini:
Gunakan Cloud Code untuk membuat sumber aplikasi Anda.
Cloud Code memperluas beberapa IDE populer (VS Code, IntelliJ, Cloud Shell) untuk mempermudah pembuatan aplikasi yang akan di-deploy dan dijalankan diGoogle Cloud.
Gunakan Skaffold untuk mengelola loop pengembangan lokal Anda.
Cloud Deploy menggunakan Skaffold, melalui Cloud Build, untuk merender dan men-deploy manifes Anda. Integrasi ini berarti Anda perlu memelihara file skaffold.yaml, tetapi tidak berarti Anda perlu menjadikan Skaffold bagian dari alur pengembangan lokal. Namun, Anda dapat memanfaatkannya untuk pengembangan berkelanjutan.
Bangun aplikasi Anda menggunakan Cloud Build.
Dengan Cloud Build, Anda dapat menyiapkan pipeline CI yang dapat dipicu dari commit ke repositori kode sumber Anda. Output dari
Cloud Build akan berupa artefak termasuk image container yang dapat di-deploy. Anda dapat menambahkan panggilan ke Cloud Deploy untuk membuat rilis
dan memanggil pipeline pengiriman.
Simpan artefak Anda di Artifact Registry.
Cloud Deploy mengambil satu atau beberapa image container dari
Artifact Registry, yang memungkinkan Anda menyimpan artefak dan dependensi secara terpusat.
Konfigurasi pipeline pengiriman di Cloud Deploy untuk mengambil image container dan men-deploy-nya dalam progres n target.
Setiap target yang diidentifikasi di pipeline pengiriman Anda mewakili cluster GKE, Cloud Run, atau cluster GKE tempat aplikasi Anda akhirnya di-deploy.
Kelola aplikasi Anda di GKE, Cloud Run, atau GKE Enterprise.
GKE adalah
Google Cloud lingkungan terkelola untuk menjalankan aplikasi dalam container
di Kubernetes.
Dengan Cloud Run, Anda dapat menjalankan container di lingkungan serverless.
GKE Enterprise memberikan pengalaman pengembangan
dan operasi yang konsisten untuk lingkungan cloud dan lokal.
Pantau performa aplikasi Anda menggunakan Google Cloud Observability.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]
