Using a badge to distinguish development and production environments

I’m currently working on a new and exciting app, and one issue I ran into is using the app in three different environments.

There’s development where I get to — nay, have to — do all the crazy stuff. The only way to catch bugs is to act like one. There’s staging, experimental but other people also accessing it. And there’s production. Production is for the well behaved.

Three different environments. A UI that looks identical in all three. I sense an accident waiting to happen.

So I added a badge that tells me which environment I’m using right now. Red is for development, yellow for staging, and if I don’t see a badge, must be running in production.

In application layout I added this line:

<%= content_tag :p, RAILS_ENV, class: RAILS_ENV, id: "rails-env" unless RAILS_ENV[/production/] %>

And in the stylesheet I have:

#rails-env { position: fixed; left: 1em; font-weight: bold; padding: .2em 0.9em; text-transform: uppercase; display: none }
#rails-env.staging { color: #000; background: #ffff00; border: 2px solid #cccc20; border-top: none; display: block }
#rails-env.development { color: #fff; background: #ff0000; border: 2px solid #cc2020; border-top: none; display: block }

You can see what it looks like here:

8 thoughts on “Using a badge to distinguish development and production environments”

Good idea. Setting opacity: 0.8 might be useful in case the badge occludes things. Or might be annoying. Or maybe set the z-index: -1?

I’ve done a similar thing, but I include a div (hidden) that includes any sort of performance metrics or request/session/environment elements I might want to see while debugging. Then, a simple jQuery call to toggle that div when clicking on the tab gives me extra info as needed. In fact, you can put this in production and only render it for admins, etc.

Still, always a good idea.

On Django projects I use a small badge which lists the current Git / SVN revision on non-production sites (i.e. if settings.DEBUG) – this is also a great way to make sure that any internal screenshots are traceable back to a specific point in time. It’s styled-inline to avoid external dependencies – something like “position:fixed; bottom:0px; text-aligned:center; width:100px; margin:auto” works pretty well for one line of text. For git try something like the output from “git describe –tags” – there are a bunch of permutations to match your preferences but the default format (–) is pretty useful.

On a more advanced note, ala Aaron H’s suggestion, steal ideas from the awesome django-debug-toolbar: http://robhudson.github.com/django-debug-toolbar/ – the new UI is very low impact (small badge in the upper right corner, offset down enough to avoid most nav) but expands into a really useful sidebar detailing SQL queries (with backtraces & explain support), template introspection, log messages, etc. I don’t use it in production (I prefer capturing data from real users and, if possible, doing so in a way which can’t cause their requests to fail) so it’s also a reliable cue that you’re not on the production site.