Intégration continue pour la vérification de modèles Simulink - MATLAB & Simulink

Articles techniques

Intégration continue pour la vérification de modèles Simulink

Par David Boissy, Paul Urban, Krishna Balasubramanian, Pablo Romero Cumbreras, Colin Branch et Jemima Pulipati, MathWorks


Si vous utilisez R2022a ou une version ultérieure et que vous disposez d'une licence Simulink Check™, vous pouvez rationaliser votre intégration CI en utilisant le support package CI/CD Automation for Simulink Check. Avec le support package, vous pouvez définir un modèle de processus pour votre équipe et configurer votre système de CI pour exécuter automatiquement les tâches de votre processus sous forme de pipeline dans le CI. Le support package inclut la prise en charge de plusieurs plates-formes de CI afin que vous puissiez générer automatiquement des pipelines spécifiques à votre projet et à votre processus, supprimant ainsi le besoin de mises à jour manuelles. 

Caractéristiques principales :

  • Tâches intégrées : Automatisez les tâches courantes de votre workflow de développement et de vérification basés sur des modèles en utilisant des tâches intégrées pour des activités telles que la vérification des normes de modélisation avec Model Advisor, l'exécution de tests avec Simulink Test™ et la génération de code avec Embedded Coder®. Au lieu de gérer différents scripts pour vos activités de développement et de vérification, vous pouvez reconfigurer et utiliser ces tâches intégrées pour une exécution cohérente et des résultats de tâches organisés.
  • Compilations incrémentielles : Identifiez l’impact d’une modification sur votre projet et réexécutez automatiquement uniquement les tâches impactées pour aider à améliorer l’efficacité de la compilation. L'application Process Advisor et son système de création peuvent réexécuter les tâches avec des résultats obsolètes et ignorer automatiquement les tâches à jour.
  • Génération automatique de pipeline : Utilisez le fichier modèle du support package pour générer automatiquement des pipelines, afin de ne pas avoir à mettre à jour manuellement les fichiers de configuration CI/CD lorsque vous apportez des modifications à votre projet ou processus. Vous pouvez facilement personnaliser les paramètres du générateur de pipeline pour séparer vos tâches en différentes tâches, exécuter des tâches de modèle en parallèle et modifier d'autres comportements du pipeline.

Pour plus d'informations, voir Intégration continue et Intégration dans Jenkins.

Ceci est le premier article d’une série en deux parties. La première partie examine l'utilisation de GitLab® pour le contrôle de version et de Jenkins® pour l'intégration continue (CI). La deuxième partie, Intégration continue pour la vérification des modèles Simulink à l'aide de GitLab, envisage d'utiliser GitLab à la fois pour le contrôle de version et le CI. 

L’intégration continue (CI) gagne en popularité et devient partie intégrante de l’approche Model-Based Design. Mais qu'est-ce que le CI ? Quels sont ses avantages et quels problèmes tente-t-il de résoudre ? Comment Simulink® s’intègre-t-il dans l'écosystème de CI ? Et comment pouvez-vous tirer le meilleur parti du CI pour vos projets ? 

Si vous connaissez l’approche Model-Based Design, mais que vous êtes nouveau dans le CI, vous vous posez peut-être ces questions. Dans cet article technique, nous explorons un workflow de CI courant et l'appliquons à l’approche Model-Based Design. Ensuite, nous parcourrons un exemple de ce workflow à l’aide de Jenkins, GitLab et Simulink Test. 

Le projet utilisé dans cet exemple est disponible en téléchargement

Qu'est-ce que le CI ?

Le CI est une bonne pratique de méthodologie agile dans laquelle les développeurs soumettent et fusionnent régulièrement leurs modifications de code source dans un référentiel central. Ces « ensembles de modifications » sont ensuite automatiquement intégrés, qualifiés et publiés. La figure 1 illustre ce workflow de CI de base ainsi que le workflow de développement. 

Diagramme de workflow de CI. Les développeurs et les auteurs de tests développent, testent, fusionnent, révisent et soumettent des modifications au contrôle de version ; elles sont ensuite intégrées, testées, empaquetées et déployées via un pipeline CI. Une fois terminé, le résultat de la compilation, les artefacts et les rapports sont disponibles.

Figure 1. Workflow de CI.

Dans la partie développement du workflow, les modèles et les tests sont développés, vérifiés, fusionnés, révisés et soumis à un système de contrôle de version sur le desktop du développeur. Le système de contrôle de version déclenche ensuite la partie CI automatisée du workflow. Les éléments clés du workflow de CI sont : 

