I lead off almost every video for reli coding by saying something like Oh I get asked all the time about 2
X Y Z and I know I say that almost every single video but I will say that this particular topic the 3
topic that we're getting covered in this video definitely the most common question I get all the time 4
how do I do a deployment of a web pack application. 5
How do we deploy it. 6
How do I let my friends co-workers boss whoever see the application I'm working on. 7
And how do we do that deployment in some kind of recently scalable fashion. 8
Right. 9
Not just like push it off to get pages but how do we make something that can scale in the future if 10
I actually want to. 11
So in this video we're going to outline steps on how we might tackle a web pack deployment. 12
This gives me a well-packed deployment off to Heroku. 13
So let's talk a little bit about it. 14
I love my diagrams so we're going to start off with a little bit of a diagram here. 15
We're going to come back to the diagram several times. 16
So the entire point of this entire video that I really want to impress upon me I really want you to 17
just understand this one piece and if you understand this one piece you're going to be in like good 18
shape for you to plunge into the future for a pack based application and that one fact is to understand 19
that when we are deploying our application or ROOM we are writing our application. 20
We have two separate pipelines. 21
We've got this kind of development pipeline of how we write our code test our code in the browser. 22
It is kind of like your work and do our development and then we have a completely separate process for 23
doing our production deployment. 24
Now this isn't you know there's a billion ways to do deployment. 25
At the end of the day. 26
And so this is one possible interpretation right. 27
You're not going to claim this is like the end all be all pro-trade you're bound to say that had great 28
success with following this kind of two pipeline methodology of saying here is some process I have for 29
developing my code and then here is some process I have for deploy my code to a production server. 30
So we'll do one very quick run through these these two diagrams here are these two flows and then we're 31
going to go off change a project that I've already installed. 32
And well again we're going to try to install Idda or soon be deployed off to procure and just kind of 33
see how it goes. 34
OK. 35
So let's go through the development pipeline first. 36
This is likely the pipeline or kind of the practices that you're very much use to. 37
So we start off with kind of our code at the top in our repository. 38
We run something like NPM start or well-packed dead server whatever that might be when we run that command 39
. 40
All of our code gets processed by web pack where PAC is responsible for maintaining or linking together 41
all of our different files. 42
Right. 43
Like all those import statements all those require statements whatever you got. 44
Westpac is all about linking those files together in producing some final bills like bundled G-S or 45
main JSA or something like that. 46
Well-packed then hands off that built file to well-packed dead server which is responsible for like 47
giving you something to visit like localhost 1880 or 3000 or 8000 or whatever it is just something that 48
we can visit in our browser to check out our application as we're developing it. 49
And so is flown on the left hand side is probably something that you can be reasonably familiar with 50
even if you don't really recognize it you know if you've worked on any web based application you're 51
probably doing something like Scuse me off on the left hand side over here so we can juxtapose this 52
process or this pipeline right here with how our production pipeline works or how we actually deploy 53
our application. 54
And so obviously you know on the left hand side this is kind of like a running process right. 55
We've got our code here and whenever we make a change well-packed we'll rebuild some particular files 56
and then them off to the dead server again. 57
And so this is kind of a left on the left hand side it's a continuous rerunning process that happens 58
over and over and over again as we're doing our development. 59
Whereas on the right hand side our production pipeline is more like a one shot deal right. 60
We do our deployment one time it builds deploys and we can walk away for a couple of days or couple 61
hours until we decide to deploy it again. 62
So just to be clear. 63
Left hand side as can be continuous running process whereas the deployment on the right hand side is 64
going to be a one shot deal. 65
So let's do a run through on the production pipeline because this is you know the the real point of 66
this video that we're talking about and after we talk do you know kind of a brief run through on this 67
we'll go through a little bit more details and we'll do an actual deployment of an application. 68
So it all starts off with our code. 69
Right of course we've got our code base like some working application that we want to make available 70
to other people online. 71
And I was saying here specifically that we want to work with Heroku. 72
OK. 73
So if I go into Digital Ocean or AWOS these directions might change slightly but everything I have is 74
very well set up for working with pro-people which is definitely one of the easiest hosting providers 75
out there. 76
And then also at the end the day ends up being pretty darn cheap as well compared to some other competitors 77
. 78
Your Digital Ocean is just the cheapest you can find. 79
But Heroku has a little bit more easier to work with. 80
It was getting a bit off topic there so let's go back up to the top so we start off with our code. 81
We're going to push our project to Heroku and by push I mean basically kind of copy paste our entire 82
repository over to our Heroku server. 83
And so from that point on Heroku is like basically responsible for building our project in Serbia out 84
to the world. 85
So we don't really get to do a lot of you know hands on configuration after it goes to Heroku. 86
We have to set up some configuration script to run it so that once our code shows up on Heroku it knows 87
how to build and run our project. 88
So that's the really key factor here. 89
Heroku we have to give it directions on how to build and serve our project now by default. 90
Heroku will understand that we are pushing it a node package and so it will install any of modules for 91
us which is fantastic definitely what we want but besides installing some NPM modules it doesn't really 92
do a whole lot for us. 93
So to make sure that Protea actually builds and runs their application by the way we'll talk exactly 94
what I mean by build's we're going to implement some additional scripts notably one called post install 95
and one called You know I put server Jay last year but it's really just the start and only after these 96
two scripts get ran or executed. 97
Should I be able to visit an address like you know X Y Z at Heroku app dot com and see my application 98
actually running. 99
OK. 100
So the again the idea here is that we're going to push our code off to Roku. 101
Roku will install our NPM modules for us which all of our dependencies like react redox whatever else 102
and then we have to manually specify some amount of configuration to say hey Heroku This is how you 103
should build and run my project. 104
So that's where we spend a lot of time doing setting up the post install thing and is starting whatever 105
those are. 106
OK let's give this a shot. 107
The first thing I'm going to do is I'm over at Heroku dot com. 108
I've already got an account here. 109
Am I going to create a brand new app. 110
So we get to choose from this like whole scratch right something you could follow through from from 111
scratch. 112
So I mean you don't have to provide an app name if you leave the blank it will generate one for us. 113
It's totally fine. 114
So I'm going to create my application 115
and there we go. 116
Everything is deployed. 117
And if I scroll down a little bit I get some directions on how I might create a get repository and on 118
my project you know we'll walk through all this stuff in just a moment saying go over to my application 119
. 120
So this is my project directory right here just to show you what my project looks like once it should 121
actually be deployed. 122
You know pull it open in the browser on a local server. 123
So this would be using well-packed dead server in this case 124
and it can take just a second to get the thing started up which seems like it takes slightly too long 125
. 126
All right. 127
Almost there there you go. 128
All right. 129
Let's check this out. 130
And OK. 131
So here's my youtube application that I've got I can search for videos of the top I can click on videos 132
you know whatever is that I don't want to do. 133
But basically what the app does is completely decoupled from deployment. 134
So this you know this is what it looks like. 135
This is where we're going to try to get up to a Roku server. 136
All right. 137
So I don't really need to have the app running at all so I'll stop the process. 138
I'm going to open up my code editor. 139
So remember the two tasks we need to make sure that actually occur is I need to set up this kind of 140
like post install thing and this start thing over here. 141
So let's figure out what these two scripts are like what are we actually doing where we have to do on 142
the Heroku side. 143
OK. 144
So these two scripts are used to configuration little pieces of configuration are actually scripts that 145
we're going to place inside of our package not just on file. 146
So these are going to be scripts that Marocco is going to run automatically for us. 147
Heroku is set up to automatically call a script called post install in a script called Start. 148
Now the purpose of both of these scripts are absolutely key post install is a script that is intended 149
to build our project in some fashion. 150
I know I've been saying build all the time so just to be clear when I say build I specifically mean 151
take all of our development code like in all these separate files and run web pack to produce a single 152
javascript file that we use for applications. 153
So it's going to be like our bundle. 154
Yes. 155
This step right here is where we build or produce our bundle JS or like single production version of 156
our application where I say single I mean like single javascript file. 157
This script will be ran automatically after installing all of our Antium modules and it's executed exactly 158
once. 159
So this post and sculp post install script right here is the ideal spot for us to tell well-packed please 160
go and build our application because we're about to deploy it and serve it to the rest of the world 161
. 162
After that script runs Heroku is then going to execute a second script automatically called start and 163
remember it's up to us entirely to make sure that these scripts are defined. 164
So Heroku is going to try to run them if they are not available. 165
That's fine but it's going to just kind of say like God or know what you want me to do then write in 166
or fail to actually deploy. 167
So this stern script right here is responsible for actually starting and maintaining the servers. 168
This is where we actually say OK I've built my application I've got like my index HTL file I've got 169
my Bunnell JS I want to serve this out to the world. 170
And so this start script right here we need to make sure that start is actually makes like our server 171
available to the world in response to HTP requests. 172
So as long as we implement these two scripts right here inside of our package sheets on file that's 173
basically all we got to do. 174
That's the whole shebang right there we just got to implement these scripts in Heroku we'll take it 175
from there. 176
So let's start off with our post install script. 177
We will create our post-soul script. 178
Our goal there is to make sure that it actually builds our application as we want to do. 179
So I can open up my project back up and I can open up my package not just on file in my package it's 180
on file I've got my script section and I've already got a script called Start in here. 181
And so it just so happens that the boilerplate package that I'm using here already has a script called 182
Star. 183
We will you know make a couple of changes to this thing in just a minute. 184
But right now again we're going to be creating the post install script so I can add another script I 185
need to first put a comma at the end of this one line and I'll say Posten stall. 186
And this is where you know it's kind of hard to naturally lead into what I'm doing here at this post 187
and so install scripting on the nursery build my package. 188
Basically this is just a bit of trivia. 189
You just got to know how web pack works. 190
To tell well-packed that we want to build a production version of our entire application we can run 191
the command well-packed Mashpee and that's it. 192
If we run well-packed ASC-P we will generate a complete bundle G-S that contains all the code for our 193
application. 194
And I can actually prove that to you right now inside my project directory. 195
I can run well-packed ASC-P and after a couple of seconds it's going to build my bundle that js file 196
that has my entire application in case I need to save this file and then I'm going to create my second 197
script which is responsible for starting running maintaining my entire server like so people can visit 198
it get back some index each HTML file and also get my you know bundle JS file of that kind of good stuff 199
. 200
And so remember that one's called Start. 201
I've already got a naming collision here. 202
You know we've already got a script filled store. 203
So just because of the boilerplate package I'm using already defined the script so it is going to change 204
this existing one to Dev because it's really all about starting up my web pack dead or for development 205
. 206
OK. 207
So in the case of my start script again this is what's actually running some useful server for me. 208
And so for my server I want to run. 209
I'm going to create a server file here in just a second called server. 210
Yes Songlian do is going to run the file server. 211
Yes. 212
OK so I'm going to save this by the way you can see I know it's really small but up here I've now got 213
a bundle that just file inside my project because that web pack dash P file or a command that it ran 214
just finished actually kind of compiling all my stuff into a single bundled g file right here just to 215
see how it actually finished. 216
Ok so I need to now create my server G-S file which is going to be responsible for serving my application 217
out to the world. 218
So I'll create a new file called Server JS decode that we're going to place in here is going to be ah 219
I want what I'm trying to say here is the video that I did last week on really coding or two weeks ago 220
was all about creating a simple issue Hedy's server and serving up a web application. 221
I need a kind of speed through the implementation here. 222
I if you want to figure out the kind of intricacies of what I'm doing I recommend going back two weeks 223
checking out that video and I go through a super in-depth explanation of everything I'm about to put 224
in this file right here. 225
OK. 226
So I'm going to just go through the implementation. 227
First we're going to create an express application and then will import Express and imports the path 228
module. 229
I'll declare my port 230
and then I will create my actual express application. 231
Notice that on my port declaration right here I've got this first line says Process environment port 232
and so Heroku when it executes the server farm right here Heroku provides a support that expects us 233
to listen to Traficon and we get that variable. 234
You know from Heroku as a environment variable. 235
And so if a variable is provided if a port is provided we need to make sure that we buy into that port 236
and not just to like you arbitrarily ADHD or wherever we want to do. 237
And that's why I've got this. 238
Okay try to use port. 239
If it's not to be able to just default back to 1880. 240
OK now here really comes the part where I encourage you to go back to my video from two weeks ago and 241
check out all the stuff in there on why I'm doing these different statements. 242
But basically we're just saying if anyone tries to get any file out of here give them like you know 243
bundle J us. 244
Otherwise if we don't know what route they're trying to get to just send them back our index on HD and 245
I'll file 246
name and listen on port and just console log server started. 247
OK. 248
Now before I actually try to deploys to Roku I'm going to run it locally just to make sure I don't hear 249
typos or anything in there. 250
So I got server started after I ran node Sergius and I should now be able to go to local host ADHD and 251
yeah looks good go. 252
OK. 253
So I've now implemented my post install script and my start script. 254
Remember Posten soul is all about building her application. 255
It gets executed one time on a Roku. 256
And inside the script I need to make sure I do everything required for generating like a deployable 257
version of my application like my actual javascript file. 258
And then I also just implemented a start script which is responsible for saying OK here is my actual 259
server like my express server that is responsible for sending people an index each e-mail file a bundled 260
Jay ass or whatever other API endpoints I might have. 261
So the last step we need to do is actually deployed off to her Roku. 262
So I already generated my Heroku server and now we're going to kind of get into the realm of you know 263
exactly how I Heroku works if this for a year is not that bad. 264
You know we've got some very clear directions right here. 265
I've already installed this Droguet command line tool and logged into it. 266
And so all I have to do is start up a good repository. 267
I will add my Heroku end point or microcode server that just generated as a good hook or a remote origin 268
and then I can actually deploy the application. 269
So I will first get in it. 270
I will add all the files I have in here. 271
I can then add my Heroku endpoint. 272
So Heroku I mean adding and point of this randomly generated name baroque chocolatier. 273
OK this is a crazy town name but OK I'll buy it. 274
And then the very last step I have do is I already committed all my code. 275
I'll have to do is push it all off to Roco. 276
And so this is one of the big promises of Roekel and the reasons I got so popular in my opinion years 277
ago was that it had this fantastic good integration. 278
And so if I want to push or deploy something to Heroku all I do is treat it like a good endpoint so 279
I can get push Heroku master. 280
And so normally you might be used to writing like you know get push Orjan master. 281
And if you're using good hub or get lab or bitbucket that would post it or shuffle your code off to 282
your remote repository. 283
But in this case by pushing to Heroku we are actually pushing to our Heroku server like our actual server 284
. 285
Ok so we're going run this. 286
And let's see what happens. 287
So we get some really nice output here. 288
You'll notice that Procul automatically detected that we are deploying a node application. 289
It installs some you know whatever stuff cast well I don't know stuff stuff stuff. 290
And then here's the important part installing node modules so these are all the modules we've got list 291
inside of our package States on file by default. 292
It's only going to install modules that are underneath the dev section. 293
And so if you've got like some dev dependencies modules and depends in debt or just dependency modules 294
you'll just to get your dependencies. 295
Notice that we just saw. 296
OK. 297
Well it's really up there. 298
It was on screen for just half a second but here it is. 299
This is our post install script well-packed ASC-P. 300
And so this is what's responsible for building our bundled up js file. 301
So after well-packed ASC-P executed we ended up with this bundled G-S which is our complete application 302
and you can see these are all the install Antium modules that we've got. 303
And then finally at the very end something something something very fine deployed done. 304
So let's check out our server now. 305
That's where it is right here. 306
So this is where our application should be deployed. 307
So broke chocolatier dot Brochu at dot com. 308
So let's give this a shot. 309
And boom there's our application. 310
Exactly as we saw it before. 311
If you ever tried going to your Heroku app you are Elop here and nothing pops up or just kind of hangs 312
. 313
One of the most valuable troubleshooting features of Roku is the command line tool Heroku logs and this 314
will reach out to your server and we'll say OK are there any any logs available from the server. 315
Did anything go wrong. 316
And so when I grab that you can see that we've got like basically everything that's how that happened 317
on server starting process with command and start which executed node server gave us. 318
That's the command we write. 319
We added here's server started. 320
That's the console log we added on side of the server dodgiest file and then blah blah blah a bunch 321
of stuff. 322
And eventually I made a request to our server. 323
You know the path forward slash. 324
And then we loaded up the style CSSA. 325
Here's the bundle J us and all the other stuff. 326
And boom there's our application. 327
So that's pretty much it. 328
That is Heroku deployment of a web well-packed based application in nutshell. 329
The big thing to keep in mind here again is to keep in mind that we've got a development pipeline and 330
we've got a production pipeline on the production pipeline. 331
We are responsible for making sure that Heroku knows how to build our application and then actually 332
run something to run something to stuff files off to anyone who asks for something like Bunnell J us 333
or index it's smell or whatever it is. 334
And so normally this will this start command right here what gets executed with something like an express 335
server. 336
All we really have to do is make sure that we implemented the post install and start commands so that 337
whenever we deployed our application Heroku Heroku had some reasonable idea of what it had to do to 338
get our server running. 339
All right. 340
So that is deployment in a nutshell. 341
Again there's just a billion away from deployments. 342
This is one of the simplest ways out there. 343
Definitely the fastest to get started to actually push your stuff out and be able to test it in the 344
wild. 345
I hope you've enjoyed this video. 346
I do weekly videos on everything re-act redux javascript. 347
You know all topics. 348
Check in again next week. 349
And I don't know you know we'll see what new topic we have at that point in time.