Pratiques exemplaires de déploiement du système TestStand

Un système de test est généralement complexe, contenant de nombreux composants et fichiers, qui doivent tous être correctement déployés pour garantir le bon déroulement du test sur un système de production. Dans ce document, nous prenons uniquement en compte les composants logiciels utilisés pour tester un produit.

Les systèmes TestStand ont de nombreux composants qui doivent être inclus dans un déploiement

Les principaux composants d’un système de test TestStand sont le code de test, les fichiers du framework du test, les drivers et les moteurs d’exécution.

Code de test

Le code de test comprend les fichiers de séquence et les modules de code que vous créez pour implémenter les tests réels. Lors du déploiement du code de test, vous devez vous assurer que toutes les dépendances requises de vos modules de code sont incluses et que les fichiers sont déployés aux emplacements appropriés sur le disque afin qu’ils puissent être trouvés par leurs appelants. En règle générale, le code de test comprend un ou plusieurs fichiers de séquence avec les fichiers auxquels ils font référence. 

Fichiers de séquence

Les fichiers de séquence dépendent des modules de code qu’ils appellent, des dépendances des fichiers de séquence et des fichiers supplémentaires tels que les fichiers de chargeur de propriétés. Vous pouvez utiliser l’utilitaire de déploiement TestStand pour analyser les fichiers de séquence et énumérer ces dépendances. Les dépendances référencées dynamiquement, telles qu’un fichier de propriétés spécifié par l’expression TestStand, ou les fichiers référencés implicitement, tels que la documentation de test, ne seront pas reconnues par l’utilitaire de déploiement TestStand.

Dans la mesure du possible, vous devez stocker tous les fichiers dépendants d’un fichier de séquence particulier dans un sous-répertoire sous le chemin du fichier de séquence. Cette structure présente les avantages suivants :

• Les fichiers peuvent être référencés à l’aide d’un chemin relatif au fichier de séquence actuel, garantissant que les chemins restent valides si vous copiez le fichier de séquence et les dépendances vers un autre emplacement.
• Le suivi des dépendances appelées dynamiquement et implicites est beaucoup plus facile, car vous pouvez déployer le répertoire des dépendances dans son ensemble.

Vous devez également prendre en compte les dépendances des modules de code eux-mêmes. Le processus de déploiement de ces dépendances varie en fonction du type de module.

Modules de code LabVIEW

Les modules de code LabVIEW incluent des VIs, des appels de membres de classe LabVIEW, des appels de VIs Express et des appels de nœuds de propriété. Afin d’exécuter des modules de code LabVIEW sur un système sans avoir le système de développement LabVIEW installé, vous devez vous assurer que toutes les dépendances des modules de code VI sont enregistrées dans la même version de LabVIEW. Vous devrez également inclure tous les VIs dépendants livrés avec le système de développement LabVIEW, tels que ceux présents dans les répertoires vi.lib ou instr.lib de l’installation LabVIEW, sont inclus dans le déploiement. Vous pouvez utiliser les approches suivantes pour vous assurer que les deux conditions sont remplies :

• Créer une distribution de code source LabVIEW pour tous les VIs de module de code et assurez-vous que les options d’exclusion de vi.lib, instr.lib et user.lib ne sont pas sélectionnées. Pour éviter les références croisées entre vos VIs sources et les VIs de la distribution de code source, assurez-vous d’ajouter les fichiers à une nouvelle bibliothèque de projet.
• Créer une ou plusieurs bibliothèques de projet empaquetées (PPL) pour vos fichiers sources. Une PPL est un fichier compilé unique contenant tous les VIs et leurs dépendances. Avec cette approche, vous pouvez mettre à jour les déploiements existants en remplaçant une PPL déployée par une version mise à jour.

* Les PPL n’incluent pas les dépendances qui sont des DLL ou des VIs qui sont déjà compilés dans une PPL

Pour gérer automatiquement une grande partie de ce processus, vous pouvez utiliser l’utilitaire de déploiement TestStand pour déployer vos fichiers de séquence qui appellent des modules de code LabVIEW. L’utilitaire de déploiement TestStand enregistre tous les VIs dans une seule version de LabVIEW et inclut toutes les dépendances requises qui font partie du logiciel de développement LabVIEW. L’utilitaire de déploiement peut également éventuellement générer une bibliothèque de projets empaquetée (PPL). Pour plus d’informations, reportez-vous à Déploiement de VIs dans les bibliothèques de projets empaquetées LabVIEW.