Compiler : Le code source et les modèles deviennent des fichiers objets et des exécutables. 

Tester : Les tests sont effectués comme un contrôle de qualité. 

Packager : Les exécutables, la documentation, les artefacts et autres livrables sont regroupés pour être livrés aux utilisateurs finaux. 

Déployer : Les packages sont déployés dans l’environnement de production. 

Ensemble, ces quatre étapes sont connues sous le nom de « pipeline » CI. Le pipeline est généralement automatisé et son exécution peut prendre de quelques minutes à quelques jours, selon le système. Il convient de noter qu’au cours de ces étapes, de nombreux artefacts sont créés, tels que des nomenclatures, des résultats de tests et des rapports. 

Les workflows de CI sont souvent associés aux workflows des développeurs liés aux systèmes de contrôle de version. Dans ces workflows, les développeurs conservent souvent leurs modifications dans des référentiels locaux et utilisent un pipeline CI local pour qualifier leurs modifications avant le déploiement. 

Quels sont les avantages du CI ?

Les équipes qui ont mis en œuvre l’intégration continue signalent généralement les avantages suivants : 

  • Répétabilité. Le pipeline CI fournit un processus automatisé cohérent et reproductible pour la compilation, les tests, le packaging et le déploiement. L'automatisation répétable permet aux développeurs de se concentrer sur le travail nécessaire et de gagner du temps sur un projet. Il s’agit également d’un aspect important de la réduction des risques et constitue souvent une exigence de certification.
  • Assurance qualité. Les tests manuels sont efficaces, mais ils reposent souvent sur des instantanés datant de plusieurs jours et manquent de répétabilité. Avec le CI, les modifications sont toujours testées par rapport à la base de code la plus récente.
  • Temps de développement réduit. Des processus répétables avec une assurance qualité intégrée conduisent à une livraison plus rapide de produits de haute qualité. Le déploiement automatisé signifie que votre code est toujours prêt pour la production.
  • Collaboration améliorée. Avec le CI, les développeurs disposent d'un processus défini pour gérer les ensembles de modifications et fusionner leur code dans la ligne de production. Des processus cohérents permettent de gérer de grandes équipes et de réduire le coût de recrutement de nouveaux développeurs.
  • Code prêt pour l'audit. Le processus de CI fournit une piste d’audit complète. Pour chaque changement effectué dans le pipeline CI, il est possible d'identifier qui a effectué le changement, qui l'a examiné et la nature du changement, ainsi que les dépendances, les tests et leurs résultats, ainsi que tout nombre de rapports et d'artefacts associés générés en cours de route.

Comment l’approche Model-Based Design s’intègre-t-elle dans le CI ? 

Par design, le workflow et les outils de CI sont neutres en termes de langage et de domaine. Cela signifie que le défi consiste à enseigner aux outils, systèmes et processus de CI à s’intégrer avec l’approche Model-Based Design, en d'autres termes, faire de Simulink et des outils associés les lingua franca du workflow de CI. 

Cela peut être réalisé en intégrant trois composants clés de l’approche Model-Based Design dans le workflow CI : la vérification, la génération de code et les tests (Figure 2). L’approche Model-Based Design met l'accent sur la vérification précoce, qui correspond au pipeline CI avec une phase de vérification avant la phase de compilation. La génération de code a lieu dans la phase de compilation. Des tests dynamiques via la simulation et l'analyse statique du code généré peuvent être effectués dans la phase de test. 

Illustration d'un workflow de CI de l’approche Model-Based Design dans lequel une modification du modèle déclenche le pipeline de CI pour vérifier la modification, compiler, tester, packager et déployer les artefacts.

Figure 2. Approche Model-Based Design mappée sur le pipeline CI.

Voici un aperçu de la façon dont nous enseignons au processus de CI à s’intégrer à l’approche Model-Based Design : 

Développer. MATLAB® Simulink, les codeurs et les toolboxes sont utilisés pour les activités de développement. Les projets MATLAB sont utilisés pour organiser le travail, collaborer et interagir avec les systèmes de contrôle de version. 

Tester. Simulink Check est utilisé pour effectuer des contrôles qualité du modèle avant la simulation et la génération de code. Simulink Test est utilisé pour développer, gérer et exécuter des tests basés sur la simulation. Simulink Coverage™ est utilisé pour mesurer la couverture et évaluer l'efficacité des tests. Les contrôles de qualité, les résultats des tests et les mesures de couverture peuvent ensuite être utilisés comme des outils de contrôle qualité finaux pour permettre aux développeurs de qualifier leur travail. 

