I'm wondering how others deal with versioning when developing/deploying SL apps that utilize the CSLA.
More specifically, if a user is using version 1 of our software, they may perform work (let's say add a bunch of records and not commit them). Over night, we deploy version 2 of our software, and now the binaries for that user won't match, so that user will not be able to save their changes.
Something like utilizing a polling duplex binding that will reach out to all open clients, invoke a save, and close the app automatically comes to mind, but seems like an awfully rude approach (especially if the user is in the middle of interacting with the UI).
I guess a week's warning and notice of upgrade via email might suffice, but seems a bit archaic and error prone as well.
I'm hoping to get some thoughts as to how to deal with this specific issue.
Thanks!
Are you serializing your BOs to disk to store them?
No, not directly. I'm utilizing the dataportal methods to perform my CRUD operations against the database.
So when I speak "versioning", I mean the actual BO library that is built upon CSLA. If version 1 exposes 5 classes and version 2 exposes 7 classes, after a deploy, the server will host version 2. If the user in my example never refreshes their browser before they hit save, they will have version 1 loaded up. I guess I'm assuming that a save at this point will fail because the assembly loaded in his/her browser will not match the new hosted assembly (version 2). Am I missing something?
I realize this is going to come off as kind of harsh, but I've never had much sympathy for users who leave an application open and never log off the network. I realize that your question is more of a general sense, but your original question talked about an overnight deployment. When paired with your next scenario (they don't refresh their browser before saving), that says to me that your user(s) left your SL app (and browser) open when they left work for the day.
There are precious few apps that really are used 24/7 and cannot tolerate any kind of downtime. If your app is that kind of app, then you have a whole set of issues to resolve that go far and above your general question (and, presumably, you would have resolved them and thus wouldn't ask us. 
) So, presuming your app isn't that kind of app, inform your users of the projected downtime window and call it a day. Every business I've worked for has maintenance windows, and most of them "ask" their users to log off at the end of the day, since they use the after-hours window to push/install patches and other updates to the users' desktops.
Now, if you're deploying a change during the day that is a "breaking change"... well, there isn't a whole lot you can do to cushion the blow. As you've noted, the save will fail because of mismatched assemblies. About all I can think of would be to build in some kind of interception system on the server that does a version check before performing the update, and in the case of a mismatch sends an error message back to the user saying "We can't save your work because a newer version of the app is available. Close your browser and re-load the app. We're sorry we lost your updates." I think something like that might be possible in the new CSLA 4 DataPortal inspector options, but I'm not sure. I wouldn't try to automatically resolve the issue either - that could be a rat's nest of code to write.
HTH
- Scott
Scott,
Hahah, actually, I appreciate your candidness, and I completely agree with you on all counts. As far as I'm concerned, this application is not business critical. However, the folks who wrote the original version gave the world to it's users, so it's going to be a difficult case for me to deliver less to the users. Unfortunately, many of it's users log in during random hours of the night (nation wide), so it's not your typical 9-5 usage app.
I'd still love to hear how others have handled this scenario.
Thanks!
If it is at all realistic to allow users to run the old version while other users start running the new version you can do a rolling update.
To do this:
This isn't without its limitations obviously, but if your underlying database structure didn't change or something like that, it might be possible to make this work.
This is exactly the kind of thing people do when they need 99.999% uptime - they have to do rolling updates to avoid having any downtime...
Yeah, I thought about this solution as well, the largest problem being that the URL changes and everyone who had it bookmarked/linked/whathaveyou will now have to update them. Not the end of the world, but annoying, nontheless.
Thanks for the thoughts though, I appreciate it.
Copyright (c) Marimer LLC