Why even have a staging environment?

Unless you’re running the exact same operating system on the exact same hardware, there’s a chance your development environment will be just a little bit different than your production environment. Heroku is a wrapper for Amazon services, so it’s safe to assume there’s no way you can be running the exact same hardware and software as Amazon.

And since you’ll only want to push working, tested code to production, you need a way to be absolutely sure your code will work before you open it up to your users. Enter, your staging environment: another development environment that mirrors the hardware of your production environment.

How I use my staging environment

After my feature branches are complete and are merged back into dev, I double-check my tests and push to my staging environment on Heroku.

The only difference between my staging environment and production are my environment variables. Assets are stored in a different S3 bucket, I use my development Stripe API so nobody’s credit card accidentally gets charged, and my RACK_ENV is changed to “staging” for environment-specific code (like Airbrake tagging). My staging environment only requires one dyno, and since your first dyno on Heroku is free, my staging environment is completely free to me.

Here’s how to create your staging environment on Heroku:

• create another Heroku app with the same add-ons as your production Heroku app
• rename your git remotes to point to production, staging and (optionally) github
• add any necessary environment variables
• push your app to staging and test

Start another Heroku app

We’re going to assume you already have a production app setup and running the way you like it, so you probably already know that the Heroku gem lets you start a new Heroku app directly from the command-line.

Since we’re attempting to create an exact mirror of production, we’ll also want to install the same add-ons on our staging environment. Luckily for us, the Heroku gem lets you install a comma-delimited list of add-ons at app creation.

First, get a list of the add-ons you use on production:

$ heroku addons
custom_domains:basic
mailgun:starter


Next, copy that list of add-ons and add them to the end of the Heroku creation command, separated by commas:

$ heroku create --stack cedar --addons custom_domains:basic,mailgun:started
Creating cold-sky-1696... done, stack is cedar
Adding custom_domains:basic to cold-sky-1696... done


You now have a Heroku app called “cold-sky-1696″. You can verify this by logging into heroku.com.

Rename your git remotes

Next, we’ll want to add your new staging environment to your git config. Open your git file and create a remote called “staging” with the URL to your heroku repository URL (obviously replacing cold-sky-1696 with your Heroku app name:

[remote "staging"]
url = git@heroku.com:cold-sky-1696.git
fetch = +refs/heads/*:refs/remotes/heroku/*

Optionally, you can rename your production and Github remotes. I use “production”because I am highly creative. Be sure to change the URL’s to match your Heroku repo URL.

[remote "production"]
url = git@heroku.com:my-production-heroku-app.git
fetch = +refs/heads/*:refs/remotes/heroku/*

Add any API keys or config options as environment variables

If you have environment variables, you can set them now. My environment variables include keys for APIs like Stripe and config options for setting this development’s name.

Note the --app specification at the end of the line. Now that you have multiple apps present, you’ll need to append --app to the end of most Heroku commands – like rake, restart and console.

Push to staging

Now, you can push your code by using the standard git push command:

$ git push staging master
Counting objects: 50, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (27/27), done.
Writing objects: 100% (27/27), 5.13 KiB, done.
Total 27 (delta 22), reused 0 (delta 0)

-----> Heroku receiving push
-----> Ruby/Rails app detected
-----> Configure Rails 3 to disable x-sendfile
Installing rails3_disable_x_sendfile... done
-----> Configure Rails to log to stdout
Installing rails_log_stdout... done
-----> Gemfile detected, running Bundler version 1.0.7
All dependencies are satisfied
-----> Compiled slug size is 17.6MB
-----> Launching... done, v124
http://cold-sky-1696.heroku.com deployed to Heroku

To git@heroku.com:cold-sky-1696.git
456e9b9..bfa53c3 master --> master

Remember to run a rake db:migrate and any data population scripts you may have, since this is a brand new app with a brand new database.

Everything look good? Push to production.

Once you push your app, run migrations and are certain everything is working the way that it should, you can push to production the same way you pushed to staging:

$ git push production master

It’s been a while since there was a new CSS spec, and while it’s probably very far away from being fully supported in enough browsers, the W3C published an update to their CSS4 draft recently.

Of most interest is the update to CSS selectors. For example:

ul > $li > p { border: 1px solid #ccc; }

The $ allows for styling of the parent method WITHOUT styling the child! In the above example, you would be styling a line item that contains a paragraph tag. Handy, no? Very.

Click here to view the entire CSS4 spec draft.

[thx @ david walsh]

A handy shortcut that will checkout and track a remote branch for you:

git checkout -t origin/branch-name

It’s the -t that makes all the difference. Delicious.

Just saved me about an hour’s worth of work:

$ git checkout branch file


If you work on multiple Git branches throughout your workday, you probably  find yourslef constantly git branch‘ing more than you’d like.

Instead, why not add your current Git branch to your command prompt?

Just add this to your ~/.bashrc file:

That creates a command prompt that looks like this:

jeff@lookitdev Resources dev-MEM59 :

That’s your username at your current hostname, your current folder, and your current Git branch.