Lier une machine physique à l’outil CI

Lier une machine physique à l’outil CI

Choix de l’outil d’intégration continue

Plusieurs outils permettant de faire du CI existent. Certains d’entre eux sont plus répandus, et d’autres sont intégrés aux plateformes d’hébergement. Ainsi, un choix arbitraire est fait concernant les outils CI à tester. Voici-en la liste : • Gitlab-CI4 • Travis5 • Bitbucket-Pipeline6 • Jenkins7 Veuillez prendre en compte que les informations suivantes sont valables au mois de mai 2019, il est possible que des modifications des conditions d’utilisations aient changées d’ici là. 2.3.1 Compte-rendu L’analyse des différents outils amène au tableau ci-dessous, dans le cas d’une utilisation entièrement gratuite. Pour de plus amples informations concernant chacun des outils d’intégration continue, veuillez regarder les annexes 4 (Utilisation de Gitlab CI/CD), 5 (Utilisation de Bitbucket – pipelines) et 6 (Utilisation de Travis CI). Travis, l’outil CI typiquement utilisé avec github, possède le plus d’inconvénients. En effet, il ne permet pas de sauvegarder des fichiers entre les diverses étapes de l’intégration, ni de définir une machine physique comme exécuteur du CI. De plus, pour les mêmes étapes, plus de commandes doivent être entrées. Bitbucket-pipelines ne permet également pas de définir une machine physique en tant qu’exécuteur du CI. Concernant le reste des caractéristiques, toutes sont valides, avec quelques limitations pour certaines d’entre elles. En effet, il faudrait alors utiliser Bitbuket comme plateforme d’hébergement et le temps offert pour le CI est limité à 50 minutes par mois. De plus, une limite est imposée quant à la taille mémoire des fichiers enregistrés durant le CI. Le choix s’est alors porté sur Gitlab-CI et Jenkins. En effet, ces deux outils permettent de définir des machines physiques fixes(appelées « runners » pour gitlab) sur lesquelles il sera possible de connecter l’appareil à tester et le testeur. De plus, ils offrent tous les deux la possibilité de lier l’exécution de leur CI à des répertoires désignés sur Gitlab, qui est la plateforme d’hébergement choisie. Dans un premier temps, le déploiement du CI est réalisé par Gitlab CI, car cet outil nécessite bien moins de configurations que Jenkins et est plus intuitif.

Relier une machine physique à Gitlab CI

Pour réaliser la liaision, plusieurs méthodes sont proposées par Gitlab CI11 : – Se connecter via un protocole de contrôle de transmission (TCP) directement dans l’interface Shell de la machine hôte – Établir une connexion sécurisée (SSH) entre le CI et l’hôte – Lancer une machine virtuelle et utiliser celle-ci dans la machine principale – Utiliser des images docker Il est cependant important de mentionner que la connexion SSH est déconseillée par Gitlab, car elle est susceptible à des attaques12. La plateforme d’hébergement recommande également d’utiliser une image Docker au lieu d’une machine virtuelle, pour plus de découplage et moins d’espace mémoire utilisé sur la machine principale. Ayant essayé d’utiliser chacune de ces méthodes, les deux seules qui n’ont pas fonctionnées sont celles déconseillées par Gitlab. La cause du disfonctionnement du SSH est que la connexion n’est pas autorisée par Gitlab. Quant à la machine virtuelle, la machine hôte n’arrive pas à la lancer via la commande externe envoyée par la plateforme d’hébergement, qui utilise le SSH. Ce problème lié à l’utilisation d’une connexion SSH avec Giltab CI est connu mais n’est pas encore résolu, ce qui amène à la conclusion qu’actuellement il est préférable d’utiliser des images Docker ou l’interface Shell de la machine hôte.

Environnement de tests CI

Avec les deux options vues précédemment aux chapitres 3.1.2 et 3.1.3, la solution d’une image docker a été choisie. En effet, elle permet de sécuriser l’environnement de test et permet à toute autre personne souhaitant réaliser le même type de CI de le faire de manière très simple, en prenant les images qui seront configurées par la suite. Il est souhaitable d’utiliser un runner local qui est connecté à gitlab, afin de s’affranchir de la limite des 2000 minutes par mois offertes par Gitlab pour utiliser ses runners, mais également pour pouvoir disposer des outils qui seront définis par la suite, soit la cible à programmer et à tester, ainsi que l’appareil qui va émuler les signaux d’entrées/sorties de la cible. Le point fort de Gitlab CI est qu’il permet d’utiliser plusieurs images Docker en parallèle, tout en pouvant déterminer un nombre maximal de chaque « instance » d’image (voir annexe 4 chapitre 7). De plus, si de multiples tests veulent être effectués mais que tous les runners sont utilisés, ceux-ci sont automatiquement mis en attente et seront lancés une fois qu’un runner est utilisable. Pour lier une machine physique à Gitlab, veuillez-vous référer à l’annexe 4 chapitre 5.1.