Fusionner. La fonction MATLAB « Compare Files and Folders » est utilisée pour comparer et fusionner des fichiers MATLAB. L'outil de comparaison de modèles est utilisé pour comparer et fusionner les modèles Simulink. 

Revoir. La révision est l’étape finale du processus de qualité avant que les modifications ne soient soumises au système de contrôle de version. Les modifications apportées aux scripts MATLAB et aux modèles Simulink sont examinées ici. Les résultats des tests de préqualification sont également examinés comme contrôle qualité final avant la soumission. 

Envoyer. Les projets MATLAB fournissent une interface aux systèmes de contrôle de version. 

Vérifier. Simulink Check, le même outil utilisé pour la vérification locale, est utilisé pour la vérification automatisée au sein du système CI. 

Compiler. MATLAB Coder™, Simulink Coder™ et Embedder Coder sont utilisés pour générer du code pour les tests SIL (Software-In-the-Loop). 

Tester. Simulink Test, le même outil utilisé pour les tests locaux, est utilisé pour les tests automatisés au sein du système CI. 

Packager et déployer. Le packaging est l’étape au cours de laquelle les exécutables, la documentation, les artefacts et autres livrables sont regroupés pour être livrés aux utilisateurs finaux. Le déploiement est la publication du logiciel packagé. Dans les workflows de l’approche Model-Based Design, ces phases varient considérablement selon les organisations et les groupes, et impliquent souvent le regroupement de différentes versions et artefacts de certification dans un produit prêt à être livré à d'autres équipes. 

Les outils et pratiques de développement modernes permettent aux développeurs de créer des systèmes plus robustes et de tester les fonctionnalités tôt et souvent. Lorsqu'un système CI est intégré au workflow, les tests au niveau de l'unité et au niveau du système sont automatisés. Cela signifie que le développeur peut se concentrer sur le développement de nouvelles fonctionnalités, et non sur la vérification des fonctionnalités pour savoir si elles ont été correctement intégrées. 

L’étude de cas suivante décrit un workflow qui intègre le CI et l’approche Model-Based Design. 

Étude de cas : un modèle Simulink vérifié, construit et testé dans un système CI 

Dans cet exemple, nous utilisons l’approche Model-Based Design avec CI pour effectuer des tests basés sur les exigences sur un système de suivi de voie automobile (Figure 3).

À gauche, une capture d'écran montrant un exemple de modèle de suivi de voie dans Simulink. À droite, une capture d'écran montrant la vue à vol d'oiseau d'un exemple de modèle de suivi de voie dans Simulink.

Figure 3. Modèle de système de suivi de voie.

Le pipeline que nous utiliserons (Figure 4) est exécuté à chaque compilation Jenkins.

Diagramme montrant les actions effectuées dans un exemple de pipeline de suivi de voie, y compris la vérification de la conformité aux normes, la création du modèle et l'exécution des cas de test, dans l'ordre, et les trois menant à une étape de package des artefacts.

Figure 4. Pipeline pour un exemple de suivi de voie.

Les phases du pipeline sont les suivantes : 

  1. Vérification de la conformité aux normes : un script d'unité MATLAB exécute une vérification simple de Model Advisor. Les critères d’évaluation garantissent que le modèle ne comporte pas de lignes non connectées.
  2. Modèle de compilation : un fichier de test unitaire MATLAB génère du code SIL de production pour notre modèle. Les critères d’évaluation sont validés si la compilation réussit sans avertissement.
  3. Exécution des cas de test : une suite de tests dans Simulink Test utilise plusieurs scénarios de conduite pour tester le contrôleur de suivi de voie. Trois critères d’évaluation sont utilisés pour vérifier le bon fonctionnement du contrôleur :
    • Évitement des collisions : l’ego-véhicule n'entre en collision avec le véhicule de tête à aucun moment du scénario de conduite.
    • Maintien des distances de sécurité : L'écart de temps entre l’ego-véhicule et le véhicule de tête est supérieur à 1,5 seconde. L'écart de temps entre les deux véhicules est défini comme le rapport entre l'intervalle calculé et la vitesse du véhicule individuel.
    • Suivi de voie : L’écart latéral par rapport à la ligne médiane de la voie est de 0,2 mètre.
  4. Artefacts du package : Chacune des étapes précédentes produit des artefacts, notamment un rapport Model Advisor, un exécutable généré et un ensemble de résultats de test qui peuvent être archivés pour une utilisation ou une référence ultérieure.

