Where?

In the `config/environments` directory!

    config
    └── environments
        ├── development.rb
        ├── production.rb
        └── test.rb
  

But what are they?

    config
    └── environments
        ├── development.rb # <- ends with .rb, so it's ruby CODE
        ├── production.rb
        └── test.rb
  

The 11'th Holly Commandment

ALL THAT IS CODE SHALTH BE TESTED

RAILS ENVIRONMENTS BAD PRACTICES AND HOW TO AVOID THEM

So what are they supposed to be?

Runtime code optimisations:

Development: optimise for code reloading and developer experience

Test: a sandbox environment so tests can safely run

Production: optimise for performance

Bad Practice NO. 1

Confusing RAILS environments with DEPLOYMENT environments.

      export RAILS_ENV=development
      export RAILS_ENV=test
      export RAILS_ENV=production
  

- Using `development` locally

- Using `test` in CI

- Using `production` when deploying to the production "environment"

Since they're code...

You have to be able to run ALL of them BEFORE deploying.

Don't assume RAILS_ENV means deployment location

1. You have to be able to run with any RAILS_ENV on your local machine

2. You have to be able to run with any RAILS_ENV on any remote server

3. Don't hardcode deployment specific values... anywhere

Bad Practice NO. 2

Creating more rails environments.

You only need the 3.

No need for a `staging.rb` or a `uat.rb`. Use `RAILS_ENV=production`

Why?

You end up not testing the content of `production.rb` until you actually deploy to production.

BUGS! BUGS! BUGS!

What about...

Create a `staging.rb` file and have it contan:

    require_relative './production'
  

...and nothing else.

That's just `RAILS_ENV=production` with extra steps.

Plus you need to document the differences somehwere...

Bad Practice NO. 3

Using RAILS_ENV as a global feature flag:

    if Rails.env.production?
      # ... do one thing
    elsif Rails.env.development?
      # ... do another
    end
  

1/2: Again!

You end up not testing the content of `production.rb` until you actually deploy to production.

BUGS! BUGS! BUGS!

2/2 And...

Global feature flags are bad practice in general, you should have feature flags per feature.

Exceptions

You develop code for Rails internals

Development tools

Test runners

Performance optimisations

Actions

Improve your Rails codebase by:

- Differentiate between RAILS environments and DEPLOYMENT environments

- Removing deployment specific hardcodings

- Remove extra rails environments

- Use feature flags per feature

- Run with all RAILS_ENV locally before merging code

Thank You!

Q&A