On 15 May, 15:10, Jamis Buck <[EMAIL PROTECTED]> wrote:
> I disagree. You've certainly described *another* way to do it, but if
> it means people have to actually set up those scripts themselves, your
> way means additional (potentially confusing) setup is required for
> people who want to use Capistrano, and that's what I'd like to avoid.
No more than installing the operating system, apache, mongrel, rails
or anything else on the server and determining whether you will
install the binary packages or compile from source - all of which you
have to do to get going from a blank box. The solution is to provide
native packages containing the scripts necessary to provide a common
interface and tie them together with the dependency interface.
What we need is:
'apt-get install rails-server'
and its equivalent in other package managers that abstracts away the
problem, much as the current binary packages save you having to work
out how to compile stuff.
>
> What I'd love (pie in the sky, here) is for someone to install
> Capistrano, and have everything they need right there. I think the
> deprec stuff is a good example of that--a bunch of capistrano tasks
> that help you go from zero to deploy using only Capistrano. I don't
> think Capistrano needs to ship with a complete solution like deprec,
> especially it would need to understand all the different server
> platforms, and that would get ridiculously complex (I believe).
That's the problem. I've tried it and it doesn't work for the same
reason
that a huge case statement in a computer program is a bad idea and
polymorphic classes make life much easier. There are too many options
and not enough information hiding. It gets exponentially complex very
quickly and requires a very tight specification of systems if it isn't
to fall over.
Deprec utilises a lot of my lower level libraries that tried to keep
things on the client. Now just trying to install to a Debian Sarge and
Debian Etch machine at the same time introduced enough complexity to
put me off the idea permanently.
The package manager knows where stuff is on the server and the server
knows what operating system it is. Once you have the scripts packaged
then you can install them and run capistrano to the provided
interface. The differences between Etch and Sarge, that you need to
have full visibility of with a client side solution, are eliminated
when you abstract the problem away with packaged scripts.
>
> Now, maybe the "right" way would be for deploy:setup to push the
> desired web-start/web-stop/etc. script to each server, but from the
> user's perspective that's transparent. In their deploy.rb, they've
> added a variable or variables indicating which configuration they
> want, and they don't care how it's implemented under the covers. The
> deploy.rb (or Capfile) is their "recipe" for deployment, and should
> ideally be the centralized place where they describe how it is
> configured.
I feel the right way is to leverage the native package manager (or
even gem) and build a common interface that hides the complexity and
difference away. Then capistrano only needs to know what package to
install on the server to get Rails up and running.
I've just done the proof of concept with Brightbox (http://
blog.brightbox.co.uk/posts/brightbox-gem-v2-beta) by building a
'server-tools' system which is installed on the server using the
package manager along with everything else (in this case it is just a
gem). The client deployment script then becomes very simple indeed
either calling a single command script with each task, or running a
Rails rake task and it all gets tied together in a nicely decoupled
way via the Capistrano callback system.
The user then just plays with the variables and it all works nice and
easily with no real server admin skills required.
I think it can probably be abstracted further, and I'm working with
Passenger and an Nginx/mongrel setup to see where I can push the idea.
Essentially we need some server-side convention over configuration to
simplify things.
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
