Once you finish this chapter, you will get an idea of all the steps that we need
to take to deploy to Heroku.
But to make your application work in Heroku, you would have to complete the
upcoming chapter
"Configure Sidekiq in Heroku"
and execute the steps mentioned there to make our Sidekiq jobs run as
intended.
Utilizing neetoDeploy for Application Deployment
All candidates undergoing orientation at BigBinary are required to utilize neetoDeploy for application deployment instead of Heroku. To facilitate this process, kindly post a message in the designated orientation Slack channel, addressing the responsible individual overseeing the orientation, requesting the essential documentation for deploying the application on neetoDeploy.
Add Uglifier
Uglifier is a Ruby wrapper for the UglifyJS JavaScript compressor. It is
required to compile the JavaScript assets.
Let's add the uglifier gem to the end of the Gemfile:
Add the highlighted line in the config/environments/production.rb file:
Update the manifest file
The manifest.js file inside the app/assets/config directory helps
Sprockets to determine which assets to include and serve.
Fully replace the manifest.js file with the following content:
Update engines in package.json
We should specify the version of node and yarn that our application is using
in the package.json file. If we don't specify the version then different
versions can be used in different environments and machines and it can result in
failure when building the application.
We can use the yarn -v command to find the current version of the yarn in
the system. The node version should be exactly same as the version we have
mentioned in the .nvmrc. We can define the version for different engines in
package.json, like this:
Creating a Heroku application
The first step in setting up Heroku is to
Sign Up for Heroku.
Then, install the Heroku CLI.
If you are using macOS, then run the following:
For Ubuntu/Debian based distros, the installation command is:
Now you should be seeing the current version number if the Heroku command-line
interface (CLI) installation was successful.
Once we’ve verified that the Heroku command-line interface is installed, we need
to use the following Heroku command to log in:
We will be redirected to authorize our account via browser.
Note: All the commands given below should be run from the root of the
granite project.
Finally, we need to create an application in Heroku. In this case, Heroku will
choose a random name for our application:
We will see the output something similar to this:
In the above command, we have also specified the Heroku stack while creating the
new Heroku application. A stack is an operating system image that is curated and
maintained by Heroku. According to the configuration of our granite application,
we should use the heroku-20 stack.
We can verify the selected Heroku stack using the heroku stack command like
so:
The output should show heroku-20 as the selected stack and will be like this:
If heroku-20 is not selected then we can update the Heroku stack in an
existing Heroku application using the command heroku stack:set <stack> like
so:
We can use the git remote command to confirm that a remote named heroku has
been set up for your app:
The output will contain the initialized heroku remote, and would look
something like this:
The name of the application will be different for everyone. We will refer to it
as <heroku_application_name> here on.
Setting up buildpacks
Heroku Buildpacks are sets of open source scripts that are used for compiling
apps on Heroku. They determine the build process for an app, and which assets
and runtimes should be made available to your code at runtime.
We will configure the following two buildpacks for our granite project.
Run the following commands from the root of your granite project:
Let's see the list of buildpacks we have:
Ensure that both nodejs and ruby are in the list of buildpacks.
The order of the buildpacks matter. So please ensure that the order is as shown
in the above output.
This is because the last buildpack in the list will be used to determine the
process types for the application. Any process types defined from earlier
buildpacks will be ignored.
We will learn more about process types in the upcoming Procfile section.
After the buildpacks are set we also need to update our lockfile yarn.lock. We
can do so by running:
This will make sure yarn.lock is up to date before we deploy our application.
Setting up Heroku for deployment
Before we can deploy our branch to Heroku, we need to make sure to add platform
x86_64-linux to our Gemfile.lock file, otherwise we will receive an error
saying:
We also have to push our code to Heroku. To do that we also have to commit our
code till now. We can add this new platform and commit the code by running the
following commands from the terminal:
Now let's deploy the application to Heroku. Let's execute the following command
to deploy our application to Heroku:
We should not push the code from the local development branch to Heroku. If we
are working on a local development branch, we should first create a PR and merge
it with the main branch. After merging pull the latest changes to the local main
branch and then push from the main branch to Heroku using the above mentioned
command that is git push heroku main. If we want to see the deployment for a
pull request we should use the "Review Apps" which are discussed later in this
chapter.
We need to manually migrate the database. This is important as we have to
apply all the migrations in the production database. Therefore, don't forget to
run the following command:
To view the newly deployed application on the browser, execute the following
command:
Note: The app may not be fully operational as we haven't set up Sidekiq in
Heroku. We will set it up in the upcoming chapter.
Setting up auto deployment
- Log into Heroku and go to the overview page of the deployed application.
- Click on the
Deploy tab.
- In the
deployment method section, select GitHub and provide the GitHub
details.
- Scroll to the
Automatic deploys section and select the branch to be
deployed. Let's keep it main for now.
- Click on the
Enable Automatic Deploys button.
- Then, Heroku will display the message "Automatic deploys from
<branch_name>
is enabled".
The <branch_name> will be main by default.
Now anytime code is pushed to that branch, Heroku will automatically deploy the
latest code from that branch.
Heroku commands
The following are some useful commands that will help you debug Heroku
application from your terminal itself.
To get into the Rails console of the deployed application, run the following
command:
To check the logs of the application:
Renaming the application
The auto-generated Heroku application names always look pretty weird.
We can rename the deployed application to <new_application_name> from the
initial <heroku_application_name> by executing:
The <new_application_name> can be of the form
granite-[github_username]-production. You can replace the [github_username]
with your GitHub username so that the application name is unique.
Strictly use your GitHub username in your Heroku app name. Unique
identification of your Heroku app is important.
The -production suffix signifies that it is the production version of the app
and we can easily differentiate it from the other review apps. We will learn
about review apps in the next section.
An example app name for the GitHub user named yedhink:
Setting up the Heroku pipeline
Heroku pipelines allow us to
have a review app for each pull request. This is immensely useful in testing. We
no longer need to pull down all the changes and run the application locally to
see the application in action.
Here are the instructions to set up review apps for PRs:
-
Enter the name of the pipeline as "granite-pipeline".
-
Select your granite repository and then click on "Connect".
-
Then click on "Create pipeline".
-
Now click on "Enable Review Apps".
-
Check "Create new review apps for pull requests automatically".
-
Choose a region - "United States".
-
Click on "Enable Review Apps".
-
Now when we send a pull request, Heroku will create a new review app for the
corresponding PR.
- When you click on "View Deployment", the review app will open up in a new tab.
This saves us a lot of time. This is especially useful while reviewing a PR.
app.json file
The app.json file enables developers to define their application's details,
setup configurations, and runtime environments in a structured way. Setting up
an application for deployment is an error-prone and time-consuming task. With
the help of app.json file, we can set up our application for deployment in a
fast and efficient way.
app.json is a manifest file that defines the process of how the code can be
built into a live application. Instead of performing the same steps manually
every time we want to setup a review application in Heroku, we can define the
app.json with all the details and dependencies and add this file to the root
source of the code's directory.
An example app.json file would look something like the following:
Let's check some of the specifications mentioned in the above shown example of
app.json file:
Under this property, we can define the various scripts or shell commands to
execute at different stages.
It shows which Heroku stack or
Heroku OS is used for the application.
This property carries an object consisting of all the config variables required
for the application's runtime environment.
It's an array of strings and objects specifying the necessary Heroku add-ons
required by the application.
It's an array of objects specifying the URL of the required buildpacks to build
the application. The order of buildpacks in the array matters. The buildpack
mentioned earlier in the array will be loaded first.
Please note that this app.json file is only used for setting up the review app
in Heroku. We cannot automate deploying or setting up the other pipeline
instances using this file.
For more details refer to the
app.json schema article
from Heroku documentation.
The upcoming chapter is a continuation of this chapter. Please go through the
next chapter too, to make the app working in Heroku.
There is nothing to commit in this chapter since all we had done was
deploying application on Heroku.
