Comments on: Developer-Specific Environments in Rails http://www.webficient.com/2008/10/01/developer-specific-environments-in-ruby-on-rails Your Web Development Partner Fri, 12 Mar 2010 07:06:38 +0000 http://wordpress.org/?v=2.6 By: Phil Misiowiec http://www.webficient.com/2008/10/01/developer-specific-environments-in-ruby-on-rails#comment-210 Phil Misiowiec Thu, 02 Oct 2008 16:03:53 +0000 http://www.webficient.com/?p=558#comment-210 Hey Glenn - great point! The last thing you wanna do is store sensitive info under source control. I've been involved with other projects where this approach was used, and we simply had a database.sample as a template under source control for the benefit of new developers and kept the .yml version local. In our projects, we typically create a new db user for each app to avoid exposing root credentials. Also, I toggle between a desktop and laptop, so I prefer keeping my (non-sensitive) settings under source out of convenience, if nothing else. Hey Glenn - great point! The last thing you wanna do is store sensitive info under source control. I’ve been involved with other projects where this approach was used, and we simply had a database.sample as a template under source control for the benefit of new developers and kept the .yml version local.

In our projects, we typically create a new db user for each app to avoid exposing root credentials. Also, I toggle between a desktop and laptop, so I prefer keeping my (non-sensitive) settings under source out of convenience, if nothing else.

]]> By: Glenn Gillen http://www.webficient.com/2008/10/01/developer-specific-environments-in-ruby-on-rails#comment-209 Glenn Gillen Thu, 02 Oct 2008 12:06:18 +0000 http://www.webficient.com/?p=558#comment-209 Is there any reason you couldn't just stop database.yml from being checked in to subversion/mercurial/git? That was every developer can have their own setup with whatever they want using the standard approach. Have capistrano deploy the real database.yml into production. It's the way every rails team I've worked on has structured it. Also prevents root passwords from being in version control, and if you're particularly anal places an extra burden on the devs for finding out what the production root passwords are Is there any reason you couldn’t just stop database.yml from being checked in to subversion/mercurial/git? That was every developer can have their own setup with whatever they want using the standard approach. Have capistrano deploy the real database.yml into production. It’s the way every rails team I’ve worked on has structured it.

Also prevents root passwords from being in version control, and if you’re particularly anal places an extra burden on the devs for finding out what the production root passwords are

]]>