Deploy Code with Capistrano

Developing a web application isn’t going to do much good if we aren’t able to find a way for the world to see it. For other web frameworks,this can often be a tedious and time-consuming process. Application code needs to be updated, database schemas need to be migrated, and application servers must be restarted. We could do all of this manually by ssh into the server, pulling the latest code from the repository, running database migration tasks, and restarting the application server. Even better, we could write some shell scripts that would automatically perform these tasks for us. But why do all that when we could be spending time improving App instead?

The good news is that we don’t have to do all that.Battle-tested and used for deploying many of today’s Rails apps, Capistrano (originally authored by Jamis Buck and now ably maintained by Lee Hambley) is the tool that Rails developers have used for years to get their applications from development to production on a daily basis. It was built from the start for deploying Rails applications, and it has all the tools we need to get App deployed and to help keep deployments running smoothly afterward. Capistrano’s library of tasks, plugins, and utilities has also evolved over the years with the rest of the Rails ecosystem, and thus Capistrano continues to meet the deployment needs of Rails applications both new and old.

Configuration

Add capistrano gem to development environment

group :development do
gem 'capistrano', '~> 2.11.2'
end

Don't forget to bundle update. and check your capistrano instalation by: cap -H

Generate necessarily file with :

capify .

// Will generate:
[add] writing './Capfile' // created in project’s root directory and takes care of loading Capistrano’s default tasks
[add] writing './config/deploy.rb' // Rails asset pipeline tasks, and our primary deployment script
[done] capified!

Settings

Example of config settings in /config/deploy.rb

require 'bundler/capistrano'

// Configurations from repository
set :application, "massiveapp"
set :scm, :git
set :repository, "git://github.com/myapp/myapp.git"

// Tell capistrano about server address host
server "localhost", :web, :app, :db, :primary => true
// port running in server
ssh_options[:port] = 2222
// path to private key
ssh_options[:keys] = "~/.vagrant.d/insecure_private_key"

set :user, "vagrant"
set :stages, %w(staging production)
set :default_stage, 'staging'
set :use_sudo, false
set :group, "vagrant"
set :deploy_to, "/var/myapp"
set :deploy_via, :copy
set :copy_strategy, :export

namespace :deploy do
  task :start do ; end
  task :stop do ; end
  desc "Restart the application"
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
  end
  desc "Copy the database.yml file into the latest release"
  task :copy_in_database_yml do
    run "cp #{shared_path}/config/database.yml #{latest_release}/config/"
  end
end
// task that copy database.yml file into place, so we’ll put that here as well as a before directive that will force that task to be called as part of a deployment
before "deploy:assets:precompile", "deploy:copy_in_database_yml"

Setting in Server

From console application

cap deploy:setup

- /releases
- /shared
|- /log
|- /system
|- /pids

Each time we deploy, Capistrano will create a new subdirectory in the releases directory and place the source code for Application there. The shared directory will contain various, well, shared resources. Thus, shared/log will contain Application log files, and shared/system will contain any files that need to be kept from deployment to deployment. We also have shared/config, which we created with Puppet and which contains Application database.yml.

Push Command from Local

// as describe in /config/deploy.rb set_staging.
cap deploy staging

Read More