# Continuous Delivery with Cloud Deploy and Spinnaker

> Chapter 7 of the Courseiva GOOGLE-PCDOE curriculum — https://courseiva.com//learn/google-pcdoe/cd-pipelines-with-cloud-deploy

**Official objective:** 1.5 — Implement continuous delivery pipelines to deploy applications to GKE and other environments using Cloud Deploy.

## Introduction

How do you get a new version of your software to run on a hundred servers without breaking anything or waking up at 3 a.m. to fix a disaster? Continuous delivery pipelines solve exactly this problem by automating the journey of code from your laptop to live production, and both Cloud Deploy and Spinnaker are purpose-built tools for that job on Google Cloud. For the PCDOE exam, you need to understand how these pipelines work, why they exist, and what decision criteria you would use to choose between them.

## The Food Truck Festival Analogy

A food truck festival is a bustling event where dozens of trucks serve hungry crowds all day long. Each truck has its own kitchen, menu, and crew. The festival organisers do not own the trucks; they coordinate the space, power, and crowd flow. When a new menu item is ready, the truck owner tests it in a small parking lot with a few friends. Once it is perfect, they send the recipe to every truck in the fleet. The update must reach all trucks without any truck boiling the wrong sauce or running out of ingredients. 

The festival uses a central radio system. The owner announces the new item and gives step-by-step instructions. Some trucks update immediately, while others wait until the lunch rush ends. The radio system tracks which trucks have applied the change and which still need it. If a truck reports a problem with the new recipe, the owner can send a rollback order to revert to the old recipe instantly. The crowd never sees this coordination. They just enjoy the new dish without knowing the complex orchestration behind it. This is continuous delivery — the ability to push a change to many locations reliably, safely, and with automated oversight, just like the radio system manages the festival's menu updates.

## Core explanation

Let’s start with the big picture. When you write code, you eventually want it to run somewhere useful — a website, a mobile app backend, or a data-processing job. That ‘somewhere’ is called an environment. For the PCDOE exam, the primary environment is Google Kubernetes Engine, or GKE, which is a managed service that runs your applications inside containers. A container is a lightweight, portable package that contains everything your code needs to run, like a shipping container for software. 

Now, imagine you want to update your application. If you do it manually, you would log into every server, stop the old version, copy the new files, and restart. That is error-prone, slow, and terrifying. Continuous delivery solves this by automating the entire process. The key idea is that every change to your code that passes automated tests is considered ‘releasable’ — it could go to production at any moment. You then choose when to actually deploy it. 

Cloud Deploy is Google Cloud’s native service for continuous delivery. It is fully managed, which means Google handles the servers and infrastructure behind the scenes. You define a delivery pipeline, which is a YAML file (a human-readable configuration format) that describes the stages your software goes through. For example, you might have stages called ‘dev’, ‘staging’, and ‘prod’. Cloud Deploy uses a concept called ‘targets’ to represent each environment, and it manages promotions — the act of moving a release from one stage to the next. 

A release in Cloud Deploy is a snapshot of your application at a specific version. When you create a release, Cloud Deploy automatically deploys it to the first target (usually dev). After you verify it works, you promote it to the next target manually or automatically using a ‘promotion policy’. Cloud Deploy also supports ‘canary’ deployments, where you send a small percentage of traffic to the new version first. If things look good, you increase the traffic gradually. This is called a progressive delivery strategy. 

Spinnaker is an older, open-source continuous delivery platform that predates Cloud Deploy. It was originally developed by Netflix and later made open source. Spinnaker is more flexible and powerful, but it requires you to manage your own infrastructure to run it. On Google Cloud, you can run Spinnaker using a managed service called ‘Cloud Run’ or on GKE directly. Spinnaker uses a similar concept of ‘pipelines’, which are sequences of stages like ‘deploy’, ‘resize’, or ‘disable’. Spinnaker also integrates deeply with GKE and has robust support for multi-cloud deployments — sending your application to Google Cloud, AWS, and Azure from the same pipeline. 

Why would you choose one over the other? Cloud Deploy is simpler, cheaper (no infrastructure to manage), and tightly integrated with Google Cloud and GKE. It is the recommended choice for most Google Cloud-native teams. Spinnaker is better if you need to deploy to multiple clouds, if you need very custom behaviour, or if you already have Spinnaker expertise in your team. The PCDOE exam focuses heavily on Cloud Deploy because it is the newer, exam-relevant service. 

