Fine Tuning the Deployment

[?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