|Last Updated On||February 21st, 2015 - 5:00pm EST|
|Notes||Works with other versions of Rails with small modifications.|
As you are probably aware, Ruby on Rails has 3 distinct environments it runs in. The first, development, is used for writing application code. It typically has full debugging support enabled along with a number of useful tricks that makes it easier to build the application. The next environment, test, is used for running unit/behavioral testing. The final environment, production, is used when the application is running on a production web server. It's optimized for speed and almost all debugging features are turned off.
In this article we will show you how to create your own customized environment. For the purposes of this example we will create a staging environment. Staging environments typically mimic production as close as possible and allows us to quickly fix issues that may arise in an actual production environment. Let's get started.
Creating a Custom Environment
To create a custom Rails environment we must perform a couple of different steps. First, we must create a config file for the new Rails environment. Next, we must modify our secrets.yml and add a secret key base for the new environment. Next, we must modify our database.yml to add database credentials for the new environment. Next, we may have to perform additional steps such as compiling assets if asset debugging is disabled. Finally, we have to run the Rails server and or console under the new environment.
To get started, let's first create a copy of
/config/environments/production.rb. We will call this file
staging.rb and it will go in the same path.
Now we need to modify our secrets.yml file and add a new entry for staging. To do this, first we will need to set a new environment variable containing our secret. Run the command below to generate that secret, then copy it to the clipboard.
Next, open up the .bash_profile file in your home directory. In OS-X you can typically type
open -e ~/.bash_profile and it will open up the file in TextEdit. If you are using Linux, you can use your favorite text editor (example:
vim ~/.bash_profile) to edit the file. Once the file is open, add the line listed below to the bottom of the file, replacing "YOUR SECRET KEY" with the secret key you copied earlier.
export SECRET_KEY_BASE="YOUR SECRET KEY"
source ~/.bash_profile to load the changes you made.
Next we need to modify our
config/secrets.yml file. Open up your secrets.yml file and modify it so that it looks like the code listed below.
# Be sure to restart your server when you modify this file. # Your secret key is used for verifying the integrity of signed cookies. # If you change this key, all old signed cookies will become invalid! # Make sure the secret is at least 30 characters and all random, # no regular words or you'll be exposed to dictionary attacks. # You can use `rake secret` to generate a secure secret key. # Make sure the secrets in this file are kept private # if you're sharing your code publicly. development: secret_key_base: <%= ENV["SECRET_KEY_BASE"] %> test: secret_key_base: <%= ENV["SECRET_KEY_BASE"] %> staging: secret_key_base: <%= ENV["SECRET_KEY_BASE"] %> # Do not keep production secrets in the repository, # instead read values from the environment. production: secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
You'll notice that we not only added an entry for staging, but we also switched the other environments to use the secret key base stored in our environment variable. This file could be cleaned up even more, but for the purposes of this article we will leave as is.
Next, we need to create an entry in our database.yml that tells Rails where to get the database config. In this example application we are using SQLite 3 so we simply copy paste productions and change it from production to staging.
# SQLite version 3.x # gem install sqlite3 # # Ensure the SQLite 3 gem is defined in your Gemfile # gem 'sqlite3' # default: &default adapter: sqlite3 pool: 5 timeout: 5000 development: <<: *default database: db/development.sqlite3 # Warning: The database defined as "test" will be erased and # re-generated from your development database when you run "rake". # Do not set this db to the same as development or production. test: <<: *default database: db/test.sqlite3 staging: <<: *default database: db/staging.sqlite3 production: <<: *default database: db/production.sqlite3
Now if you start your rails server (use
rake assets:precompile RAILS_ENV=production
If you start your rails server, you'll notice that the scripts and stylesheets are now working as they should. Great!
What if we want to conditionally load a gem for staging? It's pretty simple actually, simply use the
:staging rails group like below.
group :development, :test, :staging do # Call 'byebug' anywhere in the code to stop execution and get a debugger console gem 'byebug' # Access an IRB console on exception pages or by using <%= console %> in views gem 'web-console', '~> 2.0' # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring gem 'spring' end
Then run the following command to install the staging gems.
- For this staging example, modifying pages won't be reflected on a page reload, instead you'll have to stop and restart. the Rails Server.
- You can also optionally set an environment variable called RAILS_ENV which corresponds to the Rails environment you wish to use. This saves some typing.
- You can open the rails console by typing
rails c <environment>. For example:
rails c staging.
That's it! Thanks for reading!