Both tools use a declarative approach: you describe the desired state of your deployment (e.g., ‘100 replicas of version 5 running on GKE’), and the tool makes it happen. This contrasts with an imperative approach where you specify every command step-by-step. Declarative deployment is more reliable because the system automatically corrects deviations from the desired state. 

To make this concrete, here are the key components of a Cloud Deploy delivery pipeline:


- Pipeline: The overall definition of your delivery process, including stages and targets.
- Target: An environment (like dev, staging, prod) where your application runs.
- Release: A specific version of your application, built from your source code.
- Rollout: The process of applying a release to a target.
- Promotion: The action of moving a release from one target to the next.
- Approval: A manual or automated gate that must pass before a promotion occurs.


The entire workflow looks like this: you commit code to a source repository (like GitHub). A CI (Continuous Integration) tool like Cloud Build automatically tests and packages your code into a container image. That image is pushed to a registry like Artifact Registry. Then you create a Cloud Deploy release using that image as the source. The release automatically deploys to your first target. You verify it, promote it to the next target, and so on until it reaches production. Each promotion can require approvals, canary analysis, or automatic rollback if something fails. 

This automated pipeline replaces manual SSH sessions, reduces human error, and gives auditors a clear record of who deployed what, when, and with which approvals.

## Real-world context

An IT professional at a mid-sized e-commerce company called ‘ShopFast’ is responsible for deploying a new checkout feature. The team uses GKE and wants to adopt continuous delivery. Here is what they actually do step by step. 

First, the professional sets up Cloud Deploy by writing a delivery pipeline YAML file. This file defines three targets: ‘dev’, ‘staging’, and ‘prod’. Each target points to a separate GKE cluster in different Google Cloud projects. The professional uses Cloud Build as the CI system. Whenever a developer merges code to the main branch, Cloud Build runs unit tests, builds a container image, and pushes it to Artifact Registry. Then Cloud Build triggers a new Cloud Deploy release. 

The professional configures an automatic promotion from dev to staging — no manual approval needed for internal environments — but requires a manual approval before promotion to prod. This approval is a simple button click in the Google Cloud Console, but it requires a user with the correct IAM permissions. The professional also sets up a canary deployment strategy for the prod target. The YAML configuration specifies that the first phase of the canary sends 5% of traffic to the new version for 10 minutes. If no errors spike, it automatically increases to 20% for 10 minutes, then 100%. 

During a routine Friday afternoon deployment, the canary phase reports a 200% increase in error rates in the first 5 minutes. Cloud Deploy automatically rolls back the canary to the previous version, and the promotion is halted. The professional receives a notification via Cloud Logging. They investigate the error logs and discover a missing configuration file. After fixing the code and re-running the pipeline, the deployment succeeds on Monday morning — without any customer impact. 

The professional also uses Cloud Deploy’s ‘rollback’ feature to revert a problematic release that made it to production. They click ‘Rollback’ in the console, and Cloud Deploy automatically deploys the previous known-good version to the prod target. This takes seconds and requires no manual scripting. 

In a different project, the same team might use Spinnaker if they need to deploy the same application to both GKE and Amazon EKS simultaneously. The professional would set up Spinnaker on GKE, configure a pipeline with multiple ‘Deploy (Manifest)’ stages, each targeting a different cluster credential. Spinnaker’s ‘Pipeline Templates’ and ‘Stage Dependencies’ allow them to orchestrate complex sequences like ‘deploy to AWS, then run integration tests, then if successful, deploy to GCP’. 

Key actions the professional takes day-to-day:


- Write and version-control pipeline YAML files in the same repository as the application code.
- Review canary analysis metrics (like error rate, latency, CPU usage) in Cloud Monitoring before promoting.
- Manage IAM roles to grant approval permissions for production promotions.
- Monitor deployment history and audit logs in Cloud Deploy for compliance.
- Use the gcloud CLI to create releases and promote them during incident response, not just the console.


The result: deployments that used to take a full day with two engineers now happen in under 15 minutes with zero manual steps. The company ships features faster, and the IT professional sleeps better at night.

## Exam focus

The PCDOE exam tests your understanding of continuous delivery pipelines using Cloud Deploy and Spinnaker in several specific ways. First, you will see scenario-based multiple-choice questions where you are given a business requirement and must choose the correct tool or configuration. The exam loves to test your ability to distinguish between Cloud Deploy and Spinnaker based on cost, complexity, and multi-cloud needs. 

A common question type presents a scenario like: ‘A team wants to deploy a containerised application to GKE with automated canary analysis and manual approval for production. Which service should they use?’ The correct answer is almost always Cloud Deploy, because it is the native, simpler solution. A distractor answer might be ‘Spinnaker’, but the correct pattern is that Cloud Deploy is preferred unless the question explicitly mentions multi-cloud or advanced custom stages. 

