# Capistrano deployment questions == Best practice type ones **URL:** \ **Category:** Rails\ **Created:** [July 6, 2006, 7:18pm UTC](https://www.ruby-forum.com/t/capistrano-deployment-questions-best-practice-type-ones/97383 "2006-07-06T19:18:44Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Mats\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e79b87/32.png) [@Mats\_P](https://www.ruby-forum.com/u/Mats_P)\ **Post date:** [July 6, 2006, 7:18pm UTC](https://www.ruby-forum.com/t/capistrano-deployment-questions-best-practice-type-ones/97383/1 "2006-07-06T19:18:44Z")
Hi everyone, I’ve been sold on the whole idea of using Capistrano for deployment of my sites and have successfully deployed three apps in three different environments all with success. As I’m trying to configure my sites I’ve encountered a number of issues/questions hence this post. 1. Database.yml Twice I’ve been stumped by apps refusing to work on the host because I did not include the database.yml file in my SVN repos. How does everyone else handle this point ? In my mind, I would like to store it in the /shared directory so that it remains in location for each release. Is there a reason why this is NOT the default function today ? It seems to me that Capistrano does so much else, why not this little bit too? I’m thinking of creating a ‘deploy\_db’ task that takes the local database.yml and uploads it into this location that is run at some point in the process. When is the key question in my mind ? 1. /tmp/cache, /tmp/sessions etc This is also in the release version directory. Is there a valid reason for this as well, or can I move the whole /tmp directory into / shared/tmp ? Why is this not the default already ? 1. Local Rails & Plugins On a shared host - like Dreamhost - it’s advised to freeze rails with your app. Freeze normally stores rails inside /vendor/rails which is also on per versions basis. I’ve tested on a local staging server and it seems possible to run an app with a symlinked /vendor/rails. Would this introduce any issues I can’t think of right now ? The same with Plugins. I’d really appreciate some feedback or comments on the above before I proceed. Kind regards, Mats * * * “TextMate, coding with an incredible sense of joy and ease” - [www.macromates.com](http://www.macromates.com) - “RubyOnRails, joyful web development! Nothing more nothing less.” - [www.rubyonrails.com](http://www.rubyonrails.com) - ---
**Author:** ![Mats\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e79b87/32.png) [@Mats\_P](https://www.ruby-forum.com/u/Mats_P)\ **Post date:** [July 6, 2006, 9:41pm UTC](https://www.ruby-forum.com/t/capistrano-deployment-questions-best-practice-type-ones/97383/2 "2006-07-06T21:41:29Z")
Mats P. wrote: > 1. Database.yml > > […] > > I’m thinking of creating a ‘deploy\_db’ task that takes the local > database.yml and uploads it into this location that is run at some > point in the process. When is the key question in my mind ? I seems to me that this should work. Remember to soft link it (ln -nfs) to #{release\_path}/config/database.yml. I do similar things with other files in :after\_update\_code. [no opinion on tmp/\*…] > 1. Local Rails & Plugins > > On a shared host - like Dreamhost - it’s advised to freeze rails with > your app. Freeze normally stores rails inside /vendor/rails which > is also on per versions basis. I’ve tested on a local staging server > and it seems possible to run an app with a symlinked /vendor/rails. > Would this introduce any issues I can’t think of right now ? On Dreamhost, I built my own binaries for ruby et al. in /home//local/bin. I liked this solution better than exposing myself to random acts of updating or freezing Rails in each app. It works fine, though I have to remember to edit the paths in public/dispatch\*. I do this via a :before\_restart Capistrano task. > The same with Plugins. Wouldn’t all your applications load all your plugins in this case? –Al Evans ---
**Author:** ![Mats\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e79b87/32.png) [@Mats\_P](https://www.ruby-forum.com/u/Mats_P)\ **Post date:** [July 6, 2006, 10:55pm UTC](https://www.ruby-forum.com/t/capistrano-deployment-questions-best-practice-type-ones/97383/3 "2006-07-06T22:55:22Z")
Apologies for opening my mouth and removing all doubts… On 6 Jul 2006, at 20:41, Al Evans wrote: > Mats P. wrote: > > > 1. Database.yml > > I’m thinking of creating a ‘deploy\_db’ task that takes the local > > database.yml and uploads it into this location that is run at some > > point in the process. When is the key question in my mind ? > > I seems to me that this should work. Remember to soft link it (ln - > nfs) to #{release\_path}/config/database.yml. I do similar things > with other files in :after\_update\_code. Why soft link ? What does that do ? Never encountered that one before, so don’t get it right now. > local/bin. I liked this solution better than exposing myself to > random acts of updating or freezing Rails in each app. It works > fine, though I have to remember to edit the paths in public/ > dispatch\*. I do this via a :before\_restart Capistrano task. WOW, do I understand you correctly (??) but do you mean you compiled your own Ruby 1.8.4 and etc on a normal DH a/c ? IF so, how did you manage to do so? Any pointers or are welcome. Does that speed up the site, or just insulates you against DH’s activities ? I’m on poprock and alondra at DH in case it matters. God, I’d really like to have my own server, but it’ll have to wait awhile. > > The same with Plugins. > > Wouldn’t all your applications load all your plugins in this case? Yes, that’s kind of the idea. It’s all about DRY over here 😉 Honestly though there are three apps all running with basically the same plugins so it’s better to keep just one in there, as long as that does not cause any conflicts. I should probably just use svn:externals more than I am though 😉 Kind regards, Mats * * * “TextMate, coding with an incredible sense of joy and ease” - [www.macromates.com](http://www.macromates.com) - ---
**Author:** ![Mats\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e79b87/32.png) [@Mats\_P](https://www.ruby-forum.com/u/Mats_P)\ **Post date:** [July 6, 2006, 11:01pm UTC](https://www.ruby-forum.com/t/capistrano-deployment-questions-best-practice-type-ones/97383/4 "2006-07-06T23:01:55Z")
On 7/6/06, Mats P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > WOW, do I understand you correctly (??) but do you mean you compiled > your own Ruby 1.8.4 and etc on a normal DH a/c ? IF so, how did you Hi Mats, you can visit this page [http://wiki.dreamhost.com/index.php/Collaboa](http://wiki.dreamhost.com/index.php/Collaboa) to have a feeling of what you need to do if you want your own binaries. [http://wiki.dreamhost.com/index.php/Ruby\_on\_Rails](http://wiki.dreamhost.com/index.php/Ruby_on_Rails) also has some good insghtings about using local gems. Cheers. ---
**Author:** ![Mats\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e79b87/32.png) [@Mats\_P](https://www.ruby-forum.com/u/Mats_P)\ **Post date:** [July 6, 2006, 8:26pm UTC](https://www.ruby-forum.com/t/capistrano-deployment-questions-best-practice-type-ones/97383/5 "2006-07-06T20:26:16Z")
On Jul 6, 2006, at 1:17 PM, Mats P. wrote: > database.yml and uploads it into this location that is run at some > point in the process. When is the key question in my mind ? I’ll just address this part, but the technique is useful other places. My database.yml is placed into svn and works standalone. The defaults are the login and connection used by production in this example, but you could “hard-code” the production values, too. To override the settings, simply place a file in config/mydatabase.yml containing the lines indicated by the comments and adjust as needed. For example, the login defaults are fine, but I want to change the connection method on my local machine: ### config/mydatabase.yml connection: &connection host: localhost socket: /tmp/mysql.sock ###EOF ### config/database.yml # MySQL (default setup). Versions 4.1 and 5.0 are recommended. # # Get the fast C bindings: # gem install mysql # (on OS X: gem install mysql – --include=/usr/local/lib) # And be sure to use new-style password hashing: # [http://dev.mysql.com/doc/refman/5.0/en/old-client.html](http://dev.mysql.com/doc/refman/5.0/en/old-client.html) # vvv Copy the following two YAML maps to a file called config/ mydatabase.yml login: &login username: demo password: demo connection: &connection host: 127.0.0.1 port: 3306 # ^^^ Copy the previous two YAML maps to a file called config/ mydatabase.yml \<%= file = File.join(RAILS\_ROOT, “config”, “mydatabase.yml”) IO.read(file) if File.exist?(file) %\> development: adapter: mysql database: demo\_development \<\<: \*login \<\<: \*connection # Warning: The database defined as ‘test’ will be erased and # re-generated from your development database when you run ‘rake’. # Do not set this db to the same as development or production. test: adapter: mysql database: demo\_test \<\<: \*login \<\<: \*connection production: adapter: mysql database: demo\_production \<\<: \*login \<\<: \*connection ###EOF Since the database.yml is passed through ERB, you can do a lot between ruby and YAML. I don’t put the config/mydatabase.yml files into svn and keep other config/\*database.yml files on my development machine. You could have conditional settings based on environment variables or anything else that Ruby can gets its hands on. -Rob Rob B. [http://agileconsultingllc.com](http://agileconsultingllc.com) removed\_email\_address@domain.invalid ---
**Author:** ![Mats\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e79b87/32.png) [@Mats\_P](https://www.ruby-forum.com/u/Mats_P)\ **Post date:** [July 7, 2006, 2:47pm UTC](https://www.ruby-forum.com/t/capistrano-deployment-questions-best-practice-type-ones/97383/6 "2006-07-07T14:47:43Z")
Mats P. wrote: > > I seems to me that this should work. Remember to soft link it (ln - > > nfs) to #{release\_path}/config/database.yml. I do similar things > > with other files in :after\_update\_code. > > Why soft link ? What does that do ? Never encountered that one > before, so don’t get it right now. A soft link is the same as a symbolic link. That means it points to whatever file is _named_ database.yml, as opposed to a hard link, which links a second name to a specific file, regardless how you rename it. > WOW, do I understand you correctly (??) but do you mean you compiled > your own Ruby 1.8.4 and etc on a normal DH a/c ? IF so, how did you > manage to do so? Any pointers or are welcome. Does that speed up the > site, or just insulates you against DH’s activities ? I’m on poprock > and alondra at DH in case it matters. God, I’d really like to have my > own server, but it’ll have to wait awhile. It’s not like having your own server, but it does insulate me against DH’s activities, at least with regard to Ruby, Rails, what Gems I have installed, and a few other things (ImageMagick, for one). I didn’t “manage to do so”, I just sort of did it, like I’d install software in any other UNIX system. The link given in the message from Francesco Levorato gives you the basic steps. > > > The same with Plugins. > > > Wouldn’t all your applications load all your plugins in this case? > > Yes, that’s kind of the idea. It’s all about DRY over here 😉 > Honestly though there are three apps all running with basically the > same plugins so it’s better to keep just one in there, as long as > that does not cause any conflicts. I should probably just use > svn:externals more than I am though 😉 I guess if you’re using the same plugins in all your apps, it makes sense to have just one copy. You could try moving the vendor/plugins directory from one of your apps somewhere else, removing it from the app/vendor directory, and ln -s /path/to/plugins /path/to/app/vendor/plugins, then restart your app and see if it works. If so, you’re golden, and you can remove the plugins directory from your other apps, make a link to the global plugins directory, and restart them. If not, just move the plugins directory back where you found it. Personally, I keep everything under Subversion, and use svn:externals for all my plugins. –Al Evans ---
**Author:** ![Mats\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e79b87/32.png) [@Mats\_P](https://www.ruby-forum.com/u/Mats_P)\ **Post date:** [July 8, 2006, 1:55am UTC](https://www.ruby-forum.com/t/capistrano-deployment-questions-best-practice-type-ones/97383/7 "2006-07-08T01:55:07Z")
Al Evans wrote: > Mats P. wrote: > > > > I seems to me that this should work. Remember to soft link it (ln - > > > nfs) to #{release\_path}/config/database.yml. I do similar things > > > with other files in :after\_update\_code. > > > > Why soft link ? What does that do ? Never encountered that one > > before, so don’t get it right now. > > A soft link is the same as a symbolic link. That means it points to > whatever file is _named_ database.yml, as opposed to a hard link, which > links a second name to a specific file, regardless how you rename it. > > > WOW, do I understand you correctly (??) but do you mean you compiled > > your own Ruby 1.8.4 and etc on a normal DH a/c ? IF so, how did you > > manage to do so? Any pointers or are welcome. Does that speed up the > > site, or just insulates you against DH’s activities ? I’m on poprock > > and alondra at DH in case it matters. God, I’d really like to have my > > own server, but it’ll have to wait awhile. > > It’s not like having your own server, but it does insulate me against > DH’s activities, at least with regard to Ruby, Rails, what Gems I have > installed, and a few other things (ImageMagick, for one). I didn’t > “manage to do so”, I just sort of did it, like I’d install software in > any other UNIX system. The link given in the message from Francesco > Levorato gives you the basic steps. > > > > > The same with Plugins. > > > > Wouldn’t all your applications load all your plugins in this case? > > > > Yes, that’s kind of the idea. It’s all about DRY over here 😉 > > Honestly though there are three apps all running with basically the > > same plugins so it’s better to keep just one in there, as long as > > that does not cause any conflicts. I should probably just use > > svn:externals more than I am though 😉 > > I guess if you’re using the same plugins in all your apps, it makes > sense to have just one copy. You could try moving the vendor/plugins > directory from one of your apps somewhere else, removing it from the > app/vendor directory, and ln -s /path/to/plugins > /path/to/app/vendor/plugins, then restart your app and see if it works. > If so, you’re golden, and you can remove the plugins directory from your > other apps, make a link to the global plugins directory, and restart > them. If not, just move the plugins directory back where yndorou found it. > > Personally, I keep everything under Subversion, and use svn:externals > for all my plugins. > > –Al Evans Be careful sharing the plugin as plugins evolve over time with your application and the dependency is broken if individual component are also not tightly released. I would rather have it in my vendor folder and take on extra overhead for the sake of versioning. But again this raises the question: Do u need to go back to a previous version. I am thinking more or less practically. If it is just a version or two then sharing is ok. But if u go back 3 or 4 then plugin dependency could cause trouble. Just a thought. aj aj