Julie wrote:
I thought the reason we use role:web, role:app and role:db was to make capistrano deploy differently to each server (different files).
Deploy differently means to perform different tasks on different servers. By default, the update_code task is not one of those different tasks, for reasons I'll get to below.
After doing some more reading I can see that update_code and symlink tasks apply to all 3 servers (app, db and web) by default. However, I need to do the following: 1) update_code, symlink and restart (with the full repository): on the app server 2) update_code with only current/public directory contents: on the web server (that's where I will put all the static data for the web application) 3) only perform migration: on the db server
There are going to be multiple gotchas if you treat your servers differently like this. 1) In order to perform the migrations on the db server, you will need to have, at a minimum, the contents under your application's db directory. If you create a migration that modifies your data using your models, then you need to have app/models, and config. You might need to have vendor. You might need to have lib. A new member joins your team, they aren't going to know that you have a non-standard deploy to your db servers. Migrations fail. Chaos ensues. 2) For the web server, if you only have the bare contents of the public directory what will you do when the deployment fails and needs to be rolled back? Suppose you change the images on your site at some release and the deployment fails for some other reason. If you don't have the symlinking to current, and you need to rollback, how are you going to do it? Granted that you don't need your applications app, lib, or even config directories on your web server, but this seems like a small saving for the maintenance penalty that you will incur. 3) Instead of having one deployment task that you can test on every machine, and is the de facto standard in the rails community, you are going to have to have 3 different deployment recipes that you write and maintain yourself. It's not clear to me why you would want to bother with this if you didn't have to.
For app server, everything is fine with the default version, web server is the problem one. Seems like I need to overwrite the update_code task and call my version rather than the default one, which means I also have to overwrite the deploy task.
Assuming you still want to do this, instead of messing with the default web tasks, you could just define a new role, say :asset and write a task that only checks out the contents of public into a location of your choice.
this is the default update_code of Capistrano, notice it applies to all 3 servers (I dont know why...):
Simplicity on the web server. Necessity on the db server.
I have also read the migration tasks in the standard.rb, default migrate task needs this variable migrate_target to be set to either current or latest. Can anyone clarify what's the difference between current and latest? AFAIK, "rake migrate" migrates it to the latest version and sets the current to the latest version.
Current is the current directory after the symlink is made. Since you might not have made the symlink yet, and might not want to make it if the migrate task is not successful, for instance, there is the capability to set the current working directory for the migration to the latest version that has been checked out. This has to do with the directory structure within which "rake migrate" is called. If you haven't make the symlink yet, and run "rake migrate" in the current directory, your changes won't be seen and won't be applied. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
