- Let's say you find a small security issue with a kubelet
and you fix it.
You've got your change ready to go.
What happens when you type get push,
and hit enter?
Actually, nothing happens.
You have to click on a PR first.
(gentle electronic music)
CICD. What does it mean?
- I think...
- Everyone makes up their own acronym.
- CICD stands for
continuous integration continuous deployment,
or some might say continuous delivery.
- But for the point of this video we'll scope it as
continuous integration continuous deployment.
CICD is important to any modern software project.
It's what enables the addition of new code.
Code is coming from hundreds of contributors,
from all over the world,
from hundreds of repositories into a single project.
It would be impossible to add any new features
without CICD system.
- When a developer or just anybody in the ecosystem
notices that something isn't working quite right,
or they'd like to change something,
they submit a pull request to propose that change.
- [Urvashi] What you first have to do
is fork the upstream project,
that creates your local repository
and your local GitHub.
You create a separate branch
because you want to separate out each task you're doing.
You don't want to do everything in one branch,
that will just make everything more complex basically.
So now you have everything the upstream has,
and now you can make your own changes.
You want to update it,
fix bugs, add features,
whatever you want to do.
- [Sally] And then I'll push that branch
up to my GitHub repo.
From there I can submit a pull request.
So when you submit a pull request
it's your branch against an upstream branch.
- [Urvashi] You have to go on GitHub
where it registers those changes
and you actually have to hit a button that says
"open a pull request".
So first thing you want to do
as a developer who's pushed code to a repository
is to make sure all your tests are running.
So initially you have some basic tests that run,
like unit test,
validation test,
formatting test.
So basically you have like 15 tests running,
and all of them have to be green before
we go ahead and merge the PR.
- It's a very lucky day
if all of the tests pass on the first go.
That usually never happens.
- Basically reviewers will now look at your code.
If they see tests are failing,
that means something is definitely wrong in there.
- [Sally] So often you'll get a red x next to a test,
and that tells you your test has failed.
That leads you to digging into the logs,
and figuring out how your change broke the cluster.
I might know that a test is flaky.
- A flake is when a test doesn't do the same thing
every time you run it.
There's no way to guarantee that a test
is always going to do the same thing.
So you might look at a test that fails once a week,
and that's a flake.
- [Sally] Oftentimes what you think is a flake,
is a real issue,
and something can merge
and break everybody's environment.
Because once a pull request is merged,
that newer environment becomes the test environment
for everybody else.
- [Steve] Once the tests are passing,
on the GitHub you'll see that everything is green
and that's when they start looking
for a code owner to actually approve their changes,
and make sure that the changes they're proposing,
even if they're written well,
are actually moving the project
in the direction that the owners want.
- You want to document your PRs pretty well.
This just makes it easier
for the reviewers who are looking at it
to actually understand what you're trying to add in.
- And if they're not, your pull request won't get merged.
- IncuBrand is when a pull request is being reviewed,
oftentimes the reviewers are looking to see
if the code is of good quality
and whether it's written correctly.
- But not everyone is going to always be happy
with your code.
People do things in different ways, right?
So sometimes people have tiny nits,
where like "oh if you do this and this form instead
or that form" and that is up to you,
whether you want to incorporate it
or you want to stand your ground.
- Write why you made this pull request,
what broke,
how you fixed it,
that just helps the community grow and learn.
- And if we're happy with it,
we usually like to have 2 reviewers at least
review it and give a "look good to me" on the PR.
- So you've submitted your PR,
it got bounced back to you,
you fixed it and you've submitted it again,
and it's passed all of its tests.
Now what happens?
- Once all the tests are green,
it goes through an automatic tide merge kind of process.
So you tell the bot that "I'm happy"
and "let's merge this."
- Well wait,
- You really don't want a human pushing the merge button.
- So you don't want to do that manually,
it does that whole automatic process.
- [Scott] So let's say your PR has finally been accepted,
now it's time to enter Integration Hell.
- [Sally] A lot of developers
will talk about Integration Hell.
If your pull request doesn't get merged quickly
after you have your approvals,
you could run into merge conflicts.
- So GitHub does it,
has a very nice interface that tells you
that these files are conflicting.
- [Sally] Somebody else created a change and it merged,
and it is in the same file that you were working.
That would mean you would have to go
back to your local environment.
- [Urvashi] And you pull in the changes
from the upstream project.
- [Sally] Fix any conflicts,
and that happens all the time.
You need to re-push your pull request,
and all of the tests need to start over.
- It sort of like "rewinds"
and puts all the new stuff
and thenputs your comment on top of that.
So even if you started
before all this new stuff that got in,
it pushes that before any of yours goes on top.
- It's essential to have a CI system managing that.
- It is a huge complex infrastructure
and a lot goes into maintaining this.
Integration Hell to me is when your CICD goes down.
- Do you know what's worse than CICD being down?
GitHub being down.
Your PR has made it through the rough waters
and finally arrived at the tranquil tide pool.
- Once it's in the tide pool and I know it's merged,
I'm very happy.
- [Steve] Tide looks at the ocean of available pull requests
and it scoops passing pull requests into little pools
to notice when they're passing all their tests
and they're actually ready to merge.
And then it makes sure that all the tests are up to date
and not only is any one pull request
up to date with the latest version it wants to merge into,
but even together as a pool,
they're all working together as well.
And then tide is able to merge either one or a couple,
whichever ones are available from that pool.
- [Scott] CICD might sound intimidating,
but actually not having CICD is intimidating.
The business problem is what's actually complex,
having hundreds of people working together
on a single project.
A sophisticated CICD system is actually the easiest way
to facilitate hundreds of people working together
to create a single project like kubernetes.
(gentle electronic music)