Every line of business has its own unique lingo which often makes it hard for “outsiders” to follow a conversation. As an executive, whether you are a CEO, COO, CFO, or even a CIO, application packaging and testing terms can seem like a completely different language with their three and four letter acronyms.
Today, I want to go through the most commonly used ones and define them using non-technical language in the hope of simplifying future conversations, but also to clarify a few things. So, let’s jump right in:
MSI File Or MSI Package
An MSI file or MSI package is a file format that was originally developed by Microsoft to package all information necessary to install Windows update information and kick off other processes needed within the Windows Operating System. However, the file format became popular with other software vendors that have been using it to install applications on Windows.
Inside an MSI file or package is information on an application’s features and components. The latter includes files, registry data, shortcuts and so on. In addition, it contains the user interface to walk the user through the install process (usually a popup) as well as instructions regarding how and when to execute custom actions. It also sometimes holds the actual files to be installed or instructions on how to find the path to the actual files.
Internally Developed Applications vs. COTS
There are several ways an application can be developed. The most common two are:
- Internally developed. These are applications designed, developed, and built within the organization by internal developers to solve a specific problem (e.g., trading software). This software is not going to be resold to anyone else. While it requires a specific skill set and can be very costly, internally developed apps can create a significant competitive advantage and, if using an Agile software development methodology like Rapid Application Development (RAD), can change within a matter of weeks or even days.
- Consumer-Off-The-Shelf (COTS). The opposite of internally developed software is a COTS app. These apps are commercially developed applications that are created with a certain (business) problem in mind, but resold to a large number of organizations (e.g., SAP ERP, Microsoft Office, Adobe Reader). These products are generally already wrapped up in executable files, MSI packages, or virtual file formats to be installed right away.
.Net vs. Java-Developed Apps
Traditionally, there have been two opposing application development views: applications created on the .Net (pronounced Dot Net) Framework and applications using Java.
Java was developed as the first object-oriented programming language by Sun Microsystems in 1991. Although it is almost 30 years old, it is still the most popular programming language in the world. There are still more than 9 million Java developers worldwide. Products developed in Java are web apps, which means they are running within browsers.
The .NET Framework is a Microsoft-developed software framework that runs primarily on the Windows Operating System. .Net programs require a special environment to run in, called Common Language Runtime (CLR), to provide security, memory management, and exception handling as well as a large class library called the Framework Class Library (FCL). Together, the CLR and the FCL create the .Net Framework.
Universal Windows Platform (UWP), AppV, & MSIX
In the past 12-18 months, Microsoft has been actively trying to move developers away from outdated file formats like Click-to-Run (CTR), Powershell scripts, AppX apps, MSIs, and others and to encourage developers to adopt the new Universal Windows Platform (UWP). This would provide a common application platform to develop one application that runs on every Windows 10 device and is able to leverage native Windows 10 capabilities.
- App-V. App-V stands for Microsoft Application Virtualization for Windows 10 and allows developers to deliver Win32 applications to users as virtual applications. Virtual applications are not installed on each user’s individual device but on a centrally managed server. They are then delivered to the users “as-a-Service” in real time and as needed. Users can launch an App-V application from desktop shortcuts or other familiar access points and interact with it as if it was installed locally.
- MSIX. MSIX is a new Open Source container type that can be used for all Windows applications, such as Win32, UWP apps, and other operating systems. While it inherits features from the Universal Windows Platform, it unites other application packaging technologies, such as AppX, AppV, and MSIs. This will be the future of packaging applications — at least in the Microsoft universe.
For more information on the Universal Windows Platform, please refer to a recent article on our blog.
Now that we have looked at the different file and application types, let’s have a look at terms used to describe part of the application testing process.
Application Packaging
Application Packaging is the process of bundling together all files, components, and information in an application executable file or package that are required to install, start, execute, and run an application in a specific environment. As an application is developed and readied for release, it will be packaged. However, re-packaging might become necessary down the road if the environment in which the application is running changes. For example, re-packaging might be needed for certain applications to upgrade them to run on Windows 10.
This process can be managed internally through a dedicated application packaging and testing team or can be outsourced. Traditionally, this tedious, labor-intensive, and lengthy/costly process was the number one bottleneck for any IT Transformation project. Thankfully, with application packaging and testing automation, the workload, time, and cost can be significantly reduced!
Application Testing: QA, OAT, and UAT
After an application has been packaged, it is time to ensure that it will not only install, run, and uninstall without any issues (e.g., screen freezes during start-up process), but also that the application performs as expected, doesn’t interfere with any other applications, and doesn’t cause any bandwidth or other performance drains for the environment it runs in.
- Quality Assurance (QA) Testing. The first step is your Quality Assurance (QA) testing which should be completed as part of the installation package creation process. It allows your testers to ensure that the database is operating correctly to install, uninstall, and repair an application. Once you have a successful test outcome, your application can be routed to your operational acceptance testing.
- Operational Acceptance Testing (OAT). Next, your packaging or development team needs to test the application for non-functional issues, meaning the team looks for how much bandwidth, RAM capacity, and other KPIs the application uses. This is an important step for any larger organization. Imagine thousands of users opening up a certain business application at the beginning of the workday and the app freezes because it maxes out your bandwidth capacity!
- User Acceptance Testing (UAT). Once the application clears that hurdle, it is time to test on a functional level — e.g., is the application doing what it is supposed to do? This is done by a designated product owner in a business unit.
Application Pilot, Publishing, And Deployment
Before your app can go live and be made available to your business users, you will have to do a few more things:
- Pilot Release. The term “Pilot”, in regards to application packaging and testing, refers to the initial soft release of the User Acceptance Testing package to a small number of users. This pre-production release allows you to ensure that the application isn’t going to break anything under real-world circumstances before it is rolled out to a broader audience.
- Publishing. Now your app has passed all tests and needs to be published, which means its application package is made available in a form that business users can install to access the application. One common approach to publishing apps in enterprises is doing so through a corporate app store or the Microsoft Store. The file or package output is created in a desktop management platform (e.g., Microsoft SCCM) for multiple testing platforms and teams.
- Deployment. Finally, the successfully UAT signed-off application can now be released. The official term for that step is “deployment”.
This concludes the application packaging and testing cycle. However, there is one more important term I want to share with you as it is a crucial concept to keeping your application estate as secure as possible: application whitelisting.
Application Whitelisting
Imagine your application portfolio as a huge assortment of potential vulnerabilities.
You don’t know if they will cause damage or not, nor do you know how much. To keep your organization safe, you will have to come up with a process that separates the wheat from the chaff, so to speak — the ones that are deemed safe as they meet internal security guidelines, and the ones that aren’t.
Now, there are two ways of going about that. In the first method, called black-listing, you assume the application is safe until there is a reason not to, at which point you then specifically declare it as unsafe and put it on a blacklist. This method has been used by antivirus programs for years. However, the downside is that you are exposing yourself to potential threats until the application is blacklisted.
Contrary to that, application whitelisting will disallow all applications by default and only permit those explicitly allowed. This proactive approach tightens your security defenses from the start as it exposes your environment to fewer potential threats!
Next Steps
I hope this article cleared up some confusion around the very technical world of application packaging and testing. I encourage you to dig deeper and to have conversations around automating and accelerating this process to eliminate one of the largest bottlenecks your team will face on their path to Digital Transformation and Evergreen IT. If you have any questions, please feel free to reach out directly or schedule a consultation below.
