Hi Lee and Jamis,
all fair points. Sorry for delay with reply. If it's worth anything,
I'd like to add some more:
First, the original docs at
http://www.capify.org/getting-started
*are* really good. The problem with them is that they have kinda loose
focus, cover lots of functionality and are quite extensive (and even
outdated in some parts).
I think a very concise and tight "Using Cap to deploy Rails app in 10
minutes" would be great to have as an authoritative source *in some
central place*. (Me personally would like that as part of Rails
Guides, but that could bring some strong discussion.) When everything
is set-up on the server, deployment with Cap really should not take
any longer. Such "walktrough" could guide developer through the whole
deployment scenario, from `cap deploy:check` to `cap
deploy:migrations` / `cap rolback`, etc. It could provide basic info
about various parts of Cap, like "What is the `deploy:start` task",
etc. This guide should be tighly focused *on the developer*, and not
cover any sysadmin stuff around Cap.
Because, *setting up the infrastructure* on the server may be another
matter and could be quite complicated. Of course, lots of developers
are "their own sysadmins", so both angles matter for them, but I think
two things are important:
1/ The guides should be split: one for developers and another one for
sysadmins. In my experience, these are quite different angles when
using Capistrano. (First problem: obviously, different deployment
strategies -- proxied Mongrel/mod_rails -- and different OSes would
probably need different guides.)
2/ There should be some "advocacy" or other initiative from Capistrano
core aimed at hosting/VPS/etc providers. *They* should be concerned
about smooth deployment experience for *their* customers, and *they*
have all the means to do so. (And let's not forget that you can deploy
whatever with Cap, not only a Rails app.) For instance, where I live,
major Rails hosting provider
www.railshosting.cz provides you with
custom `deploy.rb` when you order new hosting package. So you just
drop this in your `config` directory after capifying the app, and you
are set. For another example, UK provider Brightbox offers a
deployment Rubygem:
http://wiki.brightbox.co.uk/docs:gemv2:howto ,
which works similarly. There's probably no reason the experience
should not be as smooth as this everywhere -- it's just a matter of
education and offering support.
That said, I personally would gladly help with the first part -- the
guide, but just cannot promise anything at this point. Not only
because I have promised to participate on two different guides for
other projects...
However, I think it would work best to set up a Github repo a la
"capistrano-book", put some kind of draft in there and then start
bugging people to fork/update/amend. Whenever someone complains,
whenever someone discovers something, he should fork/updated/amend.
This works reasonably well for Sinatra book (
http://github.com/sinatra/
sinatra-book/commits/master), for instance. And of course, it works
great for the Rails Guides.
Best,
Karel