Application Deployment

Why bother with automated application deployment (or ‘packaging’ as it is sometimes known)?

Most people start a packaging initiative because it makes the applications quicker to install on a users workstation (sometimes simply cutting out the process of having to find the installation CD ROM and the associated application key).

However, there are far more important reasons: STABILITY and MANAGEABILITY.

If you’re careful you can build all your workstations so that they look the same - this is called a ‘build’:

A base build starts off with all machines being identical (here three machines).

Some organisations will then ‘brute-force’ the build, effectively copying the base build and rolling out the build unchanged to every desktop. This has operational and cost implications - every desktop is the same BUT it also has all of the applications required in the organisation. This needs lots of disk space but more importantly lots of licenses to be negotiated and paid for.  There is also the further complication that diverse types of hardware cannot easily be supported.

It is more elegant to only install the applications that the user requires. However, this can lead over time to the configuration of the workstations changing until they all look different:

Over time, as applications and sevices are installed (often in different orders) the machines diverge. If you were to examine the files and registry entries of the machines they would not be the same.

Sometimes this is down to something as simple as the order in which the applications are installed.

Consequently, if you try installing a new application on these workstations, sometimes it will work and sometimes it will appear unstable. You’ve started out from a different base and this causes problems.

Application packaging attempts to layer the applications onto the base build thereby eliminating any inter-application issues such as conflicting versions of shared application components (i.e. Dynamic Link Libraries or "DLLs"), or conflicting settings stored in the Registry:

Starting with a base build and implementing a controlled, automated application deployment methodology layers the applications onto the machines. Inconsistencies and instabilities in the resultant machines are minimised.

Now adding an application is almost guaranteed to work – the base build has not been corrupted. You will be able to detect low level incompatibilities between applications in advance.