Skip to main content
Google Cloud Platform (GCP)
CHAPTER 17

CI/CD with Google Cloud

Updated: May 15, 2026
25 min read

# CHAPTER 17

CI/CD with Google Cloud

1. Introduction

If a developer has to manually build a Docker container on their laptop, authenticate with GCP, and manually run a deployment command every time they fix a bug, human error is inevitable. In modern DevOps, deployments must be boring, automated, and mathematically reproducible. In this chapter, we will connect the final piece of the architectural puzzle: Continuous Integration and Continuous Deployment (CI/CD). We will automate the pipeline from a GitHub commit directly into Google Cloud using Cloud Build.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define Continuous Integration (CI) and Continuous Deployment (CD).
  • Understand the role of Google Cloud Build.
  • Connect a GitHub repository to a GCP Project.
  • Author a cloudbuild.yaml pipeline configuration file.
  • Automate the deployment of an application to Cloud Run.

3. Beginner-Friendly Explanation

Imagine a car factory.
  • Manual Deployment (The Old Way): An engineer designs a new engine. They have to walk onto the factory floor, stop the assembly line, remove the old engine by hand, bolt the new one in, and restart the line. It is slow and prone to mistakes.
  • CI/CD (The Automated Factory): The engineer drops a blueprint into an inbox (GitHub). A robot (Cloud Build) instantly detects the blueprint. The robot autonomously builds the engine (Docker build), tests it to ensure it won't explode (Unit Tests), walks onto the factory floor, and seamlessly swaps the engine while the car is still moving (Zero-downtime deployment). The engineer never leaves their desk.

4. Google Cloud Build

There are many CI/CD tools in the industry (Jenkins, GitHub Actions, GitLab CI). Google's native offering is Cloud Build. Cloud Build is a serverless CI/CD platform. You provide it a series of "Steps" (run this test, build this container, deploy this app). Google provisions a temporary secure environment, executes your steps sequentially, and then destroys the environment. You only pay for the exact minutes your build was running.

5. The CI/CD Pipeline Flow

A standard GCP pipeline follows this exact sequence:
  1. 1. Trigger: A developer merges code into the main branch on GitHub.
  1. 2. Cloud Build Wakes Up: The GitHub webhook triggers Cloud Build.
  1. 3. Step 1 (Test): Run automated Python/Node.js tests. If they fail, STOP the pipeline.
  1. 4. Step 2 (Build): Run docker build to package the new code.
  1. 5. Step 3 (Push): Run docker push to securely upload the image to Artifact Registry.
  1. 6. Step 4 (Deploy): Execute gcloud run deploy to update the live application with the new image.

6. Anatomy of a cloudbuild.yaml

You define your pipeline steps in a YAML file located in the root of your code repository.
yaml
12345678910111213
steps:
  # Step 1: Build the Docker Image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA', '.']

  # Step 2: Push the Image to Artifact Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA']

  # Step 3: Deploy to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args: ['run', 'deploy', 'my-production-app', '--image', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA', '--region', 'us-central1']

*Note the $COMMITSHA variable! Cloud Build automatically injects the unique Git Commit hash to tag the image. This creates a perfect audit trail!*

7. Mini Project: Automated Deployment

Let's conceptualize the setup of an automated pipeline.

Step-by-Step Overview:

  1. 1. Ensure your application code and the cloudbuild.yaml file are committed to a GitHub repository.
  1. 2. In the GCP Console, navigate to Cloud Build > Triggers.
  1. 3. Click Create Trigger.
  1. 4. Name: deploy-to-production
  1. 5. Event: Choose "Push to a branch".
  1. 6. Source: Connect your GitHub account and select your repository.
  1. 7. Branch: ^main$ (This Regex ensures it only triggers on the main branch).
  1. 8. Configuration: Select "Cloud Build configuration file (yaml)".
  1. 9. Click Create.
  1. 10. The Test: Go to your laptop, change a line of code, and git push origin main. Return to the Cloud Build console. You will see your build executing live, successfully updating your application without a single manual terminal command!

8. Real-World Scenarios

A financial technology company requires absolute security. They cannot allow developers to deploy code from their laptops. They implement a strict CI/CD pipeline using Cloud Build. Developers do not have the IAM permissions required to update the GKE production cluster. Only the Cloud Build Service Account has those permissions. To get code into production, a developer must submit a Pull Request, get it approved by a senior engineer, and merge it. Cloud Build takes over, ensuring the deployment is sterile, tested, and perfectly auditable.

9. Best Practices

  • Cloud Deploy: While Cloud Build is excellent for building and testing, orchestrating complex deployments across Dev, Staging, and Production environments can get messy. Google recently released Cloud Deploy, a specialized Continuous Delivery tool that works alongside Cloud Build to manage complex rollout strategies, approvals, and easy rollbacks.

10. Common Mistakes

  • Missing Service Account Permissions: When Cloud Build reaches "Step 4" and tries to deploy to Cloud Run or GKE, it often fails with a "PERMISSION DENIED" error. Beginners forget that Cloud Build acts as a robot identity (The Cloud Build Service Account). You must go to the IAM page and grant the Cloud Build Service Account the Cloud Run Admin or Kubernetes Engine Developer roles so it has the authority to actually update your infrastructure!

11. Exercises

  1. 1. What is the fundamental security advantage of allowing a CI/CD pipeline to handle deployments rather than allowing developers to deploy code from their local laptops?
  1. 2. Why is utilizing the Git $COMMITSHA as a Docker image tag superior to simply tagging every new image as :latest?

12. FAQs

Q: Should I use Cloud Build or GitHub Actions? A: Both are excellent. If your company already heavily utilizes GitHub, GitHub Actions is a natural fit. However, Cloud Build is natively integrated with GCP IAM, making authentication to Artifact Registry and GKE completely seamless, without needing to manage long-lived service account JSON keys inside GitHub Secrets.

13. Interview Questions

  • Q: Detail the architectural flow of a Continuous Deployment pipeline from a developer's git push to a live application update on Google Cloud Run, specifically highlighting the roles of Cloud Build and Artifact Registry.
  • Q: A Cloud Build pipeline successfully builds and pushes a Docker image to Artifact Registry, but the final deployment step to a GKE cluster fails with an IAM Authorization error. Identify the specific identity attempting the deployment and describe the IAM Role assignment required to resolve the failure.

14. Summary

In Chapter 17, we eliminated manual toil and embraced automation. We introduced Continuous Integration and Continuous Deployment (CI/CD) as the mandatory delivery mechanism for modern cloud architecture. We utilized Cloud Build to autonomously build, tag, push, and deploy our containerized applications in response to a simple GitHub commit, ensuring that our deployments are fast, sterile, and mathematically reproducible.

15. Next Chapter Recommendation

Our applications are running flawlessly. Now, we need to analyze the petabytes of user data our applications are generating. We need the most powerful analytics engine on earth. Proceed to Chapter 18: BigQuery and Data Analytics.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·