Git Tagging et Git pour le développement de matériel dans Altium Designer

Ari Mahpour

|  Créé: July 23, 2020  |  Mise à jour: September 2, 2020

Le concept de versionnage dans le domaine des conceptions électroniques est resté assez standard dans l'industrie. Chaque version est généralement identifiée par une lettre et parfois un chiffre. Il existe de nombreux autres schématiques de version qui ont déjà été expérimentés, mais, d'après mon expérience, les versions par lettre standard semblent prévaloir au sein de notre industrie. Je me suis toujours posée la question suivante : Comment les versions intermédiaires sont-elles utilisées ? Je comprends qu'un changement de lettre signifie une nouvelle version, mais qu'en est-il de toutes les modifications intermédiaires ? Comment sont-elles suivies ?

Au fil du temps, cette question a été résolue avec des systèmes de contrôle de version tels que CVS, Subversion et Git. Il est probable que les développeurs de logiciels connaissent déjà Git, mais son utilisation pour développer du matériel est un excellent moyen de suivre les versions, les projets de bifurcation de PCB et les projets de lancement. Ces systèmes de contrôle de versions nous donnent la possibilité de visualiser chaque version entre les sorties. Dans le cadre de l'intégration et du déploiement continus au sein de l'ECAD, nous avons discuté de l'idée de publier une nouvelle modification finalisée. Dans cet article, nous allons passer en revue un moyen simple, mais efficace pour diffuser des versions sur votre serveur Git, tout en maintenant le lien avec la lettre de version de votre PCB.

Marquage de vos PCB avec Git

Git Tagging est une fonctionnalité de Git qui permet aux utilisateurs de désigner une modification finalisée spécifique dans un but particulier. Les utilisateurs "marquent" une modification comme étant finalisée pour confirmer sa diffusion. Par exemple, on peut marquer la troisième modification dans un référentiel comme étant la version 1.0.0, alors que les dix modifications ultérieures peuvent être marquées comme étant la version 1.1.0. Il n'y a pas de bonne ou mauvaise manière d'utiliser les étiquettes, mais Git Tagging pour les points de version est généralement la principale utilisation de cette fonctionnalité. 

Que vous utilisiez des projets gérés dans Altium Concord Pro, GitHub, Bitbucket, Gitlab ou toute autre forme de serveur Git, ils sont tous dotés de la possibilité de marquer une modification. Certains serveurs Git ont leur propre système de marquage qui peut être exécuté à partir de leur interface web telles que GitHub ou Bitbucket. Pour les autres serveurs Git, vous pouvez utiliser la commande git-tag dans la ligne de commande. Quelle que soit la méthode de marquage Git appliquée au développement du matériel, un système de dénomination des versions doit être défini afin que chaque membre des équipes comprenne l’enchaînement des différentes versions.

Séquencement des versions et des modifications

Alors que la communauté ECAD migre vers un système de contrôle de versions tel que Git, il est important de maintenir le lien entre Git et le processus de versionnage que nous connaissons tous. Nombreux sont les ingénieurs qui ont des difficultés à déterminer la meilleure façon de gérer leurs modifications dans un système de contrôle de version tout en conservant la liberté de constituer un dossier officiel qui pourra être envoyé aux vendeurs (ou pour examen à une date ultérieure). Il existe de nombreuses façons de procéder. Je propose que le processus de versionnage ne soit pas une solution universelle. Je recommande de l'essayer comme base de référence et de l'adapter ensuite aux besoins de votre groupe.

Le plus grand défi est de donner un sens à toutes les modifications Git et de les lier à une version de production. Voici un exemple d’une série de modifications Git dans GitHub :

Comme vous pouvez le voir, les commentaires des modifications sont nombreux pour décrire chacune des modifications apportées, et d'autres commentaires de modifications confirment la "version officielle". Cette pratique est courante chez de nombreux utilisateurs de systèmes de contrôle de version, et en général elle fonctionne. J'ai également vu des utilisateurs regrouper des versions au sein du référentiel. Bien que cette solution ne soit peut-être pas la plus propre (car elle pollue le référentiel avec des fichiers non conçus), elle semble avoir fait ses preuves.

