Building an automated serverless deployment pipeline with Cloud Build | C2C Community

Building an automated serverless deployment pipeline with Cloud Build

Categories: DevOps and SRE

January 20, 2023
Roger Martinez

Developer Relations Engineer

Patricia Shin

Cloud Developer Relations Engineer



Build, push and deploy your serverless application to Cloud Run automatically.


You’ve got a shiny new application ready to deploy to the cloud. After researching your options, you land on using Cloud Run with Cloud Build to build and push your containerized application code to an Artifact Registry repository. In three steps, using a Dockerfile and a Cloud Build configuration you  build your container, push it to Artifact Registry, and deploy it to Cloud Run:


# Build the container image
- name: ''
args: ['build', '-t', '', '.']

# Push the container image to Artifact Registry
- name: ''
args: ['push', '']

# Deploy container image to Cloud Run
- name: ''
entrypoint: gcloud
args: ['run', 'deploy', 'my-serverless-app', '--image', '', '--region', 'us-central1']



The example above combines the build, push and deployment steps into one Cloud Build job.  This blog will show you what this could look like as a series of manual deployment steps, and how it can be developed into an automatic serverless deployment pipeline that can be used as a jumping off point for more complex solutions.  We’ll be using Cloud BuildArtifact RegistryPub/Sub and Cloud Run.  

We'll use the open source GitHub project, Emblem, to model a working reference of Google Cloud serverless architecture.  References to Emblem will be marked with the 💠 emoji.

A manual pipeline

Let’s start by examining the manual steps to deploy a containerized application to Cloud Run.
  1. First, you make application code changes to your repository's main branch. 

  2. When an application change is merged, you use Cloud Build to build a new container.

  3. After a successful build, Cloud Build pushes the newly built container to Artifact Registry. 

  4. You update Cloud Run with a new configuration pointing to the new build.

  5. Cloud Run deploys a new revision of your service. Your code changes are now deployed.  

Of course, you would need to go through these steps each time there are changes to your application code. That’s not practical and can turn into a logistical nightmare for a team making continuous updates to the code.  Not to mention the added complexity of staging changes to multiple environments or incorporating systematic testing or incremental rollouts. Let’s see how you can automate your lovely little pipeline by looking at it as two parts: the build and the deployment.  

Automate the build

To automate the build step of your pipeline, Cloud Build should build and push when a change is committed to the application code in your repository.  Here’s what’s needed to make this happen:


1. Connect your GitHub repository to your Cloud project

By connecting your GitHub repository to your project, Cloud Build can use repository events to initiate a Cloud Build trigger. Common repository events are supported including pushing to a specific branch, pushing a new tag, and creating a pull request.  


2. Include a Cloud Build yaml configuration in your repository 

You can configure a Cloud Build job with a build config file. This YAML file provides task-level instructions to Cloud Build.  This file can live alongside your application’s Dockerfile, or in a separate directory in your repository.  For an automatic build, your config file will tell Cloud Build to build the container image and push it to Artifact Registry.  


💠 The Emblem project continuously builds multiple containers and keeps corresponding build config files in a centralized ops/ directory.  This allows for the separation of ownership of the Cloud Build configs and the application code they may build. 


Click here to read more

Be the first to reply!