In last video we made a little change to the Express side of our application to make sure that it handles
routing correctly when it's in production.
We're now going to continue by talking about some changes we have to make around the client side of
our application to make sure that any updates we make to the client side of our codebase are correctly
reflected on our production server.
So when we're talking about here well remember that just like two minutes ago we ran the NPM run build
command from our client directory.
So we were out the terminal.
We ran NPM run built and that started up the build process to take all of our javascript code make a
production version of it and then dump all that inside of our client build directory.
Now as you might imagine every single time we build our project it's a one time step it's like we run
it one time and that is a built version of our code base as it stands at that point in time.
If I build my project and then I go back into my SIRC directory and start changing some re-act component
I have to build my project again.
I have to build a second time.
I have to build my project every single time I go to deploy my application when I have made a change
to the client side code base.
So as you might imagine we need to make sure that any time we are going to deploy our application to
Heroku we actually deploy are assuming we actually build our code base and then deploy it.
So the second big part of this talk that we're having about deployment on Hoku is around exactly how
we execute that build step.
So the reason that this is kind of a big question at all is that by convention traditionally we do not
commit any of our built assets to get.
And remember we have a get based workflow for deployment we use get to commit our project and then push
that to Heroku.
So if we were to say hmm I want to build my project committed and then shove all that off to Heroku
that means that we are including all of our build assets inside of our Get repository which is not necessarily
a bad thing but by convention we dont really do it.
So lets talk about a couple of different ways that we can handle building our project and deploying
it to Heroku.
Okay.
So I got a good diagram on this one right here.
So theres a couple of different options available to us.
Obviously we're going to take one very specific option but I want to talk about all three of them.
So remember the entire idea here is that we have to make sure that we actually build our project before
we push it off to Hoku or at least before we intend to deploy it.
So let's go through option number one.
Option number 1 is the one I kind of just mentioned and I said this kind of violates convention.
The one I've just mentioned it kind of violates convention of how we do web development or at least
source control in general.
So for option number one we can run the entry and run build command at our terminal on our local machine.
We can commit that built project with all those built javascript files to our Get up repo and then we
push that all off to Heroku.
So no words were breaking convention.
If we go with option number one remember I said there's not necessarily something inherently bad about
this but it breaks convention and there are a couple small reasons to not go this way.
Now I'll tell you that right out of the gate create re-act out actually makes this challenging to go
with option number one right here because by default Krait react up doesn't commit the build directory
in here.
And inside my code editor you'll see that this whole directory is kind of greyed out.
Again that's my code editor telling me all these files are ignored by get.
And they will not be committed.
OK.
So that's option number one.
Obviously it's pretty straightforward.
You can run into them run build you commit those files you push off to Heroku.
Everything seems to just magically work.
Now option number two this one is getting a little bit more complicated but it's kind of making sure
that we don't have to commit any of those built files.
So in option number two we're going to say that the entire build process is being executed on Heroku
servers.
So we will commit all of our code.
We do not build the project on our local laptop.
We push it off to Hoku And then once our project is on Heroku we tell it to install all the dependencies
for a client project and then to run the command to build the client project and then to actually deploy
the stuff and actually serve it.
So it's optional to here we are telling Heroku itself to take care of the entire build process.
So you might look at option over to here and say oh well heck.
This seems straightforward like we'll just have Heroku do do a build step.
Well there's still kind of a bad side to this one.
And I'm going to tell you that it's not only rephrased to say it's not bad per se but I'm going to say
that this is where.
Kind of like some developers superstition comes in you know superstition around thinking that you might
have bad luck if you do it this way.
And here's why.
In order to get Heroku to build our project we have to install all key word here is all dependencies
all dependencies.
So when we install all dependencies I'm talking about like web pack and babbel anything else the battle
depends upon anything else that well-packed depends upon.
Any other pieces or dependencies that create re-act relies upon in the development environment at all.
So when we tell her Oku to build our project we have to install all of those dependencies and so the
kind of superstition here is that you are installing a ton of dependencies that are only being used
for the development environment or just for like developing your application you're installing all these
dependencies on your production server.
So why do I say that superstition.
Well it is superstition.
Let me be clear it is completely superstitious.
You are installing the dependencies for the development evironmental just to build the project.
And then after that those dependencies will never be used again by Heroku.
They do not get included into our client side javascript files they don't get included into the Express
server they just exist on the hard drive.
They never get loaded up into RAM.
Never anything after that after the build is complete.
So some people look at this right here and they say oh you're installing your development dependencies
on your production machine.
Yeah it doesn't matter because they're not actually used outside of the build process.
So my opinion.
Option number two here is pretty straightforward as well and it definitely follows convention as far
as making sure that you do not actually commit your project.
Now there is of course one final option here.
So option number 3 and this option right here is a little bit more overkill certainly for the application
we are building.
But you might more commonly see this option right here at a company so at any serious company a startup
a large midsize whatever company is telling you that this option exists and that you might see some
companies in the wild at your job or freelance projects whatever using this type of process right here.
So in this process we make use of a third party server to actually build the application.
So we take all of our files all the re-act side of our application all the Express side will commit
all of it to get and that will push it off to.
We refer to as see-I or continuous integration a C.I. server which is how we usually refer to it a see-I
server is a server that has the ability to run tests or checks or basically any task you can possibly
imagine over your codebase.
So a CIA server per Donnelley is set up for running tests.
But we can easily configure a CII server to say OK after you run all these tests over our codebase.
If the tests all successfully pass then install all the client dependencies all of them all the development
ones as well.
Build the project committed to a different branch like a deployment branch on get and then automatically
push that build off to Heroku and that includes all of the actual built project files.
So again this is really taking use or making use of a third party server some type of essentially intermediary
that occurs between Heroku and our own personal laptop.
So of course for us we don't have any tests.
We don't have any extra steps like that to run.
So for our application this would just like very much be overkill.
My opinion we really don't need to go down this path right here.
And technically what we're doing with option 2 is very similar where we are relying upon some outside
server to build our project for us which is essentially what option number three is.
The big difference between Option number two and number three is that that server that is doing the
build process is our actual production server as opposed to this third party server being used for by
s.i.
Now regarding option 3 really quickly I want to say that if you want to like really dive into the rabbit
hole and try to set this thing up I'm going to tell you this is not a trivial thing at all.
This is pretty serious stuff right here.
You can go over a circle site and you can sign up for it for free and use it to start actually building
your project and doing your deployment to Roku.
Now let me repeat again this is very serious stuff right here.
You really shouldn't take it lightly.
It would be a good side project but definitely outside of the scope of this course for setting up.
OK.
So in other words you know we're going with option number two here.
So our goal is to make sure that we can push all of our code to Hoku make sure that Heroku installs
all of our client side dependencies and then builds the project and starts up our server.
So I think that this video has gone on long enough.
Let's take a quick break.
We're going to come back in the next video and start to tackle.
Option number two for deployment.
So I'll see you in just a minute.