I also did it this way on PyCon server - from a PC (for rsync, I installed cygwin - I couldn't stand to be without shell and basic utilities when I still _had_ to use a windows box).
the "script" is rather simple in this sense: $ rsync -n -exclude-from rsync.deploy.ignore -avup source destination Let me walk thru this a bit. exclude-from: list a file that is much the same format as "glob" secrion of .bzrignore or .hginore files - that is, it is a list of patterns to ignorel. Here's who I used this: since Massimo and I would both make changes / maintain the registration server on PyCon, I would "grab" a backup of the running server, including all the important, useful migration files in the ./databases folder. I kept this copy - the "deployment" copy - on the server, in my account's personal space. In that "deployed" folder, the web2py tree (along with all the tickets, database files) I kept under version control (bzr, since bzr is what we kept web2conf under, in launchpad). Keeping things in revision control (it could have been bzr, mercurial, or git) let me take changes from two people and merge / resolve / test them before deploying to the live server. It gave me a stable staging area. Now - this may not be the best or only way, but it is an example - I kept a mirror image of this "deployed" directory on my local machine. This way I was not pushing to the launchpad repository from the server (and hogging resources). But that is secondary: the real reason I kept a local copy: I kept an "as it" copy of the server, and cloned it to my local development branch (rsync). On the developement tree, I would ignore things that required all the visa accounts of the running server, keeping instead the test or development stubs of that. Thus I could add features after the registration system was deployed, by working on my local copy, testing, then rsyncing / merging (in case Massimo made changes in the meantime) with the server version, then push up to my local space in the server - test w/ appropriate accts there. When I was satisfied, rather than copy files on the running server, I would pick a deployment time and rsync the changes, and watch like a hawk. In the cases when a restart was needed, with mod_wsgi, we made an apache restart not needed - we touched a mod_wsgi file, and the web2py wgsi thread would restart, and thus restant just the web2py stack. Cool stuff. Back to the rsync: - one kind of rsync.ignore file for taking a copy of the running server; - a different kind of rsync.ignore for deploying out to the live server (don't want to overwrite any of the servers error files or databases files) Finally, on my local computer, I would have the same: rsync.ignore to exchange with my local space on the server; rsync to echange with my local bzr work/development space. This seemed to work fine.... but I think if I had to do again, I would do mercurial to pull between machines, and leave rsync for just exchanging between the live and local copy of the deployed app. Oh - the "-n" said "don't do it; just test run" --- this is how I would check I was using a good "ignore" pattern set before I actually pushed to the running server. When convinced, I would remove the "-n". I also "sudo -u web2py-app-id" that is, needed to rsync out as the user-id that we had the registration system running as. rsync is nice - be sure you get the difference between "rsync source destination" and "rsync source/ destination" , etc. These small distinctions may make it worthwhile to have either short scripts, or aliases that have meaningful names (I used aliases). On Thu, Jul 2, 2009 at 10:48 AM, Jason Brower <encomp...@gmail.com> wrote: > > meeh, I don't know :) > Regards, > Jason > > > On Thu, 2009-07-02 at 08:05 -0700, AchipA wrote: > > Great tip ! How would you go about handling tickets/errors ? > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
