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