Staging

Staging is our last step before production, so this app should always be stable. The app is always online, so you won’t have to create it. You’ll either push directly to it (quickfix) or squash & merge a PR into it.

How is it built?

Compared to review apps, it is not done automatically by Heroku. The built of this application is triggered by a Github Action, if every check passes.

Those actions are defined in our codebase: .github/workflows/ruby.yml

It’s divided in four sections:

Name

The name of the action (no shit)

On

This defines when the action should run, basically when we:

• push on main or staging

• push on pull request from main or staging

Concurrency

This is a config that cancels a running action if a new one is triggered (this is to avoid a waste of resource from Github, as every minutes of a Github Action is paid).

Jobs

This is the heart of the Github Action, this is the place where we actually define what it should do.

In our case, it’s split in two:

• Test: Runs every time, and basically do a few checks (CVE, linters, unit testing,…)

• Deploy: Runs only on staging and prod and only if the “test” section has succeeded. This is what tells Heroku: “Ok, we’re good on our side, you can go ahead for the build & deploy”).

This is the main difference with reviews apps, where:

• Only tests are ran from the Github Actions (no deploy for Review App)

• Deploy is automatically done by Heroku, regardless of the test status

In summary, if you push to a review app, it will simultaneously trigger:

• The testing section of the Github Action

• The deployment on Heroku

If you push to staging or main (don’t do that last one, except when rebasing staging onto main AKA promoting to prod), it will trigger IN ORDER, and only if the previous step succeeded:

• The testing section of the Github Action

• The deployment of Heroku (triggered by the Github Action, if the testing succeeded)

---

Last thing on our pipeline (but definitely not last): our production application.