Commencer avec DevOps pour les systèmes embarqués en utilisant le ATmega328P

DevOps et les méthodologies Agile ont transformé le développement logiciel en mettant l'accent sur la collaboration, l'automatisation et l'amélioration continue. Appliquer les principes DevOps à mes conceptions et projets a été un changement radical, améliorant l'efficacité et la fiabilité. Dans cet article, nous allons vous guider dans la mise en place d'un flux de travail d'intégration continue (CI) pour un projet de systèmes embarqués existant qui utilise le microcontrôleur ATmega328P. À la fin de cet article, vous verrez comment ces pratiques peuvent rationaliser votre processus de développement et livrer des produits de meilleure qualité.

Comprendre DevOps et Agile pour les systèmes embarqués

DevOps est un ensemble de pratiques, popularisé par le monde du logiciel, qui relie le développement logiciel (Dev) et les opérations informatiques (Ops) dans un flux continu. Dans le monde du logiciel, il était courant de développer un logiciel et de le « jeter par-dessus le mur » aux équipes d'opérations pour le déploiement chez les clients. DevOps a introduit un moyen de non seulement abattre ce mur, mais aussi d'automatiser tout le processus de bout en bout. Dans le monde du matériel, nous trouvons des similitudes entre le développement de produits et la production, en jetant constamment la conception « par-dessus le mur » à nos équipes d'ingénierie de fabrication pour s'assurer que tout est prêt pour la production.

Dans la conception de produits embarqués, nous devons toujours faire passer notre logiciel en production mais nous sommes confrontés au défi de bouger plus rapidement que jamais et de livrer avec la plus haute qualité possible. Avec les principes DevOps, nous visons à résoudre certains de ces défis.

• Dépendances matérielles : Les systèmes embarqués dépendent du matériel et de révisions spécifiques de ces PCBs. Cela peut rendre les tests et le déploiement complexes s'ils ne sont pas rationalisés pour être automatisés et hautement évolutifs. Les pratiques DevOps aident à automatiser ces processus en utilisant la même configuration pour le matériel et le logiciel et en les soumettant à des systèmes d'intégration continue (CI) automatisés.
• Longs temps de construction : Configurer la construction de logiciels embarqués peut être difficile et entraîner de longs temps de construction. La CI automatise et accélère ce processus en déléguant les constructions au cloud en utilisant des instances plus puissantes auxquelles les développeurs n'ont normalement pas accès.
• Tests manuels : Tester sur du matériel réel est essentiel mais souvent manuel, fastidieux et chronophage. L'automatisation via des tests hardware-in-the-loop (HIL) améliore l'efficacité et la précision et peut être déléguée à une configuration d'équipement de test automatique configurée avec votre système CI.

En appliquant les principes DevOps, nous sommes capables d'itérer rapidement en utilisant les méthodologies Agile dans le paradigme de construction-test-déploiement pour chaque fonctionnalité supplémentaire que nous souhaitons libérer en production.

Comment tout cela fonctionne

« Construire, tester et déployer » est un ensemble de mots que vous entendrez souvent lorsque l'on discute de DevOps. Dans les systèmes embarqués, nous faisons la même chose puisque notre déploiement va également en production (et ensuite au client final). Dans le référentiel du projet, nous utilisons Gitlab CI pour piloter notre flux de travail de bout en bout pour le DevOps embarqué. Nous utilisons ce qu'on appelle des « pipelines » pour créer des tâches qui accomplissent certaines missions telles que compiler le logiciel, exécuter des tests sur cible, ou le publier en tant que package officiel. Dans Gitlab, un pipeline est une collection de tâches qui s'exécutent dans un flux séquentiel comme ceci :

Figure 1 : Exemple de pipeline utilisé avec le flux de travail DevOps ATmega328P dans Gitlab

Voici une explication du script CI (.gitlab-ci.yml) pour vous donner une idée de son fonctionnement.

