Deploy Without Worry


My last post was about the power and flexibility of deploying an app with one command. The drawback that I didn’t get to touch on was the lack of third-party plugins, open source build packages, and a dashboard that could communicate to multiple teams using data visualization of the load of your app and its security. I am not going to write any additional notes comparing my previous post on Now and this post on Heroku, but I will mention that it is a great idea to deploy using both methods (if you are a JavaScript developer). Heroku has (like AWS) the ability to deploy using multiple languages and frameworks.

Heroku is built on the idea that app development should be intent on scalability and security. While there is a little more work involved in preparing your app for deployment, Heroku was created so that the process could be as painless as possible. Complexities including infrastructure, provisioning, and management are part of what makes it difficult to deploy your apps without heavy lifting on these fronts. Heroku is a tool to streamline this process.

In order to examine how we can use Heroku to deploy an app, even at the early stages, let’s create a bookstore app that will be deployed via Heroku and use Heroku’s add-on Heroku Postgres. This will not be a thorough walkthrough of the app build; rather, we will look at benchmark moments in our app build process specific to the deployment process. This will be a two-part post, so here we will look at how early we should deploy.

For this example, we are going to build and deploy as early as possible. That’s right, as early as possible. Even if we just deploy hello world, we will be in great shape. For the first commit and setup, I am going to assume that you have made a commit and pushed to a GitHub master.

Now (even with a simple express app printing “Hello World!” to the console), let’s set up Heroku to deploy. After creating a login, you’ll notice that you have your choice of language to start up your Heroku app. I wouldn’t click on the Create New App button—I would click on the language of choice.

We will select Node.js, which takes us to this screen:

Step by Step

A great quality of Heroku is that it includes a step-by-step guide on deployment. (Even though AWS and Azure have guides, they are not as explicit as this one, in my opinion.)

For setup, you should definitely use the command line. Thankfully, Heroku has a CLI to help with app management. Once you have downloaded the CLI, you may begin the setup by logging in (note that the credentials here will be the same as those you used to create your Heroku account on the browser:

Okay, so you logged in—That should allow you to use Heroku commands on the terminal to deploy.

*Important security note (direct from the Heroku team via the Node.js team): The Node.js team has announced that a high severity remote Denial of Service (DoS) Constant Hashtable Seeds vulnerability in Node.js versions 4.x through 8.x has been patched in the following versions:

If you are using Node.js because you are following along, or because it is your backend language preference, then make sure you are at one of these node versions!

Heroku uses git for version control, and for its build/deploy process, which makes it very easy to manage. You push to Heroku like you would push a master branch to a remote GitHub repository. This allows for separation of development pushing of code vs. production pushing of code.

Prepare to app

In this step you will prepare a simple application that can be deployed.

To clone the simple application so that you have a local version of the code that you can then deploy to Heroku, excute the following commands in your local command shell or terminal:

The next step is deploying the app. To do this, even with a simple printout to the console of “Hello World”, you’ll still need to include code in your app that will account for the production environment. The way I’ve done this is by setting up a www file in a bin folder:

Keep your express middleware and instructions in your app.js file, and import it into this www file so that you can create a server off the app and set up the port to either listen at localhost 3000, or the port that is assigned by Heroku at the point of deployment. The rest of the www file should include error handling. If you want to generate a solid example of a www file, then I would encourage you to use express-generator. I would use it as a template, but, it’s also good to read the code and learn how to set this up manually so you can dive deeper into the node http process.

Here is a quick look at the app.js file I created. (Again, we are just printing “Hello World” to the console.)

Time to Deploy

In this step you will deploy the app Heroku.
Create an app on Heroku, which prepares Heroku to receive your source code.

When you create an app. a git remote ( called heroku) is also created and associated with your local git repository.

Heroku generates a random name ( in this case sharp-rain-871) for your app, or you can pass a parameter to specify your own name.

Heroku is explicit about its instructions, and when you execute the heroku create command, you will generate a git repository and a random name for the app.

The next step is pushing your master to the Heroku git master. My recommendation is that you have a fully updated master already pushed to your GitHub repository. Once you have that set, you can then execute the command git push heroku master. (Note that you do not need to create a git remote for Heroku. It does that for you when you execute the create command—easy peasy.)

Since we are using Node.js, the Heroku build process will notice that.

Heroku compresses the build source and then launches it to the random app name in the https URL. You can cmd click the URL or copy/paste into your browser’s address bar to see the app in production, which for us is:

So we have now deployed our app. Deploying at every stage is a great tool to test your app, and avoid the big surprise of long hours of development, only to find that deploying adds time to ship your product. Deploy early and often! In part two, we will finish creating the bookstore, and using the Heroku Postgres plugin. See you then, and happy coding!

Do you think you can beat this Sweet post?

If so, you may have what it takes to become a Sweetcode contributor... Learn More.

Phillip Lorenzo is a recent graduate of Learners Guild, an apprenticeship program in Oakland, CA. Before beginning his journey to code, Phil was in nonprofit arts management and was also pursuing a filmmaking career. He started coding last January, and hasn’t looked back since.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *