On Wed, May 27, 2009 at 6:08 PM, Jean-Philippe Moal <[email protected]> wrote:
> For the next version (2.6 ? 3.0 ?) I think changing the default recipe > to deploy without rails specific defaults (and even without any > application/langage specific default, I'm thinking static site here) is > a reasonable choice. > I disagree on that part, I still think Rails should be the default, but see below for more thoughts. > Almost everyone is already rewriting the start/stop/restart tasks, but > there are many other changes required or welcomed if you are not > deploying a rails app : > - The deploy:migrate and deploy:migrations is obviously rails specific > (or at least activerecord specific ? I don't know about merb migrations) > - The deploy recipe creates the system/log/pids shared directories > (using the shared_children var), but log and pids may not be used (even > with a rails app, when you're using passenger). > - An other rails default is in the finalize_update task which assumes > there is a public directory, with images, stylesheets, and javascripts > subdirectories (this task also symlinks the shared/system dir and the > tmp and tmp/logs directories) > - The web:disable and web:enable tasks also uses the system directory > assuming the public/system/maintenance.html file will be check and used > at the web server level > - I should also repeat that (re)creating empty restart/start/stop tasks > seems ugly and feel like a hack > It sure does seem like a hack. I think in general we're talking about not changing too much internally, basically having different ways of running a deployment for different purposes. I do like the idea of having app-specific templates, and app-specific deployment recipes. I'm not sure yet how necessary the latter would even be, because in my experience the difference between deploying a Rails application with Capistrano is not too big, but still it sounds like it would be a good way and would to a certain extent make Capistrano make more friendly to deploying other things than Rails applications. You can't serve every purpose, you can't treat everyone right, but what popped up in my head was something similar to the Rails application templates, basically a simple recipe file suitable for a specific framework or a simple way of deploying applications. What I would like is something that you can tell the capify command to generate for you. That in turn would obviously just include the right files, which in turn will contain the app-specific deployment recipes. I'm thinking of something along the lines of this: capify -a php capify -a static Obviously there'd be templates for generating that stuff, and Capistrano would come with a list of packaged templates and deployment recipes for different purposes. For the record, I also deploy PHP code with Capistrano, and I deploy static websites with Capistrano, so I'm well aware of some of the things needed to work with other projects than Rails-based ones. > That said, I understand such changes in the defaults should not be rushed. > Taking note that many people are using the deploy recipe as a base for > creating their own, my proposal would be : > > - Publicly release the 2.5.6 version with the bugfixes only > - Have a "transitional" release (2.6 ?) that splits the deploy tasks in > two recipes : 'deploy/core' (or 'base' ?) would contain the basic > deployment tasks, usable as is for a static website (and should work for > a PHP website); and 'deploy/rails' include the necessary tasks and hooks > for rails deployments. Theses rails tasks should not be changed (so > script/spin would still be used). > The 'deploy' recipe should include the core and rails files, and throw a > warning informing the user of theses changes. > - In the future releases (3.x ?), have the 'deploy' recipe only load > 'deploy/core'. This would also be the time for discussing important > recipe changes and code cleanups. > Some recipes could be also added, including 'deploy/mongrel', > 'deploy/passenger', 'deploy/wordpress' (which would symlink the correct > assets dir), etc (I have many other ideas but this is another topic :-) ). > As I said, I like the idea of step three with regard to having specific templates, but I'd still have Rails be the default. Call me stubborn on that front, but you'd have to give me a very strong argument to convince me that it's a good idea to dump it as a default. Cheers, Mathias -- http://paperplanes.de http://twitter.com/roidrage --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
