In-Depth

More Software Packaging Rules to Live By

The final part in a series of articles on ways to guarantee a smooth deployment of software and applications across your enterprise.

• By Danielle Ruest and Nelson Ruest
• 02/09/2005

Most system administrators who have been packaging software will have realized that 10 commandments are not enough to cover software packaging. That’s why we bring you 10 more commandments. Along with the first set, these commandments will help you make sure that your packages work the first time, every time. If you want to reach this goal, then read on and see what Macrovision, makers of AdminStudio—a comprehensive integrated packaging environment (IPE)—and Nelson and Danielle Ruest, independent packaging consultants, suggest to make both your packages and your packaging experience better.

1. Use a Global Exclusion List
There are a lot of components that should never be included in any package—temporary files, system files, INI files, registry keys and so on. These components must be part of an exclusion list that is applied to all packages as they are created. If you use a proper and complete global exclusion list, it will help reduce the time you’ll spend removing unwanted and unnecessary data from the packages as you create them. This global exclusion list will complement the packaging templates you use to generate your packages.

2. Know Your Packages
When preparing a package, you should extract as much information from the package as possible. IPEs will include special tools that are designed to help you gain a lot more information from a package as you prepare it. For example, AdminStudio includes two tools that can help in this situation. SmartScan is a tool that will automatically identify any files that are part of the package, but were not collected during the standard repackaging process. SmartScan will add these files in a color coded format so you know what other files can optionally be included. It also includes the Setup Intent Wizard which will also help identify files that are related to the package through file dependencies but are not included in it. Both tools let you discover more information about your package.

3. Use a System Construction Model
Another key method to help reduce the complexity of creating packages is to use a system construction model. This means that you build a core system and add all generic capabilities to this system. This image or “system stack” is then applied to all PCs or servers.

Once applied, it must be managed and maintained as a single object. In real life, three comprehensive updates per year are sufficient. Of course, you also have to provision for emergency update deployments.

Software Packaging Webinar Want to get more tips on software packaging? Attend a FREE Web Seminar "The 20 Commandments of Software Packaging: Practical Application of Software Packaging Best Practices" When: February 16 at 1 p.m. Central Standard Time, hosted by Nelson Ruest and Macrovision's Steve Schmidt. Registrants will also receive the "20 Commandments of Software Packaging" whitepaper for Free! For information and registration CLICK HERE: http://info.101com.com/ default.asp?id=12371

4. Create Package Catalogs
Once you have your system stack in place, you can them move on to create collections or catalogs of applications that can be deployed to groups of users that can be identified through the role they play in your organization. For example, one group could be financial analysts who require special financial software along with the generic office automation capabilities provided by the core system stack.

Using this type of system construction model will help reduce the time it takes to create packages because it reduces the number of applications with which each package must coexist on a system.

5. Perform Conflict Detection
One of the major reasons why you should package software with the MSI format is because the Windows Installer service includes special features that can manage software conflicts “on the fly.” But, this does not eliminate the need to test all packages for conflicts against all of the other software that will coexist on a system.
When testing for conflicts, you should use the internal validation tests, check against internal consistency evaluation (ICE) rules, and check against cross-application conflict evaluator (ACE) rules. By using the IPE to build application catalogs and group applications within this catalog, the time it takes to detect conflicts will be reduced.

6. Test as a User
Too many people forget that they are administrators with full rights on a machine when they prepare a package. Because of this, a lot can go wrong when it gets to the user. Make sure you always work with two accounts, one with administrative rights and another with normal user rights. Then use both the Run As command in Windows to test the application and the IPE’s capability to test for behavior in locked-down environment before you deploy the package to users with limited rights.

7. Perform Deployment Testing
Installing a package in a laboratory environment—the environment where you prepare the package—often means pulling the package from a network share. Yet, when a package is delivered to users, it tends to be deployed by a remote software delivery system. A lot can go wrong when this deployment isn’t tested before the package goes live. Deployed packages are most often installed in the background through a silent installation. In addition, deployed packages require specific conditions to be met on target systems for the deployment to work properly.

With an IPE such as AdminStudio, you can create instrumented packages—packages that include all of the behavior of an installation, but which do not modify target systems, and send the test results back to a central web site—and test them with small sample target groups. This way, you’ll know whether target computers are ready for the package or not and increase the success rate or your deployments.

8. Document Your Changes
It’s very important to document how packages are made, but as you know, documentation is often not the strongest points of your technicians. Nevertheless, you need to document changes in packages as they are prepared, otherwise your packagers may well be repeating the same tasks or worse, performing conflicting tasks as they prepare packages. If your team hates writing, use the IPE’s capabilities to capture all of the packaging operations and testing data. This will greatly reduce the amount of documentation your technicians actually need to perform.

9. Patch Your Packages
Patching is a fact of life today. Few software products can avoid being patched. Make sure you identify any required patches for the packages you prepare and if possible, make sure they are applied before the package is deployed. You’ll find that it’s a lot easier to patch in the packaging lab than it is to patch once a package is deployed.

Use your IPE to help determine the impact of patches before you apply them. Include the patches you intend to deploy inside your application catalogs. This will let you quickly identify which applications can be affected by the patch and greatly reduce the time require to test a patch before deployment.

10. Manage Packaging as a Project
Software packaging is a process that moves through specific steps, one after the other. Like all processes, this activity should be managed as a project with sound project management practices. Your IPE should offer strong project management support and should help you keep track of project status at all times. This way, you’ll not only create solid packages that require little post deployment support, but you’ll do it as efficiently as possible.

There you have it: Another 10 commandments that tally up to a total of twenty. Altogether, they will go a long way towards helping you make clean packages that always work. Include all 20 into your everyday packaging approaches and begin to reap the benefits of proper packaging. Make sure the IPE you use lets you take advantage of each and every one of these commandments.