Software AG Installer.

The Software AG installer was designed and written (> 95%) by me to replace dozens of slightly different InstallShield installers with a single unified installer architecture. It grew to include hundreds of individually installable components from dozens of development groups.

Written in Java, the Software AG Installer runs on Solaris, Windows, HP-UX, AIX, AS/400, Linux and MacOSX. Deprecated platforms include DEC and IRIX.

Instead of a monolithic installer containing dozens of products that takes months to fully QA, the plugin architecture allows each group to independently test their installable products. To the user, the installer looks like any other monolithic installer containing many installable components. The install architecture smoothly combines the disparate elements together.

For Windows, we provided a self-extracting EXE which included a JRE. For MacOSX, we provided a DMG file which included a JRE. For all other platforms, we provided a Java JAR file.

Developers and release engineers only have to code once for Windows, UNIX, console, scripted (installation or uninstallation without user input) and GUI installation scenarios.

Each product group can independently code custom wizard panels that show up in the installer wizard to get user input, run configuration and unconfiguration steps. There are platform specific features such as registry access on Windows. Since each product group plugs in custom wizard panels, installable files and product property files independently of other product groups and the installer core, there are no bottlenecks in the development process, allowing for asynchronous development. By providing the product groups with this API, the installer core can be agnostic about any product-specific configuration and user input, removing the dependencies between the product teams and the installer team, and empowering the product teams to have total control over the configuration and installation behavior of their product.

Products can depend on any number of other products, and the installer architecture manages the various relationships during installation and uninstallation.

The installer client contains the installer API and bootstrapping code to connect to a server and download the server half. This allows Software AG to fix problems and add improvements to the server side without forcing the user to download a new client.

After the initial bootstrapping step, the remainder of the installer is written using the same APIs as for any product. This allowed us to ensure that a complete feature set was available to every product installation.

Each new installer client can install all of the older product releases.

Before this installer architecture, it took 100+ steps (many non-intuitive and/or required to be executed in a specific order) and hours of time to install the full webMethods product suite. This has been reduced to a few steps and just dozens of minutes. The level of core product expertise required to run the installer has been lowered significantly.

On the server side, product files are delivered through an Apache httpd server. Logins are handled using a CGI script.

Release engineers set up "sandboxes," or a directory under the Apache server containing one or more products. The installer client is then given the URL for one of these sandboxes and the user can install one or more products. I wrote scripts in perl to synchronize files between servers in the USA, Germany, Israel, India, and Bulgaria to facilitate the international development process.


Wednesday, 18-Nov-2015 19:47:29 PST