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:
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.
There are several ways an application can be developed. The most common two are:
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.
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.
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 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!
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.
Before your app can go live and be made available to your business users, you will have to do a few more things:
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.
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!
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.