#72 Adding an Environment (revised)

Jan 19, 2012 | 4 minutes |

Rails comes with three environments: development, test, and production, but it is easy to add your own. Here I show how to add a separate staging environment and how to start up Rails under this.

Click to Play Video ▶

Download:
mp4Full Size H.264 Video (9.68 MB)
m4vSmaller H.264 Video (5.18 MB)
webmFull Size VP8 Video (6.19 MB)
ogvFull Size Theora Video (11.5 MB)

Dominik Menke almost 13 years ago

Is there a convenient way to separate view and controller logic depending on the environment? I have, for example, a "demo" environment which limits some of the functionality of the app. In result, I have many snippets like

          ruby
        
# in a view
<% if Rails.env.demo? %>
  <dt>Amount (fixed in demo)</dt>
  <dd>2</dd>
<% else %>
  <dt><%= f.label :amount %></dt>
  <dd><%= f.text_field :amount %></dd>
<% end %>

and a corresponding conditional in the controller (+ some modified models – but I don't think, there is a way around different behavior, is it?), which is some kind of messy, especially if only some fields are going to be unchangeable in the demo environment.

Maybe CanCan 2.0 could be a solution, since then the "demo abilities" are more or less centralized... But: would that be the right way?

—Dominik

Paul Gisbourne almost 13 years ago

wouldn't the rollout railscast help here? rollout & degrade

Dominik Menke almost 13 years ago

That also crossed my mind, but in this case it basically adds complexity. Instead of a Rails.env.demo?, I would have a rollout? helper call and an overhead through the feature set management (the demo-abilities won't change over time)

I've also thought of a custom form builder to shrink down the view overhead—but then I still need a comfortable way to define the accessibility restrictions…

—Dominik

Alexandre de Oliveira almost 13 years ago

What you can do is set config.rollout in your env file and then use App::Application.config.rollout.

For something more elaborated like App::Application.rollout?, you can create your own mixin and have method_missing verifying the actual variable.

cbmeeks almost 13 years ago

What about separating into partials and then:

          ruby
        
<%= render "myview_#{Rails.env}" %>

Then have the following partials:

myview_demo
myview_production

etc...

regis-leray almost 13 years ago

When i had a new environment staging, i have some issues with my dependencies.

im using rails 3.2.1, with bundler 1.0

when i running
$> rails c staging

i m getting this error

/home/regis/RubymineProjects/bb-rails3/config/initializers/devise.rb:3:in `': uninitialized constant Devise (NameError)

But with
$> rails c development (no issue)
$> rails c production (no issue)

I found a trick, if i put in my application.rb
require 'devise'
require 'cancan'
require 'rails_config'

All the errors disappear why im doing wrong ?

regis-leray almost 13 years ago

Oki my bad i found the solution in my Gemfile.

i forgot to add the new environment "staging" in the group where i declare all the gems i was using.

group :development, :test, :staging, :production do
gem 'will_paginate', '3.0'
gem 'devise', '1.5.3'
gem 'cancan', '1.6.7'
end

I hope it will help

Alexander Balashov over 10 years ago

Adding separate env for staging looks like not a good idea, because it will differ from real production. BTW you can use special service for stages https://teatro.io/ that will automate the whole process.

Ralph Larson over 7 years ago

Is there a convenient way to separate view and controller logic depending on the environment?