Dépendances DLL C/C++

En règle générale, toutes les DLL dépendantes seront copiées dans le répertoire de construction ou sont des DLL système incluses avec les moteurs d’exécution requis. Lorsque possible, vous ne devez pas déployer directement des DLL ou d’autres binaires directement dans les répertoires système Windows, mais plutôt déterminer le logiciel qui installe ces dépendances et l’inclure dans votre déploiement. Reportez-vous à la section Drivers et moteurs d’exécution ci-dessous pour plus d’informations sur le déploiement de logiciels supplémentaires.

Dépendances .NET

Comme les DLL C/C++ non gérées, les DLL .NET gérées sont du code compilé qui peut être exécuté sans logiciel de développement. Contrairement aux DLL C/C++, les assemblys .NET peuvent référencer des assemblys dépendants dans le Global Assembly Cache (GAC), qui peuvent inclure des assemblys installés avec des drivers ou des logiciels d’exécution, mais peuvent également inclure votre propre code.

Lors de la création d’assemblys .NET, vous pouvez utiliser la propriété « Copier local » (Copy Local) pour les assemblys référencés pour en inclure une copie à côté de votre assembly. Ce faisant, vous pouvez vous assurer que les dépendances .NET sont déployées en déployant le dossier contenant vos assemblys et dépendances.

Fichiers du framework de test

En plus du code de test, vous devez également déployer des fichiers de framework TestStand. Si vous incluez le moteur d’exécution TestStand dans votre déploiement, les versions par défaut de ces fichiers seront installées sur le système. Toutefois, si vous disposez de versions personnalisées de ces composants, vous devrez les inclure dans le déploiement du système de test. 

Fichier de configuration TestStand

Les fichiers de configuration TestStand stockent les paramètres de l’installation locale de TestStand.  Ces fichiers décrivent et pilotent le comportement d’un système de test. Les fichiers de configuration TestStand se trouvent dans le répertoire <TestStand Application Data>\Cfg.

Pour plus de détails sur les fichiers de configuration inclus avec TestStand et les informations stockées dans chaque fichier, reportez-vous à la rubrique d’aide Fichiers de configuration.

Composants TestStand

Les composants TestStand sont des fonctionnalités qui implémentent l’exécution de haut niveau du système de test et sont découplés de la séquence de test pour améliorer la modularité de l’architecture TestStand. Les composants TestStand implémentent des fonctionnalités telles que la fonctionnalité de connexion et de déconnexion, les rapports, l’enregistrement de bases de données et la saisie du numéro de série. Ces fichiers se trouvent dans le répertoire <TestStand>\Components.

Pour plus de détails sur les éléments du répertoire des composants TestStand, reportez-vous à la rubrique d’aide Répertoire des composants

Interfaces utilisateur TestStand

Pour exécuter des séquences sur une machine déployée, vous devrez déployer au moins une interface utilisateur, car l’éditeur de séquence n’est disponible que sur les machines de développement. Les interfaces utilisateur peuvent être simples ou hautement personnalisées, selon vos besoins. TestStand inclut des applications d’interface utilisateur que vous pouvez déployer dans <TestStand Public>/UserInterfaces.

Pour des informations spécifiques sur la création d’interfaces utilisateur TestStand à utiliser sur les machines déployées, reportez-vous au document Pratiques exemplaires de développement d’interface utilisateur NI TestStand.

Drivers et moteurs d’exécution

Pour exécuter des séquences et tester du code sur un système de production, vous devez vous assurer que tous les moteurs d’exécution et drivers matériels requis sont installés. Les moteurs d’exécution sont requis pour l’exécution des composants logiciels, tels que les DLL, les VIs et les fichiers de séquence. Des drivers sont nécessaires pour les composants matériels utilisés par le système de test. Vous devrez toujours déployer le moteur d’exécution TestStand, qui contient le moteur TestStand et les fichiers de support. 

Si vous effectuez un déploiement à l’aide de l’utilitaire de déploiement TestStand, vous pouvez choisir de détecter et d’inclure la version requise des drivers et des moteurs d’exécution référencés par des modules de code. Si vous n’incluez pas le moteur d’exécution, l’utilitaire de déploiement TestStand fournit à la place un message de journal informatif indiquant les versions à inclure dans le déploiement.

