You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 7, 2020. It is now read-only.
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!
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
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!
The text was updated successfully, but these errors were encountered: