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