What's wrong with Rails.env ?

Question

Hi,

Today I implemented a small piece of code that include analytics only in production environment using something like:

<% if Rails.env.production? %>
  analytics here
<% end %>

I don't see anything wrong about it... however one of my c0-workers told me that it wasn't a good practice at all, that it would for sure introduce problems in a future maintaining phase and that was much better to set up a constant in the environment and do something like

<% if defined?(INCLUDE_ANALYTICS) && INCLUDE_ANALYTICS %>
  analytics here
<% end %>

I don't see such a big difference between these 2 approaches, however I would like to see what other developers think about it and how would other solve this in a better way :)

Answer 1

The only difference is that the second solution will let you deactivate analytics tracking while in production without having to change the code. You can set INCLUDE_ANALYTICS to false and you analytics will not be included. Using Rails.env.production? is surely not a problem, but you can't change behaviour of the application while in production mode.

Think of the following example: The servers of your analytics provider go down and the JavaScript that tracks the visits is blocking the page load in the browser. Your client want analytics to get deactivated until the issue has been fixed. Using your first solution, you'd need to find the place inside the code, remove that line and deploy the application. The second approach lets you change a global configuration file and everything is fine.

Answer 2

1. If the block contains another ruby code inside then Rails.env.production? is bad here as you are losing ability to test that block. Imagine you use helper inside which may explode on some pages. Simple controller tests with views just render pure HTML without loading any external resources and running JS, so it shouldn't affect your stats. Only browser based integrations tests (Selenium) may affect stats.

2. INCLUDE_ANALYTICS is quite good option, but usually there is too many of such constants in the application scope. The better option is to introduce YAML configuration file. It gives ability to define multiple production configuration files (main production, beta production without analytics etc...). Once used it helps externalize other settings easily.