I'm posting a few "recipes" for capistrano that I've found useful.
These are all working on a production system using Capistrano 2.4.3. I
welcome and criticism/suggestions of the techniques... just be
nice ;-)
Cheers.
1. Using github with capistrano:
- if you're using a public repository...
> set :scm, :git
> set :repository, "git://github.com/user/#{application}.git"
- if you're using a private repository, create a keypair and add the
public key into your repository's deploy keys
> set :scm, :git
> set :repository, "[EMAIL PROTECTED]:user/#{application}.git"
2. Keeping database.yml outside of my source repository:
- after running deploy:setup, create a shared/config/database.yml and
link to it with the following task
> after "deploy:symlink", "deploy:db:symlink"
>
> namespace :deploy do
> namespace :db do
> desc <<-DESC
> Updates the symlink to database.yml. When you deploy a new version, \
> this task's job is to update the `config/database.yml' symlink \
> to point at the shared version. You will rarely need to call this task \
> directly; instead, use the `deploy' task (which performs a complete \
> deploy, including `restart') or the 'update' task (which does
> everything \
> except `restart').
> DESC
> task :symlink, :except => { :no_release => true } do
> run "ln -fs #{shared_path}/config/database.yml
> #{current_path}/config/database.yml"
> end
> end
> end
3. Depending on non-gem libraries (e.g. ruby-odbc)...
- add the following mixin to your deploy.rb (and replace "odbc" with
whatever library you depend on)
> # extend capistrano's remote dependency checking to handle libraries
> require 'capistrano/recipes/deploy/remote_dependency'
> Capistrano::Deploy::RemoteDependency.class_eval do
> def lib(name, options = {})
> @message ||= "library `#{name}' could not be found"
> try("ruby -r#{name} -etrue 2>&1", options)
> self
> end
> end
>
> ...
>
> depend :remote, :lib, "odbc"
4. Changing the current branch for a remote cache when using
subversion...
- when deploying using subversion "set :deploy_via, :remote_cache" the
branch has to be the same as it was on the preceding deployment... you
can work around this by changing how capistrano gets the latest source
from subversion... so now you can cahnge the value of :repository to a
new branch when you deploy and subversion will deal with it
> require 'capistrano/recipes/deploy/scm/subversion'
> # use switch instead of update to sync the subversion repository (so that it
> handles a possible repository change)
> Capistrano::Deploy::SCM::Subversion.class_eval do
> def sync(revision, destination)
> scm :switch, verbose, authentication, "-r#{revision}", repository,
> destination
> end
> end
5. Rollback the database schema when rolling back code...
- sometimes changes to the schema (via migrations) render different
versions of your application incompatibile with the schema requiring
the database (structure) to be rolled back if the code is rolled back
> before "deploy:rollback_code", "deploy:rollback_database"
>
> namespace :deploy do
> desc "Rolls back database to migration level of the previously deployed
> release"
> task :rollback_database, :roles => :db, :only => { :primary => true } do
> if releases.length < 2
> abort "could not rollback the code because there is no prior release"
> else
> rake = fetch(:rake, "rake")
> rails_env = fetch(:rails_env, "production")
> migrate_env = fetch(:migrate_env, "")
> migrate_target = fetch(:migrate_target, :latest)
>
> run "cd #{current_path}; #{rake} RAILS_ENV=#{rails_env} #{migrate_env}
> db:migrate VERSION=`cd #{File.join(previous_release, 'db', 'migrate')} && ls
> -1 [0-9]*_*.rb | tail -1 | sed -e s/_.*$//`"
> end
> end
> end
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
