2

I'm working in a team in a Rails project.

Each of us have a local database for development purpose. We have a problem: Everyone have different configuration for the local database. When someone make a commit without reset the /config/database.yml the other members of the team can't use their database because the access is not configured.

Can I have a local configuration not commited? To each one can works without problem and without the need of re-set the file every time? Sometime like the local_settings.py in Django

joseglego
  • 2,011
  • 1
  • 17
  • 28

2 Answers2

4

You can configure the database in Rails via both the config/database.yml file and the DATABASE_URL env var. They are merged but settings from DATABASE_URL take precedence.

A good solution is to check in the config/database.yml with a basic configuration thats just enough to support postgres.app or whatever is the most common solution.

Developers that need other settings can set the DATABASE_URL env var to customize the database configuration. Gems like figaro and dotenv make this easier.

If you have ever wondered this how Heroku manages to use the correct DB no matter what you throw into database.yml and the DATABASE_URL ENV var is how you should be configuring your production DB.

Why should I use ENV vars and not more database_*.yaml files?

The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.
https://12factor.net/config

max
  • 96,212
  • 14
  • 104
  • 165
  • It was an excellent answer. I really thanks. I say nothing but accepted before. I take this time to say thanks. And tell you we took the idea of the DATABASE_URL. We are using it. – joseglego Aug 19 '16 at 19:20
  • In 2021 you can consider using the Rails encrypted secrets which offer some security benifits over env vars. – max Jun 16 '21 at 11:46
2

Add config/database.yml in to the .gitignore file at root path of your rails-app. Copy config/database.yml with the values you need for production into config/database_example.yml. Now you can modify your local database and in production you copy config/database_expample.yml to config/database.yml

If the config file is ignored by git, everyone can change it locally without getting tracked by git.

EDIT: HERE YOU SEE HOW YOU CAN REMOVE FILE FROM TRACKING!!! Ignore files that have already been committed to a Git repository

Community
  • 1
  • 1
DenicioCode
  • 8,668
  • 4
  • 18
  • 33
  • this works only if you haven't already commited config/database.yml. Git ignore doesn't ignore committed files. In our system we don't even have database.yml checked in. We have various database.production.yml and so on, each having placeholders in them. At deploy time the correct version is found and the placeholders replaced with real data (so that that data is nowhere checked into our repo). THEN you can add your local version of database.yml to .gitignore and it works fine. – jaydel Aug 17 '16 at 17:03
  • Still seems like a very un-convention over configuration approach and a very hacky solution to a problem which ENV vars handle better. – max Aug 17 '16 at 17:28
  • I agree, ENV vars are always better. But in this example I showed how to use gitignore not to change current workflow. – DenicioCode Aug 17 '16 at 17:55
  • I've seen this system setup at a few jobs now. I probably wouldn't choose to use it, but it's not a hacky, one-off solution by any means. Oh and the edit you added to show how to ignore committed files completes your answer nicely so +1 – jaydel Aug 17 '16 at 18:19