Staging environment, effortlessly.


When you work in a team on a web app it is important to reguraly test your code before releasing it in production, expecially when major improvements occur. At Sellf we have our own staging enviroment and thanks to RoR, Heroku and Figaro gem it is a piece of cake to set it up. For those that don’t know Figaro, it is a gem that allows to configure Rails apps in a clean and simple way through a yml configuration file. The cool think is that it automatically integrates in your local app and provides a rake task to to configure your application ENV on Heroku.

#1 Customize staging.rb file

The first thing to do is to create a new environment file, called staging.rb, into the config/environments directory of your Rails app. It is enough to copy the existing production.rb file and parametrize those variables that need different values depending on the environment they are intended.
E.g. if you want to integrate the ActionMailer both in production, development and staging environment you can config the default url and asset host as the following:

config.action_mailer.default_url_options = {
    :host => ENV['MAILER_HOST']
  }
config.action_mailer.asset_host = "http://#{ENV['APP_DOMAIN']}.herokuapp.com"

The parametrization is necessary to use Figaro, as we’re gonna see in the next steps.

#2 Create staging app

Now it is time to create a dedicated Heroku application to receive the staging git push:

 heroku create --remote staging

Remember to add all the Heroku add-ons you need, expecially those already installed within the production app.

#3 Add ENV specifications to Heroku

Now it is critical to tell Heroku which environment it should run for this staging app instance. This is very important because Figaro will use automatically the RAILS_ENV configured on the Heroku server in determining the proper configuration.

 heroku config:add RACK_ENV=staging RAILS_ENV=staging --remote staging

#4 Configure the application.yml file

Once you have the staging app it is time to properly namespacing the application.yml required by Figaro gem. If you haven’t already installed this gem, do it as explained in this guide. Recalling the ActionMailer example, you can namespace the application.yml file as the following:

production:
  APP_DOMAIN: appname-production
  MAILER_HOST: bucket.website-production.com.s3.amazonaws.com
staging:
  APP_DOMAIN: appname-staging
  MAILER_HOST: bucket.website-staging.com.s3.amazonaws.com

#5 Push ENVs to Heroku

Thanks to Figaro you can push all the environments variables specified into the application.yml file through a bash command, passing the name of the corresponding Heroku app. E.g. for the staging environment:

figaro heroku:set -e [staging] --remote staging

Tips

  • Now that there are more than one repo and Heroku app for the same project you need to specify the repo/app you are dealing with everytime you deploy and run rake tasks. E.g. for the staging enviroment you should call the commands:
git push staging master
heroku run rake db:migrate --remote staging
  • Remember to configure your databases in config/database.yml if it is needed, and add any other configuration blocks for the staging environment in other YAML files (such as the Amazon S3).

Lastly, I suggest to manage your environment in combo with the great branching model git-flow by @nvie. Take a look at this awesome cheatsheet created by created by Daniel Kummer.


Questo articolo è stato pubblicato in Blog da r4m . Aggiungi il permalink ai segnalibri.
  • michaelhawkins

    The rake task in step #5 has been replaced by figaro heroku:set -e [environment-name]

    • Thanks Michael I updated the post accordingly with your note. Cheers!