Welcome to the Test Management Software Developers Guide. This guide is a collection of whitepapers designed to help you develop test systems that lower your cost, increase your test throughput, and scale with future requirements. This paper describes the different deployment options for your test software.
As today’s engineers try to meet industry challenges, such as the need to bring products to market faster and integrate new technologies into existing systems, a modular test software architecture has emerged as an ideal solution. The modularization of a test system extends to software by emphasizing the development of test system software using reusable and easy to maintain modules. One of the tasks a test system developer will need to accomplish when creating a modular test system is to deploy this test software to the production floor. Whether you choose to build an installer, use a network server to distribute your test software, or leverage a source code control package, you will want to use care to ensure the integrity of the test stations while at the same time working quickly to have the upgrade process be as seamless as possible. Therefore, an appropriate software deployment strategy will be needed. Software deployment is the process of managing and automating the packaging, testing, distribution and installation of software files and/or applications to test systems across an enterprise network or production floor.
An effective software deployment strategy provides the confidence and reliability needed to ensure an effective software deployment. When facing software deployment, several challenges present themselves and need to be addressed such as:
To address these issues, several methods will be described below on how to effectively deploy your software. We will first discuss the methods of creating a deployment image. Once this deployment image has been created, we will cover the three methods for deploying this image to your test systems which are:
A test system can rely on a wide variety of files and components. When it comes time to deploying your test software, all of these components must be identified, collected, and transferred to the target computer. Hence a “deployment image” is created that contains a directory of files that will be installed to the target computer. Two different options for creating this deployment image are
Manually gathering all files needed for distribution is a tedious job, but provides the developer full user control over what files are deployed to the target computer. One of the most common problems developers experience when deploying test software is missing or incorrect versions of file dependencies. A file dependency is a secondary file that a file requires to compile, load, or run correctly. Normally dependencies come in the form of DLLs, .NET assemblies or subVIs. It is extremely important that you identify exactly what dependencies your test software requires, as well as their versions. This can be challenging and in many cases one might need a third-party product to determine the explicit dependencies of a file.
Since it’s extremely easy to forget to include various dependencies in the deployment image, a tool that packages all relative files together for easy distribution would be nice. The TestStand Deployment Utility greatly simplifies this process by using workspaces and project files to collect all of the files required to successfully distribute your test software to a target computer.
The TestStand Deployment Utility is tightly integrated with LabVIEW facilitating the deployment of the VIs that make up your test system. One of LabVIEW’s biggest benefits is that it is inherently modular. Although LabVIEW applications can be compiled into monolithic executables, they can still be executed and maintain their modular nature as VIs. The TestStand Deployment Utility focuses on facilitating the collection of all necessary VIs. The deployment utility analyzes all of the LabVIEW VIs that it deploys to determine their complete hierarchies, including all subVIs, DLLs, external subroutines, run-time menus, LabVIEW Express configuration diagrams, and help files that your VIs may reference. It then packages these VIs and their hierarchies to ensure that they will be executable on systems that do not have the LabVIEW development system installed. Now that the deployment image has been created, the next step is to actually deploy this image onto your test machines using one of the three methods described below.
The File Copy method consists of copying and pasting the deployment image either directly to a test station’s local drive or to a network drive. Copying the deployment image to a local drive allows the test station to become “self-sufficient” and thus only reliant upon itself. However, the downside to using this option is the fact that distributing updates to all the separate test stations will be time consuming. Copying the deployment image to a network drive reduces distribution time and greatly assists in providing updates to the test software. Since this method is solely network based, common network problems such as network status (up, down), speed of accessing network components, and accessing files already in use must be factored in. Another difficulty when deploying to a network drive would be determining if the test system fails because of an update of the files in the network or an actual test failure. When test software developers send updates to the network, normally notices do not get sent out. Thus it will be difficult to narrow down the test failure.
The File Copy method in general requires very little Windows knowledge and provides the greatest level of control over distributing test software. It also allows upgrades to be easily installed by simply copying over the updated files. Since most test software applications usually incorporate the use of software/hardware drivers, one must ensure that these drivers are present on the target computer. The File Copy method requires that the installation of software/hardware drivers be done separately increasing the effort required to successfully deploy your test software.
Using a source code control (SCC) system to assist in distributing your deployment image can be very beneficial. In this case, the source code control server will maintain a centralized master copy of the deployment image and allow clients (test stations) to sync up and use the test software. Even though in this case the SCC software is networked based, local copies of the deployment image will be downloaded to each client machine which addresses the possible event of network failure. Upgrading the client machines to the latest test software is easy since clients are connected directly to this SCC server and therefore be using the latest revisions of the test software. Additional, this SCC software will allow clients to revert to older revisions in the case of the newest revisions being corrupted or incorrect. This ensures test stations will continue to run regardless of unexpected events. In order to use SCC software, one does require some background knowledge and experience with SCC. Similarly to the copy and paste method, this method will also require the installation of software/hardware drivers been done separately.
The deployment methods mentioned earlier centralize around a more user-controlled deployment approach where the developer performs most of the labor. However, as software applications continue to grow in complexity, a more automated approach to deployment might be a feasible option. Installers allow one to integrate installer technology with the deployment image to create one easy to use installer package that is distributed using any convenient means. Installers provide the additional benefit of bundling together supporting software such as hardware drivers, documentation, licenses, and configuration files with your software application into a single package. Aside from including the supporting software, installers also work directly with the Windows operating system to keep track of user created files, and use the modify/repair/uninstall features of windows installers.
Installers do provide multiple benefits but also bring along some challenges such as distributing minor updates and usability. It is difficult to simply deploy minor changes to a target system as a whole new installation package must be rebuilt. One must also consider the usability difficulties that come along with using common installer packages. Most installer applications are not user-friendly. Windows installers in general provide extreme flexibility and maximum freedom. However, this also forces the user to understand more of Windows technologies. The TestStand Deployment Utility reduces the common difficulties associated with normal installers. The easy-to-use graphical user interface for creating installers is extremely simple to use and provides a flexible and customizable environment to include various components. You need no previous installer knowledge to create a TestStand installer. Including National Instruments drivers and 3rd party drivers is easily done with the deployment utility.
Learn how to use the TestStand Deployment Utility to analyze, build, deploy, and maintain your TestStand sequence.
Developing an appropriate and efficient software deployment strategy is an essential component in the lifecycle of test software. This strategy must determine the most applicable method for collecting required files and distributing them to test stations. Collecting required files can either be done manually or automatically using the TestStand Deployment Utility. After gathering these required files, one must evaluate the advantages and disadvantages of using the three deployment methods. The File Copy and Source Code Control methods provide the greatest amount of user control over test software distribution. However, since this method is solely based off of human effort, it does come with human error. Forgetting to distribute a single file could easily cause a test station to crash. The automated deployment method of using installers fixes the possibility of human error and reduces system replication and deployment times. You must also consider the amount of additional software/hardware drivers that must be installed on the test systems. With the File Copy and Source Code Control methods, these drivers must be installed manually vs. automatically when using installers.
Finally, one must remember that the TestStand Deployment Utility covers both areas of system replication and system deployment. The TestStand Deployment Utility automatically determines and analyzes all required files as well as provides multiple options for deploying the test software. It allows users to create very basic installation packages as well as advanced customized installation packages at an extremely fast pace.