Adding a staging environment to the workflow [closed]

Question

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?

Trochanter

Answer 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

Hydrosome

Thank you so much for the detailed explanation. I started by getting my head around the concept of staging/production remote-setup, and once that was in place I started to wonder - what are the actual benefits to separate the production/staging environments? I would typically have two local branches: master/development, and when the development has been pushed and reviewed on the staging remote, I would merge development -> master and push it to production remote. – Trochanter

You should have the staging env, same to your production env to see the how the app really performs in the production environment, and to be able to have the product owner/s test the features before they go into production. Most of the issues TDD can't really catch are for example css regressions that you can easily skip, or the always bellowed asset hell can break somewhere. Short thing, have a staging env, should be the same config as the production one, you don't have to have the same beast of the server, just be sure the stack is completely the same, down to deployment. – Hydrosome

when I run the heroku config:pull command I get config:pull is not a heroku command. Downloaded toolbelt a few days ago for mac: heroku-toolbelt/3.2.1 (x86_64-darwin10.8.0) ruby/1.9.3 – Borges

@jpwynn you have to install the heroku-config plugin, sorry i forgot to add that. devcenter.heroku.com/articles/… – Hydrosome

Anyone else getting PG::DataCorrupted errors when they try to migrate after following babinho's steps? – Realgar

Answer 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.)

Borges

Answer 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.

Coextend