Our project is now looking pretty good.
And now it's time for us to actually deploy it.
This is going to be a lot of fun.
We're going to walk through the process of creating a production style deployment pipeline.
And when we talk about deployment, it's not really just about making sure that our code is live somewhere.
Instead, it's about the entire workflow and how we make sure that we can make changes, somehow save
those changes and make sure those changes get deployed somewhere automatically.
They're going to build out an entire workflow process here.
We're not just going to look alone at doing the deployment stuff.
All right.
So, of course, a couple of quick diagrams.
So here's the entire idea at some point time.
You might have multiple different teams working on a single product.
These two teams might be working on very different services.
And after they make some changes to the services, we should expect that those changes will be eventually
deployed into some production communities cluster.
So we need a workflow to make sure that multiple teams can be working on the same project at the same
time and eventually merge all these changes together and deploy them in some meaningful fashion without
having some nasty conflicts or errors along the way.
So I'm going to show you a little diagram or a workflow that I've personally used in many projects and
I know many, many other engineers use in projects as well.
It's a pretty foolproof diagram or really workflow.
The first time you learn it, it's a little bit confusing.
But once you understand the idea behind it, the workflow is pretty bullet proof.
And it's going to work in the vast, vast majority of scenarios.
OK, so here it is.
So this is the overall diagram.
I'm going to zoom in and we're going to walk through it step by step.
So we're starting off on your local machine where you are going to be working on some changes to some
particular service.
So we're going to imagine that you are making that change to, say, the ticket service after you have
made your changes.
You are then going to commit that code or those changes to a get branch.
So we're going to created branch whip gets.
We're going to commit all of our changes to that branch.
The only requirement here is that we make changes and we commit them to any branch besides the master
branch.
We're going to treat the master branch as a very special branch in this workflow.
After we have committed those changes will then push that branch up to get up.
Then our workload jumps over to get up.
Get Up is going to receive that update branch.
You are then going to mainly create a pull request.
Do you get Huub UI?
A pull request is a request to essentially merge some changes from one branch into a another branch.
In this case, we're going to make a pull request to merge changes from the branch you just created
into the master branch.
The instant that we create that play request, we are going to configure GitHub to automatically run
all the tests inside of our project by just creating this pull request.
We're going to make sure that GitHub runs all those different tests we have created over time.
After all those tests pass, we are then going to merge our pull request into the master branch.
Like I said, the Master Branch is going to be a very special branch inside of rap.
Whenever we make a change to the master branch, we're going to configure GitHub so that it automatically
deploys all of our changes to our live Cuban natives cluster.
You'll notice that in this entire workflow, we haven't really said that much about deployment or where
we are deploying are up to.
But this is really a very generic general workflow that you can use to deploy code to any kind of target
to be at Google Cloud eight of us or anything else.
All right, now, you've seen a very rough outline here.
We're going to take a quick pause.
When we come back, the next video, we're going to create a get repository on our local machine.
We're also going to create a get repository on GitHub.
We're going to tie the two together and just do a little bit of setup.