Cloud Build- Google’s new weapon in CI/CD arsenal

CI/CD is one of THE MOST IMPORTANT part of any Software Development Life Cycle (SDLC) and with the right set of tools, it can tremendously increase both the productivity of your team as well as the quality of your product.

Now, as soon as you think of CI/CD, a tool that instantly comes to your mind is Jenkins. You quickly spin up an instance, install a Jenkins server, configure a pipeline and viola — you have your CI/CD process setup.

Is it really that easy and fast as it sounds? The answer is sometimes yes and sometimes no.

Jenkins is a great open source tool. If you’re looking for a CI tool with unlimited customization options, then Jenkins is the best choice for you.

However, at the same time, being highly configurable is one major drawback of Jenkins as there is no out-of-the-box setup. So, sometimes this results in two-three hours to even days of work, to get everything configured in the system.

Wait!! Aren’t there quite some CIaaS (Continuous Integration as a Service) tools out in the market? — CircleCI, Travis CI, et al.

These are cloud based tools directly available for your use. No server setup, no software installation. Just define your pipeline and start using it, kind of plug and play.

They make setting up CI/CD process faster but they have average to high pricing as well and that too mostly with a fixed static monthly cost irrespective of your usage.

In this war of easy & fast but expensive commercial CIaaS tools vs free & open source but sometimes slow and complex tools, a new competitor has launched its weapon — Google’s Cloud Build.

In this year’s Cloud Next event, Google announced Cloud Build, its new CI/CD framework.

In Google’s exact words, and I quote, — Cloud Build is the company’s “fully-managed Continuous Integration/Continuous Delivery (CI/CD) platform that lets you build, test, and deploy software quickly, at scale.”

Cloud Build is CIaaS that executes your builds in docker containers on Google Cloud Platform. It can import source code from various repositories like GitHub, Bitbucket, Google Cloud Source repository and even Google’s Cloud Storage.

Using Cloud Build is pretty simple.

1. You need to create a build configuration file which contains a set of instructions about the tasks to be performed (similar to Jenkinsfile in case of Jenkins).
   You can perform following tasks like fetching dependencies, executing unit tests, integration tests, creating artifacts as well as performing static analysis.
2. Configure cloud build trigger, which will invoke the cloud build once the condition is met.

In order to see how Cloud Build works, let’s get a bit deeper.

As I mentioned above, one of the key component of Cloud Build is the build config file which looks like this in YAML format:

Note: This is a simplified version taken for quick understanding and doesn’t include all available fields. Build Configuration Overview explains the entire file template.

So, if you look at the above template, a build config file basically contains set of one or more steps where each step specifies an action to be performed by Cloud Build. For each step, Cloud Build will spin off a docker container and execute the step inside it. Let us have a look at some of the important fields:

1. Name (Builder): If we further drill down into a step, each step has name, a field that specifies a cloud builder which is a container image with common languages and tools installed within them. These builders are used to execute the tasks provided in the build steps. Following categories of cloud builders are supported:

• Cloud Build has some predefined set of supported builders. A few of them are:

• There are a few Cloud Build developer community-contributed builders too. A few examples are:

• Cloud Build allows you to use any publicly available container image in a build step. For example any image from Docker Hub or any other accessible container image repository.

• You can also write your own custom builder.

1. Args: The second part of build config file is args. This field takes a list of arguments which are passed to the builder specified in the name field which in-turn can be passed to the tool that is running inside the builder. For example, if you are using maven builder, you can provide install arguments to it.

1. Entrypoint: If you don’t want to use the default entrypoint of the builder, you can define a custom entrypoint using this field.
2. Timeout: This field can be used to set a time limit for the step execution. By default, there is no time limit and the step will run till its execution is completed.

Ok. Enough of the theoretical talk. Let’s get some hands-on experience.

Demo

We have a typical “Hello World” node.js app built for Google App Engine here.

This app can be built using npm install and deployed to App Engine using gcloud app deploy –project $PROJECT_ID –version $VERSION_ID

Now, let’s see how we can automate the CI/CD cycle for this app using Cloud Build:

Step 1: Login to your account on google cloud console.
If you don’t have an account on GCP, you can take advantage of the free trial.

Step 2: Create a project if you don’t already have one.

Step 3: Enable following APIs in your project:

1. App Engine API
2. Cloud Build API

Step 4: Goto IAM page, search for <project-id>@cloudbuild.gserviceaccount.com, edit it and add App Engine Admin role.

Step 5: Clone the repository from here.

Step 6: Add cloudbuild.yaml file. (I have already added this config file in the repo).

Step 7: Add trigger for the build from here.

1. Click on Add trigger.
2. Select relevant source (in our case, it will be GitHub). Click on Continue.

1. Authenticate your git account.
2. Select the relevant repo, check “I consent to Google collecting and storing….” and click on continue.

1. Under Trigger settings, set Name, select Branch as trigger type, set Branch (regex) to master, set build configuration to cloudbuild.yaml and click on Create trigger.

Step 8: Trigger the build manually using this command:

You can check the history and logs of the build process here.

Step 9: Launch the app on the web: https://hello-dot-{project-id}.appspot.com/

Now, let’s test the final part and see the pipeline working end to end.

Step 10: Make changes in app.js. Change Hello, world! to Hello, world! Welcome to Google Cloud Build!! Commit & push your changes to the master branch.

Step 11: Check the history page of Cloud Build here.

Step 12: Refresh the application and check the response — https://hello-dot-{project-id}.appspot.com/
Note: Due to browser caching, you might have to do a hard refresh (Ctrl + F5).

That’s it!!! You have successfully configured the CI/CD pipeline using Cloud Build.

Cloud Build Pricing

Now that you have hands on experience on using Cloud Build, the other crucial aspect of Cloud Build is its pricing.

We now know that it is pretty easy to use but is it going to be as expensive as other CIaaS tools? Well, Google has been a strong competitor (and usually the cheapest) one when it comes to pricing.

Where most of the other CIaaS tools have a fixed monthly cost, Cloud Build charges you per minute (build-minute: time for which the build is processed)