I'm a bit of a different breed: I am my own sysadmin. Not technically fulltime "dedicated", but close enough that no one else here worries about admin stuff.
This means, among other things, I get to fight with myself over whether to do a proper normalized data structure or just Rails STI. Ideally, I would like a solution that works well for either -- maybe start with a picture of how your ideal dedicated sysadmin would set things up for you, then take the best of those system-wide scripts and allow Capistrano to add them to ~/bin on the server. I'd like to play with that sometime, I have some ideas for how to do it "The Right Way". For the moment, I'm content in that I manage both the server-side configuration and the client side deploy scripts, so it ends up being the same thing anyway -- and as a bonus, all our cap stuff goes into version control. On Thu, May 15, 2008 at 12:39 PM, Jamis Buck <[EMAIL PROTECTED]> wrote: > I think it boils down to the fact that there are basically two types of > developers who are deploying rails apps: those who have dedicated sysadmins, > and those who don't. I think the latter are more common, and those are the > ones I want capistrano to target out of the box. Naturally, capistrano can > be adapted to many other uses, and that's fine--I just want people with > little deployment experience and no experts on retainer to be able to use > capistrano with a minimum of pain. > > - Jamis > > > On May 15, 2008, at 11:20 AM, David Masover wrote: > > I think it's a difference in philosophy. >> >> As a Unix admin, I see the value in setting a system-wide script on the >> server. After all, I might have mongrel_cluster and nginx installed, or I >> might have Apache and mod_rails -- as the admin, that's my choice, and the >> app developer not only doesn't have any say in it, they shouldn't have to >> think about it. >> >> However, it's pretty clear that the Rails philosohpy is pretty much >> exactly the opposite -- the plugin system seems designed to ensure that >> absolutely everything to do with running the app is bundled up in the app >> itself. It's the moral equivalent of static linking -- the assumption is >> that you can't trust the remote host to have things setup properly, but with >> plugits, you don't have to. >> >> Capistrano seems to be driven by the same philosophy -- the entire app is >> distributed everywhere, and all the configuration is included with the app, >> in such a way that, in theory, you can deploy the same way to any remote >> host. >> >> I'm not going to actually state a preference, just pointing out where I >> think the disconnect is. >> >> On Thu, May 15, 2008 at 9:10 AM, 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. >> >> 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). >> >> 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. >> >> - Jamis >> >> >> On May 15, 2008, at 3:39 AM, Neil Wilson wrote: >> >> >> That's not the way to do it. The way to approach it is to abstract the >> 'start', 'stop' process on the *server* not the client. >> >> That way you install a set of server scripts that conform to a >> standard interface and they depend upon the application/web/database >> layer you have installed on the server. >> >> Your client then simply calls 'web-start' and the right thing happens >> on each server depending upon which equipment you have installed. You >> can probably even have a mix of mongrels and passengers if you want. >> >> The client shouldn't care what is installed on the servers. It just >> needs a standard interface to work to. >> >> On 14 May, 22:34, Tom Copeland <[EMAIL PROTECTED]> wrote: >> "set :application_container, :modrails" or something like that. That's >> >> >> >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