Another trap is around the term ‘approval’. The exam will test whether you know that approvals in Cloud Deploy are configured as part of the delivery pipeline YAML, using the ‘approval’ field within a stage. You must know that approvals can be ‘manual’ or ‘automatic’, and that manual approvals require an IAM user with the ‘clouddeploy.approver’ role. They test that you understand approvals are not the same as IAM roles for creating releases. 

The exam also tests your knowledge of ‘canary deployment’ versus ‘blue-green deployment’. Cloud Deploy supports both, but the exam focuses on canary with automated analysis. You need to know that canary analysis uses metrics from Cloud Monitoring (like error count, latency) to decide whether to proceed. The exam might give you a YAML snippet with a ‘canaryDeployment’ section and ask you to interpret what percentage of traffic goes to the new version first. 

Key concepts that appear repeatedly:


- Delivery pipeline vs. release vs. rollout: Know the difference. A pipeline is the definition of stages. A release is a specific version. A rollout is the execution of a release to a target.
- Promotion policies: Understand that you can automate promotion or require manual approval.
- Rollback: Cloud Deploy supports rollback to a previous release. This is not the same as reverting a pipeline.
- Targets: Each target can have a different GKE cluster, namespace, or even a different project.
- Spinnaker stages: The exam expects you to recognise stage types like ‘Deploy (Manifest)’, ‘Resize’, ‘Disable’, and ‘Wait’. You don’t need to memorise every stage, but you should know the common ones.
- Cloud Deploy’s integration with Cloud Build and Artifact Registry: The flow of code to deployment is a classic exam chain.


Traps you must avoid:


- Thinking Cloud Deploy is only for GKE: It can also do Cloud Run and GKE. The exam may test this.
- Confusing ‘release’ with ‘rollout’: A release creates a rollout for the first target. They are not interchangeable.
- Assuming Spinnaker is always better: The exam prefers Cloud Deploy unless multi-cloud is explicitly stated.
- Forgetting IAM roles: You need ‘clouddeploy.operator’ to manage pipelines and ‘clouddeploy.approver’ to approve promotions.


To memorise: Cloud Deploy is for GKE-first teams who want simplicity. Spinnaker is for multi-cloud or advanced customisation. The exam will test this binary choice repeatedly.

## Step by step

1. **Define the Delivery Pipeline** — You write a YAML file that declares the series of stages (e.g., dev, staging, prod) and the targets (GKE clusters or Cloud Run services) for each stage. This file is stored in your source repository. It is the blueprint for how software moves from code to live users.
2. **Configure the CI Trigger** — You set up Cloud Build (or another CI tool) to run whenever code is pushed to the main branch. The CI tool runs tests, builds a container image, and pushes it to Artifact Registry. This step is the ‘continuous integration’ part that feeds the delivery pipeline.
3. **Create a Release** — After the CI step succeeds, you create a new release in Cloud Deploy. You specify the container image (from Artifact Registry) and which pipeline to use. Cloud Deploy automatically deploys that release to the first target (usually dev). This is the beginning of the delivery process.
4. **Promote Through Stages** — Once the release is healthy on the dev target, you promote it to the next stage (e.g., staging). Promotion can be automatic or require manual approval. You can also configure canary deployments to gradually shift traffic. Each promotion creates a new rollout on the target.
5. **Approve Production Deployment** — For the production target, you typically require a manual approval step. An authorised user with the clouddeploy.approver role clicks ‘Approve’ in the console or uses the gcloud command. After approval, Cloud Deploy executes the rollout to the production environment.
6. **Monitor and Rollback if Needed** — After deployment, you monitor application metrics and logs via Cloud Monitoring and Cloud Logging. If something goes wrong, you can initiate a rollback from the console. Cloud Deploy will automatically deploy the previous release to the target, restoring the old version quickly.

## Comparisons

### Cloud Deploy vs Spinnaker

**Cloud Deploy:**
- Fully managed by Google, no infrastructure to run
- Simpler YAML-based pipeline definition
- Tightly integrated with GKE, Cloud Run, and Google Cloud monitoring

**Spinnaker:**
- You must manage your own control plane (on GKE or VMs)
- More flexible with custom stages, scripts, and complex logic
- Supports multi-cloud deployments (GCP, AWS, Azure) out of the box

### Continuous Delivery (CD) vs Continuous Deployment

**Continuous Delivery (CD):**
- Every change is releasable but requires manual approval for production
- Human decides when to push to production
- Safer for high-risk applications

