ANTHONY BUSHONG: So Steph, why are we in your garage?
STEPHANIE WONG: I thought you said
we were building stuff, right?
ANTHONY BUSHONG: No, I was talking
about automating builds with Google Cloud Build, not that.
STEPHANIE WONG: Oh, Google Cloud Build.
You mean the one that lets you orchestrate
build steps that run as container images.
ANTHONY BUSHONG: Exactly.
And this means that each build step
can do anything a container can, such as executing
a script or a binary.
So let's look at how you can use Cloud Build today
to automate a simple Terraform workflow in a way
that you might see a small team run infrastructure as code.
Now, as a developer, I may want to edit our team's Terraform
code on a dev branch to create a new node pool to accommodate
a more CPU-intensive workload than our Kubernetes Engine
cluster currently allows for.
I can do this by updating our Terraform code
with a new node pool resource.
This node pool will be called Olympic Pool.
And we can commit those changes to a development branch.
This way we can actually use Cloud Build
to create an approval workflow as opposed to me actually
applying changes to our infrastructure from Terraform
locally.
We'll do this using Cloud Build's notion
of build triggers.
You'll see that my first build trigger
is set to kick off a build off of any push
to a non-master branch.
Because I changed the Terraform configuration
on the dev branch, our build has already been triggered.
So when we actually dive into the build,
you'll see that it's comprised of two distinct build steps,
each running in a container with the Terraform binary.
The first build step will initialize Terraform,
and the second will show us what resources
will be created with the updated code
without actually creating those resources.
In this case, it will be one new node pool.
And we can actually see this in the logs from those
build steps in the Cloud Build UI.
STEPHANIE WONG: So if we wanted to, we could run more
build steps to, let's say, run test suites,
or actually apply this to a staging environment.
ANTHONY BUSHONG: Precisely.
That's the idea.
This is a very simple illustration.
Build steps are actually customizable to the point where
you should use them to represent the workflow that
fits your culture.
So the two use cases that you just mentioned,
they're definitely patterns that you can adopt.
STEPHANIE WONG: So in this demo, how will these changes
be realized in production?
ANTHONY BUSHONG: With another build trigger, of course.
So once I've actually pushed those changes to the dev
branch, we're actually going to create a pull request
against the master branch.
This is what will actually allow for our infrastructure
to be realized in production.
You'll see here that a new node pool resource is now
going to be created.
So we'll create that pull request.
Typically, this introduces a level of approval
where we can actually have someone
with the proper permissions review these changes
and give the approval to actually merge the pull
request.
So once we actually merge the pull request into the master
branch, we will actually be invoking
our second build trigger.
This second build trigger is actually
setup to run on any change to the master branch
as defined here.
And you'll see that we actually have a different Cloud Build
YAML file for this build trigger.
In this case, what we're doing here
is we're actually adding a third build
step using the same Terraform container
image that we had previously.
In this case, we'll now be able to apply
those actual infrastructure changes with Terraform.
So because we've actually merged dev into master,
our build has been triggered to actually run
with those three build steps.
So you'll see here that we still have the Terraform container
image running in it, plan, and now we have the third step that
says apply, and auto approve.
So it happens that's because we actually
were able to merge something into master,
this build was then triggered to actually apply those changes,
as opposed to the previous build,
which just ran a plan so that we could introspect
what we wanted to create.
So because that build has actually run,
let's look in our GKE cluster.
And we'll see here that the node pool called Olympic Pool is
actually being created.
Google Cloud Build can easily make your workflow automated
and help you easily enable continuous building, testing,
and deployment.
STEPHANIE WONG: Don't forget to like, comment,
and subscribe for more great Google Cloud Platform content.