Utilisation des processus CI/CD pour les systèmes embarqués
CI/CD apporte beaucoup de valeur aux équipes de logiciels embarqués. Une fois le processus mis en place, il peut aider à identifier rapidement les problèmes.
Dans plusieurs de mes articles précédents, nous avons examiné les tests de logiciels embarqués à l’aide de Cpputest et des environnements de construction à l’aide de Docker. Chaque sujet est un élément constitutif d’un processus logiciel moderne utilisant l’intégration continue/le déploiement continu (CI/CD). CI/CD est un processus d’automatisation de la création, du test, de l’analyse et du déploiement de logiciels pour les utilisateurs finaux. CI/CD peut fournir aux équipes de développement une variété de valeurs telles que :
- Améliorer la qualité des logiciels
- Diminution du temps passé à déboguer
- Diminution des coûts du projet
- Améliorer la capacité à respecter les délais
- Simplifier le processus de déploiement de logiciels
Dans cet article, nous explorerons CI/CD pour les systèmes embarqués.
Introduction à CI/CD
Il existe de nombreux outils et configurations différents qu’une équipe peut utiliser pour configurer un processus CI/CD à utiliser avec le développement de logiciels embarqués. Les pièces générales restent cependant relativement similaires.
Tout d’abord, l’équipe dispose d’un référentiel git qui contient le code source du produit. Les développeurs branchent le code source des référentiels pour développer une fonctionnalité ou corriger un bogue localement sur leur machine de développement. Dans l’environnement local, le développeur peut utiliser des outils comme Docker pour un environnement de construction conteneurisé ainsi que des outils de test et de débogage. Une fois la fonctionnalité prête, le développeur validera ses modifications dans sa branche dans le référentiel.
Ensuite, la validation du code lancera un processus prédéfini à l’aide des chaînes d’outils CI/CD sélectionnées par l’équipe de développement. Par exemple, les outils courants à utiliser dans les processus CI/CD incluent Jenkins et GitLab. Le processus CI/CD sera configuré pour exécuter une série d’étapes automatisées, appelées pipeline, afin de garantir que le logiciel respecte les paramètres préconfigurés.
À ce stade, la première étape d’un pipeline consiste généralement à créer l’image de l’application. Construire l’image de l’application nécessite de disposer de tous les outils nécessaires pour réussir la construction. C’est là qu’intervient Docker ! L’outil CI/CD peut utiliser une image Docker sur laquelle la chaîne d’outils de génération est déjà configurée pour vérifier que le code peut être généré avec succès. Pour ce faire, l’outil CI/CD a souvent besoin d’une configuration d’exécution qui peut envoyer des commandes pour créer et exécuter l’image Docker. Pour les petites équipes, l’exécuteur peut exister sur l’ordinateur portable d’un seul développeur, mais il est fortement recommandé que l’exécuteur soit installé sur un serveur sur site ou dans le cloud. Cela supprime la dépendance de l’ordinateur portable du développeur lorsque quelqu’un doit valider du code.
Voici un aperçu des composants nécessaires dans un processus CI/CD pour les systèmes embarqués.
Lorsque le coureur a terminé l’étape du pipeline, il rapportera les résultats à l’outil CI/CD. L’outil CI/CD peut envoyer d’autres commandes s’il y a plusieurs étapes dans les pipelines. Une fois terminé, l’outil CI/CD rapportera les résultats de l’exécution du pipeline. Si tout s’est bien passé, le statut sera défini sur réussi. Si quelque chose ne s’est pas terminé avec succès, il sera défini sur échoué. Si le pipeline échouait, les développeurs pouvaient entrer et examiner quelle tâche du pipeline ne s’était pas terminée avec succès. Ils sont alors chargés de le réparer.
Canalisations CI/CD
Un pipeline CI/CD n’est qu’un ensemble de tâches exécutées ; Cependant, ces travaux spécifient des aspects importants du processus de création d’applications logicielles qui doivent être vérifiés avant la publication du logiciel. Par exemple, lors du démarrage, une équipe peut créer un pipeline simple qui construit l’image, lint est le code source, effectue des tests unitaires, puis déploie l’application. Le pipeline ressemblerait à la figure 2. Lors d’un premier déploiement, je recommanderais même de ne pas vous préoccuper d’un travail de déploiement. Le simple fait de mettre en place la construction et les tests peut apporter beaucoup de valeur à l’équipe. (De toute façon, toutes les équipes n’ont pas besoin d’un déploiement automatisé).
Un premier pipeline contient quatre tâches pour construire, tester et déployer l’application.
Une fois que les bases fonctionnent, les équipes peuvent ensuite s’appuyer sur leur pipeline pour ajouter des tâches supplémentaires qui ajoutent de nouvelles fonctionnalités. Par exemple, un pipeline plus avancé pourrait commencer à ressembler à la figure 3.
Un pipeline logiciel intégré plus avancé qui ajoute une analyse de code et des tests ciblés.
conclusion
CI/CD apporte beaucoup de valeur aux équipes de logiciels embarqués. Au début, le processus peut sembler compliqué, d’autant plus que les systèmes embarqués nécessitent souvent du matériel personnalisé. Cependant, une fois le processus mis en place, il peut aider à identifier les problèmes tôt, ce qui permet d’économiser du temps et de l’argent à long terme. Le processus peut aider à tenir les développeurs responsables du code qu’ils écrivent, en particulier du niveau de qualité qu’ils écrivent. Si vous débutez dans CI/CD, commencez simplement et lancez une étape de construction. Après cela, augmentez progressivement les capacités jusqu’à ce que vous disposiez d’un processus CI/CD complet et automatisé.
