For the big stuff we bring the boxes out of their pools one at a time and upgrade them.
In both cases, the worse case is that a user might see two versions of the same page in the span of 60 seconds if they catch us in mid-update.
John-
On Wed, 30 Oct 2002 21:47:01 +0000
Richard Clarke <[EMAIL PROTECTED]> wrote:
John, [EMAIL PROTECTED] wrote:We felt the same way but once we went to CVS we never looked back and can not imagine going with out source control. It may seem like the web doesnt fit that paradigm but if you break your modules up properly it works like a champ.Do you use CVS checkouts to upgrade the live system or do you this manually. i.e. stop apache, tar and remove old code, untar new code, start apache et voila?
We broke out into 'html','components', 'Libs','external_tools','internal_tools','perlinstall'. This gave us good control over each different area.
For our development team its more about consistency then versioning. If you go all the way with it like we did you can give each developer a sandbox that they work in and CVS merges for you, it is a huge benefit. Its to the point now where you check out all the modules and run one script. That script builds all the perl dependancies, rebuilds your http daemon, rebuilds the proxies, configures the server for the platform its on based on hostname and installs all the relevant files.
Every so often we bundle everything up into a tagged 'Release' and send it on its way to production. This works really well. A case in point was when we did our I18N conversion. We had one version of the code that was being entirely hacked apart to accomodate our changes but we still had to actively support bug fixes on the release. Without CVS[insert favorite source system here] this would have been impossible.
So, without good CVS things like our I18N effort, our auto-install systems etc would have not been possible or been a LOT more painful. As it was we busted through it in record time.
John-
Ric.
