-: In the last section, we started talking about how
we're going to develop a development workflow
that's going to allow us to develop our application,
test it in some fashion,
deploy it
and then repeat that process all over again.
So in this section, we're gonna start talking
about some more specifics around that flow.
Now I'm gonna give you a diagram here
that's going to be just a little bit interactive.
So I'm going to add in a couple of elements
as we go through this description over time.
The important thing to keep in mind here
around this diagram is
that we're not gonna talk too much
about Dockers flow in this just yet.
Instead, I'm gonna focus
on telling you about some outside services
and outside technologies that we're going to use
to set up this development workflow.
Once we kind of understand the core principles
or the kind of design behind this development workflow
we will then kind of introduce Docker
and tell about how Docker kind of facilitates everything.
Okay, so let's get to it.
Our development workflow is going to revolve
around creating a GitHub repository.
This GitHub repository is going to kind of serve
as the central point of coordination for all the codes
that you and I are going to write
and then eventually deploy
to outside hosting service.
Our GitHub repository is going to have two
different branches.
One branch we're going to call the feature branch.
This feature branch is essentially a development branch
of sorts.
This is a branch that you
and I are going to add code to make changes or
do whatever it is we need to do to update our application.
We're also going to have a master branch.
A master branch,
it belongs to traditionally every GIT repository
that you might make.
Our master branch is going to kind of
represent our very clean working copy of our code base.
Any changes that we make to this master branch right here
are going to be eventually automatically deployed out
to our hosting provider.
Let's now draw on a couple arrows here to kinda walk
through the process through which you and I are going to
make changes to our code base and then eventually
deploy those.
So everything is gonna start off with you and I
on some local development machine,
like your desktop or your laptop.
You and I are going to pull all the latest code that we have
from our feature branch.
And so we're going to imagine that maybe you are working
on this project with some other engineer
and maybe they have already published some amount of code
on this feature branch.
So you're gonna pull down that code base
and then on your laptop
you are gonna make some amount of changes
to the application.
After you've made those changes, you'll then
push those changes back up to the GitHub repository again
to the feature branch.
You are never going to push code directly to master.
You're only going to pull and push code
from the feature branch.
Once you push your changes up to this feature branch
you'll then create what is called a pull request.
So we're gonna make a pull request to take all the changes
or all the new features you've added to this feature
branch right here and merge them over to the master branch.
So this kind of merging of code from feature over
to master is done by what we call that pull request.
Now this pull request right here
or this request to add some code
from feature over to master,
is going to set off a series of actions
that are going to kind
of govern how you manage your code base.
So once you create this pull request right here
and then eventually merge it into master
two very important things are going to occur.
First off, when you make this little pull request
we're going to set up a workflow that is going to
automatically take our application and push it
over to a service called Travis CI
Travis CI is a continuous integration provider
and essentially what they do is pull down your code
and run a set of tests that you write on your code base.
These are tests that you are gonna write yourself.
Now for your particular application
or wherever you go and use this flow,
you'll end up using tests relevant
to your particular application
or whatever language you're working with.
For our application
the one that we're going to kind of test this flow out on
we're going to just be making use
of a couple of pre-generated tests.
So we don't need to worry too much
about the testing for right now
Assuming that Travis CI is able to pull all the code
from our master branch and run tests on it successfully
Travis CI is then going to be set
up to automatically take our code base
take our entire project,
and push it over to some Amazon web services hosting.
So essentially this entire flow is going to be
depending upon you pushing some code
up to this feature branch,
creating the pull request
merging the pull request with the master branch.
And the instant you do that, we'd run our tests.
If the test runs successfully
Travis CI will automatically deploy your application to AWS.
So that is the flow in a nutshell.
Now this flow is a little bit complicated,
so I want to talk about the entire flow again,
like from start to finish.
One more time in a slightly different format
just kind of a different diagram here,
just to give you kind of a different take
on what's going on.
If you feel
like you already understand this flow,
that's totally fine.
Take a pause right here
and skip over to the next video.
Otherwise gonna give you essentially
the same description again
but with a different set of diagrams.
All right
so we can kind of imagine that we're gonna have three phases
to our project here.
We've got the dev phase,
the testing phase
and the production phase.
During the dev phase,
you and I are going to make some number of changes
to our code base.
And again, these are all going to be made
to a branch that is not the master branch.
We're gonna call it our feature branch
'cause it's where we develop new features.
Once we make our changes to that feature branch
we're then going to push our changes to GitHub
and then we're going to create a pull request to merge
with the master branch.
As soon as we make that pull request, we are gonna set
up Travis CI to automatically pull that master branch
with the new and updated code.
Travis CI is then going to run our tests.
If all the tests are executed successfully
We're gonna say great
we can merge all the changes over to the master branch.
We're going to again, push our code over to Travis CI
We're gonna run the test one more time
and then have Travis CI automatically deploy our application
over to AWS services.
So we're essentially a very specific service set
is called elastic beanstalk
Okay, so that's kind of the whole flow
that we're gonna go through here in two different diagrams.
Let's take a quick pause right here.
We're gonna come back to the next section
and start talking about how Docker fits into all this stuff.