[?music?]

[Master Class: Designer and Developer Workflow]

[Fourth Sprint: Preparing for Deployment]

[Jim Hoskins] All right, so we're ready to start the next Sprint of our project.

Nick has updated the GitHub repository with some new changes,

so the first thing I'll be doing is pulling down those changes into my project.

I can do that by doing $git pull

and hopefully we'll get some new things.

And I did not tell it what to merge into, so I will say $git pull origin master.

I want it to pull from the origin remote into the master branch.

All right, it looks like we have some new files

and let's go ahead and fire up a server

and see what the project looks like right now.

So I'll do $rails s

to do the server on its default settings

and we'll go to the browser

and load up localhost: 3000

and it looks pretty good.

I haven't seen this myself, so I'll take a moment to familiarize myself with it.

I like all the new stuff and I'm guessing that it's responsive.

Oh, yeah.

Very nice.

We can click around here.

We can't create a new job unless we're logged in, so let's sign in.

We'll see if all of that still works.

Cool, I can sign in.

We have little Edit buttons on the ones that belong to us.

A pretty simple form--cool.

It looks pretty good.

So the next thing I like to at about this point

is to see if I can get this deployed somewhere on the Internet.

That makes it easy for us to test it with our beta testers

or whoever's running the project, so I like to get a version of the site up

as quickly as possible,

so I'm going to take that opportunity now.

One of the tools that I really like for this is Heroku

and Heroku is a platform that allows us to deploy Rails applications

as well as applications of many different languages and frameworks

to the Internet very quickly and keep them updated quickly

and we can even scale them up using multiple servers, or "dynos," as they're called.

Now, we can host an application for free using a single dyno or single instance

and that's exactly what we'll do, and if we want to continue deploying on Heroku

for our production, we'll be able to scale up nicely.

Now, there are some restrictions to our application

in order to make it compatible with Heroku.

For instance, we can't write to the file system if we have something like uploads.

We couldn't simply write to the file system of the server

since they may be deployed onto several instances.

Instead, we would have to use a third-party service like S3 from Amazon

to store our data, and there are a couple of other little restrictions here and there,

but usually, it's pretty easy to get your application up and running on Heroku.

So what we want to do first is sign up, and I've already gone ahead and created an account.

It's really easy, just give it your email address and they will get you

all the information you need to get an account set up.

So I'm just going to log in.

So now we're signed into Heroku and we are going to now create our first application.

Now, a great tool for getting familiar with Heroku is the Getting Started guide.

Basically, we're going to be creating a new Heroku instance

or a new Heroku app for Easy Jobs! and deploying it,

and hopefully being able to run it through the Heroku architecture.

Now, there are a few restrictions with Heroku that we'll need to work around

in our app in order to get our app compatible with Heroku,

but let's just get started and see what those errors are.

Now I'm going to open up a terminal in our project root

and the first thing that I want to do in order to work with Heroku

is install the Heroku gem, and this installs the utility that will allow us to issue

commands to Heroku; for instance, creating our app

or performing other modifications to how our app is configured.

So to do that, I'll just do $sudo gem install heroku.

All right, and so Heroku is now installed.

Now, one of the restrictions of Heroku is the relational database they offer is PostgreSQL.

Now, you'll remember that right now we're using SQLite on our development server,

so if we were to try to run our application right now,

it would not work because it would not interface properly with Heroku's database.

Instead, we need to add a dependency for Postgre in our application.

Now, this means we can do one of two things:

we can either switch to Postgre for our development

or we can set up different environments for development and production

in which in development we use SQLite and in production we use Postgre.

Now, typically, I'd recommend you use the same database

for both development and production; however, installing Postgre right now

is going to be a lengthy process,

so I would prefer to keep using SQLite on our development machine here

and set it up for separate environments for production and development.

Now, since our application is fairly simple, there's only a couple of tables

and we're using standard Rails queries,

there shouldn't be any problem with using different databases.

However, if we were using custom queries or our app was a little more complicated,

it would definitely be more important to be working on a single-database platform.

So let's go ahead and set up our application to use Postgre in production

and SQLite in development and testing.

So what we're going to do is open up the gem file.

Here we can see we are defining the sqlite3 gem as dependency in our application.

Right now, this SQLite will be included in every environment,

including production, development, and test.

However, when we send it up for production,

we don't want to include SQLite3.

Instead, we want to include the Postgre gem.

What we're going to do is change this line here so sqlite3 is only included

in development and test environments.

So we'll add a line above with a group command and we'll say

group: development, :test do.

And then for only that group, we'll do gen "sqlite3"

and now we need to set up our production environment.

So we'll do group: production do

gem "pg" end.

So now we can save out our gem file.

So now, if we want to bundle our dependencies for development or test,

what we're going to do instead of simply doing $bundle install

we'll add the --without

and add the production group to this.

So this will install all of the dependencies in our gem file

except the things bundled in the production group.

So now we see we're able to bundle all of the dependencies in our application

and it used sqlite instead of pg because we bundled it without production.

Now when Heroku installs our app, it will use the production group

for installing pg, and hopefully that means our app will run under the Postgre database

that Heroku will configure for us.

When we upload our application to Heroku,

what actually happens is instead of using our config database yml file

for connecting to a database,

instead, Heroku will provide its own database credentials

for the database that it manages for us.

So we don't set up a database ourselves; instead, Heroku will provide a database for us

and transparently insert the credentials to access it inside of our application

when it boots it up,

so we don't have to worry about changing anything in our database.yml file.

Now, the way that Heroku apps are managed and deployed is using git,

and fortunately, our application is already set up in a git repository

and managed on GitHub.

When we create an application using Heroku,

it will create another remote repository.

This repository will be on the Heroku servers

and every time we push an update to the master branch,

Heroku's going to detect it, try to build our app and deploy the latest version,

so pushing out updates is as simple as doing a $git push to Heroku.

So let's see what the current status of our repository is by doing $git status.

So it looks like our gem file has been updated, which is what we just did,

so we want to commit this into our repository.

So let's do $git add .

$git status

so the changes to be committed are the modified: Gemfile

and the modified: Gemfile.lock, which is good.

So let's do $git commit

and we'll say we updated Gemfile for heroku

so now we've committed to our local repository.

Now, I'm not going to push this to GitHub right away,

but I will definitely push it later, but this is just to show you

that Heroku will not be pulling from GitHub.

Instead, we'll be pushing directly from our computer to Heroku,

and GitHub and Heroku act as separate remote repositories,

unaware of each other, and all we need to do is manage between them

which one we push to when we want to add changes

or when we want to push changes to production.