evolving running systems
Locked
 
|
Hi,
Each time I make a major update to my live web site, it feels like a big bang event, rather than a simple evolution, with huge relief when I pull it off. I've been wondering if there's a better way that will allow me to sleep more soundly at night.
Here's my current routine: 1 Take a backup of the live server. 2 Write a migration script to update the code and migrate the data if necessary. 3 Test on a staging server.
4 Run the migration script on the live server. 5 Re-test and reward myself with a calming drink if successful. 6 Worry over the next few days that I've introduced some un-foreseen bugs. Issues I've run into are that there are subtle differences between the live and the staging server - especially when calling out to external services - plus my test coverage isn't terribly comprehensive.
As an alternative would it be possible to have the old and new code running in parallel on the live site, from the same stone, partitioned by user or some other Gemstone mechanism. This way I could run the migration scripts on the live system, create a parallel repository(?), redirect specific incoming requests to the updated repository for example initially only requests from my machine - then once I'm confident migrate all requests to the updated repository.
This is more of a stream of consciousness than a clearly thought through solution. On reflection I'm looking for a system where I can experiment with new features on the live server, for a few experimental users, including the ability to set break-points and evolve the code, without effecting the live site most users experience. Am I missing some tricks? Is there is an easier way to achieve my goals? I'm really interested to understand how others evolve live systems and if they too loose sleep after a major update.
Thanks Nick |
|
Based on what you have said, your best bet would to start by improving your testing process. Unit tests are a pain to write -- especially the first time, but once working they can make life MUCH easier. You can also try to adopt something simmilar to what is done where I am: - the developer who changes a class structure writes their own migration script. - test the script early on against a copy of the production data.
- source code updates should be in the form of a file-in, or some easily repeatable automated process. - have real users test stuff against a beta version of your release before going live (this would be the staging server from your step 3 below).
On Fri, Feb 18, 2011 at 12:48 PM, Nick Ager <[hidden email]> wrote: Hi, |
|
|
In reply to this post by Nick
On 02/18/2011 12:48 PM, Nick Ager wrote:
> Hi, > > Each time I make a major update to my live web site, it feels like a big > bang event, rather than a simple evolution, with huge relief when I pull > it off. I've been wondering if there's a better way that will allow me > to sleep more soundly at night. > > Here's my current routine: > 1 Take a backup of the live server. > 2 Write a migration script to update the code and migrate the data if > necessary. > 3 Test on a staging server. > 4 Run the migration script on the live server. > 5 Re-test and reward myself with a calming drink if successful. > 6 Worry over the next few days that I've introduced some un-foreseen bugs. > > Issues I've run into are that there are subtle differences between the > live and the staging server - especially when calling out to external > services - plus my test coverage isn't terribly comprehensive. > > As an alternative would it be possible to have the old and new code > running in parallel on the live site, from the same stone, partitioned > by user or some other Gemstone mechanism. This way I could run the > migration scripts on the live system, create a parallel repository(?), > redirect specific incoming requests to the updated repository for > example initially only requests from my machine - then once I'm > confident migrate all requests to the updated repository. I _have_ been thinking about issues in this area a little bit, specifically in the area of sandboxed servers for upgrade testing ... this process started last ESUG, but I haven't made much progress ... you could maintain two separate and distinct systems in the same repository by bootstrapping into a user other than DataCurator ... so you could run the test system gems as this other user and at least share the hardware and infrastructure ... I think Norbert has done quite a bit of work in this area as far as running multiple independent pier instances in the same stone ... so this might not be a bad route to go ... although the data wouldn't necessarily be shared, but then you wouldn't want that ... > > This is more of a stream of consciousness than a clearly thought through > solution. On reflection I'm looking for a system where I can experiment > with new features on the live server, for a few experimental users, > including the ability to set break-points and evolve the code, without > effecting the live site most users experience. Am I missing some tricks? > Is there is an easier way to achieve my goals? I'm really interested to > understand how others evolve live systems and if they too loose sleep > after a major update. I'm interested in hearing about what other folks are doing as well ... I am trying to head in a direction where many of the deployment steps are automated as much as possible so hearing what other folks do would be enlightening ... I haven't got very far, but I'll be make a push in this direction sometime in the late spring to early summer time frame ... Dale |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |