Working with multiple environments in Google Cloud Build

Douglas Augusto
Aug 29, 2018 · 3 min read

Working on large projects requires several environments, such as DEV, QA, UAT, STAGE, PROD. This text details an approach to use Google Cloud Build features to create generic pipelines that can adapt to multiple environments.

Context

Google Cloud Build is a cloud service that lets you create Continuous Integration, Delivery, and Deployment.

The trigger containing the execution rules and pipeline variables can be created via interface or command line.
The pipeline containing the steps is described and versioned in your repository through a configuration file in .yaml or .json.

Scenario

To illustrate how to work with multiple environments, we’ll use an App Engine application and create separate runs for the PROD and STAGE environments. It follows our needs for each environment:

PROD: in the production environment we must publish in the prod version, guarantee the promotion of the version and that all traffic is redirected to the environment.
STAGE: in the stage environment we must publish in the stage version, do not promote the version and they migrate 20% of traffic to this environment.

Solution

We will create 2 triggers, one for each environment. For SCM issues, I've associated each environment with a branch, respectively, PROD: master and STAGE: rc. We will use the substitutions feature to configure variable values for each environment. Following is our triggers:

We will create a generic configuration file called .cloudbuild.yaml that will contain the DEPLOY and SERVICES steps of our pipeline, receiving and overriding the values of the variables described in the triggers that were previously created. Here is our pipeline:

Tests

When committing a new functionality in our environment in branch rc our Release Candidate trigger will be triggered and will perform all process for our STAGE environment, as can be seen in the images below:

Checking the versions and traffic of our environments on Google App Engine:

When we accept a merge request from the branch rc in the master we will activate our Production trigger that will carry out the entire process for our PROD environment, as can be seen in the images below:

Checking the versions and traffic of our environments on Google App Engine:

Conclusion

Google Cloud Build is a very versatile tool and will allow you to create pipelines that fit your environments. If your workflow is quite distinct by environment, the best approach is to create a configuration file for each environment.

Douglas Augusto

Written by

Cloud & Software Engineer | Machine Learning Enthusiast | https://douglasaugus.to/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade