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