Comment utiliser Git-Flow dans le développement de logiciels embarqués

Lorsque vous parlez de développement agile, d'intégration continue, de livraison continue et de pratiques DevOps, il est essentiel de disposer d'un système de contrôle de version approprié et de la configuration du flux de travail approprié. Il vous guide dans la plupart des blocs de construction Dev-Test-Operation - code, construction, test et version. Les recherches effectuées par les équipes de R & D de SW montrent des améliorations significatives réduisant le délai de mise sur le marché de nouvelles fonctionnalités lorsque des pratiques de contrôle de source appropriées sont mises en œuvre [1].

Aujourd'hui, Git est le système de contrôle de version le plus populaire pour les équipes agiles. Ce billet de blog sera donc centré sur un flux de travail Git spécifique, adapté au développement de logiciels embarqués.

Git-Flow

image tirée de - http://nvie.com/posts/a-successful-git-branching-model/

Pour Jumper, après avoir essayé quelques workflows git, nous avons décidé de travailler avec Git-Flow proposé par Vincent Driessen (si vous n'êtes pas familier avec Git-Flow, je vous encourage à le lire).

En résumé, Git-Flow est conçu principalement autour de la publication et préconise de répartir votre travail entre deux branches principales:

Master: Ce qui est actuellement en production - la branche stable.
Développer: Le prochain ensemble de fonctionnalités sur lequel nous travaillons - la branche en saignement.
Git-Flow parle également de quelques branches de support et de la manière dont tout est connecté.

Nous trouvons ce flux de travail, bien que cela puisse paraître un peu lourd, très utile pour les projets de logiciels embarqués. Sur une application Web ou mobile, vous n’avez peut-être pas besoin d’une ou de plusieurs branches de développement, de version et de maître. Cependant, les logiciels intégrés ne peuvent pas être déployés tout le temps car les périphériques physiques ne sont pas toujours prêts pour la mise à jour. Une autre raison est que les mises à jour logicielles doivent éventuellement être certifiées. Nous trouvons que les branches maître, release et développement sont indispensables lorsque vous ne déployez pas tout le temps.

Réfléchissez à ce qui se passe lorsque vous trouvez un bogue dans la production mais que le temps nécessaire entre un package prêt à être déployé et la mise à jour réelle du microprogramme sur le terrain est de plusieurs jours ou de plusieurs semaines. Pendant ce temps, votre équipe de développement travaille sur le prochain ensemble de fonctionnalités. Si vous fusionnez directement dans master, mais que vous n'êtes pas encore prêt à publier toutes vos fonctionnalités et qu'un bogue est détecté dans la production, vous êtes obligé de revenir à la balise en cours de production, qui branche, teste, libère la branche. , puis fusionner. Avec une branche en développement, ce n’est pas un problème. De nouvelles fonctionnalités sont en cours de développement. Les correctifs sont divisés en fichiers maîtres, puis fusionnés en fichiers maîtres et se développent une fois l’opération terminée.

Puis-je obtenir les mêmes avantages avec les tags?

Git-Flow établit une distinction claire entre les préoccupations relatives au développement de nouvelles fonctionnalités, à la maintenance générale en cours, à chaque fenêtre de publication et à la maintenance d’urgence. Le Maître est le plus saint des saints et doit rester dans un état pur, fonctionnel et livrable à tout moment. Bien sûr, nous pourrions techniquement atteindre le même objectif en étiquetant les validations validables, mais les branches distinctes fournissent une distinction claire, ce qui est inestimable pour le développement de logiciels embarqués.
Il est également utile de voir en un coup d’œil ce que vous avez publié, ce que vous êtes sur le point de publier et les fonctionnalités qui ne figurent pas dans les versions.

Contraintes de développement de logiciels embarqués

Le développement de logiciels pour les systèmes intégrés introduit des contraintes qui ont une incidence sur votre flux de travail de développement logiciel et Git. Nous pensons que les trois ci-dessous sont les plus communs pour la plupart des projets de systèmes embarqués:

  1. Configuration matérielle - Pendant la durée de vie d'un projet, vous devez prendre en charge différentes configurations matérielles, ce qui signifie que vous devez gérer différentes versions de logiciel.
  2. Temps de certification - Le processus de certification, qui est indispensable pour les secteurs médical, automobile, industriel, etc., introduit de longs cycles d’essais avant une sortie, ce qui signifie que la fusion avec le maître est différée.
  3. Test automatisé - Le périphérique physique rend la connexion du processus de test automatisé à un flux de travail Git fastidieux (découvrez ces cinq étapes pour passer des tests manuels aux tests automatisés intégrés).

Les trois contraintes sont liées au flux de travail Git que vous choisissez, mais la troisième nécessite également une infrastructure de test vous permettant d'exécuter des tests automatisés pour les produits logiciels intégrés (consultez l'automatisation des tests avec les outils Segger).

