In a way, this lifecycle is very similar to the
software lifecycle, or the history of the software products you choose
to use in your network. That's because they both begin with a request;
someone somewhere decides they need to have or use a specific product, a
product that will provide the particular features they need. In the
packaging lifecycle (see Figure 1), this request can stem from a variety of sources, but most often it stems from the user community.
In many cases, these
requests are informal — a manager decides a product is required to
better the productivity of their team; some user tells a manager they
can't do without a given product; IT decides it is time to upgrade or
change one of the core products in the network. Ideally, you should be
using a tracking system that automatically ferries this request through
the proper channels, locating the budget required for the acquisition or
the development project if no commercial product responds to your
needs, providing approval for the purchase or project launch, and
delivering the product to be packaged to your doorstep. At the same
time, this tracking system can let users, or rather requesters, know of
the status of their request and the expected delivery date for the
product on their desktop.
Next, you begin
the actual packaging process by examining the product to be packaged.
How does it behave when installed? Are there prerequisites for its
operation? Will it run properly on your operating system of choice? Does
it conform to given Windows standards? These are the types of questions
you need to answer and document before you can move on to further
stages. One of the most important questions at this stage will be, is
the product designed to work with the Windows Installer service or not?
The answer to this question will greatly influence how you proceed in
the next stages of your packaging lifecycle.
A key step in the
discovery process is research and review of existing documentation
sources for the application installation. Help may be found in
locations, such as a README.TXT
file, included documentation, or the vendor's Web site (FAQs or
knowledge bases). Unfortunately, this information can often be difficult
to uncover. One place where such information can be found for most
applications is the AppDeploy Package Knowledge Base. This knowledge
base is a community-contributed resource of information on the automated
installation of applications on a product-by-product basis with a
separate living document available for each version of a product
installation. Details include:
Command Lines:
Command line syntax for installation and removal of the software, which
may include available command line arguments and/or public properties.
Notes: Shared information on how to handle the automated installation of the software.
Virtualization:
Shared information regarding how to work with the software in
sequencing or creating a virtual deployment package for products like
Altiris Software Virtualization Solution (SVS), Microsoft's SoftGrid
Application Virtualization, VMware's Thinstall, and Citrix XenApp.
Terminal Services:
Details on how to address problems working with this software in a
Terminal Services session as with Citrix shared environments.
Related Links: Links to official and unofficial information regarding the deployment of the software.
Security Lockdown:
Information regarding which files, directories, and/or registry entries
must be opened to standard users for operation in a locked-down
environment.
It should be noted that AppDeploy.com
offers forums for questions and discussions on this subject, but its
Package Knowledge Base is designed for the sharing of facts. The most
commonly reported method of package development (repackaged,
transformed, and scripted) as well as a simple difficulty rating is
voted on by members, which can provide you with a quick starting point
to judge how difficult packaging will be for the application with which
you are working.
The next step is what most
people consider the packaging process itself. This is where you prepare
the automation of the installation and configuration of the product you
intend to deploy. If the product is compatible with Windows Installer,
you can customize it by creating a transform manually or by capturing
the installation and configuration settings in a file that may be
applied to the original product installation to modify its behavior
according to your needs and requirements. If the package is not
compatible with Windows Installer, you'll want to convert its legacy
installation into one that will work with this service. In this case,
you can capture the installation and configuration settings into a
special file that will serve as a new installation executable.
After you've created the
initial package, you need to test it to ensure that it behaves exactly
as you expect it to. There are a number of different tests you can
perform at this stage for example: automated or silent installation
test, pull installation (manually launched on the workstation or server
from a network location), push installation (automatically deployed with
your systems management software), uninstallation, and so on. But
system tests are not the only tests you require. More often than not,
software packagers find themselves preparing a product for deployment
that they've never heard of nor have very little experience with.
Therefore, it is difficult for you to understand if the configuration
you devised for this product is properly designed or if the eventual
user will approve of this configuration. To validate the configuration,
you need to involve an experienced user in the testing process. His role
will be to ensure that the product behaves as it should after it is
deployed. This is normally referred to as acceptance or integration
testing and is often formalized to identify the expert users who
perform it as software owners, people who will be responsible for more
than just testing, but also for recommendations on product evolution
after it is in formal use in the network.
Another form of
testing is conflict detection. It was only a few years ago that we began
to realize the impact of "DLL Hell" or the impact of trying to make a
multitude of products from different vendors, developed at different
times behave properly on a single system. In fact, DLL Hell became so
prevalent that Microsoft finally decided to implement a single
installation standard for software products in Windows: the Windows
Installer service.
Although this service has
been rightly hailed as a savior by many systems administrators because
of its many features for the support of the coexistence of misbehaved
products on a single system, it is not the be all and end all of
conflict resolution. Take, for example, the integration of two products
on a system: product A and product B. Product B includes components that
are not compatible with product A, yet both must be installed on the
same system.
The solution is to
convert both to an MSI installation to integrate them to the Windows
Installer service if they don't already support it. Thanks to this
service, incompatible programs can coexist and operate on the same
system. Should product B's components damage product A's, Windows
Installer's self-healing capabilities will automatically repair the
damaged product the next time it is launched, so long as Windows
Installer has access to the source installation files. However, you
could find yourself in a DLL Hell Loop: When product B is launched, it
breaks product A, but fixes itself; when product A is launched, it
breaks product B, but fixes itself, and so on. This may be because each
program uses a different version of the same DLL or requires the same
registry keys with different settings. Nevertheless, you certainly don't
want your users to see Windows Installer launch each time they start a
program on their system.
That's why conflict
detection and resolution are still required. Despite the fact that
Windows Installer can handle conflicting situations on the fly, you want
to control the behavior of packages in your network. This means
ensuring that products are well behaved when delivered. Detection is
handled by comparing the package you are working on with the others you
have deployed (or a subset of those deployed) and conflict detection can
even handle a snapshot of your baseline system image to ensure
conflicts with Windows itself are accounted for.
After all
testing and conflict detection is done, you need to perform a final
quality assurance on the package. Ideally, the person performing this
final QA activity will be different from the person who originally
packaged the product. This will provide you with a better and more
thorough verification. Don't forget to complete all documentation about
this package at this stage. Too many organizations try to save time by
leaving documentation until after the product is deployed only to find
out some critical component was missed and they have no means to find
out how to repair it.
So now, your package is
ready for release. At this stage, users begin to hearten because your
package tracking system has announced to them that they will soon see
the package on their own desktop. All they have to wait for now is
deployment. Your release process should fit smoothly with your
deployment system, automatically integrating the package into the source
package store that your software deployment team will use as the source
for deployment.
Now that the package is out, you feel that your job is done. Unfortunately that is not so. The packaging lifecycle does not end with deployment.
That's because today, it seems that released software must constantly
be patched to maintain its operational consistency and protect those who
have chosen to use it. Patches, hotfixes, and service packs are a fact
and will have varying impacts on your packaging process depending on
when in its own lifecycle you decide to deploy a product. If you deploy
the product after it has been out for some time, you will need to
integrate its patches and possibly service packs to the package before
you deploy it. If you have decided to use a new product in its infancy,
you will have to deploy patches for the product once it is in use in
your network. In both cases, you must continue deploying hotfixes and
other patch types throughout the lifetime of the package in your
network.
|
Although Windows
Installer offers strength and resiliency for product installations,
unfortunately, there are some key products, which should not and cannot
be packaged through the Windows Installer service. They include these:
Service
packs, hotfixes, and some system extensions cannot be repackaged with
WIS. Good examples of this are core Windows system component updates,
such as Windows Media Player or even the Direct X system. Along with the
service packs, these components make low-level changes to the Windows
system and therefore cannot be supported by Windows Installer. Windows
File Protection (WFP) components excluded from WIS. As you know,
components that are included in the SFP are automatically protected by
the operating system; only the system can update files under this
protection. Currently, only Microsoft has the ability to modify files at
this level. Special
packages that are already included in deployment kits. For example,
Internet Explorer comes with its own Administration Kit (IEAK) that lets
you package and deploy IE within your network. This type of product is
best left to its original state because packaging it in WIS might break
something that is automatically taken care of in the IEAK. Device
drivers and network protocols. These special components must verify a
system's configuration extensively before installation. It's not that
WIS can't do that, it is mostly that the changes brought about by these
installations are at such a low level that it is very difficult to
package them into a WIS package. A good example is Adobe Acrobat.
Because this product installed actual printer drivers, it took Adobe
several years to modify its installation to the MSI format. Before this,
many organizations invested heavily into the repackaging of Acrobat
sometimes with little or no success. Now that it is an MSI, it is much
simpler to work with. Commercial
MSI products. Vendor provided MSI packages should never be repackaged.
Remember that to modify these packages, you need to use a transform
(MST) and apply it at the time of installation.
If, however, your
only mode of deployment is through Active Directory and Group Policy,
you can still use Windows Installer to help deploy these types of
components. Windows Installer may be used as a wrapper that may use
custom actions to turn the installation into an MSI. Windows Installer
doesn't actually perform the installation, but it does perform the
delivery of the package and launches the setup.exe that is required to perform the installation.
|
In addition, you
must be constantly deploying new applications and updates on target
systems that already include installed programs. Therefore, you always
need to consider the installed applications whenever you test either the
new program or the new update.
Then, after the package
has reached the end of its usefulness to users or once the package has
become obsolete, you need to retire it from the network. Retirement may
also mean replacement if the business function the package fulfills is
still required. If you plan to replace the package with a newer version
of the same product, then you face an upgrade, which is a native feature
of Windows Installer.
NOTE
To be fair, it is
important to mention that using existing command line arguments to
install a product that is not in MSI format preserves the vendors'
provided installation logic and is supported by the vendor. Repackaging
has many benefits, but it also adds complexity. If a problem with a
repackaged installation cannot be reproduced in an interactive
installation, the vendor is very unlikely to provide support.
