Comment définir votre pipeline CI/CD intégré idéal

Le concept moderne d’un pipeline CI/CD est qu’il est automatisé et facilite la fourniture rapide d’améliorations mineures du logiciel au client.

Dans mon article précédent, Comment définir votre système de build embarqué idéal, nous avons discuté des systèmes de build et de l’importance de définir votre système de build embarqué moderne. Un système de build constitue la base de la façon dont vous allez construire votre code, et il va bien plus loin qu’une simple build de débogage. Le système de build que vous développez sera intégré à votre processus DevOps et facilitera le fonctionnement de votre pipeline. Un système de build mal conçu peut entraîner de nombreux problèmes plus tard dans votre cycle de développement et vous coûter du temps et de l’argent.

Les équipes de logiciels embarqués modernes mettent aujourd’hui en œuvre un processus DevOps qui améliore la sécurité, automatise le cycle de vie du développement logiciel, développe la collaboration et assure une amélioration continue. DevOps est une combinaison de philosophies culturelles, de bonnes pratiques et d’outils qui accélèrent la livraison de logiciels. Si l’on évoque DevOps, de nombreux développeurs embarqués pensent immédiatement à l’intégration continue/déploiement continu (CI/CD). Dans cet article, nous explorons ce qu’il faut pour que vous définissiez votre pipeline CI/CD intégré idéal. (N’oubliez pas que DevOps est plus que du simple CI/CD !).

Qu’est-ce qui compose un pipeline CI/CD ?

Un pipeline CI/CD est une série d’étapes ou de tâches qui doivent être complétées avec succès pour fournir une nouvelle version du logiciel. Dans une certaine mesure, les développeurs embarqués ont toujours eu un pipeline CI/CD, mais il s’agissait d’un processus manuel et long. Le concept moderne d’un pipeline CI/CD est qu’il est automatisé et facilite la fourniture rapide d’améliorations mineures du logiciel au client.

Un pipeline CI/CD typique comprend trois activités simples : créer, tester et déployer le logiciel. Conceptuellement, les pipelines sont assez simples, mais les détails font souvent raccrocher les développeurs. Par exemple, si je devais répertorier les différents composants qui composent un pipeline CI/CD, ma courte liste comprendrait les éléments suivants :

• Dépôts – D’où le code source est extrait pour une build. (Peut-être un ou plusieurs).
• Système de construction automatisé – Souvent un système conteneurisé qui peut créer automatiquement le logiciel.
• Tests automatisés – Comprend les tests unitaires, d’intégration, de système et de régression.
• Analyse du code statique – Analyse du logiciel qui comprend des vérifications par rapport aux normes de codage, une analyse des métriques, l’exactitude du langage, etc.
• Émulation/simulation matérielle – Utilisez du matériel virtuel pour tester et vérifier l’exactitude du logiciel.
• Mécanisme de déploiement – ​​Une méthode permettant de fournir un nouveau micrologiciel au produit une fois qu’il a réussi tous les tests automatisés et les portes manuelles.
• Surveillance et reporting – Un mécanisme permettant de surveiller les progrès et de signaler l’état du logiciel et tout problème pouvant nécessiter une enquête.
• Analyse de sécurité – Analyse pour identifier les vulnérabilités de sécurité et garantir la protection du système. (La sécurité pourrait faire l’objet d’une analyse statique, mais j’ai pensé qu’elle valait la peine d’être répertoriée séparément car elle peut être facilement négligée).

Comme vous pouvez le constater, réfléchir à chacun de ces domaines, identifier l’implémentation que vous souhaitez utiliser et la configurer ne sera pas anodin. La mise en œuvre de votre propre solution CI/CD nécessitera de la réflexion et du temps, mais à quoi devrait ressembler cette solution ? Chaque équipe aura ses propres besoins, mais tous les pipelines CI/CD auront certaines fonctionnalités standard. Examinons quelques domaines et définissons un pipeline CI/CD générique pour les développeurs embarqués. Nous garderons les choses simples afin que vous puissiez en tirer parti à l’avenir.

