Comments on: Better setup for environments in Rails http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/ News and updates from the people at SmartLogic Solutions Thu, 04 Dec 2008 19:51:29 +0000 http://wordpress.org/?v=2.7-bleeding By: SmartLogic Solutions Blog » Blog Archive » Introducing environmentalize: an intuitive, environment-focused config structure for your rails applications http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/#comment-171 SmartLogic Solutions Blog » Blog Archive » Introducing environmentalize: an intuitive, environment-focused config structure for your rails applications Mon, 04 Aug 2008 19:30:22 +0000 http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/#comment-171 [...] couple of months ago, I wrote an article (Better setup for environments in rails) discussing the standard set of changes we make to the config structure of each of our rails [...] [...] couple of months ago, I wrote an article (Better setup for environments in rails) discussing the standard set of changes we make to the config structure of each of our rails [...]

]]> By: rick http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/#comment-63 rick Thu, 12 Jun 2008 14:23:55 +0000 http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/#comment-63 New developers have to create a database.yml (we have an app:bootstrap task that sets up the database.yml, the schema, and any initial data that's needed for a quick script/server demo), but that's it. Usually they don't need the staging or production info. But who knows, we have maybe 5 developers in my small company, usually all working on different things. I imagine the practices would have to evolve as the size of the team grows. New developers have to create a database.yml (we have an app:bootstrap task that sets up the database.yml, the schema, and any initial data that’s needed for a quick script/server demo), but that’s it. Usually they don’t need the staging or production info.

But who knows, we have maybe 5 developers in my small company, usually all working on different things. I imagine the practices would have to evolve as the size of the team grows.

]]> By: John Trupiano http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/#comment-62 John Trupiano Thu, 12 Jun 2008 12:04:29 +0000 http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/#comment-62 Nice-- so you more or less simulate an svn:externals. I do like keeping configuration out of the same repository, but does it add extra steps when a new developer hops onto the project? People raised some interesting points at Bmore on Rails. One I particularly liked was completely leaving SCM off of production servers by doing local checkouts and rsync'ing. Your procedure could fit in here when the local copy is checked out. Another thing to point out is that I'm currently leaving all of my non-production configuration on the production box (shame on me). It's not simple to restrict a single directory from being checked out (an ignore won't work, because you want those files in dev). I suppose your process would also aid me here. Nice– so you more or less simulate an svn:externals. I do like keeping configuration out of the same repository, but does it add extra steps when a new developer hops onto the project?

People raised some interesting points at Bmore on Rails. One I particularly liked was completely leaving SCM off of production servers by doing local checkouts and rsync’ing. Your procedure could fit in here when the local copy is checked out. Another thing to point out is that I’m currently leaving all of my non-production configuration on the production box (shame on me). It’s not simple to restrict a single directory from being checked out (an ignore won’t work, because you want those files in dev). I suppose your process would also aid me here.

]]> By: rick http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/#comment-61 rick Thu, 12 Jun 2008 10:26:19 +0000 http://blog.smartlogicsolutions.com/2008/06/02/better-setup-for-environments-in-rails/#comment-61 My approach to this issue is a bit different. After working with some smart sysadmins on a certain client project, and working with Engineyard, one common thread popped up: Using git to store things like your various server config files. In the same way, you can also store your production specific database.yml and any config initializers in git also. You can symlink these in the after callback for deploy:symlink_configs. I only like my approach slightly better because a) it doesn't require any changes to the framework or app config files, and b) I'm not checking those files into the same git repo as my application. My approach to this issue is a bit different. After working with some smart sysadmins on a certain client project, and working with Engineyard, one common thread popped up: Using git to store things like your various server config files. In the same way, you can also store your production specific database.yml and any config initializers in git also. You can symlink these in the after callback for deploy:symlink_configs.

I only like my approach slightly better because a) it doesn’t require any changes to the framework or app config files, and b) I’m not checking those files into the same git repo as my application.

]]>