The first thing that usually happens to kick off a packaging and testing process is making an application service request. 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 is routed to the initiation or discovery team.
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 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 Microsoft 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.
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 installation 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.
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.
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."
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, Microsoft 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 an 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.
Traditionally, although most organizations theoretically know they have to manage an application's lifecycle, most application management processes stop 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, applications continue to be constantly tested against new environmental components, like new Windows releases, to ensure that it is still working appropriately. At some point, when the end of life of an application is reached, the application needs to be retired properly.
Prioritizing applications in a large backlog for packaging and testing involves assessing each application's criticality, impact on business operations, and dependencies. Obviously, applications essential for daily business functions, those with a broad user base, or those critical to the security of the IT environment need to be assessed first. Further considerations also include compliance requirements and the potential risks of not updating or testing an application promptly. This approach ensures that resources are allocated effectively, minimizing disruptions and maintaining system integrity.
The application packaging and testing processes vary significantly across industries and types of software due to differing regulatory, security, and operational requirements. For instance, applications in the healthcare and finance sectors undergo stringent compliance and security testing to protect sensitive data, whereas applications in the gaming industry might prioritize performance and user experience.
Cloud-based applications require robust scalability and integration testing, contrasting with on-premises software that may focus more on compatibility and network configuration. Each industry's unique demands shape the approach to application packaging and testing, necessitating customized strategies to meet specific needs.
Common pitfalls in application packaging and testing include underestimating the complexity of application dependencies, overlooking the need for testing across various environments, and insufficient documentation. These can be avoided by employing thorough planning and dependency mapping, implementing comprehensive testing strategies that encompass different user scenarios and environments, and maintaining detailed documentation throughout the process. This approach helps in identifying and mitigating potential issues early, ensuring a smoother deployment and operational phase.