That’s Not How Deployment Works:

Heroku deployment and what the docs leave out (so obvious you’ll miss it).

You’re bug free, kid. Now let’s deploy this thing and go home.
— Han Solo, scoundrel of the CLI

It’s finally time to deploy your app. If you’re like me, it should have been deployed weeks ago, but you kept trying to get it ‘right’.

Garvin Dreis (played by Drewe Henley)

A quick tangent to this blog and a lesson that I’m learning on my dev journey — just deploy it. Get your work out in the world and see how it really looks. You can still keep working on your code (and you can tell your host to automatically deploy your commits). There is no ‘right’, it will never be ‘done’, and that’s ok.

Do or do not. There is no try.
— You know who said it.

The first thing to consider for deployment is who to use as the host. There are a lot of good options out there, but it is important to pick the right site for your app. For an app with a back end and separate front end, you’ll need a dynamic and static host. The back end needs a dynamic host. It has your database and will get a lot of resource calls. The drawback is that a dynamic host will load slower and use more resources. I’ll talk about the advantages and disadvantages of the static website in my next installment.

For my database, built with Ruby on Rails, I went with Heroku. It’s a great resource (and free!). The Heroku docs do a great job of walking you through the process, but there are a few things they leave out. I hope to clarify those points. First, install the Heroku CLI:

brew tap heroku/brew && brew install heroku

Once that is done, it can’t hurt to check to make sure the installation has worked:

heroku --version

Next, log in to Heroku. I like to work on the CLI and you can log in right from the command line. You can log into Heroku by entering:

heroku login

That will open the Heroku login site where you can enter your login info. Or you can stay in the CLI to enter all of your information with:

heroku login -i

Now create your Heroku app. The docs will tell you to make sure you’re in the directory of your api. The command they give you to use:

heroku create

That will create a Heroku app, but it will have a randomly generated name. The way to make your own named app is a bit buried. This command will create an app with your preferred name (in this case, I’m calling it “app-name”:

heroku create app-name

Now check that you’ve got your remote repository set up:

git remote -v

You should see not only your git remote, but a Heroku remote as well. Additionally, if you already made your Heroku app, but want to connect the remote afterwards, you can use:

heroku git:remote -a app-name

You can also change the random name Heroku supplied to your app name with this command:

git remote rename heroku-name app-name

Those are the basics! Remember to git commit. Now push your creation to the host with:

git push heroku master

This is where the docs will tell you you’re done! Congratulations. When you visit your site, however, you might find some (or all) of your information is missing. What’s going on?! It might seem obvious, and it was certainly a facepalm when I finally figured out what I’d missed. I used Ruby on Rails for my back end and there are two little commands that are necessary to populate the database:

heroku run rails db:migrate
and
heroku run raild db:seed

Now your information is really there. You’ll start to breathe a sigh of relief until you actually visit the site. Heroku will direct you to your named site. Something like:

app-name.herokuapp.com

Where you’ll find… a 404! NOOO! It’s ok. Breathe. You just need to check one of your actual routes (one of your models in Ruby on Rails) to see if the information is there.

app-name.herokuapp.com/route

Great app, kid! One in a million!
— CLI Solo

I hope this walkthrough was helpful and your back end is deployed. In my next blog, I’ll tackle a Firebase deployment for the front end.