The Application Packaging & Testing Process Explained Step By Step

Application packaging and testing have always been processes that are somewhat shrouded in mystery, siloed off from the rest of the IT organization. But now that the end-to-end process is becoming increasingly automated for leading-edge organizations where even non-technical application owners are empowered through self-service to package low-to-medium complexity applications themselves, everyone needs to know what a standard well-documented process looks like. Therefore, I want to walk you through the entire thing step by step from birth (the end user requests the application) to death (the application is retired).

1) Application Service Request

The first thing that usually happens to kick off a packaging and testing process is an application service request is made. Either an end user or a business unit requests a brand new application or an upgrade to an existing application. The request specifies the exact name and desired version of the application, licensing details, and possibly the time frame in which this application needs to be packaged, tested, and deployed. The application owner typically logs the request in the appropriate system, like ServiceNow or a packaging workflow system.

At this point, only the most basic information about the application is usually captured, so a service request ticket is generated and the ticket routed to the initiation or discovery team.

2) Initiation Phase

After the application request has been submitted and logged, the initiation phase can begin. At this point, you will most likely kick off an approval process for the cost of creating the application package. Due to the often high cost of the application packaging process (which then will be charged back to the business unit), organizations usually get approval as soon as possible after the request has been submitted. In certain cases, a low volume of required installations for the application may dictate that packaging is not initiated, but rather a local/manual install process is undertaken.

Assuming that the criteria for packaging are met, and everything is approved and ready to go, an IT infrastructure application management person contacts the application owner to gather the application-specific source media, install instructions, and other relevant information (e.g, an app needing this configuration in region A and that configuration in region B).

In addition, they will need to know any test login accounts (to be able to test the application), what CPU architecture that application supports, and what dependencies there might exist. They will also need to know whether the app is to be supported on physical machines or uses different platforms or App-V virtualization, such as Citrix, AVD, or Intune. Finally, they need to understand the scope of the distribution. Will this application be deployed company-wide or just rolled out to a few people? At the end of the initiation phase, you should have all of the information you need to go into the packaging phase.

3. Application Packaging

In the next step, you assign your packager or packaging team based on capacity. That person or team is then going to work their way through the install as well as any configuration changes and custom actions that need to be applied (e.g., adding an entry to TNSNAMES or copying a file into a specific directory). Then they snapshot the application (meaning they take the changes from the machine they are packaging on and wrap them up into an application package) before they apply the required organizational standards (such as naming standards, registry permissions, and registry keys) and sign the application (required for MSIX apps). They will also apply any necessary settings, e.g., whether the application is a per-user or per-device install.

Now you have a package in the appropriate format. If your team is executing this process manually, they would have to package first, for example, the MSI package, and then repeat the same process for an App-V. They might have to do the same process twice to get two separate packages or at minimum, run a conversion process against one package to create the second.

4. User Acceptance Testing

Once your application is packaged, you move into user acceptance testing, which is commonly referred to as UAT. The packaging team makes the application available to the application owner, which typically requires the app initiation person to contact the app owner and provision the app into a virtual machine, onto a physical test machine, or in a live environment ready for testing. The application owner then tests the app configuration to confirm that this is what they were expecting. If successful, they will sign it off. If unsuccessful, a lengthy back-and-forth between the two parties may ensue as things have not worked appropriately, something has been missed, it does not install correctly, or something else was not right.

AppM Testing Dashboard 1200x490

5. Quality Review or Quality Assurance

Once the application owner is happy, we can move into a quality review or quality assurance on the package(s). Usually, an internal IT team checks that the application package meets all of the required organizational standards. This could include collecting answers regarding where the app installs, what shortcuts it has, whether or not it has an icon on the desktop, whether or not the naming standard is correct, whether or not the icons are going correctly into the menus, and so on. Depending on your organization, there can literally be more than a hundred checklist items that have to be crossed off. The outcome is typically a documented record called "Quality Assurance Review."

appM - Quality Review Screenshot

6. Staging & Deployment

Once the application passes all the tests and quality assurance, it is time to move into staging and deployment. The application binaries, now in the packaged form, are readied for uploading into MECM, Intune, Workspace ONE, Citrix, or whatever desktop management platform you are using. Typically, there is a change control to upload the application into the live environment.

You will need to run a quick test in the live environment to ensure that the application lets you add a user to an Active Directory group or device to a MECM collection and that the application then installs for that user appropriately and launches successfully. Now everything is ready to be signed off and the application can be added to the application catalog. Often this will be your enterprise application portal from which users can select the app based on the previously determined licensing and access requirements.

7. Lifecycle Management

Traditionally, for most organizations, although they theoretically know they have to manage an application's lifecycle, this application management process stops at deployment. But, in reality, we should move the application into lifecycle management mode to ensure that security updates are applied as they become available and that the application is upgraded to newer versions. Additionally, that it continues to be constantly tested against new environmental components, like new Windows servicing releases, to ensure that it is still working appropriately.