• Docker : Comme discuté dans Containeriser les environnements de construction et d'exécution pour les tests en boucle fermée, cette étape construit des images Docker pour créer un environnement cohérent pour la construction, le test et le flashage du code. Cela garantit que le processus de construction est reproductible sur différentes machines et architectures (comme un PC de bureau versus un Raspberry Pi).
• Test : Cette étape exécute des tests unitaires pour vérifier que votre code fait ce que vous avez l'intention qu'il fasse. Les tests automatisés sont rapides et importants lors de la modification ou du remaniement du code existant.
• Construction : Cette étape compile le code source en binaires. Dans ce projet, elle génère des artefacts comme des fichiers .elf et .hex, qui sont utilisés pour flasher la puce ATmega328P.
• HIL (Hardware-in-the-Loop) : Cette étape implique de tester le logiciel sur du matériel réel pour s'assurer qu'il fonctionne correctement dans des conditions réelles. Elle charge le logiciel sur le matériel et exécute des tests pour vérifier que la fonctionnalité que nous avons conçue fonctionne effectivement sur le produit final.
• Déploiement : Cette étape gère la publication des artefacts construits vers un registre de paquets, les rendant disponibles à l'utilisation.
• Publication : Cette étape crée une nouvelle version du logiciel, automatisant le processus de livraison pour assurer des mises à jour rapides et fiables. C'est ce que l'équipe de production utiliserait pour récupérer la version du logiciel nécessaire pour leur assemblage complet du produit.

Détails Fins

Il y a quelques détails mineurs qui transforment ce flux de travail d'une mise en œuvre DevOps basique en un système fonctionnant de manière fluide, bien documenté et facilement observable. Il y a quelques détails subtils au sein du flux de travail CI qui sont importants à souligner.

• Versionnement Sémantique : Définir une version, que ce soit via un mécanisme automatique ou manuellement, est extrêmement important pour le cycle de publication, surtout lorsqu'on travaille avec la production. Comme exemple, cela est défini comme une variable dans le script CI puis utilisé dans les tâches de publication et de sortie.
• Logique de construction Docker : Vous remarquerez qu'il y a un bloc de logique qui est utilisé pour les constructions de conteneurs Docker :

if [ "$CI_COMMIT_REF_SLUG" == "$CI_DEFAULT_BRANCH" ]; then

  export IMAGE_TAG=$CI_REGISTRY_IMAGE/$IMAGE_TYPE:latest

else

  export IMAGE_TAG=$CI_REGISTRY_IMAGE/$IMAGE_TYPE:$CI_COMMIT_REF_SLUG

fi

Cette logique prépare le terrain pour que notre étiquette « latest » utilise uniquement l'image Docker construite sur la branche principale (c'est-à-dire après qu'une demande de fusion passe avec succès). Cela garantit que seules les demandes de fusion réussies publient l'image docker la plus récente et la meilleure que tout le monde et chaque pipeline tirent.

• Rapports et Couverture : Dans les systèmes CI modernes tels que Gitlab, nous sommes capables d'extraire et d'afficher les rapports de tests et de couverture au sein de nos demandes de fusion et pipelines. Par exemple, dans cette demande de fusion, nous avons capturé la couverture de code :

Figure 2 : Couverture de code dans une demande de fusion

Dans cette capture d'écran, Gitlab résume les tests effectués sur la cible en utilisant le matériel en boucle :

Figure 3 : Résumé des tests pour les tests effectués sur la cible

En fin de compte, une fois que notre code a été validé à la fois avec des tests unitaires et sur cible, les étapes de publication et de libération génèrent un joli paquet qui peut être consommé par l'équipe de production :

Figure 4 : Libération du paquet logiciel

Avec toutes ces étapes automatisées, nous pouvons libérer une nouvelle fonctionnalité de manière itérative dans un mode Agile. Il n'est pas nécessaire de développer de nombreuses fonctionnalités, de les envoyer au département QA, puis une révision pour la libération du paquet par l'équipe de production. Tout ici se passe dans un seul flux de travail et c'est complètement automatisé.

Conclusion

Dans cet article, nous avons exploré comment les méthodologies DevOps et Agile peuvent être appliquées au développement de systèmes embarqués, en utilisant spécifiquement le microcontrôleur ATmega328P. Nous avons discuté des avantages de l'implémentation d'un workflow CI dans Gitlab, qui inclut l'automatisation, des temps de construction plus rapides et des tests efficaces. En décomposant le script CI et en expliquant chaque étape, nous avons montré comment créer un processus de développement robuste et rationalisé qui augmente l'efficacité et la qualité du produit. En suivant ce guide pratique (et le code source au sein du dépôt), vous devriez également être capable de mettre en place votre propre workflow DevOps embarqué.

Le code source du projet peut être trouvé ici :https://gitlab.com/embedded-designs/atmega328p-serial-led-control.