Étapes du workflow

Le processus comprend les étapes suivantes (Figure 5) : 

  1. Déclencher une compilation dans Jenkins et observer que les étapes de vérification et de compilation réussissent.
  2. Détecter un échec de cas de test dans Jenkins.
  3. Reproduire le problème sur notre desktop MATLAB.
  4. Résoudre le problème dans le modèle en assouplissant les critères d’évaluation.
  5. Tester localement pour garantir que le cas de test réussisse.
  6. Fusionner et réviser les changements sur la branche de test.
  7. Valider le changement dans Git™ et déclencher une compilation dans Jenkins.
  8. Vérifier, construire et tester dans Jenkins.
Diagramme montrant comment les utilisateurs peuvent soumettre une modification au contrôle de version, déclenchant ainsi le pipeline CI. Le changement est vérifié, compilé, testé, packagé et déployé. Si une étape échoue, les utilisateurs peuvent la soumettre à nouveau au contrôle de version en suivant les étapes précédentes.

Figure 5. Exemple de workflow.

Notre premier passage raté dans la boucle CI est illustré en haut à gauche. Il montre l'échec du test de CI, la reproduction locale, l'assouplissement des critères et la réussite du processus de CI.

Détails du workflow

  1. Nous commençons par déclencher une compilation dans Jenkins en sélectionnant Build Now. Le Simulink Check vérifie et génère du code.
Une capture d'écran du menu déroulant du tableau de bord Jenkins. « Build Now » est sélectionné.
  1. Ensuite, nous détectons un échec de cas de test dans la deuxième phase de vérification. Le cas de test LFACC_Curve_CutInOut_TooClose dans la suite de tests LaneFollowingTestScenarios échoue aux critères d’évaluation.
Une capture d'écran d'un résumé d'échec.
  1. Pour mieux comprendre l’échec, nous reproduisons l'échec localement en utilisant Simulink Test. Nous ouvrons le fichier de test LaneFollowingTestScenarios.mldatx et exécutons le cas de test LFACC_Curve_CutInOut_TooClose. Notez qu’il ne répond pas aux critères d’évaluation de la distance de sécurité. Une plus grande flexibilité est nécessaire dans l'établissement de l'écart de temps entre le véhicule de tête et l’ego-véhicule.
Une capture d'écran d'une fenêtre de Simulink Test avec les critères d'évaluation réussis.
  1. Avec une compréhension du problème, nous pouvons maintenant résoudre le problème. Nous ouvrons le modèle LaneFollowingTestBenchExample.slx et accédons au bloc Collision Detection/Test Assessments Test Sequence. La première évaluation affirme que l'écart de temps entre l’ego-véhicule et le véhicule de tête ne devrait pas descendre en dessous de 1,5 seconde pendant plus de 2 secondes consécutives.
GlobalAssessments 

% Ensure that the time gap between the ego vehicle and lead vehicle does not dip below 
% 1.5s for more than 2s at a time. 
verify(duration(time_gap < 1.5, sec) < 2); 

% Verify that no collision was detected 
verify(~collision); 

% Verify that the absolute value of lateral deviation from the lane centerline does not exceed 0.2m 
% for more than 5s at a time. 
verify(duration(abs(lateral_deviation) > 0.2, sec) < 5);

Cette évaluation est trop restrictive pour la manœuvre de conduite agressive testée. Pour les besoins de cet exemple, nous assouplissons les critères d’évaluation pour garantir que l’écart de temps ne descende pas en dessous de 0,8 seconde pendant plus de 5 secondes consécutives.

GlobalAssessments 

% Ensure that the time gap between the ego vehicle and lead vehicle does not dip below 
% 0.8s for more than 5s at a time. 
verify(duration(time_gap < 0.8, sec) < 5); 

% Verify that no collision was detected  
verify(~collision); 

% Verify that the absolute value of lateral deviation from the lane centerline does not exceed 0.2m 
% for more than 5s at a time.  
verify(duration(abs(lateral_deviation) > 0.2, sec) < 5); 
  1. Le problème semble résolu dans notre simulation. Pour confirmer, nous testons localement, en sauvegardant le modèle et en réexécutant le test dans le gestionnaire de tests. Notez qu'il est conforme aux nouveaux critères d'évaluation.
