Packaging – what developers dont do while creating installables.

November 15, 2006

Did you know that there is an industry out there which specializes in creating installers in which silent install works- using the installers provided by developers? I was blissfully ignorant about it, though designing an installer has been a part of my job description for ages.

An example of such a product is http://www.altiris.com/Products/Packaging.aspx

So what is wrong with the default installers?

Well, for a start, there are too many options. Packagers allow locking down the selected options so that the same are selected over and over again.

Secoundly, silent installation is not always available. Sometime the values in the dropdown are dynamic, sometime there are no command line parameters used for the inputs, requiring more than a single step while doing application installation.

Thirdly, we as developers are often guilty of leaving out one last thing ( or one first pre-requisite?)  in the installer – common examples are not restarting the application environment, or not copying the help files ( which were edited after the development was complete of course)

But of course a lot of blame is not with developers but it is the lack of norms for installation of enterprise applications. Lets assume there are 5environments, the development environment, the QA (quality assurance) environment, the User Testing environment, the Staging ( or Pre-Production) environment and the Production environment, it is reasonable to expect the deployment parameters will be different. For instance, the database connection string and authentication will be different. Some environments will talk to Production endpoints of interfacing systems, some will point to their test environments. Some environments will use proxy for outbound internet connection, some will use direct connect. Some will use SSL offloading, load balancer etc – while some will have SSL certificates on the servers and possibly no load balancing. Add to that other application and tuning parameters which we may want to be different.

Now what this means is that there will be too many options.

Now consider the fact that the application is distributed, so the web tier goes on one machine, the app tier goes on another machine and the database goes on a third machine – which means that there are three installers required.

So lets say there are 5 set of options, and 3 tiers, if we were to create silent installation, there will be 15 different Installers.

( So do you get how packaging is big business ?)

Alternatively we can choose to have 15 different config files.

I dont know if that is best it can get, but as long as we donot add any new parameters in the installers, this seems to work quite well.

I have also seen product vendors provide rich editors to edit these parameters in the ini file thus reducing chances of errors ( though personally I consider that an overkill, comments with examples are just fine)

I am hoping that one day there will be a best practice or a norm which developers can follow and what the Systems administration folks will come to expect.

Advertisements

One Response to “Packaging – what developers dont do while creating installables.”


  1. I follow your blog for quite a long time and must tell that your articles always prove to be of a high value and quality for readers.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: