Heads up! To view this whole video, sign in with your Courses Plus account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
In this video, update our app configuration to improve its performance.
[?music?]
0:00
[Master Class: Designer and Developer Workflow]
0:02
[Fourth Sprint: Fine Tuning the Deployment]
0:04
[Jim Hoskins] So right now what we are dealing with is a problem
0:07
when we tried to sign in.
0:10
We got a 500 error as soon as we tried to log in to our site.
0:12
By looking at the logs, we can see that there was a NoMethodError,
0:17
"valid_password?" for user, which makes me think that there is something a little bit funny
0:20
with Authlogic, the library we're using for authentication.
0:25
Now, what I've done is I've taken this string right here and put it into Google
0:29
and I have taken a look to see if anybody else has had this problem.
0:34
After a little bit of Googling, I think the problem can be resolved
0:37
by simply restarting our application, so why don't we try that out?
0:42
In order to restart our application,
0:45
we will do $heroku restart
0:49
and this will shut down any dynos that are running
0:52
and hopefully restart them again.
0:55
So it looks like it was done fairly quickly
0:59
and if we go back and we refresh here,
1:02
get the Sign In form, and let's try to log in.
1:05
All right, it looks like it was a success.
1:12
Now, what caused this error?
1:17
Well, my thought is we only deployed our application once,
1:19
so as soon as we pushed it and began running it,
1:22
the application was up and running; however, the database was completely empty.
1:25
There was no user model, so when Authlogic initialized,
1:29
it didn't have a user model in which to look for things like the passworld field
1:34
to configure itself.
1:39
Then we migrated afterward.
1:41
However, Authlogic had already configured itself,
1:43
so when we tried to sign in, it did not know how to deal with the user model
1:46
and it just crashed.
1:50
But by restarting the application with the user model correctly placed in the database,
1:52
Authlogic was able to configure itself properly and is now working as expected,
1:59
so that was a pretty easy problem to solve.
2:04
Again, when dealing with problems--just like any other computer problem--
2:07
usually the first step is to turn it off and on again
2:10
and you can do that with $heroku restart.
2:13
So now we have a running version of Easy Jobs! running on Heroku.
2:17
We have pushed our development database into the production database
2:20
so now we have some information and we're able to log in
2:24
and manage our database information just like we do from our local machine.
2:27
There's still a few things, though, that we want to configure for our deployment.
2:34
For instance, right now, deep-meadow-7939 is not the greatest URL or application name.
2:39
We could easily rename our application using the Heroku command, so let's try that.
2:45
So what we'll do is type $heroku rename
2:51
and then the name of our application.
2:54
Let's go ahead and call it easyjobs.
2:57
So what it's done is renamed our application from deep-meadow to easyjobs,
3:02
so now it can be accessed at easyjobs.herokuapp.com.
3:06
Now, this does change the URL of the Heroku Git remote repository
3:11
since now it is named easyjobs instead of deep-meadow.
3:17
Now, this isn't a problem right now because I'm the only one
3:20
with that remote repository setup in their project.
3:23
However, if I had shared this remote repository with Nick
3:26
and he was set up with the remote being deep-meadow and I renamed it,
3:30
I would have to tell him about this so he could change the URL of his remote repository.
3:34
So renaming your application is not without consequence,
3:40
but it's pretty easy to do in the beginning.
3:42
So if we type in $heroku open
3:45
right now, instead of opening up deep-meadow,
3:49
it should open up easyjobs.herokuapp.com
3:53
where we can access our application.
3:58
However, deep-meadow here will no longer exist.
4:01
Now, the next thing we want to do is change the application server
4:05
that is running our Rails app.
4:08
Right now, Heroku just uses the Rails server command in order to start our application up,
4:12
which means by default, it's using WebBrick in order to serve our application.
4:17
Now, WebBrick is fine.
4:22
It's great for development--it's actually what we use right now.
4:24
If we were to type in Rails server, WebBrick is what's hosting our application locally.
4:27
However, it's not ideal for an actual production setup.
4:32
There are faster servers, such as Thin or Mongrel,
4:36
so what we'll do is install Thin into our application
4:40
so when Heroku starts our application, it will use Thin to serve it
4:43
instead of WebBrick.
4:47
So this is easy enough to do.
4:49
We'll open up our application inside of our Gem file.
4:51
We will add the gem "thin".
4:55
We can save it out,
5:01
and we will do $bundle install --without production.
5:03
So now we have Thin installed and now we need to tell Heroku
5:20
to run the application using Thin instead of simply running the Rails server.
5:25
Now, in order to change how Heroku will run the application,
5:32
we now have to define a Procfile, and this is the file I was telling you
5:35
that Heroku created itself when it saw that we had a Rails application.
5:39
But now, we're going to create our own to override it.
5:44
This is easy to do.
5:47
We'll create a new file
5:49
and it'll be a Procfile
5:51
and it's going to be in the root of our application.
5:56
Now, the Procfile takes a certain format.
5:59
Basically, this defines all the processes that are needed to run our application.
6:03
Now, a Rails app only needs one process, which is the web server process,
6:07
which actually runs your application.
6:12
But if your application requires things--like for instance, to index something
6:14
or to run a background file or to run a background process--
6:19
we could define multiple processes here.
6:23
However, it would cost money on Heroku since our application is limited to one free dyno,
6:26
which means one process running at a time.
6:31
But if we wanted to scale up to multiple processes,
6:34
we could simply do that in this Procfile.
6:36
So let's just define our web process by typing in web:
6:40
and then we will define the command that we will run
6:43
in order to make our server actually run,
6:46
and that is bundle executive rails server
6:50
and we're going to tell it to run on thin
6:57
and we also need to tell it what port to run on.
7:00
Now, Heroku will define that port for us
7:03
by using the port environment variable.
7:08
So within our Rails bundle, we'll execute the Rails server running Thin
7:11
on the port that Heroku will define for us.
7:17
So if we save that out, we can actually test it locally by using the forman Gem,
7:20
and this actually utilizes the Procfile and starts your application
7:26
using the processes defined in that Procfile.
7:29
So we'll go over to our terminal, we'll do $sudo gem install foreman
7:35
and now that we have Foreman installed, we can type in $foreman start
7:47
and this will look for the Procfile and start up our application
7:53
using the information within it.
7:57
So we can see by default the port that Foreman uses is 5000
8:01
as opposed to the 3000 that Rails runs on by default.
8:05
so it was able to pick up that custom-defined port
8:09
and it also runs the Thin server.
8:13
So if we were to go to our browser, change our local address from 3000 to 5000,
8:15
we can see that it's up and running properly.
8:25
So I'm going to close out Foreman and our 5000 process here.
8:28
We will do a $git status to see what has changed--
8:33
our Gem file and our new Procfile, so let's do $git add .
8:37
Check out our status again $git status
8:43
so those are the three things that will be added
8:46
and we will do a $git commit.
8:49
So we added a Procfile and confiugred to run on thin.
8:53
So now it's committed to our local repository
9:04
and in order to update our Heroku application, all we need to do is type in
9:07
$git push heroku master
9:11
and now Heroku has recompiled our slug now that we're using Thin
9:25
and some new dependencies.
9:30
And it has restarted our system, so hopefully if we go to easyjobs.herokuapp,
9:32
we shouldn't see any changes on the front end.
9:36
However, if we take a look at $heroku logs,
9:38
we might be able to catch a glimpse of where it started up Thin
9:42
and we could see it is now running the Thin web server,
9:47
which should increase our performance.
9:50
All right, so now we got a server up and running with data.
9:54
It's working.
9:57
We've pushed the application to the Heroku repository in order to release it onto the web,
9:59
but the last thing we need to do is actually send it over to Git Hub
10:03
so we keep our project in sync.
10:07
We'll be using the Git Hub repository to actually develop and track our progress,
10:10
but we'll only be pushing to the Heroku respository
10:15
whenever we want to actually deploy features to the web.
10:17
So now I will push all the changes that we've done to the Git Hub repository
10:21
by doing $git push origin master
10:25
and this should push to Git Hub so Nick can pull down my changes.
10:30
And then, we'll simply be committing to Git Hub whenever we do development
10:34
and pushing to Heroku whenever we want to deploy.
10:39
You need to sign up for Treehouse in order to download course files.
Sign up