Une capture d'écran d'une fenêtre de Simulink Test avec les critères d'évaluation réussis.
  1. Nous avons résolu le problème et vérifié localement. Nous utilisons maintenant l’outil de comparaison de modèles pour revoir les modifications avant de les valider dans le contrôle de version.
Une capture d'écran montrant la comparaison des modifications anciennes et nouvelles dans l'outil de comparaison de modèles.

Nous pourrions également utiliser la fonction Publish de l’outil de comparaison de modèles pour examiner le code.

Une capture d'écran montrant la comparaison des modifications anciennes et nouvelles lorsque la fonction Publish de l'outil de comparaison de modèles est utilisée.
  1. Une fois le bug corrigé, nous transmettons ces modifications à GitLab avec les projets MATLAB, en ajoutant un message de validation pour noter le changement apporté aux critères d'évaluation.

Nous notons ensuite la dernière validation dans GitLab.

GitLab déclenche automatiquement une compilation dans Jenkins. Le tableau de bord du projet Jenkins affiche l'état et la progression de la compilation.

Une capture d'écran du tableau de bord du projet Jenkins montrant l'état de la compilation et la progression via une barre de chargement.
  1. La compilation Jenkins s'exécute. Nous voyons que les phases Verify, Build, and Test du pipeline sont désormais terminées.

Nous pouvons maintenant lancer une demande de fusion pour fusionner les modifications de la branche Test dans la branche principale. Dans GitLab, sous Repository, nous sélectionnons Branches, puis nous cliquons sur Merge request à côté de la dernière validation sur la branche Test.

Nous complétons le formulaire et soumettons la demande de fusion.

En tant que propriétaires de la branche, nous pouvons accepter la demande de fusion en cliquant sur le bouton Merge. Toutes les modifications sont désormais capturées sur la branche principale.

Une capture d’écran montrant le message qui s’affiche lorsqu’une demande de fusion réussit.

En utilisant l'exemple : outils, ressources et exigences 

Les sections suivantes décrivent les ressources pour vous aider à démarrer, les outils dont vous aurez besoin et la manière dont ils doivent être configurés. 

Configuration des systèmes

Jenkins est utilisé comme système CI et GitLab comme système de contrôle de version. MATLAB, Jenkins et GitLab doivent être configurés pour fonctionner ensemble. Les tutoriels suivants vous aideront à effectuer la configuration. 

Les tutoriels sont spécifiques à GitLab et Jenkins, mais les concepts peuvent s'appliquer à d'autres systèmes de contrôle de version et de CI. 

Outils requis

Les outils suivants sont nécessaires pour cet exemple : 

  • Jenkins version d'installation 2.7.3 ou ultérieure. Jenkins est utilisé pour l'intégration continue.
  • Plugin MATLAB pour Jenkins version 1.0.3 ou ultérieure. MATLAB, Simulink et Simulink Test utilisent tous ce plugin pour communiquer avec Jenkins. En savoir plus sur GitHub.
  • Plugins supplémentaires requis :
  • Compte GitLab. GitLab est utilisé pour le contrôle des sources et est disponible en tant que service cloud. Les projets MATLAB incluent une interface Git pour la communication avec GitLab.

Considérations relatives aux licences pour CI

Si vous prévoyez d'effectuer une CI sur de nombreux hôtes ou sur le cloud, contactez continuous-integration@mathworks.com pour obtenir de l'aide. Remarque : Les produits de transformation tels que les produits de codage et de compilation MATLAB et Simulink peuvent nécessiter des licences d'accès client (CAL).

Appendice : Configuration de MATLAB, GitLab et Jenkins

Étape 1. Configurer le projet MATLAB pour utiliser le contrôle de source

La première étape de notre exemple consiste à configurer notre projet pour utiliser le contrôle de source avec GitLab. 

  1. Créez un nouveau répertoire nommé MBDExampleWithGitAndJenkins, chargez l'exemple et ouvrez MATLAB Project MBDExampleWithGitAndJenkins.prj.
  2. Dans GitLab, créez un nouveau projet qui sera le référentiel distant. Nommez-le MBDExampleWithGitAndJenkins et enregistrez l'URL où il est hébergé.
  3. Dans MATLAB, convertissez le projet pour utiliser le contrôle de source. Dans l'onglet Projet, cliquez sur Use Source Control.
Une capture d’écran montrant l’onglet Project dans MATLAB, avec le bouton Use Source Control sélectionné.

