Vérifier tôt, préparer la livraison progressivement

L’intégration continue automatise les vérifications après une modification du code. La livraison continue prolonge ce travail jusqu’à la préparation et la distribution d’une version. L’équipe définit les étapes automatiques et les décisions qui restent humaines.

Dans l’un de nos workflows GitHub, une branche de fonctionnalité lance les tests. La branche de développement ajoute la construction des exécutables et des packages, sans les publier. Les branches de release ou de correctif préparent ensuite leur distribution. Cela permet de détecter un problème de build avant le jour de la livraison.

Exemple de progression dans nos workflows GitHub
  1. Fonctionnalité

    Vérifier le code
    Tests et retours pour le développeur

  2. Développement

    Vérifier et construire
    Exécutables et packages sans publication

  3. Release / correctif

    Préparer la distribution
    Livrables publiés selon les règles du projet

L’équipe prépare la version et ses notes ; le serveur exécute les étapes configurées. La validation avant diffusion reste définie par le projet.

Des étapes qui connaissent LabVIEW

Le fichier de pipeline organise le travail ; des Custom Steps exécutent les opérations propres au projet LabVIEW. Nous avons développé des commandes pour appliquer une configuration VIPM, compiler les VI, lancer les tests, contrôler le code et produire les livrables.

Selon le projet, ces opérations sont appelées depuis des workflows GitHub réutilisables ou des jobs GitLab avec g-cli. Les paramètres précisent notamment la version de LabVIEW, le projet, la configuration des dépendances et les spécifications de build.

  • Préparer les dépendances avec une configuration VIPC.
  • Exécuter les tests unitaires et conserver leurs résultats.
  • Effectuer les contrôles adaptés au projet : compilation, documentation des VI, validation DQMH ou analyse avec VI Analyzer.
  • Construire un exécutable ou un package VIP et organiser sa publication.

Intégrer la CI/CD au quotidien avec Fork

L’automatisation côté serveur ne suffit pas si préparer une release reste une procédure difficile à suivre. Dans certaines réalisations, des Custom Commands du client Git Fork donnent accès à des outils LabVIEW dédiés.

Une interface aide à configurer les variables du projet GitLab à partir des fichiers LabVIEW, VIPC, VIPB et VI Analyzer. Une autre présente la version actuelle, la version à livrer et le changelog à relire. Le développeur confirme la mise à jour des dépendances et peut différer le push pour terminer sa préparation.

Un moniteur affiche ensuite les étapes du pipeline, leur état et leur durée, avec un accès au détail dans GitLab. L’équipe peut suivre ce qui attend, ce qui tourne et ce qui a terminé sans perdre le contexte de son travail.

Rendre les résultats exploitables

Dans l’exemple GitLab, les résultats des tests unitaires sont conservés au format JUnit. Les étapes VI Analyzer produisent un rapport de qualité de code. Ces retours aident à identifier ce qui demande une correction avant de poursuivre.

Tous les contrôles n’ont pas forcément le même rôle : certains doivent bloquer la livraison, d’autres signalent des améliorations à traiter. Nous définissons ces règles avec votre équipe, ainsi que les déclenchements manuels, les versions autorisées et les conditions de publication.

Relier le build à la distribution

Les réalisations présentées couvrent la construction et la publication de packages dans un dépôt VIPM, ainsi que la livraison d’exécutables avec BLT for LabVIEW. Dans le workflow documenté, une version bêta est testée avant sa promotion manuelle en version publique.

La préparation des dépendances, le numéro de version, les notes de release et le commit d’origine font partie du parcours. Une étape encore manuelle, comme la création du premier installateur dans l’un des projets, peut rester explicite plutôt que disparaître derrière un pipeline affiché en vert.

Commencer par un parcours reproductible

Nous partons de votre procédure actuelle : ce qui est testé, ce qui est compilé, les outils installés sur le serveur et la manière dont les utilisateurs reçoivent une version. Nous choisissons un premier projet et automatisons un parcours que l’équipe peut comprendre et reprendre.

Les versions de LabVIEW, les dépendances, les licences, les accès et les contraintes du serveur de build font partie de la configuration. Nous vérifions aussi les chemins d’échec et le diagnostic, pour que l’équipe sache quoi faire lorsqu’une étape ne passe pas.

Poursuivre avec le déploiement par composants →