Making a Friendly Multiuser Rails Database Configuration Files
Many people and sites recommend not checking in your database.yml file directly in the subversion repository but instead check in a database.example.yml file that each developer is responsible for modifying themselves. The reason for this is because if other developers are working on the project at the same time you will both end up clobbering the file as one person changes the information to match their machine and you change yours back to match your machine.
Fortunately the database.yml (along with all the other rails config files) can contain code in them. This makes is possible to write this:
For development and test configurations we use a local database that runs on our local development box with the username we logged in with but for the production server it runs as the 'deploy' user.
There is no need for passwords because the database servers are configured to not accept connections from remote sources.
For our small development team we find this solution works great and there is no need to special case our deployment to the production server by having a step to copy the production database.yml file. It may not work in some cases but for small development teams this might make your life a bit easier.
Fortunately the database.yml (along with all the other rails config files) can contain code in them. This makes is possible to write this:
development:
adapter: postgresql
database: critic_development
username: <%= ENV['USER'] %>
test:
adapter: postgresql
database: critic_test
username: <%= ENV['USER'] %>
production:
adapter: postgresql
database: critic
username: deploy
For development and test configurations we use a local database that runs on our local development box with the username we logged in with but for the production server it runs as the 'deploy' user.
There is no need for passwords because the database servers are configured to not accept connections from remote sources.
For our small development team we find this solution works great and there is no need to special case our deployment to the production server by having a step to copy the production database.yml file. It may not work in some cases but for small development teams this might make your life a bit easier.
Labels: backend, development, rails

0 Comments:
Post a Comment
<< Home