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.
This video doesn't have any notes.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[?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 upYou need to sign up for Treehouse in order to set up Workspace
Sign up