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
