HCIDeploy Publisher - Testing

HCIDeploy Publisher - Testing

Recommended Practices for Testing Deployments

• Make heavy use of testing locations. Create at least two test locations for testing installs and uninstalls.
• Put test lab workstations in testing locations based on XA mode if your organization uses more than a single XA operation mode.
• Test install.bat/install.vbs files before putting them in packages for distribution.
• Test uninstall.bat/uninstall.vbs files before putting them in packages for distribution.
• Test installs and uninstalls by adding and removing the package from the location(s) using HCIDeploy Publisher.
• Ensure that there are no wscript.echo or msgbox commands in VB Scripts. In short, don't put any UI elements in the VB Script files that would cause the script to hang. UI Elements will not be displayed to end users.
• Do not use pause or other commands that would hang a .bat file.
• Remember that Batch and VB Script files may only execute for 30 seconds or less - if the script isn't finished with its work before that time, it will be deemed lost and will be terminated. If you need to perform a more lengthy process, consider using the batch command START to spawn a secondary script.
• Add user notification script calls to the deployment install and uninstall scripts to monitor script execution during testing.

Look beyond Staging and Default

Make use of these locations for their intended purposes. Staging can be used to quickly "un-deploy" a wrapper - just remove it from the location. Remember that EVERY registered PC will receive the packages listed in Default, so be sure that what you put in the Default Location is supposed to be deployed to every workstation running HCIDeploy.

Given that, think carefully about creating new locations to organize the packages for deployment.

As mentioned in Recommended Practices for Testing Deployments, consider making a few test locations and only adding workstations to those that are under IT control. Remember to consider real world usage as a potential test as well, so consider creating a pre-deployment test location where one or two production machines are associated.

A good process to follow might include the following checklist:

• Create your wrapper executable and any supporting files.
• Pre-test any install.bat or install.vbs files using standard command line CMD.exe or WScript.exe under ADMINISTRATIVE account permissions.
• Pre-test any uninstall.bat or uninstall.vbs files using standard command line CMD.exe or WScript.exe under ADMINISTRATIVE account permissions.
• Once confident the custom scripts are operational, publish a new package containing your updates. The package will be associated with the Staging location.
• Add the package to the Install Testing location (You would have to create one)
• Install Testing should contain at least one IT machine - use the HCIDeploy Console application to quickly execute the synchronization, or have the Test Lab machines set for a 5 minute schedule for update checks. If XA is deployed in multiple modes in your organization, use a test machine in the test lab containing each of the modes in your deployment testing.
• Verify any install.bat or install.vbs files execute on the test workstation and perform their intended operations as desired.
• Remove the package from the Install Testing location - this will allow you to test the uninstall.bat or uninstall.vbs files to ensure they perform their intended tasks.
• Add the package to the Connector Testing Location (you would have to create one) - The intent of this location is to provide a test bed to ensure proper connector operations.
• Perform your standard connector testing procedures before considering putting the connector into pre-deployment production. Make updates to the connector and package as necessary.
• Once confident any custom scripts are correctly operating for install and uninstall, add the package to the pre-deployment location (you would have to create one)
• The Pre-deployment workstations should have a short time schedule for checks as well - maybe every 10-15 minutes
• Gather feedback from the employees using these pre-deployment workstations to ensure they see acceptable behavior from the new or updated connector.
• Once confident the connector is performing as expected, add the package to full production for the correct location. Remember, a package may be deployed to multiple locations if necessary.
• If connector errors are reported from production, create new test packages with the contents of the old packages. Associate these new packages with your test environment and update and re-test the connector. Once the defect has been addressed, perform an update on the original package so that it creates a new version of the existing package.
  • Given Package 1 and Package 2
  • Package 1 is reported to have a defect - Package 2 is a clone of the contents of Package 1, just under a different name (They must be unique)
  • Update the connector, then update Package 2 via HCIDeploy Publisher.
  • Perform testing of Package 2 in the test locations.
  • Once confirmed the defect is addressed, perform an update of Package 1 via HCIDeploy Publisher.
  • This will ensure that connectors deployed to production address the defect without causing additional problems, and without having to uninstall or revoke the current connector from production.