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 going to start talking about some more specifics around that flow.
Now I'm going to 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 going to talk too much
about Dockers flow in this just yet.
Instead I'm going to focus on telling you about some outside services in 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'll then can introduce stalker intel about how docker kind of facilitates everything.
OK.
So let's get to it.
Our development workflow is going to revolve around creating a good hub repository.
This repository is going to kind of serve as the central point of coordination for all the code that
you and I are going to write and then eventually deploy to out some outside hosting service market hub
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 the 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 get repository that might make our master branch is going to kind
of represent our very clean working copy of our codebase.
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 of arrows here to kind of 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 going to 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 going to pull down that code base and then on your laptop you are going to make some amount
of changes to the application after you've made those changes.
You'll then push those changes back up to the good 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 polar request.
So we're going to make a pull request to take all the changes or all the new features you've added to
this feature branch right year and merge them over to the master branch.
So this kind of merging of code from feature over the Master is done by what we call that poll request.
Now this pull request right here or this request to add some code from feature over to a master is going
to set off a series of actions that are going to kind of govern how you manage your codebase.
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 requests 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 see-I Travis C.I. 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 going to 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 test so we don't need to worry too much about the testing for right now.
Assuming that Travis is able to pull all the code from our master branch and run tests on it successfully.
Travis C.I. is then going to be set up to automatically take our codebase 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 puller request merging the request with the master branch and the instant you do
that we'd run our tests if the tests run successfully.
Travis see-I will automatically deploy your application to AWOS.
So that is a flow in a nutshell.
Now this flows 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 we're going to 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 going to have three phases to our project here.
We've got the death phase the testing phase in the production phase during the death phase.
You and I are going to make some number of changes to our code base.
And again these are all going to meet to a branch that is not the master branch.
We're going to call it our feature branch because it's where we develop new features once we make our
changes to that feature branch we're going to push our changes to get up 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 going to set up Travis see-I to automatically pull that Master branch with the new and updated
code Traviss then going to run our tests.
If all the tests are executed successfully We're going to say great we can merge all the changes over
to the master branch.
We're going to again push our code over to Travis s.i.
We're going to test run the tests one more time and then have Travis see-I automatically deploy our
application over to AWOS services are essentially a very specific very specific service that is called
elastic beanstalk.
OK.
So that's kind of the whole flow that we're going to go through here in two different diagrams.
Let's take a quick pause right here.
We're in come back the next section and start talking about how docker fits into all this stuff.