ProblemWe have had this problem statement at hand which requires the field engineer to validate that any engineered solution, when deployed at a customer site, is running the supported versions of the firmware and driver.
BackgroundWell, we already have Pester tests written and placed inside a validation kit which tests whether a deployment is as per the practices outlined in our deployment guide.
So this was only natural to add the driver version validation under this kit (firmware validation in the future release).
We use Pester (PowerShell unit testing framework) for the Infrastructure/Ops validation and PSRemotely to target all the nodes in our solution for these tests. So the code samples in the post correspond to that.
Where to store supported version info?First, of all, we decouple the environment details (inputs) to our validation kit in a file named EnvironmentConfigData.psd1. This file follows PowerShell DSC style configuration data rules.
Inside this configuration data, we maintain a list of all supported versions under the PnPDeviceMetadata. See below EnvironmentConfigData.psd1 for sample :
Now this metadata inside the configuration file serves as the source of truth for the supported versions in our solution.
Test the nodeThe above metadata is used by a generic test block written in Pester as below and runs on each node in our solution. Note that $Node variable below is a placeholder for all the information specific to a node in our solution and is generated after reading the above environment configuration data by the framework PSRemotely : Decoupling of the supported driver version and making the PnP device driver version validaiton test a generic Pester test enables us the agile addition of validation new components that are shipped with our solution e.g S2D, CPS etc. We also are working on extending this to validating firmware versions as well. Useful reference: