Google Cloud Build in Action

Building a CI/CD pipeline is essential for lean delivery. In my career as a full-stack dev, I’ve built and used many pipelines using different technologies and tools. One I hadn’t yet tried out was Google’s Cloud Build, so naturally, I took it for a ride.

Why Google’s Cloud Build?

Why not? We had been using GCP with our clients to deploy and manage their infrastructure and services for quite some time. When we started building out our own product, we were wondering if hooking everything up would be made easier if we went Google all the way. That meant using Cloud Source Repository, Cloud Build, Cloud Run, Cloud Functions and all the usual suspects to create our infrastructure and deploy, monitor and manage our services.

The Things we Loved

Easy to Use

When I first started playing around with it, it was criminally easy. All you had to do was include a cloudbuild.yaml file with any repository and it would initialise a pipeline for you based on that file like that *snaps fingers*.

Scalable

Cloud Build provides a scalable infrastructure. This allowed us to allocate more resources to speed up our builds quickly and efficiently.

Seamlessly Integrates with the GCP space

Testing, building, creating docker images and pushing those images into Container Registry was effortlessly beautiful. Deploying code across projects eventually worked seamlessly after some permission wrangling. It was my first foray into Cloud Build so there was a lot of learning as I went along.

Cost-Effective

Similar to other GCP offerings, you pay for what you use. We don’t need to pay inflated prices designed for big organisations. A fair pricing model that has worked well for us especially given that we’re still a small team working on our products.

Secure

Cloud Build integrates with Google Cloud Identity and Access Management (IAM), allowing you to define fine-grained access controls and manage user permissions. Relevant service accounts were granted the permissions they required to perform the task they were responsible for. No more, no less.

Repeatable

Cloud Build ensures build isolation by running each build in a dedicated and ephemeral environment. This isolation prevents cross-contamination between builds and eliminates any mishmash that could result from lingering states across builds.

The Bumps Along the Way

Learning Curve

I suppose this is true with anything new you try and it was certainly true in this situation. GCP products are generally well-documented with example code snippets and tutorials. Although in action, there were some hairy moments where documentation didn’t quite have enough information on how to go about doing certain things and whether or not specific functionalities were possible. It wasn’t anything that a little trial and error couldn’t fix.

Limited Flexibility

This point is by far my biggest gripe with Cloud Build. We only have 3 environments for our product: dev, staging and prod. As much as we are big proponents of Continuous Deployment, we are more of a Continuous Delivery kind of shop. Staging and prod need to stay stable as we do quite a bit of experimentation in our dev environment. To that end, while the initial trigger to get the build to dev is automatically triggered when you push code, we wanted to have a manual trigger to promote a build from dev to staging and ultimately to prod. This isn’t possible with Cloud Build.

I did a lot of reading into this and as far as I can tell, as of the moment of writing, this feature isn’t available with Cloud Build. If anyone has figured this out then please do reach out and let us know where we went wrong.

We instead implemented a work-around where we’ve created a separate pipeline to deploy to each of the environments. It takes in a commit hash to determine which docker image to deploy, therefore maintaining the ethos behind a build pipeline but making the pipeline more conceptual than concrete.

Vendor Lock-In

This wasn’t really a problem for us as we’d made a conscious decision to use everything Google. It is still worth mentioning that while implementing, we noticed that had we been using other cloud providers for the remainder of our offering, things would have gotten a tad complicated. Something to bear in mind.

Conclusion

This isn’t an exhaustive analysis of Cloud Build. Only what we've encountered using it. Cloud Build simplified a whole host of things but complicated others. It was certainly enjoyable using it especially when used alongside the rest of GCP’s ecosystem.

If you have any thoughts on what was mentioned in this blog or have figured out how to pause a Cloud Build pipeline then get in touch with us at hello@deliberate.uk.