Licences logicielles

Vous devez vous assurer que les licences logicielles appropriées sont disponibles pour les machines déployées. Chaque machine déployée nécessite au minimum une licence de déploiement de base, ce qui permet l’exécution de séquences, mais pas le développement. De nombreux moteurs d’exécution, tels que LabVIEW et les moteurs d’exécution LabWindows/CVI, n’ont aucune exigence de licence. Vous devez consulter la documentation de tous les composants supplémentaires que vous déployez pour vous assurer d’obtenir les licences de déploiement nécessaires. Reportez-vous à la section Licences de déploiement de la rubrique d’aide Déploiement et débogage des licences pour les logiciels NI pour obtenir une liste de tous les produits NI qui nécessitent des licences sur les applications déployées.

Si vous effectuez un déploiement sur un grand nombre d’ordinateurs de production, NI fournit des licences en volume, vous permettant de gérer les licences via un serveur de licences central. Pour plus d’informations sur les options de licence en volume, reportez-vous à la page Programme de licence en volume pour logiciel.

Après avoir défini l’ensemble de fichiers que vous devez inclure dans le déploiement de votre système de test, vous devrez choisir un mécanisme pour distribuer les fichiers aux ordinateurs de production. Les sections suivantes décrivent les mécanismes de déploiement suivants :

• Déploiement basé sur des paquets NI
• Déploiement basé sur l’installateur
• Déploiement du lecteur réseau

Déploiement basé sur des paquets NI

Les paquets NI fournissent un mécanisme pour consolider tous les fichiers du déploiement en un seul fichier, que vous pouvez déployer et extraire aux emplacements appropriés sur les ordinateurs de production à l’aide du gestionnaire de paquets NI. Vous pouvez utiliser l’utilitaire de déploiement TestStand pour créer un paquet contenant tous les fichiers du déploiement. Pour les déploiements basés sur des paquets, les drivers et les composants requis par le déploiement sont référencés en tant que dépendances du paquet, mais ne sont pas inclus dans le paquet lui-même. 

Lorsque vous installez le paquet sur un ordinateur de production, le gestionnaire de paquets NI détecte ces dépendances et vous permet de télécharger et d’installer ces paquets. Vous pouvez également utiliser le logiciel SystemLink pour fournir un dépôt de paquets NI au sein de votre organisation, y compris les paquets NI que vous créez. Pour plus d’informations sur l’utilisation de SystemLink pour gérer les déploiements basés sur des paquets, reportez-vous à Comment configurer des systèmes et déployer des logiciels avec SystemLink ?

Étant donné que chaque paquet NI est un composant unique, vous pouvez mettre à jour un déploiement basé sur un paquet en créant une nouvelle version du paquet avec un numéro de version mis à jour. Une fois la nouvelle version testée et validée, vous pouvez la distribuer aux ordinateurs de production via un transfert de fichiers traditionnel ou via SystemLink.

Déploiement basé sur l’installateur

Une autre approche pour déployer des fichiers consiste à créer un programme d’installation contenant tous les composants requis du déploiement, qui peuvent être copiés et installés sur les ordinateurs de la station de test. Contrairement aux paquets, les programmes d’installation peuvent inclure les drivers et les composants requis dans le programme d’installation. L’inclusion de ces composants rend le programme d’installation beaucoup plus volumineux sur le disque, mais garantit que les drivers et les moteurs d’exécution sont toujours inclus et disponibles. L’utilitaire de déploiement TestStand vous permet de créer un programme d’installation pour votre système TestStand sans connaissance directe de la technologie d’installation Microsoft et offre les fonctionnalités suivantes :

• Distribution des fichiers dans des répertoires particuliers sur l’ordinateur cible, tels que le répertoire <TestStand> ou le répertoire <Desktop>.
• Importation de la configuration matérielle que vous générez dans Measurement and Automation Explorer (MAX).
• Possibilité d’inclure des composants supplémentaires, notamment des drivers et des moteurs d’exécution. 
•  Possibilité de créer des installateurs de correctifs pour appliquer des mises à jour à un déploiement existant.

