by
Allistar Melville >> Fri, 16 Apr 1999 20:15:35 GMT
That's right, we have a Jade system which will be deployed to many different customers. Hence we want the installation and upgrading to
be "non-technical".
Installation:
=============
This is the easy part, use install sheild as you would to install any other application (we don't actually do this yet, when we go final release we will).
Patching/Updating:
==================
We have written an application in C++ which: --------------------------------------------
-asks the user for minimal information:
-system directory
-bin directory
-ini file
-directory where patches are to be found
-this info need only be entered once, it is saved in the registry
and used every other time it is run.
-The user clicks a "start" button (pretty simple really).
-The application now applies the jade patches.
Technical features:
-------------------
-The system connects to the Jade database and asks it which version this site is allowed to upgrade to (because of licensing/maintenance issues etc.)
-Patches can be .scm, .mth, .cls, .ddb files and the order in which they are imported is set by the person who makes the patches (me).
-The patcher won't run if it detects it is an old version.
-A prescript (jade code that executes before the patch is applied)
can be run before applying the patches. This is very handy if you need
to extract infor out to a file because the changes made in the patch
will lose it (for example).
-A postscript (jade code that is executed after the patch is
applied) can be run which could fix up known problems or import the
data extracted in the prescript (for example).
-Our system has a custom report writer, so the patcher also reads in the reports that have changed between patches.
-It can also copy files to the bin/system directories (new jade
..dll's for example).
-It handles all errors gracefully
-It can set production mode on the applications
-It keeps track of version numbers (i.e. if you are currently on version 0.9.16 it knows (because of jade code it imports before doing
the patch) that the next version is 0.9.17. It will only let you
upgrade to the next version, although it will do lots of version
upgrades sequencially. (i.e. 0.9.16 - 0.9.17 - 0.9.18).
-It also handles for whether the site is running a readOnlySchema:
-When the patch is finished it copeis the readOnlySchema files
from the server to a location specified in the ini file.
-When a client loads, they actually run another small C++ app
which takes a very similar command line to Jade.exe but this app first detects if the clients copy of the readOnlySchema files are out of
date. If they are it copies then from the server then runs Jade.exe.
-This makes readOnlySchema's seamless for the client, no mucking around with making sure the clients are in synch.
-Fully multithreaded
Because of the file copy feature the patcher will handle minor Jade patches easily. (Like the patch from 4.1.09 - 4.1.10 or from 4.1.10 - 4.1.11). It doesn't at the moment handles major jade patches like the 4.1.11 - 4.2.02 patch (mainly because of the reset timestamps stage.
We have a plan in the foreseeable future to make the patcher run scripts instead of a set patching routine which means that any complicated patching routine can be run, which means we will be able
to do any kind of Jade patch seamlessly. We also plan to have it
perform database features, like certify, compact, reset timestamps and change registration info.
If anyone would like any more info about it or if you want to use it
in your own jade sites, email me and I'll get back to you with
whatever you need to know.
Thanks,
Allistar.
------------------------------------------------------------------
Allistar Melville (BSc) Home:
allistar@ihug.co.nz \_
Software Developer Work:
allistar@focussoft.co.nz </'
Auckland, NEW ZEALAND /)
(/`
"Science built the Academy, superstition the inquisition."
[Robert G. Ingersoll] ------------------------------------------------------------------