Adding a Staging Environment to the Workflow

Adding a staging environment to the workflow

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

Optimal workflow for Local / Staging / Production server stack + Git

Branches are one way to facilitate this workflow. There is a great blog post about how to use Git branches to manage a typical development workflow.

You would then have one branch for production (e.g. master), one for the live-edits which correspondes to the hotfix branch in the post above, and another one for development.

To sync your local environments on laptop and desktop, you can use the aforementioned development branch also as a remote branch and have both devices push their local commits on this branch to the remote repository.

How to set up a staging environment on Google App Engine

I chose the second option in my set-up, because it was the quickest solution, and I didn't make any script to change the application-parameter on deployment yet.

But the way I see it now, option A is a cleaner solution. You can with a couple of code lines switch the datastore namespace based on the version, which you can get dynamically from the environmental variable CURRENT_VERSION_ID as documented here: http://code.google.com/appengine/docs/python/runtime.html#The_Environment

git with development, staging and production branches

The thought process here is that you spend most of your time in development. When in development, you create a feature branch (off of development), complete the feature, and then merge back into development. This can then be added to the final production version by merging into production.

See A Successful Git Branching Model for more detail on this approach.

---

Related Topics