Labnotes

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:

Oct 8th, 2009

Patrick Mueller

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?

Oct 8th, 2009

Aaron H.

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.

Oct 8th, 2009

Chris Adams

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.

Oct 8th, 2009

Assaf

Django’s debug toolbar gave birth to Rail’s Rack::Bug:

http://github.com/brynary/rack-bug

I did not have the best experience with Rack::Bug so far.

Oct 8th, 2009

Stephen

Nice.

On an app a few years ago, my friend had the idea to change the whole background color–the content itself was in a white box so still legible.

It got to where people referred to the multiple dev/qa instances (it was an enterprise app) by color–app-pink, app-orange, app-black, etc.

Oct 17th, 2009

Alex Chaffee