The main job of Capistrano seems to be running commands remotely. But if your destination git repo can run whatever you need when you push to it, then I'm not sure what benefit there is in Capistrano. I'm using git anyway, so it's one less tool.
Cheers, Chris On Fri, Feb 11, 2011 at 11:54 AM, Mike Bailey <m...@bailey.net.au> wrote: > Why don't you want to use Capistrano? There's a big community using it and a > lot of use cases have been thought through. > - Mike > > On Thu, Feb 10, 2011 at 11:14 PM, Chris Berkhout <chrisberkh...@gmail.com> > wrote: >> >> Hi All, >> >> I'm trying to improve my setup for deploying to a VPS and have run >> into a few questions. >> >> The general idea is to be able to do a git push to an account on the >> VPS and have git hooks do anything necessary on the server side to >> redeploy. >> >> I think some people just have one copy of the app, and when there is >> an update, it's just a git pull/checkout into that live directory. >> If some updated files are written before others, I guess that would be >> okay because running in production they wouldn't be reloaded until the >> server is restarted (at least for code files). Is that right? Is it >> worth having a Capistrano-style multiple version and symlink setup? >> >> If migrations need to be done and the old code is incompatible with >> the new DB schema, would the normal course of action for a low-traffic >> app or an app with periods of low traffic be to take it offline during >> the migration? In an automated setup, would it be normal to assume >> that there are incompatibilities whenever there is a migration? >> >> In a bigger setup, with multiple servers accessing a DB and downtime >> being unacceptable, how would you migrate between conflicting schemas? >> I've been led to believe there is a way, but the best I can think of >> is tricks like breaking down the migration into smaller parts that are >> not incompatible. E.g. rather than radically changing a table in one >> step, have an intermediate step with code that continues to use the >> old table, but migrates individual rows to a new table as they are >> used, then once all data is across do a final redeploy and migration >> that leaves clean final code and deletes the old table. >> Is there some non-tricksy way I'm missing? >> >> Cheers, >> Chris >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to rails-oceania@googlegroups.com. >> To unsubscribe from this group, send email to >> rails-oceania+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to rails-oceania@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