Pour plus de détails sur les fonctionnalités disponibles à partir de l’utilitaire de déploiement TestStand, reportez-vous à la rubrique Création d’un installateur avec l’utilitaire de déploiement TestStand dans l’aide de TestStand. Dans la plupart des cas, l’utilitaire de déploiement TestStand fournit les fonctionnalités requises pour créer un installateur de déploiement personnalisé. Si vous avez besoin d’un contrôle supplémentaire sur le comportement de l’installateur du déploiement, vous pouvez créer un installateur à l’aide d’outils tiers. Reportez-vous à Création d’un installateur avec des outils tiers pour plus d’informations sur les cas où cela peut être nécessaire.

Pour appliquer des mises à jour à un installateur existant, vous pouvez utiliser l’utilitaire de déploiement TestStand pour créer un installateur de correctifs, qui inclut uniquement les composants mis à jour. Pour plus d’informations sur la création d’installateurs de correctifs, reportez-vous à la rubrique d’aide Déploiements de correctifs. En outre, envisagez de créer plusieurs installateurs pour modulariser le déploiement, par exemple en ayant des installateurs distincts pour le code de test, les composants TestStand et les drivers et moteurs d’exécution. Grâce à cette approche, vous pouvez mettre à jour et distribuer uniquement les installateurs qui ont des modifications.

Étant donné que les installateurs placent automatiquement les fichiers aux bons emplacements et peuvent inclure les drivers et les moteurs d’exécution requis, il est simple de déployer le système une fois qu’un programme d’installation fonctionnel est créé. Cependant, étant donné que le déploiement basé sur l’installateur doit être déplacé et installé sur chaque ordinateur de test, ils sont généralement mieux adaptés aux déploiements qui sont utilisés sur un plus petit nombre d’ordinateurs de test. 

Déploiement du lecteur réseau

Avec les architectures de déploiement de lecteurs réseau, les fichiers sont partagés avec les ordinateurs de la station de test directement à l’aide d’un lecteur réseau, sans consolidation dans un programme d’installation. L’accès aux fichiers sur le lecteur réseau peut être géré par une solution de contrôle de code source. Grâce à cette approche, les développeurs de test créent et mettent à jour des fichiers dans le dépôt partagé. Une fois finalisés pour les tests, ces fichiers sont ensuite soit copiés sur les machines de production, soit utilisés directement à partir de l’emplacement réseau. 

Avec une stratégie de déploiement de lecteurs réseau, vous utilisez un dépôt partagé pour partager des fichiers entre des ordinateurs de développement, de transfert et de production

Lors du développement d’un nouveau code de test, il est important de s’assurer que le code en développement n’est jamais utilisé sur les systèmes déployés tant qu’il n’a pas été testé et validé. En règle générale, un ordinateur de production avec accès au matériel de test est désigné comme testeur intermédiaire et est utilisé pour valider et tester les systèmes de test de prélancement. Une fois le système de test validé sur le testeur de test, il peut être déployé sur les machines de production.

L’approche idéale pour s’assurer que le code déployé est validé varie en fonction de la fréquence à laquelle les mises à jour doivent être appliquées aux stations de test.

Dans les cas où des mises à jour fréquentes sont nécessaires, une approche d’intégration et de distribution continues (CI/CD) peut aider à garantir que le dernier code est disponible sur les ordinateurs de test, tout en garantissant que le code a été correctement testé et validé. Avec une approche CI/CD, vous automatisez une grande partie de la procédure de création, de test et de déploiement des mises à jour pour tester le code afin de réduire autant que possible la surcharge. Vous pouvez utiliser des outils tiers, tels que Jenkins, pour implémenter ce type d’automatisation. 

Pour les environnements contrôlés plus étroitement, les exigences de validation sont généralement très strictes et les mises à jour du système de test ne peuvent donc pas se produire fréquemment. Pour ces systèmes de test, définissez un dépôt ou tronc distinct dans lequel les développeurs apportent des modifications et ajoutent de nouvelles fonctionnalités au test. Une fois que la dernière version du système de test a été finalisée et validée, les développeurs créent une branche versionnée du tronc à utiliser sur les machines de production. Cette branche doit être verrouillée dans le contrôle du code source pour empêcher toute modification du code validé. Une fois la nouvelle branche terminée et validée, créez une nouvelle branche versionnée contenant le code.

Pour déployer le code de test, les machines de production obtiennent une copie du code versionné, qui doit rester en lecture seule pour s’assurer qu’il est inchangé. Pour vous assurer qu’aucune modification n’est apportée aux fichiers validés, vous pouvez ajouter du code à la séquence de test pour valider les checksums de contrôle de tous les fichiers. Pour plus d’informations sur cette approche, reportez-vous au document Pratiques exemplaires de vérification et de validation des systèmes TestStand.

