Adding a staging environment to the workflow [clos

2019-01-31 13:07发布

问题:

I currently have two environments in which I work: development locally and production on Heroku.

I would like to add a staging environment on Heroku to see that everything goes as expected before pushing the app live to users. Preferably, the staging environment should have the exact same settings and data as the production environment.

What are the steps needed to accomplish the above?

回答1:

First the predispositions, i like to have my heroku git remotes set up as staging and production so you can easily use git push staging/production to deploy to each one of them. I'll be using that setup to explain how to make a staging env.

  1. create a config/environments/staging.rb which you will copy off `config/environments/production.rb'
  2. add a database.yml entry for the staging database(not really needed for heroku but can't hurt)
  3. Backup your .env file (if you have it)
  4. Install heroku-config plugin by heroku plugins:install git://github.com/ddollar/heroku-config.git
  5. pull your environment settings from heroku(production server) with heroku config:pull --remote production
  6. make changes to the .env file and don't forget to add these values to the config: RACK_ENV=staging RAILS_ENV=staging so it will use the staging environment configuration.
  7. fork a heroku environment with heroku fork -a production staging (those are heroku appnames you want instead of production/staging)
  8. Do a `heroku config:push --remote staging'
  9. Be sure to deploy the code to staging env properly

You can also read this tutorial, i think i used it to get started with multiple envs on heroku: https://devcenter.heroku.com/articles/multiple-environments#managing-staging-and-production-configurations



回答2:

I found the heroku fork -a PRODUCTION_APP_NAME NEW_STAGE_APP_NAME to be a faster, easier way to do it... it creates the new app, copies everything (including the postgres database). Then I went in and manually downgraded the addons to smaller plans when it made sense (for example, a starter tier database).

In fact, we started using the relatively new heroku pipeline:promote to manage automatically (and VERY quickly) pushing a compiled slug from staging to production. (That assumes you have any env-specific settings via settings or environment variables, so the code slug is the same.)



回答3:

Note that the procedure explained by berislavbabic is not recommended according to the following guide on Heroku's site: https://devcenter.heroku.com/articles/multiple-environments#managing-staging-and-production-configurations

You can read in detail there, but the recommendation is to keep the staging environment the same as the production environment and simply use heroku fork to copy from production to staging.