Introduction

If you are working on any project there comes a time where you want to release it to (beta) users. Most likely you choose one of the big three cloud computing providers (AWS, GCP or Azure) to host your next SaaS solution or whatever you are working on. You complete all steps of some youtube/dev.to/medium tutorials (a nice one for Google Cloud Run) and, some debugging with Stackoverflow sprinkled in, your app is available to users.

Let's say you are lucky. Many users find your program interesting and start to use it. You receive the first inquiries: "I love your solution but this buttons needs to be red" - "This is awesome but please translate the program to German so that my grandma can use it". So you go ahead and implement all feature requests. Each time you are done with one of them, you update your service in the cloud. You use the same tutorials, try to remember commands and make some mistakes. This is frustrating and it takes up time you can spend coding.

This is why Continuous Integration / Continuous Deployment was invented. Continuous as in "automated" as in "you no longer need to do it by hand and have typos in your commands". If you are using GCP as your cloud provider Cloud Build offers an easy solution to set up your CI/CD pipeline.

This tutorial assumes you have already set up your GCP environment. Also it assumes you have your code under version control in a git repository.

The Basics

• Cloud Build can connect to your git repo, if it is hosted on BitBucket or GitHub.
• It can trigger your pipeline based on changes (e.g. commits) in the connected repo.
• There are 120 free minutes of build time per day. After that you are charged by the minute.

Connecting your repository

Before you do anything with Cloud Build you need to connect your git repo. In the console of GCP head over to Cloud Build. After activating the service, you need to click "connect repository".

First you choose where your repo is hosted (currently BitBucket and GitHub are available). Choose your provider and hit "continue".

Cloud Build will try to authenticate with the service. So maybe you need to enter your credentials. In the third step you can choose one of the repos you are hosting with the chosen service. In the end you are asked if you want to create your first trigger. This step will be explained in the next section.

Setting up your first trigger

A trigger in cloud build consists of three things:

• a repository where the code is hosted. This is the "Source".
• a condition e.g. "every time there is a push to the develop branch". Cloud Build calls this "Event"
• a list of instructions in a yaml file. They are executed if the condition is met.

Enough talking, let's get started! In order to create your first trigger you should click the "CREATE A TRIGGER" button in the last step of connecting your repository.

First you select a name for your trigger.

Choose "Push to a branch", then choose the source repo and branch (I chose "develop").

Define your actions

Now comes the most important step. You have to add the "intelligence" of your trigger by editing the yaml file that describes the steps that need to be taken. In the configuration section of the trigger, choose "inline" as the location of the yaml file and click the "open editor" button that appears.

There you can edit the yaml file that defines the "actions" of the build pipeline. The default looks like the following lines:

steps:
  - name: ubuntu
    args:
      - echo
      - hello world

This is a very easy example. In Cloud Build every step of a yaml file is run in a seperate docker container. With the name: option we tell Cloud Build what docker image it should use. This example uses ubuntu. With the args we provide a command that is executed in the container once it was started. In this case echo "hello world".

Go ahead and change the file to this:

steps:
  - name: ubuntu
    args:
      - echo
      - hello world
  - name: ubuntu
    args:
      - echo
      - the second hello world 

Hit "done" and create the trigger. The trigger will be listed in Cloud Build's list of active triggers.

Testing your trigger

Usually your trigger will be executed when you trigger the event, for example by pushing to the develop branch. There is a way to trigger a build manually by clicking "run" on the right side of the trigger list. Do that and head over to the "history" section of cloud build. In this section you can find the invocations (e.g. executions) of all triggers.

If you click on the top entry of the list, you will see the output of the build. It will look something like this:

...
BUILD
Starting Step #0
Step #0: Pulling image: ubuntu
Step #0: Using default tag: latest
Step #0: latest: Pulling from library/ubuntu
Step #0: Digest: sha256:b5a61709a9a44284d88fb12e5c48db0409cfad5b69d4ff8224077c57302df9cf
Step #0: Status: Downloaded newer image for ubuntu:latest
Step #0: docker.io/library/ubuntu:latest
Step #0: hello world
Finished Step #0
Starting Step #1
Step #1: Already have image: ubuntu
Step #1: the second hello world
Finished Step #1
PUSH
DONE

You can see that both steps were executed. In the last line with Step #0 and Step #1 you can find the output of the echo commands that you defined in your yaml file.

What to do next

Congrats, you have successfully set up your first (simple) Cloud Run trigger! Below you can find some next steps you can take to make your own code deploy with a pipeline.

• Head over to this tutorial to learn how to set up a Cloud Build trigger for a React app.
• Learn about debugging, concurrency and other performance improvements for Cloud Build (coming soon).
• Use Cloud Build for your GitOps flow with terraform (tutorial coming soon).