또한 Cloud Deploy가 렌더링 및 배포 작업을 수행하는 데 필요한 Skaffold구성이 필요합니다.
파이프라인 구성 파일 또는 별도의 파일 또는 파일에서 타겟을 정의합니다.
Cloud Deploy 서비스에 파이프라인을 등록합니다.
이제 서비스가 애플리케이션에 대해 알고 있으므로 정의된 프로모션 시퀀스에 따라 타겟에 대한 배포를 관리합니다.
CI 프로세스 출력에는 배포 파이프라인을 시작하기 위한 Cloud Deploy 호출이 포함됩니다.
이 호출은 각 타겟의 렌더링된 매니페스트를 나타내는 release 리소스를 만듭니다. 각 리소스는 제공된 렌더링 소스, skaffold.yaml, 배포할 특정 컨테이너 이미지에 대한 참조를 사용하여 생성됩니다.
출시를 처음 만들 때 Cloud Deploy가 출시 버전을 첫 번째 대상 환경과 연결하는 rollout 리소스를 자동으로 만듭니다.
이 출시에 따라 애플리케이션이 첫 번째 타겟에 배포됩니다.
Cloud Deploy 배포 파이프라인에 제공할 하나 이상의 컨테이너 이미지를 출력하는 한 모든 CI 도구를 사용할 수 있습니다.
또한 출시 버전을 만들고 배포 파이프라인을 호출하기 위한 호출을 CI 도구에서 수행할 필요가 없습니다. 스크립트 또는 CI 프로세스의 완료에 응답하는 모든 시스템에서 호출을 수행할 수 있습니다.
다음 대상에 애플리케이션을 배포할 준비가 되면 Cloud Deploy를 호출하여 이를 승격합니다.
두 경우 모두 프로모션을 호출하면 Cloud Deploy가 새 출시를 만듭니다.
프로모션은 프로모션 시퀀스의 모든 타겟을 진행하며 마지막 단계는 prod(또는 애플리케이션을 프로덕션에 적용하기 위해 최종 타겟에 사용하는 이름)입니다.
Cloud Deploy는 파이프라인 실행 전반에 걸쳐 측정항목 및 감사 세부정보를 수집합니다.
프로모션
출시를 승격하려면 파이프라인에 정의된 프로모션 시퀀스의 다음 타겟에 배포해야 합니다. Cloud Deploy를 처음 호출하면 release가 생성되고 프로모션 시퀀스의 첫 번째 타겟에 배포하는 데 사용되는 rollout 리소스가 생성됩니다. 이후 출시를 승격할 때마다 다음 타겟으로 출시됩니다.
승인
모든 타겟으로 승격하는 데 승인이 필요하다고 지정할 수 있습니다. 예를 들어 프로덕션 타겟으로 승격하려면 승인이 필요할 수 있습니다. 타겟의 승인을 요구하려면 타겟 정의에서 requireApproval 속성을 설정합니다.
타겟의 승인이 필요하면 Cloud Deploy는 통합 시스템에서 사용할 수 있는 Pub/Sub 메시지를 생성합니다.
예를 들어 티켓팅 시스템은 메시지를 구독하여 승인 워크플로를 시작할 수 있습니다.
Cloud Deploy는 Cloud Build를 통해 Skaffold를 사용하여 매니페스트를 렌더링하고 배포합니다. 이 통합은 skaffold.yaml 파일을 유지해야 함을 의미하지만, Skaffold를 로컬 개발 흐름의 일부로 만들어야 함을 의미하지는 않습니다. 하지만 지속적 개발에 활용할 수 있습니다.
Cloud Build를 사용하여 애플리케이션을 빌드합니다.
Cloud Build를 사용하면 소스 코드 저장소에 대한 커밋에서 트리거할 수 있는 CI 파이프라인을 설정할 수 있습니다. Cloud Build의 출력은 배포 가능한 컨테이너 이미지를 포함한 아티팩트입니다. Cloud Deploy에 호출을 추가하여 출시 버전을 만들고 배포 파이프라인을 호출할 수 있습니다.
Artifact Registry에 아티팩트를 저장합니다.
Cloud Deploy는 아티팩트와 종속 항목을 중앙에서 저장할 수 있는 Artifact Registry에서 컨테이너 이미지를 가져옵니다.
컨테이너 이미지를 가져와서 n 타겟의 진행 상황에서 배포하도록 Cloud Deploy에서 배포 파이프라인을 구성합니다.
배포 파이프라인에서 식별된 각 대상은 애플리케이션이 궁극적으로 배포되는 GKE 클러스터, Cloud Run, 또는 GKE 클러스터를 나타냅니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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)."]]
