Skip to content
This repository has been archived by the owner on Mar 7, 2020. It is now read-only.

Maybe we can join forces with our capistrano recipes? #15

Open
ndbroadbent opened this issue Aug 9, 2011 · 0 comments
Open

Maybe we can join forces with our capistrano recipes? #15

ndbroadbent opened this issue Aug 9, 2011 · 0 comments

Comments

@ndbroadbent
Copy link

We have also been maintaining a set of capistrano recipes for our organisation, and I think it would be great to join forces.
We can provide the other half of the server equation, since we run CentOS which uses the yum package manager.

Our recipes are at https://github.com/crossroads/crossroads_capistrano, and we do share a lot of recipes in common, but we will still have a few differing opinions to sort out.
For example, you prefer to check in your config files to source control, but our convention is to save config files to a 'shared' folder on the server, and symlink them into each release folder.
Instead of arguing over which way is right or wrong, perhaps we could resolve any conflicts by giving the user a choice between both options.

I've written our recipes gem with the goal of keeping our deploy.rb as concise as possible. For example, here is the full deploy script for one of our applications:

$ cat config/deploy.rb

require 'crossroads_capistrano'
load_crossroads_recipes %w(stack rvm passenger postgresql
                       newrelic hoptoad log revisions)

set :application,          "xxxxxxx"
set :domain,               "xxxxxxxx.org"
set :repository,           "https://xxxxxxxxxxxxxxxxxxxxxxx.git"
set :rvm_ruby_string,      "ruby-1.9.2-p136"
set :passenger_version,    "3.0.3"
set :user, "root"
set :use_sudo, false

$ cat config/deploy/live.rb

set :ip_address, "10.0.1.88"
set :site_domain_name, "xxxxxxxxxxxxxxxxxxxx"
server "xx.xx.xx.xx", :app, :web, :db, :primary => true
set :deploy_to, "/opt/rails/#{application}-preview"
set :branch, "master"

The last thing is that I'm not very fond of the 'deprec' namespace. I think it's really unnecessary, and I really don't want to type 'deprec' over and over again for every command.
I think this would be a barrier to collaboration if you don't see a way around that.
But I would be happy if the deprec namespace was optional, and could be configured from ~/.caprc.

Look forward to hearing your thoughts!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant