Packaging (either project based or day to day support) must follow a general process to produce a finished product. Determining a workable process for packaging allows for formalisation of the process and the introduction of systems to monitor and manage Application packaging.
The list below represents the general process of a staff member deciding they need new software and the steps involved for a package to be delivered into the production network. The workflow is a guide but a fair represntation of the steps required in a full application packaging & release process flow.
Staff Member (Non-Information Technology)
|
Software Purchasing Request
|
New Software Approver (Information Technology))
|
Purchase Order Raised
|
Software Arrives
|
Application Packaging Request Raised
|
Application Packager receives media & liaises with requestor
|
Package Created
|
Package Peer Reviewed
|
Package Testing by Expert User
|
Package Transferred to Software Distribution
|
Packaging Request Closed.
Individual parts of the process may benefit from deeper analysis.
Software Approver
Generally someone will evaluate new software requests to ensure that other software doesn’t already exist in the organisation that can fulfil the requirements of the request. In an upgrade project, this role may be someone who has an overall responsibility for consolidation of software. The philosophical importance is that Information technology provides a service to the business & should not be dictating to the business what it can and can’t do – this role is therefore one that is generally held b
Package Peer Review
This can also be referred to as “Package Testing” as what is being reviewed is the quality of the package, not the actual application that’s contained within. As this step requires the reviewer to have an in depth understanding of MSI technology, the only people who can evaluate the package are other packagers.
One major method for ensuring that standards are met is to develop separate scripts that can report on how a package meets standards. This means that a physical record of checks being run may be saved and documented as part of the peer Review process. I have personally produced a series of scripts that do this in a number of organisations & will discuss how this is done later in this document.
Package Testing
The level of testing that is appropriate for an application is strictly a business concern, not an Information Technology requirement. The majority of organisations will utilise “Expert Users” or in a Project based setting, may have a full Test team with testing scripts established.
Peer Review (Package Testing)
One of the biggest Truisms in Information Technology is that developers shouldn’t test their own work. The same is true for Application Packagers.
Any organisation seriously looking at introducing application packaging should ensure that there is some independent verification that a package conforms to internal packaging standards. Often this stage of the packaging process is referred to as Peer Review.
Someone needs to ensure that the quality of packaging is acceptable before a package is submitted for user acceptance testing. A lot of the time there are various reasons why an application can not conform properly to published standards within an organisation. Often Peer Review will just be another application packager ensuring that all of the “faults” have been documented with justifications as to why they exist.
Some elements of the MSI must be tested and recorded as part of an official testing process..
- Does the MSI install without error prompts?
- When installing with a log (/l*v) are any errors recorded in the log?
- Do errors exist in the workstation’s Application log?
- Can an installation run without a GUI being present?
- Can a repair run without errors?
- Does the application open in a locked-down user context without crashing or showing errors?
- Does the application uninstall cleanly & without errors?
- Is the package free of ICE validation errors? If not, are the errors documented with justification as to why they exist?
- Are naming formats for the package correct?
- Does the package conform to internally published standards?
Remote Installation testing
No installation testing is valid unless the installation occurs remotely and without a GUI shell loaded.
A big problem with testing is how test a package remotely without a user being logged onto a machine. An application packager may be expected to test an application many times before it is ready to be imported into a Software Distribution system, as a result, using SMS or any other system to test packages isn’t really an option during development stages.
In places that I’ve worked, I have generally created Remote Installer utilities. In organisations that utilise a standardised installation script, a utility or batch file to do the same thing could be created in minutes. Organisations that don’t utilise standardised installation scripts make the process a lot more complicated and time consuming
The best solution for an organisation who hasn’t adopted a system for remote deployment of packages is to look at Sysinternals freeware utility PSExec. Note: this writing is 10 years old & other solutions are now available. Do investigate the use of Launcher.exe (on this site).
PSExec is a command-line utility that can be used to start a remote process under particular credentials. For our purposes, we need to ensure that no user is logged on when the installation command is remotely run with an Administrative Account.
What needs to be remembered is that wherever the Installation is run from must be accessible by restricted ID’s after the installation has run. If the location was not accessible (such as a mapped drive or an inaccessible UNC location) Windows Installer is unable to heal itself when self repair is triggered. I’ve found that the easiest way to achieve this is to copy the installation files and MSI to a directory on the C drive and initiate the installation from there. In more cohesive (or smaller) organisations it will be straightforward to create a UNC share which testing user accounts have read rights to. In this scenario, installing from the network will work nicely. Unfortunately, getting something relatively simple such as a new share created in the enterprise can involve change control and a level of politics that makes the exercise unworkable.
User Acceptance Testing / Functional Testing
There can never be too much testing… unless you personally have to pay for it or you have project timeframes that can’t be met as a result of a heavy testing plan. We always have to test everything we do in Information Technology; the question is really where we draw the line as to appropriate testing.
Whatever process flow is adopted within an organisation, User Acceptance Testing should not be started until a Peer Review on the quality of the package has been completed. If the Windows Installer package conforms to Microsoft’s quality requirements (ICE validation) and has been captured correctly, User Acceptance Testing will either find problems extremely quickly or won’t find anything without a massive amount of work being completed.
Testing can soak an incredible amount of time and resource and doesn’t necessarily add any value to a product. Unless a mistake with how the package was created is found, virtually no other issues can be resolved by Application Packagers at all. We will often be repackaging very old applications that are no longer supported by their vendors so if real problems are found, the only answer is to not use the application at all.
Ultimately, the level of testing to be undertaken (and the amount of money and time that will be used) is a decision for representatives of the Business. Normally, every application will be tested by an Expert User (i.e. a staff member who extensively uses the application). In most organisations this is enough to be confident that the package will not cause any real problems in a production environment.
- Log in to post comments