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: Preparing for Deployment] 4 00:00:07,000 --> 00:00:10,000 [Jim Hoskins] All right, so we're ready to start the next Sprint of our project. 5 00:00:10,000 --> 00:00:13,000 Nick has updated the GitHub repository with some new changes, 6 00:00:13,000 --> 00:00:17,000 so the first thing I'll be doing is pulling down those changes into my project. 7 00:00:17,000 --> 00:00:21,000 I can do that by doing $git pull 8 00:00:21,000 --> 00:00:24,000 and hopefully we'll get some new things. 9 00:00:24,000 --> 00:00:31,000 And I did not tell it what to merge into, so I will say $git pull origin master. 10 00:00:31,000 --> 00:00:36,000 I want it to pull from the origin remote into the master branch. 11 00:00:36,000 --> 00:00:39,000 All right, it looks like we have some new files 12 00:00:39,000 --> 00:00:41,000 and let's go ahead and fire up a server 13 00:00:41,000 --> 00:00:44,000 and see what the project looks like right now. 14 00:00:44,000 --> 00:00:47,000 So I'll do $rails s 15 00:00:47,000 --> 00:00:52,000 to do the server on its default settings 16 00:00:52,000 --> 00:00:55,000 and we'll go to the browser 17 00:00:55,000 --> 00:00:57,000 and load up localhost: 3000 18 00:00:57,000 --> 00:01:00,000 and it looks pretty good. 19 00:01:00,000 --> 00:01:04,000 I haven't seen this myself, so I'll take a moment to familiarize myself with it. 20 00:01:04,000 --> 00:01:09,000 I like all the new stuff and I'm guessing that it's responsive. 21 00:01:09,000 --> 00:01:11,000 Oh, yeah. 22 00:01:11,000 --> 00:01:15,000 Very nice. 23 00:01:15,000 --> 00:01:18,000 We can click around here. 24 00:01:18,000 --> 00:01:23,000 We can't create a new job unless we're logged in, so let's sign in. 25 00:01:23,000 --> 00:01:28,000 We'll see if all of that still works. 26 00:01:28,000 --> 00:01:31,000 Cool, I can sign in. 27 00:01:31,000 --> 00:01:34,000 We have little Edit buttons on the ones that belong to us. 28 00:01:34,000 --> 00:01:36,000 A pretty simple form--cool. 29 00:01:36,000 --> 00:01:38,000 It looks pretty good. 30 00:01:38,000 --> 00:01:40,000 So the next thing I like to at about this point 31 00:01:40,000 --> 00:01:43,000 is to see if I can get this deployed somewhere on the Internet. 32 00:01:43,000 --> 00:01:48,000 That makes it easy for us to test it with our beta testers 33 00:01:48,000 --> 00:01:53,000 or whoever's running the project, so I like to get a version of the site up 34 00:01:53,000 --> 00:01:55,000 as quickly as possible, 35 00:01:55,000 --> 00:01:57,000 so I'm going to take that opportunity now. 36 00:01:57,000 --> 00:02:00,000 One of the tools that I really like for this is Heroku 37 00:02:00,000 --> 00:02:04,000 and Heroku is a platform that allows us to deploy Rails applications 38 00:02:04,000 --> 00:02:08,000 as well as applications of many different languages and frameworks 39 00:02:08,000 --> 00:02:11,000 to the Internet very quickly and keep them updated quickly 40 00:02:11,000 --> 00:02:16,000 and we can even scale them up using multiple servers, or "dynos," as they're called. 41 00:02:16,000 --> 00:02:23,000 Now, we can host an application for free using a single dyno or single instance 42 00:02:23,000 --> 00:02:26,000 and that's exactly what we'll do, and if we want to continue deploying on Heroku 43 00:02:26,000 --> 00:02:30,000 for our production, we'll be able to scale up nicely. 44 00:02:30,000 --> 00:02:32,000 Now, there are some restrictions to our application 45 00:02:32,000 --> 00:02:35,000 in order to make it compatible with Heroku. 46 00:02:35,000 --> 00:02:40,000 For instance, we can't write to the file system if we have something like uploads. 47 00:02:40,000 --> 00:02:43,000 We couldn't simply write to the file system of the server 48 00:02:43,000 --> 00:02:47,000 since they may be deployed onto several instances. 49 00:02:47,000 --> 00:02:51,000 Instead, we would have to use a third-party service like S3 from Amazon 50 00:02:51,000 --> 00:02:55,000 to store our data, and there are a couple of other little restrictions here and there, 51 00:02:55,000 --> 00:03:00,000 but usually, it's pretty easy to get your application up and running on Heroku. 52 00:03:00,000 --> 00:03:04,000 So what we want to do first is sign up, and I've already gone ahead and created an account. 53 00:03:04,000 --> 00:03:08,000 It's really easy, just give it your email address and they will get you 54 00:03:08,000 --> 00:03:12,000 all the information you need to get an account set up. 55 00:03:12,000 --> 00:03:21,000 So I'm just going to log in. 56 00:03:21,000 --> 00:03:28,000 So now we're signed into Heroku and we are going to now create our first application. 57 00:03:28,000 --> 00:03:33,000 Now, a great tool for getting familiar with Heroku is the Getting Started guide. 58 00:03:33,000 --> 00:03:37,000 Basically, we're going to be creating a new Heroku instance 59 00:03:37,000 --> 00:03:42,000 or a new Heroku app for Easy Jobs! and deploying it, 60 00:03:42,000 --> 00:03:47,000 and hopefully being able to run it through the Heroku architecture. 61 00:03:47,000 --> 00:03:51,000 Now, there are a few restrictions with Heroku that we'll need to work around 62 00:03:51,000 --> 00:03:55,000 in our app in order to get our app compatible with Heroku, 63 00:03:55,000 --> 00:03:58,000 but let's just get started and see what those errors are. 64 00:03:58,000 --> 00:04:03,000 Now I'm going to open up a terminal in our project root 65 00:04:03,000 --> 00:04:06,000 and the first thing that I want to do in order to work with Heroku 66 00:04:06,000 --> 00:04:11,000 is install the Heroku gem, and this installs the utility that will allow us to issue 67 00:04:11,000 --> 00:04:14,000 commands to Heroku; for instance, creating our app 68 00:04:14,000 --> 00:04:18,000 or performing other modifications to how our app is configured. 69 00:04:18,000 --> 00:04:29,000 So to do that, I'll just do $sudo gem install heroku. 70 00:04:29,000 --> 00:04:35,000 All right, and so Heroku is now installed. 71 00:04:35,000 --> 00:04:40,000 Now, one of the restrictions of Heroku is the relational database they offer is PostgreSQL. 72 00:04:40,000 --> 00:04:46,000 Now, you'll remember that right now we're using SQLite on our development server, 73 00:04:46,000 --> 00:04:48,000 so if we were to try to run our application right now, 74 00:04:48,000 --> 00:04:53,000 it would not work because it would not interface properly with Heroku's database. 75 00:04:53,000 --> 00:04:57,000 Instead, we need to add a dependency for Postgre in our application. 76 00:04:57,000 --> 00:05:00,000 Now, this means we can do one of two things: 77 00:05:00,000 --> 00:05:04,000 we can either switch to Postgre for our development 78 00:05:04,000 --> 00:05:08,000 or we can set up different environments for development and production 79 00:05:08,000 --> 00:05:12,000 in which in development we use SQLite and in production we use Postgre. 80 00:05:12,000 --> 00:05:14,000 Now, typically, I'd recommend you use the same database 81 00:05:14,000 --> 00:05:18,000 for both development and production; however, installing Postgre right now 82 00:05:18,000 --> 00:05:20,000 is going to be a lengthy process, 83 00:05:20,000 --> 00:05:26,000 so I would prefer to keep using SQLite on our development machine here 84 00:05:26,000 --> 00:05:30,000 and set it up for separate environments for production and development. 85 00:05:30,000 --> 00:05:33,000 Now, since our application is fairly simple, there's only a couple of tables 86 00:05:33,000 --> 00:05:36,000 and we're using standard Rails queries, 87 00:05:36,000 --> 00:05:39,000 there shouldn't be any problem with using different databases. 88 00:05:39,000 --> 00:05:43,000 However, if we were using custom queries or our app was a little more complicated, 89 00:05:43,000 --> 00:05:49,000 it would definitely be more important to be working on a single-database platform. 90 00:05:49,000 --> 00:05:53,000 So let's go ahead and set up our application to use Postgre in production 91 00:05:53,000 --> 00:05:56,000 and SQLite in development and testing. 92 00:05:56,000 --> 00:05:59,000 So what we're going to do is open up the gem file. 93 00:05:59,000 --> 00:06:06,000 Here we can see we are defining the sqlite3 gem as dependency in our application. 94 00:06:06,000 --> 00:06:10,000 Right now, this SQLite will be included in every environment, 95 00:06:10,000 --> 00:06:13,000 including production, development, and test. 96 00:06:13,000 --> 00:06:15,000 However, when we send it up for production, 97 00:06:15,000 --> 00:06:17,000 we don't want to include SQLite3. 98 00:06:17,000 --> 00:06:20,000 Instead, we want to include the Postgre gem. 99 00:06:20,000 --> 00:06:23,000 What we're going to do is change this line here so sqlite3 is only included 100 00:06:23,000 --> 00:06:27,000 in development and test environments. 101 00:06:27,000 --> 00:06:32,000 So we'll add a line above with a group command and we'll say 102 00:06:32,000 --> 00:06:38,000 group: development, :test do. 103 00:06:38,000 --> 00:06:44,000 And then for only that group, we'll do gen "sqlite3" 104 00:06:44,000 --> 00:06:47,000 and now we need to set up our production environment. 105 00:06:47,000 --> 00:06:53,000 So we'll do group: production do 106 00:06:53,000 --> 00:07:00,000 gem "pg" end. 107 00:07:00,000 --> 00:07:02,000 So now we can save out our gem file. 108 00:07:02,000 --> 00:07:06,000 So now, if we want to bundle our dependencies for development or test, 109 00:07:06,000 --> 00:07:09,000 what we're going to do instead of simply doing $bundle install 110 00:07:09,000 --> 00:07:14,000 we'll add the --without 111 00:07:14,000 --> 00:07:17,000 and add the production group to this. 112 00:07:17,000 --> 00:07:20,000 So this will install all of the dependencies in our gem file 113 00:07:20,000 --> 00:07:31,000 except the things bundled in the production group. 114 00:07:31,000 --> 00:07:36,000 So now we see we're able to bundle all of the dependencies in our application 115 00:07:36,000 --> 00:07:42,000 and it used sqlite instead of pg because we bundled it without production. 116 00:07:42,000 --> 00:07:45,000 Now when Heroku installs our app, it will use the production group 117 00:07:45,000 --> 00:07:51,000 for installing pg, and hopefully that means our app will run under the Postgre database 118 00:07:51,000 --> 00:07:54,000 that Heroku will configure for us. 119 00:07:54,000 --> 00:07:56,000 When we upload our application to Heroku, 120 00:07:56,000 --> 00:08:04,000 what actually happens is instead of using our config database yml file 121 00:08:04,000 --> 00:08:07,000 for connecting to a database, 122 00:08:07,000 --> 00:08:09,000 instead, Heroku will provide its own database credentials 123 00:08:09,000 --> 00:08:12,000 for the database that it manages for us. 124 00:08:12,000 --> 00:08:17,000 So we don't set up a database ourselves; instead, Heroku will provide a database for us 125 00:08:17,000 --> 00:08:22,000 and transparently insert the credentials to access it inside of our application 126 00:08:22,000 --> 00:08:25,000 when it boots it up, 127 00:08:25,000 --> 00:08:28,000 so we don't have to worry about changing anything in our database.yml file. 128 00:08:28,000 --> 00:08:33,000 Now, the way that Heroku apps are managed and deployed is using git, 129 00:08:33,000 --> 00:08:37,000 and fortunately, our application is already set up in a git repository 130 00:08:37,000 --> 00:08:39,000 and managed on GitHub. 131 00:08:39,000 --> 00:08:42,000 When we create an application using Heroku, 132 00:08:42,000 --> 00:08:44,000 it will create another remote repository. 133 00:08:44,000 --> 00:08:47,000 This repository will be on the Heroku servers 134 00:08:47,000 --> 00:08:50,000 and every time we push an update to the master branch, 135 00:08:50,000 --> 00:08:55,000 Heroku's going to detect it, try to build our app and deploy the latest version, 136 00:08:55,000 --> 00:09:01,000 so pushing out updates is as simple as doing a $git push to Heroku. 137 00:09:01,000 --> 00:09:06,000 So let's see what the current status of our repository is by doing $git status. 138 00:09:06,000 --> 00:09:10,000 So it looks like our gem file has been updated, which is what we just did, 139 00:09:10,000 --> 00:09:13,000 so we want to commit this into our repository. 140 00:09:13,000 --> 00:09:16,000 So let's do $git add . 141 00:09:16,000 --> 00:09:19,000 $git status 142 00:09:19,000 --> 00:09:22,000 so the changes to be committed are the modified: Gemfile 143 00:09:22,000 --> 00:09:26,000 and the modified: Gemfile.lock, which is good. 144 00:09:26,000 --> 00:09:29,000 So let's do $git commit 145 00:09:29,000 --> 00:09:38,000 and we'll say we updated Gemfile for heroku 146 00:09:38,000 --> 00:09:41,000 so now we've committed to our local repository. 147 00:09:41,000 --> 00:09:43,000 Now, I'm not going to push this to GitHub right away, 148 00:09:43,000 --> 00:09:47,000 but I will definitely push it later, but this is just to show you 149 00:09:47,000 --> 00:09:49,000 that Heroku will not be pulling from GitHub. 150 00:09:49,000 --> 00:09:54,000 Instead, we'll be pushing directly from our computer to Heroku, 151 00:09:54,000 --> 00:09:59,000 and GitHub and Heroku act as separate remote repositories, 152 00:09:59,000 --> 00:10:03,000 unaware of each other, and all we need to do is manage between them 153 00:10:03,000 --> 00:10:06,000 which one we push to when we want to add changes 154 00:10:06,000 --> 00:10:10,000 or when we want to push changes to production.