Working with Multiple Environments in Google Cloud Build

Large projects require the use of several environments, such as DEV, QA, UAT, STAGE, and PROD. This Snippets article details an approach to using 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. Here's how we need to configure each environment:

PROD: in the production environment, we must publish in the prod version to guarantee the promotion of the version and to ensure that all traffic is redirected to the environment.

STAGE: in the stage environment, we must publish in the stage version. Configure it so that the version does not promote and only 20% of traffic is migrated to this environment.

Solution

We will create two triggers, one for each environment. For SCM issues, I've associated each environment with a branch. These are, respectively, PROD: master and STAGE: rc. We will use the substitutions feature to configure variable values for each environment. These are 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 processes for our STAGE environment, as shown below:

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

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:

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

Conclusion

Google Cloud Build is a very versatile tool that allows 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.

Want to know more how Google Cloud Build can be a very versatile tool that allows you to create pipelines works?