Once you have defined the set of files that you need to include in your test system deployment, you will need to choose a mechanism to distribute the files to production computers. The following sections describe the following deployment mechanisms:
NI Package-Based Deployment
NI packages provide a mechanism to consolidate all the files in the deployment into a single file, which you can deploy and extract to the correct locations on production computers using the NI Package Manager. You can use the TestStand Deployment Utility to build a package containing all the files in the deployment. For package-based deployments, drivers and components that are required by the deployment are referenced as dependencies of the package but are not included in the package itself.
When you install the package on a production computer, NI Package Manager will detect these dependencies and allow you to download and install these packages. You can also use SystemLink software to provide a repository of NI packages within your organization, including NI packages you create. For more information on using SystemLink to manage package-based deployments, refer to How Do I Configure Systems and Deploy Software With SystemLink?
Because each NI package is a singular component, you can update a package-based deployment by creating a new version of the package with an updated version number. Once the new version has been tested and validated, you can distribute it to production computers through traditional file transfer or through SystemLink.
Another approach for deploying files is to create an installer that contains all the required components of the deployment, which can be copied and installed on test station computers. Unlike packages, installers can include required drivers and components within the installer. Including these components makes the installer much larger on disk but ensures that the drivers and runtime engines are always included and available. The TestStand Deployment Utility allows you to create an installer for your TestStand system without direct knowledge of Microsoft installer technology, and offers the following features:
- Distribute files to specific directories on the target computer, such as the <TestStand> directory or the <Desktop> directory.
- Import hardware configuration you generate in Measurement and Automation Explorer (MAX).
- Can include additional components including drivers and runtimes.
- Ability to create patch installers to apply updates to an existing deployment.
For more detail on the features available from TestStand Deployment Utility, refer to Building an Installer with the TestStand Deployment Utility topic in the TestStand help. In most cases, the TestStand Deployment Utility provides the required features to build a customized deployment installer. If you need additional control of the behavior of the deployment installer, you can create an installer using third party tools. Refer to Building an Installer with Third-Party Tools for more information on cases where this may be necessary.
To apply updates to an existing installer, you can use TestStand Deployment Utility to create a patch installer, which only includes updated components. For more information on creating patch installers, refer to the Patching Deployments help topic. In addition, consider creating multiple installers to modularize the deployment, for example having separate installers for Test code, TestStand Components, and Drivers & Runtime engines. With this approach, you can update and distribute only the installers which have changes.
Since installers automatically place files in the correct locations and can include required drivers and runtime engines, it is straightforward to deploy the system once a working installer is created. However, because installer-based deployment must be moved and installed to each test computer, they are typically best suited to deployments that are used on a smaller number of test computers.
Network Drive Deployment
With network drive deployment architectures, files are shared with test station computers directly using a network drive, without consolidation into an installer. Access to files on the network drive can be managed by a source code control solution. With this approach, test developers create and update files in the shared repository. Once finalized for testing, these files are then either copied to production machines, or used directly from the network location.
With a network drive deployment strategy, you use a shared repository to share files between development, staging, and production computers
When developing new test code, it is important to ensure that code in development is never used on deployed systems until it has been tested and validated. Typically, a production computer with access to testing hardware is designated as a staging tester, and is used to validate and test pre-release test systems. Once the test system has been validated on the staging tester, it can be deployed to production machines.
The best approach for ensuring that deployed code is validated varies depending on how often updates need to be applied to test stations.
For cases where frequent updates are needed, a Continuous Integration and Delivery (CI/CD) approach can help ensure that the latest code is available on test computers, while still ensuring the code has been properly tested and validated. With a CI/CD approach, you automate much of the procedure to build, test, and deploy updates to test code to reduce overhead as much as possible. You can use third party tools, such as Jenkins, to implement this type of automation.
For more tightly controlled environments, validation requirements are typically very stringent, and therefore test system updates cannot occur frequently. For these test systems, define a separate repository or trunk where developers make changes and add new features to the test. Once the latest version of the test system has been finalized and validated, developers create a versioned branch of the trunk for use on production machines. This branch should be locked within source code control to prevent any changes to validated code. Once the new branch is completed and validated, create a new versioned branch containing the code.
To deploy the test code, production machines obtain a copy of the versioned code, which should remain read-only to ensure that the it is unchanged. To further ensure that no changes are made to validated files, you can add code to the test sequence to validate the checksums of all files. For more information on this approach, refer to the Best Practices for Verification and Validation of TestStand Systems document.
Deploying Drivers and Runtime Engines with Network Drive Deployments
When using a network drive-based approach, you will need to use a separate mechanism to install the necessary drivers and runtimes on test computers. Runtime engines and drivers can be deployed through the following mechanisms:
- Building an installer containing the required software. The TestStand Deployment Utility can generate an installer which includes runtime engines and drivers.
- Creating a system image based on a system with all required drivers and runtimes installed.
The best approach depends primarily on the frequency of updates to the system. In many cases, you can use a combination of multiple approaches. The following common scenarios illustrate choosing a strategy for driver and runtime deployment:
- For systems with infrequent updates, creating an image will typically have a positive ROI. Small updates to the test system can still be implemented without the need for updating the image.
- For systems that are updated more frequently, Create an installer for your test system with the required drivers and runtimes.
Strategies for Accessing Test System Files
With a network drive deployment, you can use one of the following general approaches for managing file storage:
- Access files directly from the network drive.
- Copy files locally from the network drive, using 3rd party tools to ensure that local files are synchronized with the drive.
Accessing Files Directly from a Network Drive
The advantage of accessing files directly from a network drive is that when files are updated on the network drive, you ensure that the update is applied to all test computers. However, accessing files directly from a network drive means that the operation of the test stations will depend on the availability of the shared drive and the network connection. If either is unavailable, manufacturing operators cannot run test files from the test station, which can cause production line stoppages. It is therefore critical that you work with your IT department to make sure they can meet the uptime requirements for both the shared drive and the network. For example, using server redundancy to meet uptime requirements for the shared drive.
To use a shared drive to store TestStand configuration files and components, you must use the TestStand environments feature, which allows you to specify the location of TestStand directories. To do so, you create an environment file (tsenv) which contains the network drive location for these directories. For details on how to create and use this file, refer to the TestStand Environments help topic.
Copying Files Locally to Each Test Station
You can also choose to create local copies of all deployment files, This approach has the following advantages:
- Allows test stations to execute tests without a permanent network connection.
- Can decrease the load time for test system files.
However, this approach adds additional effort to copy files on all test stations. You must also ensure that all test systems have the latest files before running any tests.
You can build additional tools to automatically compare the version of the file on the test station matches the shared drive each time the test station is started and download any files that are not up to date.