Capistrano::Fanfare

Notice: This README is under active development.

Coming soon...

Add this line to your application's Gemfile:

gem 'capistrano-fanfare'

And then execute:

$ bundle

Create a Capfile that looks like:

load 'deploy'

require 'capistrano/fanfare'

fanfare_recipe 'defaults'
fanfare_recipe 'multistage'
fanfare_recipe 'git_style'
fanfare_recipe 'bundler'
fanfare_recipe 'assets'
fanfare_recipe 'db_seed'

fanfare_recipe 'foreman'
fanfare_recipe 'database_yaml'

fanfare_recipe 'info'
fanfare_recipe 'colors'
fanfare_recipe 'ssh'
fanfare_recipe 'console'
fanfare_recipe 'log'
fanfare_recipe 'campfire'
fanfare_recipe 'airbrake'

Dir['vendor/plugins/*/recipes/*.rb'].each { |plugin| load(plugin) }

load 'config/deploy'

Pick and choose your fanfare recipes in Capfile--they are designed to work independently but also build off each other.

Create a config/deploy.rb that looks like:

set :application, "myappname"
set :repository,  "git@mygitserver.com:myappname.git"

set :campfire_options,  :account => 'cfireaccount',
                        :room => 'Dev room',
                        :token => '010010010100101',
                        :ssl => true

Create a config/deploy/staging.rb (assuming the multistage recipe) that looks like:

deploy_server = "myserver.example.com"

role :web, deploy_server
role :app, deploy_server
role :db,  deploy_server, :primary => true
role :db,  deploy_server

There are several optional recipes that need additional gems in your Gemfile:

gem 'airbrake'

group :development do
  gem 'capistrano-fanfare'
  gem 'campy'
end

Foundational

• git_style: GitHub-style deployments, fully compatible with third party recipes.
• foreman: Forget Unicorns, Resque workers, and God. Think processes.
• bundler: Binstub PATH-aware deployments with custom shebangs and more.

Core

• defaults: Common baseline defaults and an augmented deploy:cold.
• multistage: Deploy to multiple environments like "staging" and "production".
• assets: Rails asset pipeline support: done!
• database_yaml: No more database password baked in your code, leave that up to the server.
• db_seed: Seeding your Rails database, autowired into deploy:cold.

Gravy

• ssh: Connect to your infrastructure nodes without thinking.
• console: Rails 2/3, Sinatra, and Rack consoles, running in one command.
• log: Ability to tail logs and load logs into a local editor.
• colors: Deploys, but prettier.
• campfire: Notify your team of deployment and maintenace events.
• airbrake: Track your deployments in Airbrake/Hoptoad/Errbit
• info: Deployment configuration information, available at a glance.

GitHub-style deployments, fully compatible with third party recipes.

A Git style deployment strategy based on GitHub's Deployment Script Spring Cleaning blog post.

Forget Unicorns, Resque workers, and God. Think processes.

Binstub PATH-aware deployments with custom shebangs and more.

Uses the delivered Bundler implementation with support for shebangs, binstubs PATH inclusion, and a generated bin/bundle binstub script file.

Common baseline defaults and an augmented deploy:cold.

Deploy to multiple environments like "staging" and "production".

Uses the delivered Capistrano multistage implementation with a few additional helpers.

Rails asset pipeline support: done!

Tracking deployments in Airbrake

No more database password baked in your code, leave that up to the server.

Connect to your infrastructure nodes without thinking.

Rails 2/3, Sinatra, and Rack consoles, running in one command.

Ability to tail logs and load logs into a local editor.

Deploys, but prettier.

Rails console, ready for input in one command.

Notify your team of deployment and maintenace events.

Track your deployments in Airbrake/Hoptoad/Errbit

Deployment configuration, available at a glance.

• Source hosted at GitHub
• Report issues/questions/feature requests on GitHub Issues

Pull requests are very welcome! Make sure your patches are well tested. Ideally create a topic branch for every separate change you make. For example:

1. Fork the repo
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Added some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request

Created and maintained by Fletcher Nichol (fnichol@nichol.ca)

MIT (see LICENSE)