Cliquez sur Add Project to Source Control.

Une capture d'écran de la fenêtre contextuelle Source Control Information. L'intégration est définie sur None et l'emplacement du référentiel n'est pas applicable. Il indique qu'aucun système de contrôle de source n'est détecté pour la racine du projet et dispose d'un bouton indiquant Add project to source control.
  1. Cliquez Convert.
Une fenêtre contextuelle pour Add to source control. L'outil de contrôle de source est sélectionné comme Git et la racine du projet est indiquée. Il y a un bouton de conversion.
  1. Cliquez sur Open Project une fois terminé.
Une capture d'écran montrant les fichiers ajoutés à Source Control. Les fichiers ont passé tous les contrôles et un bouton Open Project est présent. Un menu Git avec plusieurs boutons et des propositions logistiques apparaît.

Le projet est désormais sous contrôle de version local avec Git.

Étape 2. Valider les modifications et transférer le référentiel local vers GitLab

  1. Sur l’onglet Project , cliquez sur Remote.
Une capture d’écran de l’onglet MATLAB Project avec « Remote » en surbrillance.
  1. Spécifiez l'URL de l'origine distante dans GitLab.
Une capture d'écran de la fenêtre contextuelle Set Remote. Il dispose d'un formulaire permettant de spécifier une URL pour le dépôt distant d'origine. L'URL donnée est floue et il y a un bouton Validate ainsi qu'un bouton OK en bas.

Cliquez Validate pour vous assurer que la connexion au référentiel distant est réussie et cliquez sur OK. Le projet est maintenant configuré pour envoyer et extraire les modifications avec GitLab.

  1. Cliquez Commit pour effectuer une validation initiale.
Une capture d’écran de l’onglet MATLAB Project avec le bouton Commit en surbrillance.
Une capture d'écran de la fenêtre de commentaire avec le message de validation « Initial Commit ».
  1. Cliquez Push pour pousser toutes les modifications du référentiel local vers le référentiel GitLab distant.
Une capture d’écran de l’onglet MATLAB Projects avec le bouton Push sélectionné.
  1. Actualisez le tableau de bord GitLab et observez le contenu du projet MATLAB.

Étape 3 : Créer une branche de test

Dans cette étape, nous créons une branche de test pour tester et vérifier les modifications avant de fusionner avec la branche principale.

  1. Cliquez sur Branches.
Une capture d’écran de l’onglet MATLAB Project avec le bouton Branches sélectionné.
  1. Ouvrez la section Branch and Tag Creation , nommez la branche « Test » et cliquez sur Create.
  1. Observez Test dans le navigateur de branches. Depuis la branche Test, cliquez sur Switch puis sur Close.
  1. Dans MATLAB, sélectionnez Push pour pousser ces modifications vers GitLab et observer la branche Test dans GitLab.

Étape 4. Configurer Jenkins pour appeler MATLAB

  1. Installez les deux plugins requis :
    • Plugin GitLab — Ce plugin permet à GitLab de déclencher des compilations Jenkins et d'afficher leurs résultats dans l'interface utilisateur de GitLab.
    • Plugin MATLAB — Ce plugin intègre MATLAB avec Jenkins et fournit l'interface Jenkins pour appeler MATLAB et Simulink.
  2. Sélectionnez New Item et créez un nouveau projet FreeStyle nommé MBDExampleUsingGitAndJenkins.
  3. Sous Source Code Management, activez Git, pointez Jenkins vers notre référentiel GitLab et entrez dans la branche Test pour générer. Remarque : Un identifiant ou un mot de passe et un jeton API GitLab sont requis.
  1. Configurez le déclencheur de compilation pour exécuter une compilation lorsqu'une demande push est envoyée à la branche Test dans GitLab. Dans la section Build Triggers, sélectionnez Advanced > secret token. Ce jeton est utilisé par GitLab pour demander une compilation et s'authentifier auprès de Jenkins. Notez le jeton secret et le webhook GitLab.
  1. Configurez l'environnement de compilation. Sélectionnez Use MATLAB version et entrez la racine MATLAB.
  1. Configurez l’étape de compilation.

Cliquez sur Add build step et choisir Run MATLAB Command. Entrez la commande openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecModelAdvisor

pour ouvrir le projet et exécuter les vérifications du conseiller modèle.

Cliquez sur Add build step et choisir Run MATLAB Command encore. Entrez la commande : openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecControllerBuild.

