CruiseControl.rb is a continuous integration tool for Ruby on Rails application. Its basic purpose is to alert members of a software project when one of them checks something into source control that breaks the build.
To run cruisecontrol.rb first download it from http://cruisecontrolrb.thoughtworks.com/
Unpack the downloaded file.
Then go to the folder from command prompt where it is unpacked
and run: cruise add project_name --url (url of your subversion trunk)
This will create a directory under [cruise_data]/project/project_name and then checks out your project from the subversion URL you provided to [cruise_data]/projects/project_name/work/
Now run: cruise start
This will start your web browser on port 3333
Browse http://localhost:3333 and press the “Build Now” button on the Dashboard to build your project.
After this every time any one checks something into source control cruise control automatically
builds your project and report about the Build Changeset , Test failures and errors, etc.
How to run cruisecontrol.rb for continuous integration of Ruby on Rails application
Sending mail asynchronously by using Amazon SQS and ActiveMessaging
From our application we send mail to our users in many cases. Sending mail synchronously slows down the whole process. So to improve our application’s performance we feel the need of sending mail asynchronously. And I have done it using the Amazon SQS and ActiveMessaging.
What is Amazon SQS:
Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly scalable, hosted queue for storing messages as they travel between computers.
Developers can push message to the queue any time and get the message when required. They can create an unlimited number of Amazon SQS queues, each of which can send and receive an unlimited number of messages. The message body can contain up to 8 KB of text in any format. A message is "locked" while a computer is processing it Messages can be retained in queues for up to 4 days
What is ActiveMessaging:
ActiveMessaging is a Rails plug-in framework, which simplifies messaging integration. It is a generic framework to ease using messaging, but is not tied to any particular messaging system - in fact, it now has support for Stomp, JMS (using Stomp Connect or direct on JRuby), WebSphere MQ, Amazon Simple Queue Service (SQS), and the all Ruby ReliableMessaging. With ActiveMessaging and Rails now you can loosely integrate with systems as disparate as mainframes sending MQ messages or J2EE webapps, offload processing long-running tasks, or create applications with event or message-driven architectures.
To integrate ActiveMessagin with your apllication
you have to install the following gem and pugin
gem install daemons
ruby script/plugin installhttp://activemessaging.googlecode.com/svn/trunk/plugins/activemessaging
First create a process using the following command
script/generate processor message
Running this generate for the first time outputs the following:
create app/processors
create app/processors/message_processor.rb
create config/messaging.rb
create config/broker.yml
create app/processors/application.rb
create script/poller
Now configure the broker.yml as which broker you are using.
I have used Amazon SQS as a broker. Here is my configure file
development:
adapter: asqs
access_key_id: xxxxxxxxxxxxxxxxxxxxxxxx
secret_access_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
test:
adapter: asqs
access_key_id: xxxxxxxxxxxxxxxxxxxxxxxx
secret_access_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
production:
adapter: asqs
access_key_id: xxxxxxxxxxxxxxxxxxxxxxxx
secret_access_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Define your own queue by changing the config/messaging.rb file
s.destination :queue_name, ' queue_name
Add the following to the controller from where you push message to the queue
require 'activemessaging/processor'
include ActiveMessaging::MessageSender
publishes_to : queue_name
def method_from_where_push_message_to_queue
publish : scrumpadmailer, “put the required value to process the message"
end
Add the following to the app/processors/message_processor.rb
subscribes_to : queue_name
def on_message(message)
begin
send mail by processing the message
rescue
publish : scrumpadmailer, “put the received message"
end
end
Now run the poller which monitors the queue continuously and upon receiving a message it calls the on_message method of app/processors/message_processor.rb
Go to your application directory and run the following command
ruby script/poller run
To run the poller as a background process in linux run the following command
nohup ruby script/poller run >> mail_logger.txt &
Everything is done. Now when a message is pushed in the queue the on_message method
Is triggered and mail will be sent
Automatic Deployment of Rails Application by Capistrano
Previously we deployed our application manually in our Linux box. This was taking a lot of time and after every deploy we were facing some serious issues. Automatic deployment by Capistrano has made deployment life easy. Here i have shared my experience about deployment by Capistrano.
Requirements:
Install Capistrano in local machine by : gem install capistrano
Install subversion command line client in local machine
Install subversion in Linux box. I have done it by a rpm
Assumptions:
- You are deploying to a single server, at least initially.
- Your username is the same for both your subversion repository and your deployment machine.
- Your subversion repository is accessible from both your local host, and the host that you will be deploying to
- You have configured a public key to use for SSH access to your target host
Run Capistrano:
From command prompt go to your application directory then run .capify.This will create a capfile in the application root directory and deploy.rb in config folder.
Configure deploy.rb:
Now modify the deploy.rb file to deploy your application. Here is my deploy.rb
require 'mongrel_cluster/recipes‘
set :application, “your application name"
set :repository, “url of your repository"
set :scm_username, “name"
set :scm_password, “password"
set :rails_env, "production --trace"
set :deploy_to, "/var/www/rails/#{application}"
#ssh configuration
set :user, ‘user_name'
ssh_options[:port] = 22
ssh_options[:username] = ‘user_name‘
ssh_options[:host_key] = 'ssh-dss'
#set app, web, db role
role :app, "www.scrumpad.com"
role :web, "www.scrumpad.com"
role :db, "www.scrumpad.com", :primary => true
#configure for mongrel cluster
set :mongrel_servers, 3
set :mongrel_port, 6010
set :mongrel_environment, 'production'
set :mongrel_conf,"#{deploy_to}/current/config/mongrel_cluster.yml"
Now the time for deploying your application:
Go to your project directory and run cap deploy:setup Capistrano will now log into your server and try to set up a simple directory hierarchy. The basic layout is:
#{deploy_to}/
#{deploy_to}/releases
#{deploy_to}/shared
#{deploy_to}/shared/log
#{deploy_to}/shared/system
#{deploy_to}/shared/pids
Every time you deploy your application, a new directory is created under the releases directory, and then a symlink is created at “#{deploy_to}/current that points at the newr elease. This current symlink should be considered the root directory of the currently active release.
run cap -q deploy:check to check dependencies.
Cold deploy: The first time your application is not running. Things are “cold”. For this case, run cap deploy:cold
Subsequent Deploys: After the first deploy every time you want to deploy just
run cap deploy
Roll back your application to the previous release cap deploy:rollback
Problem I faced:
After deploying my application on a Linux box, I faced some permission related problem to run the application. To solve this I had to put the required file in a directory and modify my deploy.rb in the following way:
after "deploy:symlink", :copy_permitted_files
task :copy_permitted_files, :roles => :app do
run "cp -rpf /var/www/rails/Permitted/public/* /var/www/rails/# application}/current/public/"
run "cp -pf /var/www/rails/Permitted/database.yml /var/www/rails/#{application}/current/config/"
run "cp -rpf /var/www/rails/Permitted/log/* /var/www/rails/#{application}/current/log/"
end