CODEWITHSUNDEEP
ruby-on-rails-4configurationenvironment-variablesconventions
Dan L
Dan L

Reputation: 4439

Pain of configuring various environments in development and production (Rails 4 application)

As per best practices, my development team does not store the application config file in a repo for security reasons (we use a config/application.yml file to store configs). However, when we actually develop and deploy, this causes some problems:

  1. A developer needs to add a new external URL that is different depending on what environment the application is running in. Since there is no config file in the repo, he cannot update a single file that gets synced when another developer pulls the code. To make this happen, he updates his local config/application.yml file and then each other developer updates their local file, and then we have to add the new ENV variable to the server's config/application.yml. Has to be a better solution.

  2. If we stored the config/application.yml file in the repo and shared it among everyone and the servers, this solves the problem of sharing/updating global configs, BUT it opens up the possibility that a developer may accidentally start their local application in production mode and touch live data or spam real users with test emails (has happened which is why it's a concern).

Is there a standard best practice for solving these types of problems? It seems I either sacrifice productivity for security but can't really have both.

I've been thinking about creating a config/development.yml file in the repo that all developers share, which stores all environments EXCEPT production. That way they can share config/ENV items for development and sync them up. But in production, I would have a config/production.yml file that ONLY lives on the servers.

If the application is started in anything except production environment, it loads the development.yml file. If it is started in production, it loads the production.yml file. But since the production.yml file does NOT live in the repo (only on the servers), there's no chance that a developer can accidentally touch live data or spam real users, etc...

Have any professional developers tried a scheme like this? I've done a lot of googling but really haven't found a satisfactory solution.

Upvotes: 3

Views: 279

Answers (1)

Zac Hallett
Zac Hallett

Reputation: 494

Check out the RailsConfig gem. This allows you do to exactly what you stated, but with the ease of a gem. This also allows you and your dev team to have local yaml files that override settings.

config/settings.yml
config/settings/#{environment}.yml
config/environments/#{environment}.yml

config/settings.local.yml
config/settings/#{environment}.local.yml
config/environments/#{environment}.local.yml

You would then just have config/settings/production.yml within your .gitignore so that it will not be checked into source control.

Upvotes: 1

Related Questions