Différentes possibilités des comptes utilisateurs

 Plus de 100’000 organisations dans le monde utilisent cette plateforme. Tout développeur peut y avoir un compte gratuit avec les possibilités suivante : • Nombre de répertoires publics illimités • Nombre de répertoires privés illimités • Nombre de collaborateurs pour les répertoires privés illimités • Support communautaire • Tableau de tâches intégré permettant de classer le type de travail et dans quel état il se trouve • Outil d’intégration continue et de déploiement continu intégré La principale limitation du compte gratuit est la suivante : • Utilisation des machines fournies par Gitlab pour l’intégration continue limitées à 2000 minutes par mois Il est cependant possible de définir sa propre machine qui effectuera l’intégration continue. Ainsi, cette limitation n’est plus valable. Autrement, un compte payant peur être fait, permettant d’acquérir plus d’outils et de support pour les utilisateurs, comme un vérificateur de qualité du code entre autres. Gitlab offre également la possibilité d’avoir sa propre plateforme. Ainsi, les répertoires ne se trouvent plus sur la plateforme gitlab.com mais sur gitlab.hevs.ch par exemple, ce qui offre plus de contrôle sur le flux de données et les autorisations d’accès aux répertoires. Cette plateforme auto-gérée est disponible gratuitement avec les mêmes conditions que le compte gratuit de gitlab.com, et il est également possible d’obtenir une version payante aux mêmes conditions que la plateforme de base.

 Caractéristique de Gitlab-CI/CD

Il fait directement partie de Gitlab, ce qui simplifie le déploiement de celui-ci. – Il est open core – Il y a un guide d’utilisation très complet, avec un support très compétent en la matière – Il est scalable : les tests peuvent être exécutés sur diverses machines, autant que l’on veut – Les tâches peuvent être exécutées en parallèle – Il est optimisé pour le déploiement Et d’autres informations concernant ses propriétés : – Multi-plateforme : Il est possible de lancer les tests sous n’importe quel environnement, tant qu’il supporte le Go – Multi-langage : Les commandes fonctionnent sous n’importe quel langage – Stable : Les étapes d’intégrations/déploiements tournent sur d’autres machines que la plateforme elle-même – Informations en temps réel : mise à jour dynamique des états des divers étapes d’intégration/déploiement – Pipeline configurable : Il est possible de définir les liens entre les diverses étapes et des conditions pour l’exécution de celles-ci – Sauvegarde des « artifacts » : enregistre les fichiers souhaités durant les diverses étapes (voir point 3.2 Utiliser des artifacts) – Tests locaux : Il y a la possibilité de reproduire les tests localement – Supporte Docker : L’utilisation d’images Docker est simple, également l’utilisation de Kubernetes – Choix des machines de CI/CD : les « Runners » (voir point 5 Utilisation de son propre « Runner »), peuvent provenir de Gitlab, tout comme d’une propre machine.

Table des matières

1 Introduction
1.1 Contraintes actuelles
1.2 Objectif
1.3 Étapes de la thèse
2 Analyses
2.1 Pipeline de tests
2.1.1 Qu’est-ce qu’un pipeline de tests
2.1.2 A quoi cela est utile ?
2.2 Choix de la plateforme d’hébergement
2.2.1 Compte-rendu
2.3 Choix de l’outil d’intégration continue
2.3.1 Compte-rendu
2.4 Choix d’une cible
2.5 Choix d’un appareil émulant l’environnement de la cible
2.5.1 Appareils existants
3 Méthodologie
3.1 Lier une machine physique à l’outil CI
3.1.1 Relier une machine physique à Gitlab CI
3.1.2 CI via l’interface shell
3.1.3 CI via une image docker
3.2 Environnement de tests CI
3.3 Utilisation de Docker
3.3.1 Image docker depuis un Dockerfile
3.3.2 Image docker depuis une image déjà existante
3.4 Utilisation du compilateur ARM
3.5 Installer gcc-arm-embedded
3.6 Make
3.7 Installer Make
3.8 Configurer un projet avec Make
3.9 Configurer une image docker pour ARM
3.9.1 Image docker pour la compilation
3.9.2 Image docker pour l’écriture du programme dans le uC
3.10 Programmer l’appareil simulant l’environnement externe
3.10.1 Charger la librairie Digilent Waveforms
3.10.2 Connexion à un Analog Discovery 2
3.10.3 Connexion au premier appareil disponible
3.10.4 Connexion à un appareil spécifique
3.11 Configurer une image docker pour Analog Discovery 2
3.12 Configuration des images docker finales pour ARM
3.13 Exemple d’un projet avec CI « On Target Testing »

Télécharger le rapport complet