[MUSIC PLAYING]
MARTIN OMANDER: Hey, Mia.
In your previous jobs before Google,
you worked with CI/CD right?
MIA VILLASENOR: Yeah.
Over the last five years, I've built CI/CD pipelines
with Jenkins, Spinnaker, Tecton, and other tools.
MARTIN OMANDER: Very good.
When I read online articles about CI/CD,
I see many practices that seem like good ideas,
but I'm not 100% sure what they all mean.
And I don't know how to apply them
all to my serverless projects on Google Cloud.
Could we review them together?
MIA VILLASENOR: Totally.
Let's do it.
[MUSIC PLAYING]
MARTIN OMANDER: All right.
Let's first talk about the CI in CI/CD.
It stands for Continuous Integration, I believe.
And it sounds like a good idea to integrate your software
early and often.
But what does it actually mean?
MIA VILLASENOR: So CI means that whenever developers commit code
to source control, an automatic build
is triggered, followed by automatic test suites.
So for example, a developer might accidentally
check in code that prevents the software from being built.
And if that happens, we want to know right away.
That way, we can fix it quickly and avoid
wasting other developers' time with an untestable system.
MARTIN OMANDER: And you mentioned automatic test
suites?
MIA VILLASENOR: Yeah.
So if the automatic build worked,
we want automatic tests to run as well.
Usually that means running all the unit tests and maybe
some integration tests as well.
MARTIN OMANDER: And the build and test
should be automated to save developers' time.
Is that the idea?
MIA VILLASENOR: Yeah.
But also to ensure that they're done the same way every time.
Automation means that you get reliably correct builds.
And it's a good first step towards a more secure software
supply chain.
You can also read more about secure software supply chain
best practices on the website slsa.dev.
That's S-L-S-A dot dev.
MARTIN OMANDER: Sounds good.
I have a serverless application hosted on Google Cloud Run.
How do I set up continuous integration for it?
MIA VILLASENOR: So continuous integration really just means
that we need a place to execute builds and tests as part
of a workflow.
But setting that up manually can be kind of a pain.
Luckily, Cloud Build can execute your builds for you.
Cloud Build lets you define a set
of build steps in a YAML file and configure
them to run when an event like a pull request occurs.
MARTIN OMANDER: Oh, OK.
Great.
It sounds like Cloud Build would fit my needs.
Where should I start?
MIA VILLASENOR: So here's a tutorial
that will guide you through that process.
It gives a nice overview.
Also, take a look at this repo.
It shows how to add a unit test step to the Cloud Build
configuration file.
It also includes some examples for common programming
languages.
MARTIN OMANDER: All right.
I think I understand continuous integration enough to start
using it in my project.
But what about CD?
Some people say it means Continuous Delivery and others
say it means Continuous Deployment.
[LAUGHS] What's up with that, Mia?
MIA VILLASENOR: So it can mean either one.
Continuous delivery means that automatic builds are running
and that the result automatically
gets deployed to an internal test environment.
Anybody can do this.
Continuous deployment, on the other hand,
means that once code is checked into a certain branch
or some other trigger, the software is automatically
built, tested, and then, if those tests pass,
deployed to production where end users can see it.
MARTIN OMANDER: Oh!
Deployed to production?
Continuous deployment sounds risky.
MIA VILLASENOR: It can be.
But if you have a really good test suite and a strong testing
culture in your organization, it can really
improve change velocity.
But I think it's fair to say that most teams don't
use continuous deployment.
MARTIN OMANDER: Ah.
I've heard that continuous integration is a must
before you can aspire to continuous delivery
or continuous deployment?
MIA VILLASENOR: So continuous deployment
without continuous integration is incredibly risky.
It's really important that you build
confidence in your pipeline before using it
for continuous deployment.
MARTIN OMANDER: All right.
So how do I set up continuous delivery or deployment
for my Cloud Run project?
MIA VILLASENOR: So the first thing you want to do
is to make sure you're using a separate Google Cloud
project for your test environment
and for your production environment.
And if you want continuous delivery,
you can add a deployment step in your Cloud Build configuration
file so that your built software gets deployed to your test
environment.
MARTIN OMANDER: And if I want continuous deployment,
I make that last step deploy to production instead?
MIA VILLASENOR: Exactly.
But you probably don't want all commits made by developers
to make it to production right away.
You can set up a build trigger to only kick off
your Cloud Build config when code
is committed to a particular branch in source control.
Your main branch might represent production.
And you can merge code into that branch for deployments
to production.
MARTIN OMANDER: Ah.
Thank you.
That gives me a way to get started with CD.
My next question is about Canary releases.
The concept is that you deploy a new version of your software
to only some of your users to try it out before you expose it
to everybody.
I really like the idea.
MIA VILLASENOR: Yeah, me too.
So let's say you have a new version of the web application
that has a bug in it that was not
caught by your automated tests.
Let's also say that you only rolled out that new version
to 5% of your users.
Hopefully at the slightly larger 5% scale
you'll hear from a user about the unexpected behavior
or you might notice errors in your logs.
MARTIN OMANDER: And because I did a 5% Canary release,
only 5% of my users ran into the bug?
If I'd done a regular non-Canary release, 100% of my users
would have been affected by the bug, right?
MIA VILLASENOR: That's exactly right.
Canary releases get their name from an old method of testing
mines for carbon monoxide.
You can't smell or see that gas, but it can be deadly to miners.
A Scottish doctor figured out that birds
are more sensitive to carbon monoxide than people.
So he would bring a caged bird into the mine with him.
MARTIN OMANDER: Oh.
And if that bird stopped chirping
it was time to clear out?
[LAUGHS]
MIA VILLASENOR: That's right.
But it's really important that you
have a way of noticing if that happens.
A Canary release should not hide errors, but be loud about them.
For example, it could display an error message
to users, or page a site reliability engineer,
or even write errors to your log.
MARTIN OMANDER: And how long should I
run this Canary release?
MIA VILLASENOR: That's a really important thing to consider,
and you want to give the Canary release enough time so
that hard-to-find errors reveal themselves.
This depends on the application.
But it should be much longer than a typical release stub.
The thing to keep in mind is that the fewer users
that your application is exposed to,
the longer it will take for issues to surface.
MARTIN OMANDER: All right.
How do I set up Canary releases for my Cloud Run service?
MIA VILLASENOR: So Cloud Run has built-in traffic splitting,
which makes this really easy.
You can set the percentage of traffic
going to each revision of your service in the Cloud Console.
You can also do this with the gcloud command line client.
MARTIN OMANDER: I've also heard about revision-specific URLs?
MIA VILLASENOR: Yeah.
If you want to be extra careful, you
can start by sending 0% of your production traffic
to your new version.
You can give your new version a special URL so that only users
who enter that address get the new version.
Then you can let your developers, or QA team,
or even early access customers test it out
before you open it up to all of your production users.
MARTIN OMANDER: Very good.
Can't wait to start using this for my applications.
You know, Mia, so far I've been deploying my apps
by entering gcloud run deploy manually from the command line.
And I haven't used any of these techniques we talked about.
MIA VILLASENOR: And there's nothing wrong with that.
[LAUGHS] But when your users start demanding more
from your applications, a robust CI/CD pipeline
is going to help you maintain your quality.
MARTIN OMANDER: Thank you for these tips, Mia.
And thank you, everyone, for watching.
You will find links to the repos and tools we talked about
in the show notes.
If you have questions for Mia 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]