Heroku is basically our devops, e.g. it allows us to have a fully automated & continuous deployment strategy.
Our applications are hosted on Heroku. We use Pipelines to enforce our workflow:
master branch of the corresponding repo is automatically deployed to staging.
To deploy to production, a single click on Staging 'Promote to production' suffices.
Instead of stopping the existing set of web dynos before starting the new ones, preboot ensures that the new web dynos are started (and receive traffic) before the existing ones are terminated. This can contribute to zero downtime deployments.
Only caveat is that for a few minutes, there will be two versions of the code base running side by side, which might lead to inconsistencies. E.g. when removing a db column: maybe your migrations already ran, but a worker is still using the old code and thus tries to access the column.
So when we do migrations that won't support older code version (columns/tables removal/renaming), it is suggested to disable it:
# To disable:$ heroku features:disable -a app-name preboot# To enable again:$ heroku features:enable -a app-name preboot
In this case, add a [disable preboot] tag into your commit title, so that you or the other developer who will deploy your commit will remember doing it.