[?music?]

[Master Class: Designer and Developer Workflow]

[Fourth Sprint: Fine Tuning the Deployment]

[Jim Hoskins] So right now what we are dealing with is a problem

when we tried to sign in.

We got a 500 error as soon as we tried to log in to our site.

By looking at the logs, we can see that there was a NoMethodError,

"valid_password?" for user, which makes me think that there is something a little bit funny

with Authlogic, the library we're using for authentication.

Now, what I've done is I've taken this string right here and put it into Google

and I have taken a look to see if anybody else has had this problem.

After a little bit of Googling, I think the problem can be resolved

by simply restarting our application, so why don't we try that out?

In order to restart our application,

we will do $heroku restart

and this will shut down any dynos that are running

and hopefully restart them again.

So it looks like it was done fairly quickly

and if we go back and we refresh here,

get the Sign In form, and let's try to log in.

All right, it looks like it was a success.

Now, what caused this error?

Well, my thought is we only deployed our application once,

so as soon as we pushed it and began running it,

the application was up and running; however, the database was completely empty.

There was no user model, so when Authlogic initialized,

it didn't have a user model in which to look for things like the passworld field

to configure itself.

Then we migrated afterward.

However, Authlogic had already configured itself,

so when we tried to sign in, it did not know how to deal with the user model

and it just crashed.

But by restarting the application with the user model correctly placed in the database,

Authlogic was able to configure itself properly and is now working as expected,

so that was a pretty easy problem to solve.

Again, when dealing with problems--just like any other computer problem--

usually the first step is to turn it off and on again

and you can do that with $heroku restart.

So now we have a running version of Easy Jobs! running on Heroku.

We have pushed our development database into the production database

so now we have some information and we're able to log in

and manage our database information just like we do from our local machine.

There's still a few things, though, that we want to configure for our deployment.

For instance, right now, deep-meadow-7939 is not the greatest URL or application name.

We could easily rename our application using the Heroku command, so let's try that.

So what we'll do is type $heroku rename

and then the name of our application.

Let's go ahead and call it easyjobs.

So what it's done is renamed our application from deep-meadow to easyjobs,

so now it can be accessed at easyjobs.herokuapp.com.

Now, this does change the URL of the Heroku Git remote repository

since now it is named easyjobs instead of deep-meadow.

Now, this isn't a problem right now because I'm the only one

with that remote repository setup in their project.

However, if I had shared this remote repository with Nick

and he was set up with the remote being deep-meadow and I renamed it,

I would have to tell him about this so he could change the URL of his remote repository.

So renaming your application is not without consequence,

but it's pretty easy to do in the beginning.

So if we type in $heroku open

right now, instead of opening up deep-meadow,

it should open up easyjobs.herokuapp.com

where we can access our application.

However, deep-meadow here will no longer exist.

Now, the next thing we want to do is change the application server

that is running our Rails app.

Right now, Heroku just uses the Rails server command in order to start our application up,

which means by default, it's using WebBrick in order to serve our application.

Now, WebBrick is fine.

It's great for development--it's actually what we use right now.

If we were to type in Rails server, WebBrick is what's hosting our application locally.

However, it's not ideal for an actual production setup.

There are faster servers, such as Thin or Mongrel,

so what we'll do is install Thin into our application

so when Heroku starts our application, it will use Thin to serve it

instead of WebBrick.

So this is easy enough to do.

We'll open up our application inside of our Gem file.

We will add the gem "thin".

We can save it out,

and we will do $bundle install --without production.

So now we have Thin installed and now we need to tell Heroku

to run the application using Thin instead of simply running the Rails server.

Now, in order to change how Heroku will run the application,

we now have to define a Procfile, and this is the file I was telling you

that Heroku created itself when it saw that we had a Rails application.

But now, we're going to create our own to override it.

This is easy to do.

We'll create a new file

and it'll be a Procfile

and it's going to be in the root of our application.

Now, the Procfile takes a certain format.

Basically, this defines all the processes that are needed to run our application.

Now, a Rails app only needs one process, which is the web server process,

which actually runs your application.

But if your application requires things--like for instance, to index something

or to run a background file or to run a background process--

we could define multiple processes here.

However, it would cost money on Heroku since our application is limited to one free dyno,

which means one process running at a time.

But if we wanted to scale up to multiple processes,

we could simply do that in this Procfile.

So let's just define our web process by typing in web:

and then we will define the command that we will run

in order to make our server actually run,

and that is bundle executive rails server

and we're going to tell it to run on thin

and we also need to tell it what port to run on.

Now, Heroku will define that port for us

by using the port environment variable.

So within our Rails bundle, we'll execute the Rails server running Thin

on the port that Heroku will define for us.

So if we save that out, we can actually test it locally by using the forman Gem,

and this actually utilizes the Procfile and starts your application

using the processes defined in that Procfile.

So we'll go over to our terminal, we'll do $sudo gem install foreman

and now that we have Foreman installed, we can type in $foreman start

and this will look for the Procfile and start up our application

using the information within it.

So we can see by default the port that Foreman uses is 5000

as opposed to the 3000 that Rails runs on by default.

so it was able to pick up that custom-defined port

and it also runs the Thin server.

So if we were to go to our browser, change our local address from 3000 to 5000,

we can see that it's up and running properly.

So I'm going to close out Foreman and our 5000 process here.

We will do a $git status to see what has changed--

our Gem file and our new Procfile, so let's do $git add .

Check out our status again $git status

so those are the three things that will be added

and we will do a $git commit.

So we added a Procfile and confiugred to run on thin.

So now it's committed to our local repository

and in order to update our Heroku application, all we need to do is type in

$git push heroku master

and now Heroku has recompiled our slug now that we're using Thin

and some new dependencies.

And it has restarted our system, so hopefully if we go to easyjobs.herokuapp,

we shouldn't see any changes on the front end.

However, if we take a look at $heroku logs,

we might be able to catch a glimpse of where it started up Thin

and we could see it is now running the Thin web server,

which should increase our performance.

All right, so now we got a server up and running with data.

It's working.

We've pushed the application to the Heroku repository in order to release it onto the web,

but the last thing we need to do is actually send it over to Git Hub

so we keep our project in sync.

We'll be using the Git Hub repository to actually develop and track our progress,

but we'll only be pushing to the Heroku respository

whenever we want to actually deploy features to the web.

So now I will push all the changes that we've done to the Git Hub repository

by doing $git push origin master

and this should push to Git Hub so Nick can pull down my changes.

And then, we'll simply be committing to Git Hub whenever we do development

and pushing to Heroku whenever we want to deploy.