Plutôt que de publier une version officielle dans un commentaire de modification, vous pouvez utiliser la fonction Git Tagging (ou "Releases" dans GitHub). Dans cet exemple, nous avons pris des modifications de versions officielles et les avons transformées en versions GitHub (qui deviennent également des étiquettes (tags) :

Comme vous pouvez le voir ci-dessus, nous avons pris des modifications spécifiques pour les publier. GitHub attache désormais une étiquette à chacun de ces modifications, de la même manière :

Enfin, nous pouvons désormais effectuer des recherches par version ou par étiquette dans GitHub de la même manière :

Séquencement de schématique avec une modification Git

Une autre façon d'assurer une liaison appropriée entre votre projet PCB et le référentiel Git est de garder une trace du hachage Git dans votre schématique. Voici une astuce que John Watson m'a montré à l'époque où nous utilisions Subversion. En utilisant des chaînes de caractères spéciales, vous pouvez relier votre schéma (et le PCB) directement à la modification Git en relation avec le serveur Git. Dans cet exemple, nous avons placé la chaîne de contrôle de versions sur le schématique de niveau supérieur, juste à côté du bloc titre :

Comme vous pouvez le voir ci-dessus, deux versions du Git Hash sont représentée sur le schématique : la première est le Git Hash complet, et la seconde est la version raccourcie (comme ce qui est utilisé dans GitHub). Pour utiliser la chaîne complète, j'ai saisi la chaîne spéciale suivante :

=VersionControl_ProjFolderRevNumber

Si vous souhaitez la concaténer avec le titre qui précède, vous devez ajouter ce qui suit :

=’Git Hash:’ + VersionControl_ProjFolderRevNumber

Cependant, au moment de la rédaction du présent document, on a découvert que cette chaîne spéciale était trop longue pour être concaténée. Une solution de contournement consiste à donner une valeur plus courte au paramètre VersionControl_ProjFolderRevNumber. Dans ce cas, un paramètre est créé et défini comme : VersionControl_ProjFolderRevNumber in the Properties Panel pour ce schématique spécifique.

Après avoir créé un paramètre raccourci, nous pouvons manipuler la chaîne. Dans ce cas, nous voulons seulement les 7 premiers caractères du Git Hash, comme GitHub utilise lorsqu'il affiche ses Git Hash. Nous utilisons la déclaration de chaîne spéciale suivante, concaténée et manipulée :

='Git Hash: ' + Copy(GitHash,1,7)

Gardez à l'esprit que toute fonction de manipulation de chaîne de caractères utilisée provient du langage Delphi. La technique de sous-chaîne est un simple appel de fonction Copy de Delphi intégré dans la chaîne de texte. Lorsque votre équipe ouvre les documents de conception d'une version de Git dans Altium Designer, elle voit l'étiquette dans les documents de conception, qui indique donc un lien concret à la version contrôlée.

Mise en œuvre de Git pour développer du matériel dans Altium 365

Alors que l'industrie commence à utiliser les versions Git pour développer du matériel, à la fois sur site et dans le cloud, il est important de comprendre la relation entre la version officielle de la conception du PCB et la modification (hachage) réel de Git qui existe au sein du système de contrôle de versions. Grâce au concept de hachage Git et les choix pour utiliser cette fonctionnalité lors de la publication d'un projet de conception de PCB dans un système de contrôle de version, nous pouvons maintenir cette relation et garder les deux processus (ou systèmes) en synchronisation.

Au lieu d'utiliser un système de contrôle de version tiers, vous pouvez mettre en œuvre Git avec Altium Designer et la plateforme Altium 365 pour développer du matériel. Ce système remplace une solution Git basée sur le cloud pour contrôler les versions et importer instantanément des projets dans Altium Designer. Vous pouvez également déployer Altium Concord Pro sur site. Votre équipe disposera donc d'un ensemble complet de fonctionnalités de contrôle de version et de gestion des données qui s'intègrent à Altium Designer.

Altium Concord Pro sur Altium 365 apporte un niveau d'intégration sans précédent à l'industrie électronique qui était jusqu'à présent reléguée au monde du développement logiciel, permettant aux concepteurs de travailler depuis leur domicile et d'atteindre des niveaux d'efficacité sans précédent.

Nous n'avons fait qu'effleurer la surface de ce qu'il est possible de faire avec Altium Designer sur Altium 365. Sur la Page Produits, vous pouvez accéder à des descriptions détaillées des caractéristiques ou accéder à l'un des webinaires à la demande.