There is no turn-key answer, of course. The answer depends on what is changing, the scale of the change, the compatibility of the change, etc. In particular, you'll want to make sure your server source is synchronized with your active image in case the upgrade causes live errors, you really need to see the code that is associated with backtraces.
Small: I do a fair bit of online bug fixing which occasionally gets me into trouble, so you want to be very selective about this, but it often saves a ton of time. Medium: For more complex feature-specific changes, I debug on a staging server, record a darcs patch, update the live repository, and manually evaluate the code changes in an order determined by my understanding of the patch. For most cases, this incremental integration of patches works well. Major: For significant upgrades, especially if I can't be sure of the dependencies between active state and the new code, I do a shutdown and reload - again something I test on a copy of live DB on the staging server and then run my regression tests. If you wanted to automate patch integration, you'd have to be confident that there was no conflict between active state and updated code. I can imaging the following process: 1) Have a clean way of quiescing new threads/activity or having a application-level way of telling the user; hold on a sec. 2) Update the repo with a darcs patch and asdf-load the system. On a large system, this can take a little bit so you can't hide this update procedure from the users; thus #1. 3) Allow the system to run forward and keep a tab on your error logs and/or run some smoke tests. 4) When more patches, goto #1 This is basically what I do manually. I have had problems recently where I make some changes to presentation logic and there is stale data in the system that needs to be updated to the new convention. In this case, you'd like to run some update code after the source updates. This would modify the above as follows: Create an update file that is loaded by the running system with a list of records of the following form to automate DB updates before and after the source updates. If you are confident that these updates do not need to be atomic, you can inhibit the quiesce functionality. e.g. ((repo patch name; pre-fn-form; post-fn-form; smoke tests; quiesce-p) ...) One additional refinement would be to do a repo diff between the current and prior patch and record the list of files that changed; then run compile-file on them based on their load dependencies in the asdf file; this would speed up the updates and if you've been smart with things like defvar/defparameter should work well. I find the manual method forces you to think more carefully about dependencies, but it does require that each individual change can be applied atomically. The automated update is nice when you need coordinated updates, but don't want to pause user activity too long. My two cents... Ian On Mar 11, 2009, at 2:30 AM, CoffeeMug wrote: > > When people talk about Common Lisp they usually mention the > interactivity factor and the ability to fix bugs on live servers. I am > trying to figure out how to do this now, beyond making very small and > obvious changes. > > I have a pretty standard setup - SBCL and Hunchentoot behind Apache > (using mod_lisp2), a swank server (I tunnel over ssh), and detachtty. > I can make trivial changes through slime, but what about rolling out > larger updates? > > Overall, it seems that I would have to diff the tip of my branch with > the revision that's on the live server. I'd then parse the diff file > (an extension to ediff?) and send each chunk of code in the diff > through slime. Of course simply doing this straight out won't work - > I'll have to figure out full context from the diff (get whole function > body), possibly cherry pick chunks of code, and reorder them because > they might depend on each other. > > Has anyone done something like this? Writing the tools to do it isn't > trivial at all, it looks like a very time consuming project. If anyone > has experience doing this or some chunks of code laying around, they'd > be very much appreciated. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" 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/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
