On Fri, Feb 11, 2011 at 3:12 PM, Chris Berkhout <[email protected]>wrote:
> The main job of Capistrano seems to be running commands remotely. > That's the main job of net-ssh. :-) The main job of Capistrano is to allow you to define roles and tasks. > 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. > You're manually triggering a deploy by doing a git push to the target server. It's not an unattended install by any stretch. Git can call whatever code you like but the point is you'll need to provide it with something. Git isn't really giving you anything more than another manual way to say "deploy". I'd love to see something really simple that will take care of holding page, bundler, migrations, app_restart and the like. I just don't need it enough to write it myself. :-) - Mike On Fri, Feb 11, 2011 at 11:54 AM, Mike Bailey <[email protected]> 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 < > [email protected]> > > 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 [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