Cliquez sur Add build step et choisir Run MATLAB Tests. Sélectionnez TAP test results et Cobertura code coverage pour terminer la configuration de la compilation.

Étape 5. Publication des résultats du TAP

Cliquez AAdd post-build action > Publish TAP Results. Saisissez le chemin relatif où les résultats du test TAP seront publiés.

Cette action analyse les résultats du test TAP et les rend visibles lorsque TAP Extended Test Results est sélectionné. La sortie contient un aperçu des cas de test exécutés, le résumé des résultats et les logs de la console MATLAB.

Capture d'écran d'un menu déroulant sur le tableau de bord avec « TAP Extended Test Results » en surbrillance.

Le plugin TAP collecte également les résultats des dernières exécutions de tests et affiche un diagramme de santé comme indiqué ci-dessous. Vous pouvez accéder à n'importe quelle version précédente en cliquant sur le diagramme.

Un graphique des résultats des tests TAP montrant le numéro de compilation Jenkins sur l'axe des x et le nombre de tests TAP sur l'axe des y. Les tests sont codés par couleur : échoués, réussis, ignorés ou à faire. À mesure que le nombre de compilations augmente, le nombre de tests réussis augmente également.

Étape 6. Publication de rapports HTML

Cliquez sur Add post-build action > Publish HTML reports. Saisissez le chemin racine relatif où le rapport HTML sera publié et le nom de fichier de la page d'index qui se trouve dans le chemin.

Ajoutez autant d’entrées qu’il y a de rapports HTML à publier. Dans ce scénario, il y a deux rapports Web : Le Model Advisor Summary et le Code Generation Report. Il s'agit de rapports standards créés avec les fonctions intégrées de MATLAB. Vous pouvez ajouter des rapports HTML personnalisés. 

Vous trouverez un lien de rapport correspondant à la dernière compilation pour chaque rapport HTML sur la page principale des tâches Jenkins. Si vous activez la case à cocher « Always link to last build » sous Publishing options, le plugin publiera des rapports pour la dernière compilation quel que soit l'état de la compilation. Si cette case à cocher n'est pas activée, le plugin créera uniquement un lien vers la dernière version « réussie ». 

Étape 7. Configuration de GitLab pour déclencher une compilation dans Jenkins

Configurez GitLab pour déclencher une compilation automatique dans Jenkins lorsqu'un nouveau push se produit sur la branche principale. Pour ce faire, accédez à Settings > Webhooks. Utilisez l'URL du webhook et le jeton secret fourni par Jenkins dans la configuration du déclencheur de compilation et sélectionnez Push events.

Remarque : Utilisez un nom de domaine complet dans la section URL à la place de localhost afin que GitLab puisse trouver l'installation de Jenkins.

Une capture d'écran de la fenêtre contextuelle Webhooks avec le formulaire URL rempli, le champ Jeton secret vide et « Push Events » coché sous « Trigger » avec un formulaire pour remplir le déclencheur.

Dans le Test déroulant, sélectionnez Push Events pour tester l'intégration. GitLab affichera le message « Hook executed successfully : HTTP 200 » et Jenkins lancera une compilation.

Une capture d'écran de la fenêtre contextuelle Project Hooks avec les détails du webhook activés.

Étape 8. Configuration de l'authentification Jenkins-to-GitLab

Pour publier automatiquement un statut de compilation Jenkins sur GitLab, vous devez configurer l'authentification Jenkins vers GitLab.

  1. Créez un jeton d’accès personnel sur GitLab avec la portée de l’API sélectionnée.
Une capture d'écran de la fenêtre contextuelle pour les jetons d'accès personnels avec des formulaires permettant d'ajouter le nom, la date d'expiration et la portée du jeton nommé GitLabToJenkins. Sous « Scopes », « api » est coché, ce qui offre un accès complet en lecture/écriture à l'API.
  1. Copiez le jeton et créez une connexion GitLab sous Jenkins Configure System. 
    Remarque : Les connexions peuvent être réutilisées sur plusieurs tâches Jenkins et peuvent être configurées globalement si l'utilisateur dispose au moins des droits de « mainteneur ».

Étape 9. Intégration de Jenkins dans le pipeline GitLab

Pour intégrer Jenkins dans le pipeline GitLab, vous devez configurer la connexion GitLab dans Jenkins et publier l'état du travail sur GitLab.

  1. Sélectionnez GitLab Connection dans la section General de votre travail Jenkins.
  1. Ajoutez une action post-build pour publier l’état de compilation sur GitLab. 
    Remarque : Cette action n'a aucun paramètre et utilisera la connexion GitLab existante pour publier l'état de la compilation sur GitLab et créer une traçabilité bidirectionnelle pour chaque demande de validation et de fusion.
