Deployment

The tenant platform currently has two deployments:

• The development deployment is synced to the master branch and hosted at demo.justfix.org.

• The production deployment is synced to the production branch and hosted at app.justfix.nyc.

Deployments occur when a deployment's respective branch is pushed to and its test pass. This behavior is defined in .circleci/config.yml, and its status can be observed at Jobs » JustFixNYC » tenants2 on CircleCI.

Deploying to development

Just issue a PR against the default (master) branch. Once the PR is merged, the development instance will be updated.

Deploying to production

Preferred method: fast-forward merge from master into production

The preferred way of deploying to production is to merge master into production via the command-line, which should result in a fast-forward. This is preferred to a formal GitHub PR because a PR would create a merge commit, which would then require merging back into master, which is a hassle.

This can be done via e.g.:

git checkout production
git merge master --ff-only
git push

Alternative method: pull request from master into production

However, if the person making the deployment doesn't have permission to push directly to production, they can do so via a pull request from master into production. Just make sure to merge the PR using a merge commit (do not squash or rebase, as this will result in very different histories for the two branches, making future merges confusing).

Once the PR is merged, production should be merged back into master to ensure that both branches are in-sync.

Fallback method: using deploy.py from the command-line

If CircleCI or GitHub is down, a deployment can be made by running deploy.py heroku directly from the command-line. This requires setting up the Heroku CLI and is generally discouraged.

Migrations and zero-downtime deploys

As of #1366 we have support for Heroku preboot, which allows us to have zero-downtime deploys. Because the vast majority of our deploys to production don't involve database migrations that would break old backend code running against our database, this is the default way that production deploys work: any migrations that run are assumed to be backwards-compatible, the site is never put into maintenance mode, and new dynos are booted up and running before old dynos are decommissioned. This makes new deploys seamless for end-users.

However, if a backwards-incompatible database migration is required, developers should disable Heroku preboot prior to pushing to production. This will cause the deployment script to put the site into maintenance mode while migrations are run, and then Heroku will immediately decommission all dynos running old code before starting up new dynos, which will result in a couple minutes during which network requests to the site will appear to "hang" to visitors. The combination of this hanging with the prior maintenance mode screen isn't great, so such pushes should preferably be done when the site has few visitors.

Once the push to production has been made, developers should re-enable Heroku preboot.