Déploiement de drivers et de moteurs d’exécution avec des déploiements de lecteurs réseau

Lorsque vous utilisez une approche basée sur un lecteur réseau, vous devrez utiliser un mécanisme distinct pour installer les drivers et les moteurs d’exécution nécessaires sur les ordinateurs de test. Les moteurs d’exécution et les drivers peuvent être déployés via les mécanismes suivants :

• Construction d’un installateur contenant le logiciel requis. L’utilitaire de déploiement TestStand peut générer un installateur qui comprend des moteurs d’exécution et des drivers.
• Création d’une image système basée sur un système avec tous les drivers et moteurs d’exécution requis installés.

L’approche idéale dépend principalement de la fréquence des mises à jour du système. Dans de nombreux cas, vous pouvez utiliser une combinaison de plusieurs approches. Les scénarios fréquents suivants illustrent le choix d’une stratégie de déploiement de drivers et de moteurs d’exécution :

• Pour les systèmes avec des mises à jour peu fréquentes, la création d’une image aura généralement un retour sur investissement positif. De petites mises à jour du système de test peuvent toujours être implémentées sans qu’il soit nécessaire de mettre à jour l’image.
• Pour les systèmes qui sont mis à jour plus fréquemment, créez un installateur pour votre système de test avec les drivers et les environnements d’exécution requis.

Stratégies d’accès aux fichiers du système de test

Grâce au déploiement de lecteurs réseau, vous pouvez utiliser l’une des approches générales suivantes pour gérer le stockage de fichiers :

• Accédez aux fichiers directement à partir du lecteur réseau.
• Copiez les fichiers localement à partir du lecteur réseau, à l’aide d’outils tiers pour vous assurer que les fichiers locaux sont synchronisés avec le lecteur.
  
  

Accès aux fichiers directement à partir d’un lecteur réseau

L’avantage d’accéder aux fichiers directement à partir d’un lecteur réseau est que lorsque les fichiers sont mis à jour sur le lecteur réseau, vous vous assurez que la mise à jour est appliquée à tous les ordinateurs de test. Cependant, accéder aux fichiers directement à partir d’un lecteur réseau signifie que le fonctionnement des stations de test dépendra de la disponibilité du lecteur partagé et de la connexion réseau. Si l’un ou l’autre n’est pas disponible, les opérateurs de fabrication ne peuvent pas exécuter les fichiers de test à partir de la station de test, ce qui peut provoquer des arrêts de la ligne de production. Il est donc essentiel que vous travailliez avec votre service informatique pour vous assurer qu’il peut répondre aux exigences de disponibilité du disque partagé et du réseau. Par exemple, utiliser la redondance des serveurs pour répondre aux exigences de disponibilité du lecteur partagé. 

Pour utiliser un lecteur partagé pour stocker les fichiers de configuration et les composants TestStand, vous devez utiliser la fonction d’environnements TestStand, qui vous permet de spécifier l’emplacement des répertoires TestStand. Pour ce faire, vous créez un fichier d’environnement (tsenv) qui contient l’emplacement du lecteur réseau pour ces répertoires. Pour plus d’informations sur la création et l’utilisation de ce fichier, reportez-vous à la rubrique d’aide Environnements TestStand.

Copie de fichiers localement sur chaque station de test

Vous pouvez également choisir de créer des copies locales de tous les fichiers de déploiement. Cette approche présente les avantages suivants :

• Elle permet aux stations de test d’exécuter des tests sans connexion réseau permanente.
• Elle peut réduire le temps de chargement des fichiers système de test.

Cependant, cette approche ajoute un effort supplémentaire pour copier les fichiers sur toutes les stations de test. Vous devez également vous assurer que tous les systèmes de test disposent des fichiers les plus récents avant d’exécuter des tests.

Vous pouvez créer des outils supplémentaires pour comparer automatiquement la version du fichier sur la station de test correspond au lecteur partagé chaque fois que la station de test est démarrée et télécharger les fichiers qui ne sont pas à jour.

Cliquez ici pour accéder à d’autres ressources de la série d’architecture avancée TestStand, qui traite de sujets d’intérêt pour les développeurs avancés en NI TestStand.