Une capture d'écran de l'action post-build ajoutée, Publish build status to GitLab. Il y a un bouton pour les options avancées.

Étape 10. Visualisation des métriques de test basées sur les exigences (R2020b)

Les métriques de test basées sur les exigences vous permettent d'évaluer l'état et la qualité de vos activités de tests basés sur les exigences. Les résultats métriques peuvent être visualisés à l'aide du tableau de bord des tests de modèle.

  1. Créez un fichier appelé collectModelTestingResults.m basé sur la fonction indiquée ci-dessous. Cette fonction initialisera l'infrastructure du moteur de métriques et collectera toutes les métriques de modèle disponibles.
fonction collectModelTestingResults() 
    % capacité métrique ajoutée dans R2020a 
    if exist('metric') 

        metricIDs = [... 
        "ConditionCoverageBreakdown" "CoverageDataService"... 
        "DecisionCoverageBreakdown" "ExecutionCoverageBreakdown"... 
        "MCDCCoverageBreakdown" "OverallConditionCoverage"... 
        "OverallDecisionCoverage" "OverallExecutionCoverage"... 
        "OverallMCDCCoverage" "RequirementWithTestCase"... 
        "RequirementWithTestCaseDistribution" "RequirementWithTestCasePercentage"... 
        "RequirementsPerTestCase" "RequirementsPerTestCaseDistribution"... 
        "TestCaseStatus" "TestCaseStatusDistribution"... 
        "TestCaseStatusPercentage" "TestCaseTag"... 
        "TestCaseTagDistribution" "TestCaseType"... 
        "TestCaseTypeDistribution" "TestCaseWithRequirement"... 
        "TestCaseWithRequirementDistribution" "TestCaseWithRequirementPercentage"... 
        "TestCasesPerRequirement" "TestCasesPerRequirementDistribution"... 
        ]; 

        % collect all metrics for initial reconcile 
        E = metric.Engine(); 
        execute(E, metricIDs); 
    end 
end 
  1. Ajoutez ce fichier à votre projet et au chemin.
  2. Configurez Jenkins pour collecter les résultats des métriques en appelant deux fois la nouvelle fonction collectModelTestingResults. Le premier appel initialise l’intégration des métriques avec Simulink Test Manager. Le second collecte les résultats métriques à l’aide des résultats exportés de Simulink Test Manager.
    1. Cliquez sur Add build step et choisir encore Run MATLAB Command. Entrez la commande : openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
      Positionnez cette étape de compilation avant l’étape Run MATLAB Tests .
    2. Cliquez sur Add build step et choisir encore Run MATLAB Command. Entrez à nouveau la commande : openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
      Positionnez cette étape de compilation après l’étape Run MATLAB Tests.
  1. Vérifier les résultats de Simulink Test Manager dans l’étape Run MATLAB Tests.
Une capture d’écran de la fenêtre contextuelle de l’étape de compilation. Le formulaire pour les résultats de Simulink Test Manager est rempli avec le chemin du fichier.
  1. Archivez les résultats métriques dans le répertoire dérivé. Vous devez également archiver les résultats du gestionnaire de tests exportés, car ils permettront une navigation complète des résultats métriques lors de leur nouveau chargement dans MATLAB.

Cliquez sur Add post-build action et choisir Archive the artifacts. Entrer le chemin derived/**,matlabTestArtifacts/*.mldatx pour archiver tous les fichiers enregistrés dans ce répertoire.

Remarque : Pour afficher ces résultats dans MATLAB sur une machine autre que la machine de test, procédez comme suit :

  • Téléchargez les artefacts archivés (répertoire dérivé et fichiers de résultats de test MLDATX).
  • Procédez à l’extraction et à la copie locale de la même version du projet qui a été utilisée pour exécuter le travail CI.
  • Ouvrez le projet dans MATLAB et lancez le tableau de bord de test du modèle.

Les résultats générés par le CI seront affichés sur le tableau de bord.

Jenkins® est une marque déposée de LF Charities Inc.

Publié en 2024

Consulter des articles relatifs à des secteurs associés

Navigation dans l'interface

Lancez-vous dans l'intégration continue avec Simulink en utilisant le support package pour CI/CD Automation.