Heroku
What is Heroku?
As you most probably know, we use Heroku for all our hosted environments. Here is how our most beloved chat would define it:
Heroku is a cloud platform as a service (PaaS) that enables developers to deploy, manage, and scale web applications and services with ease.
Basically, this is the tool that allows us to easily & continuously push to prod. This is most commonly called as CD (Continuous Deployment).
Pipeline
One of the greatest features of Heroku is that it works like a Pipeline.
For example, our Squarehub pipeline is divided in 3 sections:
Review apps (which can contains many apps)
Staging (which only contains the Staging app)
Production (which only contains the Production app)
By default, our pipeline will always consists of at least 2 apps (Staging & Production), and as many apps as there are PR opens.
An app, regardless of its environment, will always be structured the same way.
Before diving into the specs of each sections, let’s have a look on how apps are structured on Heroku.
App Example
Let’s focus on the Staging application:
You can see multiple tabs, the first one being “Overview” which we landed on. This section, as it states, is an overview of everything related to this application.
You can see some metrics, the add-ons, the dynos & the build/deploy activity (we’ll cover those in depth a bit later).
Resources
This is where you’ll find all add-ons installed for this app, in this case we have:
Bonsai Elasticsearch
Heroku Postgres
Heroku Data for Redis
Heroku Scheduler
Papertrail
Deploy
This is a section you’ll barely visit, as it’s mostly config that’s already done. Nevertheless, there may be one interesting thing to know: you can do manual deploy from here.
Here is how it works: just click on the “Deploy Branch” button, and it’ll we trigger a new deploy.
Be careful, in this case we’re on the staging app but it’s the main branch that’s written in the input.
If you need to manually deploy Staging, you’ll need to change main to staging in the input.
If you’re doing it for Production, the branch will be main.
Metrics
This section is not very useful, as we’re going to see later we use some resources (add-ons) that are better tools.
Activity
This is where you can find all builds & deploys for an app. This is mostly interesting when promoting to prod (check that the build & the deployment was successful). An other important use-case is that you can easily roll back to a previous deploy if something broke.
For each deploy, you can “Compare diff” to see the files changes in Github and “Roll back to here” to force Heroku to build & deploy to a previous version.
However, it can be needed to check as well while developing. For example, you’re developing a feature and you want to test it in a hosted environment.
For that, you’ll spawn a review app and test it there.
However, the thing you want to test works well in local but does not in the review app. It might be anything, but first thing to check is:
Did my code was truly deployed?
If the build or the deploy failed, it’s 100% normal that you don’t have the expected result. If not, the issue lies somewhere else, but at least you’ve narrowed down the possibilities.
Access
This is the place where you set up users permissions.
Settings
A lot of settings there, including the most important one: the environment variables.
As they’re called, they are variables linked to a specific environment.
It’s the equivalent of your .env file which contains your locale environment variables.
What’s next?
Now that we’ve covered the basics, let’s focus on the beginning of the pipeline: The review apps.
Last updated