MARTIN OMANDER: Hi, Alvaro.
I know you focus on DevOps and site reliability engineering.
So I have a question for you.
If deploying code to serverless, like Cloud Run, is so simple,
do I even need a CI/CD pipeline?
ALVARO HUANCA: Hi, Martin.
That's a good question.
Let's find it out.
[MUSIC PLAYING]
When you start a new project, you
have control for all over the project.
However, when this project starts to grow,
it becomes more complex.
For example, you might start with a monolithic application
and then go to a microservice architecture.
MARTIN OMANDER: That's true.
Not only can the system grow, but also the team.
ALVARO HUANCA: Exactly.
More team members means more changes to take care of.
A CI/CD pipeline will help you to manage all that complexity
and minimize that changes will block anything
on your application.
That's why you need a CI/CD pipeline.
MARTIN OMANDER: I see.
And what would the CI/CD pipeline actually do, Alvaro?
ALVARO HUANCA: OK.
From the moment we commit the codes to the repository
until these changes appear to the final user,
there are at least some steps that should be done.
For example, build stored artifacts and deploy it.
MARTIN OMANDER: That makes sense.
Can we set up a CI/CD pipeline here to show all these steps?
ALVARO HUANCA: Sure.
I had this web app sample from the Cloud Code samples.
It's written in Node.js, and I already pushed it
to my own GitHub repository.
So we can use it for the pipeline CI/CD.
MARTIN OMANDER: Great.
And you said Node.js, Alvaro.
What if I want to use another programming language?
ALVARO HUANCA: There are more samples
in different languages on the Cloud Code
repository on GitHub.
You can go and find your preferred language.
MARTIN OMANDER: All right.
So we have the code.
It's checked out into source control.
What's next?
ALVARO HUANCA: OK.
We have one repository for the code.
And now we need another kind of repository,
a repository for artifacts.
MARTIN OMANDER: OK.
And what kind of artifacts?
What does it mean?
ALVARO HUANCA: An artifact could be a package, a library,
or, in our case, a container image, for example.
In Google Cloud, we have Artifact Registry
to store container images.
Let me show you how can we create one.
In the Artifact Registry section,
click on the Plus button to create a new repository.
Let's use Node.js Sample for the name,
and South America is one for the region.
That region is located in Sao Paulo, Brazil,
which is where I am.
Then Create and save the name because we're
going to use it later.
MARTIN OMANDER: Perfect.
We have one repository for the code in GitHub
and one repository for the container
images in Google Cloud.
What's next?
ALVARO HUANCA: OK.
With these repositories, now we can use Cloud Build.
Cloud Build is a serverless platform
that allows developers to create simple but powerful
CI/CD pipelines.
The first thing to do is connect the GitHub repository
to Cloud Build.
MARTIN OMANDER: Oh, I remember.
I did that in an earlier video I shot with Aaron.
I'll link to that video in the description below.
I will do those steps again with the GitHub repo you just
showed me, Alvaro.
In the Cloud Build section, I click on Connect Repository.
Then I select GitHub as a source,
and Cloud Build will check our GitHub credentials.
After the authentication, I will select the repository
I want to connect to--
in this case, Hello-Cloud-Run.
Perfect.
The repo is connected.
ALVARO HUANCA: Good job.
Now I will create a trigger.
The trigger will make us start the CI/CD pipeline.
So in the Console, click on Create a Trigger.
Let's put Hello-Cloud-Run-Pipeline
for the name and then choose again South America East one
because it's my region.
For event, I choose Push to a Branch to trigger the pipeline.
In which repo?
The one we just connected.
And let's use the branch Main for the pipeline.
MARTIN OMANDER: So to recap, we have put the code in Repo
on GitHub.
Then we connected that repo with Cloud Build.
And now we're telling Cloud Build
to trigger the CI/CD pipeline every time we push
to the main branch on GitHub.
Back to you, Alvaro.
ALVARO HUANCA: Now it's time to tell Cloud Build what
to do during the pipeline.
MARTIN OMANDER: And this is where
we define what happens in the build, store, and deploy steps
that you mentioned before, right?
ALVARO HUANCA: That's right.
In the Configuration part, I choose
Cloud Build Configuration file.
This file will be located inside the repo as cloudbuild.yaml.
This is a special file.
As you mentioned, here we describe every step
we want to do in the pipeline.
At the end, I'm just going to click on Create.
MARTIN OMANDER: So now you have to create
this file in the repo, right?
ALVARO HUANCA: Yeah.
I already cloned the repo on my computer,
so we can create the file right now.
In the cloudbuild.yaml, I'm going
to define the Build step first.
MARTIN OMANDER: And that looks like Docker build,
just like I would run it on my local machine.
But the syntax is a little different.
ALVARO HUANCA: Actually, it's the same.
It's just broken in different lines.
We are telling Cloud Build to run Docker
Build with some arguments.
By the way, the key argument, which
means the tag of the container, it's pretty long.
This is because part of the tag has
the path to the Artifact Registry Repository
we just created before.
MARTIN OMANDER: And why do we do that?
ALVARO HUANCA: Well, all the steps
will run in a trusted environment inside Cloud Build.
So it's harder for a bad actor to inject malicious code
into the app while building.
When Code Build finishes its work,
this environment will disappear, so the container inside
will disappear, too.
That's why we need a repository for our images.
This long tag, in the case, is where we
are going to store the image.
MARTIN OMANDER: Got it.
So that was the Build step.
The next step is store, right?
But didn't we store the container already?
ALVARO HUANCA: Not yet.
The container image is still inside the Cloud Build
environment.
We need to store it in a more permanent place.
We will use the Artifact Registry Repository for that.
So in the cloudbuild.yaml file, we have to add the store step.
This time we are using the Docker Push command.
MARTIN OMANDER: We are almost done.
It looks like the final step in your list is deploy.
And for that, I have a great candidate.
We are building container images,
and Cloud Run is a great way to run those in the cloud.
ALVARO HUANCA: That's correct.
I'm going to deploy the application to Cloud Run.
So we add the gcloud command to deploy
to Cloud Run in the Cloud Build file
with the same fields we use in the consult.
MARTIN OMANDER: All right.
Now that we are all set, we can commit and push the code
to the repo.
And if everything is right, the pipeline should start working.
ALVARO HUANCA: Yep, you're right.
Let me commit the code and push it to the branch main,
and there we go.
So let's go to the Cloud Build Console
to see what's happening Yeah, it's working,
and we can see the logs.
Here goes the building logs, the storing logs,
and the deploy logs.
It's done.
So if we go to the link of the Cloud Run service,
we can check the application, and let's go.
It works.
So "bellezza," which means "awesome" in Portuguese.
MARTIN OMANDER: "Bellezza," indeed.
And if we make any change in the code,
we only need to commit and push the code again to GitHub,
and Cloud Build will do the rest.
But one quick question-- is there
a way to make this new release show up for only some
of our users, like a Canary test release?
ALVARO HUANCA: Yep.
Cloud Run has this feature out of the box.
Let me show you how to add this step into our pipelines.
On the deploy step, we can add the --no-traffic flag,
so no traffic will be sent to this new list.
Then we can add one more step.
Let's call it Canary.
In this step, we add the update service command
to split the traffic to the latest revision.
50% of the traffic should work for testing purposes.
In a real Canary release, we might use 5% state.
MARTIN OMANDER: I like that.
Can you change the main title on the site
so it'll be easier to see the difference between the new
and the old version?
ALVARO HUANCA: Sure.
Good idea.
In the Index file, we can add Hello from Brazil.
Let's do it and then Commit and Push.
The pipeline is started as expected.
And in the Cloud Run Console, we can see this new Canary
step and all these logs.
All right.
It's completed.
Let me check the app.
Let's refresh many times.
Sometimes, we see Hello from Brazil,
which is the Canary release, and sometimes Hello
from Cloud Run, which is the old version.
MARTIN OMANDER: Thank you for showing us
how this is done, Alvaro.
I've been typing gcloud commands manually in the terminal
to deploy my Cloud Run apps.
I think I may go and add CI/CD pipelines for them now.
ALVARO HUANCA: I'm glad to hear that, Martin.
When you automate building and deployment steps
with CI/CD pipeline, you will free up time
so you can focus more on new features.
MARTIN OMANDER: Yes.
I want to spend less time with the infrastructure and more
time adding features my users actually asked for.
Thank you, everyone, for watching.
You will find links to the repos and tools we talked about
in the show notes.
If you have any questions for Alvaro or me
or suggestions for future serverless topics,
please enter them in the comments below.
We read every single comment.
Until next time.
[MUSIC PLAYING]