Définir votre pipeline CI/CD idéal

Avant d’examiner votre pipeline CI/CD idéal, je pense qu’il est important de noter que vous ne devez pas permettre aux ressources ou aux contraintes actuelles de limiter votre réflexion. Les équipes qui assemblent un pipeline CI/CD le mettent souvent en œuvre lentement, sur des trimestres ou des années. Ainsi, même si votre pipeline idéal peut sembler inaccessible, le définir vous indique où vous voulez aller. Vous pouvez ensuite implémenter chaque fonctionnalité lentement, au fil du temps, jusqu’à atteindre votre pipeline idéal.

À mon avis, votre premier pipeline CI/CD idéal devrait contenir les tâches suivantes :

• Build – Le travail de build prendra votre micrologiciel et générera les binaires de version.
• Analyse – Le travail de construction d’analyse analysera statiquement votre code. L’analyse typique inclurait la complexité cyclomatique, les métriques de code et le respect des normes de codage telles que le guide de style, MISRA et/ou CERT.
• Tests – Le travail de test effectuera tous les tests requis pour expédier le produit. Vous pouvez inclure des tests unitaires, fonctionnels, d’intégration, de système et de performances.
• Création de rapports – La tâche de création de rapports rassemblera les résultats des tâches précédentes pour fournir des informations sur la réussite de la construction, les résultats d’analyse, la couverture et les résultats des tests, et bien plus encore.
• Fusionner – La tâche de fusion fusionnera la nouvelle fonctionnalité dans la branche de déploiement lorsque toutes les tâches auront réussi. Il y a souvent un élément humain ici, mais cela peut aussi être automatisé.
• Déploiement – ​​Une fois la tâche de fusion terminée avec succès, la tâche de déploiement s’exécutera et démarrera le processus de déploiement sur le terrain. Le déploiement interagit généralement avec un logiciel de déploiement de flotte qui peut transmettre le micrologiciel aux appareils sur le terrain.

Un exemple de pipeline CI/CD idéal

Je pense toujours qu’une image vaut mille mots. Bien que nous ayons décrit les éléments importants dont vous aurez besoin pour créer votre pipeline CI/CD idéal, je pense que le visualiser sera utile. Prenez un moment pour regarder la figure 1 ci-dessous. Vous trouverez le pipeline idéal dont nous avons discuté. (Assurez-vous de le lire de gauche à droite, qui est l’ordre dans lequel je vois ces tâches s’exécuter).

Cliquez pour l’image en taille réelle

Figure 1. Un pipeline CI/CD idéal qui combine les tâches essentielles requises pour créer et déployer des logiciels embarqués modernes. (Source : Conception de logiciels embarqués ; page 25).

Vous pouvez voir chaque travail (étapes) dont nous avons discuté. Le serveur CI/CD extrait les matériaux sources du référentiel cloud et exécute chaque tâche dans l’ordre. L’échec d’une tâche entraînera l’abandon du pipeline et une notification à l’équipe de développement. Vous pouvez décider que l’ordre de vos tâches sera différent. Par exemple, vous pouvez déterminer qu’une analyse statique doit être effectuée avant de créer le logiciel. Si l’analyse révèle un problème, vous ne souhaiterez peut-être pas créer le système. Cependant, j’ai généralement créé le logiciel en premier, puis j’ai continué. Après tout, si le firmware ne se construit pas, est-il utile de l’analyser ?

Conclusions

DevOps trouve rapidement sa place dans les processus de développement embarqués de nombreuses équipes. CI/CD est un moteur important pour l’adoption de DevOps, car les équipes cherchent à fournir des logiciels plus rapidement. L’automatisation offerte par CI/CD est également un excellent outil pour alléger le travail manuel et permettre aux développeurs de se concentrer sur des fonctionnalités à plus valeur ajoutée et des innovations de produits. Lorsque vous démarrez votre parcours CI/CD, vous pouvez tirer parti du pipeline CI/CD idéal de base abordé dans cet article. N’ayez pas peur de sculpter la ligne de base dans votre propre CI/CD idéal.