Forum: Radiant CMS deploying radiant 0.9.1 with capistrano

I've done some searching on a guide for how to use capistrano + git +
bundler to deploy radiant 0.9.1 but haven't had much success in
finding something comprehensive. Is deploying radiant the same as
deploying a Rails app?

I do my development on a MacBook and have a staging and production
server that I want to deploy to. Can anyone share some guidance around
how to set up a deployment workflow?

Should I use bundler or go without it?
Should I use the capistrano extension? @ 
https://github.com/ehaselwanter/radiant-capistrano-extension

Thanks as always for the help.

Fima

The capistrano extension provides a nice set of cap recipes to use when 
deploying radiant. Here's what my personal capfile (actually deploy.rb) 
looks like:


set :application, "demo"
set :deploy_to, "/var/www/#{application}"
set :user, "USERNAME"
set :scm_user, "SCM_USERNAME"
server "SERVER_ADDRESS", :app, :web, :db, :primary => true
set :scm_password, Proc.new { Capistrano::CLI.password_prompt("SVN 
password for #{scm_user}, please: ") }
set :repository, Proc.new { "--username #{scm_user} --password 
#{scm_password} --no-auth-cache svn+ssh://#{scm_user}@SVN_REPO_ADDRESS" 
}


ssh_options[:user] = "USERNAME"
# will change based on your ssh key file
ssh_options[:keys] = ["#{ENV['HOME']}/.ssh/cap-ec2"] #cap-ec2-key.pem
default_run_options[:pty] = true


namespace :deploy do
task :start, :roles => :app do
run "touch #{current_release}/tmp/restart.txt"
end

task :stop, :roles => :app do
# nada
end

desc "Restart Application"
task :restart, :roles => :app do
run "touch #{current_release}/tmp/restart.txt"
end
end







Bradley Herman | iGoDigital® Personalized Product Recommendation 
Software | Cell 317.331.9718 l Office 888.496.2446x716
www.igodigital.com

On Dec 14, 2010, at 2:10 PM, craayzie wrote:

> I've done some searching on a guide for how to use capistrano + git +
> bundler to deploy radiant 0.9.1 but haven't had much success in
> finding something comprehensive. Is deploying radiant the same as
> deploying a Rails app?

Our cap recipes don't differ that much from a standard Rails app. Most 
of the additions are rake tasks, and we do overwrite deploy:migrate, so 
that existing Rails-based cap tasks and hooks will still fire in the 
right sequence.

If you're deploying to different environments or servers, I'd recommend 
using the capistrano-ext gem. It lets you do this:

    $ cap staging deploy
    $ cap production deploy

You can tailor your recipes and cap variables based on the environment. 
Here's the relevant parts of our Radiant recipe:

Capistrano::Configuration.instance.load do
    namespace :radiant do
        desc "Updates extension assets"
        task :update_assets do
            run "cd #{current_path} && rake 
radiant:extensions:update_all RAILS_ENV=#{stage}"
        end
        after 'deploy:symlink', 'radiant:update_assets'

        desc "Migrates Radiant extensions"
        task :migrate_extensions do
            run "cd #{release_path} && rake db:migrate:extensions 
RAILS_ENV=#{stage}"
        end
        after 'deploy:migrate', 'radiant:migrate_extensions'
    end

    namespace :deploy do
        task :migrate, :roles => :db, :only => { :primary => true } do
            rake = fetch(:rake, "rake")
            rails_env = fetch(:rails_env, "production")
            migrate_env = fetch(:migrate_env, "")
            run "cd #{release_path}; #{rake} RAILS_ENV=#{rails_env} 
#{migrate_env} db:migrate"
        end
    end
end

You guys are awesome will give this a shot. Where does bundler fit into 
all of this?

I'm not entirely sure, but I would imagine you would just create a task 
for installing the bundle in your cap file. LIke deploy:bundle:install 
or something along those lines.


Bradley Herman | iGoDigital® Personalized Product Recommendation 
Software | Cell 317.331.9718 l Office 888.496.2446x716
www.igodigital.com

hm .. if you're not using bundler then maybe i shouldnt either? maybe 
it's
overkill for a noob like me who's just starting out w/ ruby / radiant. 
how
do you handle the case where you want to play around w/ a gem in your 
dev.
environment but not deploy it to production?

I have investigated a solution with bundler capistrano radiant and rvm
for the company I am currently working with several weeks ago.

The deploy.rb file starts with this line: #require "bundler/
capistrano"

It has a simple task to install the bundle on the remote server, which
looks like this:

task :bundle do
  run "cd #{release_path} && bundle install --without test"
end

And gets called before the symlink with this line: before
"deploy:symlink", :bundle

I have to start another radiant project which uses the same
infrastructure next week, so I might come across some errors which
luckily have not occurred so far. :-)

I hope this helps
Christoph

Thanks for all the helpful posts. So I've got capistrano deploying my
github-hosted application to my staging server. Works great! I'm not 
using
bundler yet as I'm not sure of the benefits there. One of the problems 
I'm
running into is deploying migrations (capistrano complains that it's not
able to find /config/database.yml in the current release directory).

I've found a couple of blog posts describing solutions to the issue e.g.
http://www.simonecarletti.com/blog/2009/06/capistr...

I'm curious why none of your deploy.rb scripts contained any reference 
to
the database config file. How are you guys deploying migrations?

On Dec 16, 2010, at 3:58 AM, Fima Leshinsky wrote:
> I'm curious why none of your deploy.rb scripts contained any reference to the 
database config file. How are you guys deploying migrations?

That's a general concern for all Rails apps, not specific to Radiant. 
AFAIK common practice is still to keep database.yml out of source 
control and maintain a separate copy on each staging or production 
server. We symlink ours from the shared path to the current checkout on 
each deploy:

    namespace :deploy do
        desc "Symlink necessary files into current dir"
        task :symlink_configs do
            run "ln -sf #{shared_path}/database.yml 
#{release_path}/config/database.yml"
            # copy any other sensitive configs or initializers you might 
need -- S3 keys, etc.
        end
        after 'deploy:update_code', 'deploy:symlink_configs'
    end

How you get database.yml into your shared path is another matter. The 
blog you linked to has a recipe for that as well.