Si vous souhaitez disposer d’un moyen simple d’automatiser les tests du logiciel intégré de votre périphérique physique, vous êtes invité à essayer Jumper. Pour apprendre à automatiser votre processus de construction, élément essentiel des tests, lisez la suite.

Configuration matérielle

Pendant la durée de vie d'un produit intégré, vous pouvez avoir différentes configurations matérielles déployées pour différents types de clients, voire pour le même client. Cela signifie généralement que vous aurez besoin de versions différentes pour ces sous-produits, tout en utilisant le même référentiel. On peut choisir de travailler avec plus d’un maître et de développer des branches, mais nous ne le recommandons pas. Lorsque vous essayez de conserver différentes branches, vous créez des versions uniques, des tests distincts, la fusion de fonctionnalités complexes, etc. Tout cela se traduit par une perte d'efficacité.

Dans ces types de projets, le principal défi réside généralement dans les interactions entre les versions et dans la manière de partager efficacement le code entre elles, et Git-Flow n'a pas été conçu pour être une solution à ce problème.

Comme il n’ya pas de solution miracle pour résoudre ce problème avec Git en général, nous vous indiquerons peu d’approches.

  1. Divisez la base de code en bibliothèques / modules non liés prenant en charge différentes configurations, gérez-les séparément, puis effectuez une gestion de la configuration. Notez que vous devrez investir dans une architecture logicielle et des couches d’abstraction appropriées.
  2. Contrôlez différentes configurations avec des indicateurs de caractéristiques sur les mêmes branches.
  3. Créez des branches isolées et durables pour chaque version / configuration matérielle.

Pour le long terme, nous vous recommandons d’utiliser les deux premières approches ensemble. Cela améliorera également votre code et vous fera gagner du temps sur les tests.

Temps de certification

Pour les produits qui doivent répondre aux besoins réglementaires, le temps de certification peut prendre des semaines avant une sortie. Pendant ce temps, vous souhaitez que votre équipe continue à fusionner et à travailler sur les fonctionnalités suivantes, sans ajouter de bruit au processus de certification. Pour cela, le Git-Flow fonctionne à merveille.

Test automatisé

Avoir un bon flux de travail Git sans y intégrer un processus de test automatisé revient à ne faire qu'une partie du travail (apprendre à passer d'un test manuel à un test automatisé). Vous devez définir un processus dans lequel différents types de tests s'exécutent sur différentes branches afin de bénéficier d'une couverture et d'une efficacité optimales en termes de temps d'exécution. Lorsqu'une fonctionnalité est validée et fusionnée dans la chaîne de branches - d'une branche de fonctionnalité locale à un dépôt distant, en passant par le développement, la publication et la maîtrise, vous devez ajouter d'autres tests pour terminer la régression.

Chaque projet ayant des exigences de test uniques et des ressources de test disponibles, nous allons décrire notre flux de tests, ce qui peut nécessiter quelques ajustements pour s'adapter à votre projet. Notre flux de tests est basé sur l'hypothèse que vous pouvez au moins exécuter des tests sans hôte, des tests d'hôte simulés et des tests HiL [2].

Remarque pour que votre gestionnaire d'automatisation n'exécute pas le même test deux fois sur le même commit.

Intéressé d'essayer Jumper?

Si vous travaillez avec des systèmes intégrés et souhaitez disposer d’un moyen simple de tester le logiciel intégré de votre périphérique physique, vous êtes invité à essayer Jumper. Le cavalier vous permet d’avoir des tests d’hôte simulés pour booster tout votre cycle de recherche et développement.

Résumé

Adopter le bon flux de travail Git est quelque chose que vous devez évaluer avec soin. Ici, il n’ya pas de solution unique et tout dépend des exigences de votre produit. Nous espérons que notre flux de travail proposé sera bénéfique pour vos besoins. Faites-nous part de vos pensées et partagez avec nous votre flux de travail Git.

Liens

[1] - https://itrevolution.com/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/

[2] - https://docs.google.com/spreadsheets/d/1ScSDfn9v73TBaGpuiGfpPTqnBeTvNd22TzApMt_E0qE/edit#gid=0