**Continuous Deployment:**
- Every change that passes tests is automatically deployed to production
- No human gate
- Faster but riskier than continuous delivery

### Canary Deployment vs Blue-Green Deployment

**Canary Deployment:**
- New version receives a small percentage of traffic initially
- Traffic is gradually shifted based on metrics
- No need to maintain two full environment copies

**Blue-Green Deployment:**
- Two identical environments (blue and green) are maintained
- Traffic is switched all at once from old to new
- Requires more resources than canary

## Common misconceptions

- **Misconception:** Continuous delivery and continuous deployment are the same thing. **Reality:** Continuous delivery means every change is releasable but you still manually decide when to deploy to production. Continuous deployment automatically deploys every change to production without human intervention. (The terms sound nearly identical, and many exam candidates blur them. The exam explicitly tests the distinction.)
- **Misconception:** Cloud Deploy is just a wrapper around Spinnaker. **Reality:** Cloud Deploy is a completely separate, Google-built service that does not use Spinnaker under the hood. It has its own architecture and API. (Because Spinnaker is open-source and older, beginners assume Google’s own service must be built on top of it. That is incorrect.)
- **Misconception:** You must use Cloud Deploy with GKE only. **Reality:** Cloud Deploy also supports Cloud Run and can deploy to any Kubernetes cluster, including ones outside GKE. (The exam materials heavily emphasise GKE, so students overgeneralise. The exam may test non-GKE targets.)
- **Misconception:** A rollback in Cloud Deploy reverts the pipeline definition itself. **Reality:** A rollback deploys the previous release (the old version of your app) to the target. The pipeline definition stays unchanged. (Students confuse rolling back an application with reverting a configuration change. They are separate operations.)
- **Misconception:** Spinnaker is required for canary deployments; Cloud Deploy cannot do canaries. **Reality:** Cloud Deploy supports canary deployments with automated analysis natively, including traffic splitting and metric-based decisions. (Spinnaker is known for advanced canary features, so beginners assume Cloud Deploy lacks them. The exam tests that Cloud Deploy has built-in canary support.)

## Key takeaways

- Cloud Deploy is Google Cloud’s managed continuous delivery service, while Spinnaker is an open-source platform you manage yourself.
- A delivery pipeline defines stages (like dev, staging, prod) and targets (the environments where your app runs).
- A release is a specific version of your application, and a rollout is the act of applying that release to a target.
- Manual approvals in Cloud Deploy require the clouddeploy.approver IAM role and are configured in the pipeline YAML.
- Canary deployments send a small percentage of traffic to the new version first, and Cloud Deploy can automatically roll back if metrics degrade.
- Use Cloud Deploy for GKE-first, single-cloud teams; use Spinnaker for multi-cloud or highly customised pipeline needs.
- Continuous delivery means every code change is automatically tested and ready to deploy, but you choose when to go to production.
- Rollbacks in Cloud Deploy deploy the previous release to the target, not change the pipeline configuration.

## FAQ

**What is the difference between Cloud Deploy and Cloud Build?**

Cloud Build is a CI (continuous integration) tool that builds and tests your code. Cloud Deploy is a CD (continuous delivery) tool that deploys your built code to environments. Cloud Build feeds into Cloud Deploy.

**Can I use Cloud Deploy without GKE?**

Yes, Cloud Deploy also supports Cloud Run, and it can deploy to any standard Kubernetes cluster, even those running on other clouds or on-premises.

**Do I need to install anything to use Cloud Deploy?**

No, Cloud Deploy is a fully managed Google Cloud service. You only need the gcloud CLI or access to the Google Cloud Console to use it.

**What is a canary deployment in Cloud Deploy?**

A canary deployment sends a small percentage of user traffic to the new version of your app first. Cloud Deploy monitors error rates and latency, and can automatically increase traffic or roll back based on the results.

**How do I approve a promotion in Cloud Deploy?**

You need the clouddeploy.approver IAM role. In the Cloud Console, you navigate to the delivery pipeline, find the pending rollout, and click ‘Approve’. You can also use the gcloud deploy approve command.

**When should I choose Spinnaker over Cloud Deploy?**

Choose Spinnaker if you need to deploy to multiple cloud providers (e.g., GCP, AWS, Azure) from a single pipeline, or if you need highly custom pipeline logic that Cloud Deploy’s YAML model cannot express. Otherwise, prefer Cloud Deploy for simplicity.

---

Interactive version with quiz and diagrams: https://courseiva.com//learn/google-pcdoe/cd-pipelines-with-cloud-deploy