From ICISWiki

Template:Ns:Template:ICISWiki Nav

Overview

The delivery of ICIS install packages and patches is a critical issue in ensuring 100% stability. Specifically, deployment of ICIS module patches or modifications must be standardized, organized and secured. This task becomes more difficult to accomplish since ICIS has several modules working hand in hand. It is important that compatibilities between back-end and front-end can be validated so that incompatibility errors can be handled gracefully. Therefore, it is very important that ICIS developers agree on a standard method of deploying ICIS modules.

Take for instance this typical scenario. End user installs ICIS 5.0. Then, let us say version 5.1 is released with updates both on the front-end and the back-end. It is possible that the user patches the front-end modules but forgets to apply the patch for the back-end. Obviously, because of this unintentional ommission, the front-end will fail at some point with no reference to what made the module fail. Unfortunately, this error scenario does not give the proper support staff any clues that an incompatibility has occured.

The following topics will presents ideas and recommendations that addresses the issue of detecting and fixing incompatibility between front-end and back-end.

Identification of ICIS modules

It is basic in most piece of software to have an identifying information. The rationale of this property is to be able to detect incompatibilities because a state of compatibility can only be accomplished thru comparison of well-defined entities. Therefore, it is required that ICIS developers adopts standard and precise identification methods to ICIS modules and database states.

Software Versioning

An ICIS module and subsequent modifications can be identified by giving it a version number. It is important that the software versioning scheme employed should be well-defined and standard.

Currently, this is the software versioning scheme used by ICIS modules:

• DLL Level

  Format: a.b.c.d

  Where:

    a = foundation class (ICIS Annual Workshop).

    b = change in the db structure or
        change in technology or algorithm (e.g. Web service)

    c = additional functions/features

    d = bugfix 

• Module Level

  Format: a.b.c.d

  Where:

    a = foundation class

    b = dll compatibility

    c = additional functions/features

    d = bugfix

Database Build

ICIS is continously evolving as features and enhancements are made. There is a need to assign an identity to the state of the database for each time a modification is applied. This is what we will call a database build.

Let us define the properties of an ICIS database build.

• Categories

The database build scripts should be divided according to the modules that uses it. Specifically, separate scripts should be created for GMS, DMS, IMS, GEMS, etc. With this setup, patch deployment are more granular and specific.

• Schema scripts

The scripts for the schema of each categories is stored in the foundation version.

• Modification scripts

The scripts for modification is meant to be applied ONLY to a version one step lower. Therefore, application of these scripts must be in incremental form. This means that a patch will be applied if and only if the current build is one step below. For example let us say, Database build 5.3 needs to applied to an installation with Database build 5.0. In this case, Database build 5.1 and 5.2 is to be applied beforehand.

• Portability

Scripts must be written in ANSI SQL form whenever possible so that it can run on all database format. In case native language is needed, the script must be written in all applicable format.

Detection of incompatibility

The ultimate reason for setting up identification schemes is to be able to handle incompatibilities gracefully. What we want to achieve is to have a function that returns the compatibility status between two entities. An outline of recommended solution is as follows:

1. Allocate Version Information Storage

Version numbers and database build numbers must be stored where it is easily accessible programmatically. Possible candidates are ICIS.INI or the MS Windows Registry.

2. Create Detection Function

A method of querying the module version and database build must be introduced. Let us define GetSoftwareVersion(module) as a DLL function that returns the version number of a given the module.

3. Call Detection Function

ICIS developer uses the new function to check for compatibilities.

Delivery of ICIS Modules

ICIS is installed to users via InstallShield package. Currently, it only supports MS Access installation as the backend. Patches to the modules and to the backend are applied manually. There is a need to extend the InstallShield package to cater both fresh installation and module upgrades.