Git Tagging e sviluppo hardware in Altium Designer

Ari Mahpour

|  Creato: July 23, 2020  |  Aggiornato: September 2, 2020

Il concetto di revisione nel campo della progettazione elettronica ha mantenuto una tendenza relativamente standard in tutto il settore. Una revisione consiste di solito in una lettera e talvolta contiene un numero. La gente ha provato diversi schemi di revisione ma, in base alla mia esperienza, la revisione standard basata sulla lettera è quella che sembra prevalere nel settore. Una domanda che mi sono sempre posto è questa: che fine hanno fatto le revisioni intermedie? Capisco che un cambiamento in una revisione comporta una release, ma che ne è stato di tutti i cambiamenti tra una release e l'altra? Come vengono tracciate? La risposta a questa domanda potrebbe essere giustamente: il git tagging!

Nel corso del tempo, questo quesito è stato affrontato con sistemi di controllo versione come CVS, Subversion e Git. Gli sviluppatori di software hanno probabilmente familiarità con Git, ma utilizzarlo nella progettazione hardware è un ottimo modo per tracciare le revisioni, i progetti fork e i progetti di release. Questi sistemi di controllo del progetto offrono la possibilità di visualizzare ogni versione tra una release e l'altra. Nell’articolo Integrazione e Deployment continui in ECAD abbiamo discusso il concetto di rilasciare una nuova versione di un progetto ad ogni commit. In questo articolo, esamineremo un modo semplice ma efficace di rilascio con il server Git mantenendo, al contempo, il collegamento con la revisione basata su lettera del PCB.

Tagging dei PCB con Git

Git Tagging è una funzionalità di Git che permette agli utenti di designare un commit specifico per un determinato scopo. Gli utenti “taggheranno” un commit per indicare il suo rilascio. Ad esempio, si può etichettare il terzo commit nel repository come Revisione 1.0.0, mentre i dieci commit successivi possono essere etichettati come Revisione 1.1.0. Non esiste un modo giusto o sbagliato di usare i tag, ma l'utilizzo dei Git tagging per i punti di rilascio è di solito l’applicazione principale di questa caratteristica. 

Indipendentemente se gestisci i progetti in Altium Concord Pro, GitHub, Bitbucket, Gitlab o qualsiasi altra forma di server Git, tutti hanno la funzione di taggare un commit. Alcuni server Git hanno un proprio sistema di tagging che può essere eseguito dalle loro interfacce web come GitHub e Bitbucket. Per altri server Git, puoi usare il comando git-tag o git tagging dalla riga di comando. Indipendentemente da come decidi di implementare il tagging in Git per lo sviluppo hardware, il team necessita di un sistema di denominazione delle revisioni in modo che tutti comprendano come le diverse versioni si relazionano tra loro.

Collegamento tra una release e un Git commit

Mentre la comunità ECAD migra verso un sistema di controllo versione come Git, è essenziale mantenere il collegamento tra il sistema Git e il processo di release noto a tutti. Molte persone hanno avuto difficoltà nel determinare il modo migliore per mantenere i commit in un sistema di controllo del progetto e della sua versione e, al contempo, assemblare un pacchetto ufficiale da inviare ai fornitori (o per la revisione in un secondo momento). Esistono sono vari modi per farlo. Il processo di release non è una soluzione unica per tutti, tuttavia consiglio di provarlo come base di partenza e di adattarlo alle esigenze del gruppo.

La sfida principale è dare un senso a tutti i commit di Git e poi collegarli ad un pacchetto di rilascio. Ecco un esempio di una serie di Git commit visti in GitHub:

Come puoi notare, ci sono molti commenti che descrivono le modifiche al progetto e altri che proclamano una “release ufficiale”. È una pratica comune tra molti utenti del sistema di controllo versione e solitamente funziona. Ho anche notato che gli utenti raggruppano i pacchetti di rilascio all'interno del repository. Sebbene non sia la soluzione più pulita (poiché contamina il repository con file non di progetto), sembra funzionare.

Piuttosto che rendere nota la release ufficiale in un commento, possiamo sfruttare il concetto di git tagging (noto come “release” in GitHub). In questo esempio, abbiamo preso i commit di queste release ufficiali e le abbiamo trasformate in release GitHub (diventate anche tag):

​

Come puoi notare, abbiamo preso specifici commit e convertiti in release. In questo modo, GitHub etichetta i commit in questo modo:

​

​

Collegamento tra uno schematico e un Git commit

Un altro modo per assicurare un collegamento tra il progetto PCB e il repository Git è quello di monitorare il Git hash nello schematico. È un trucchetto che John Watson mi ha mostrato quando usavamo Subversion. Utilizzando stringhe speciali puoi collegare uno schematico (e PCB) direttamente al Git commit utilizzato per caricare contenuti sul server Git. In questo esempio, abbiamo posizionato la stringa di controllo del progetto e della sua versione sullo schematico di primo livello accanto al blocco del titolo:

​

Come puoi notare, ci sono due versioni di Git hash  rappresentate nello schematico: la prima è la versione completa e la seconda è quella breve (come quella usata in GitHub). Per utilizzare quella completa ho digitato la seguente stringa speciale:

=VersionControl_ProjFolderRevNumber

Se vuoi concatenarla al titolo, devi aggiungere la seguente stringa:

=’Git Hash:’ + VersionControl_ProjFolderRevNumber

Tuttavia, al momento della stesura di questo articolo, abbiamo scoperto che questa stringa era troppo lunga per essere concatenata. Un’alternativa è impostare VersionControl_ProjFolderRevNumber come parametro breve. In questo caso, è stato creato un parametro e impostato come VersionControl_ProjFolderRevNumber nel pannello Proprietà per questo schematico.

​

Una volta creato un parametro più breve, possiamo modificare la stringa. In questo caso, vogliamo solo i primi 7 caratteri del Git hash, così come viene visualizzato in GitHub. Inseriamo la seguente stringa speciale combinata e modificata:

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

Ricordati che qualsiasi funzione di modifica delle stringhe utilizzata proviene dal linguaggio Delphi. La tecnica del sottostringa è una semplice funzione Copia incorporata nella stringa. Dopo aver aperto i documenti di progettazione della release Git in Altium Designer, vedrai un tag contenente un link specifico che si ricollega direttamente alla versione controllata.

Implementazione Git per lo sviluppo hardware in Altium 365

Mentre l'industria inizia a utilizzare le revisioni Git per lo sviluppo hardware, in particolare per la fase di controllo del progetto, sia in ambiente locale che cloud, è importante capire il legame tra il rilascio ufficiale di un progetto PCB e il Git commit (hash) nel sistema di controllo versione. Il concetto di Git hash e l'uso di questa caratteristica nella pubblicazione di un progetto PCB in un sistema di controllo versione ci consente di preservare questo collegamento e di mantenere i due processi (o sistemi) sincronizzati.

Invece di utilizzare un sistema di controllo versione di terze parti, puoi implementare il Git tagging per lo sviluppo hardware con Altium Designer e la piattaforma Altium 365. Questo sistema sostituisce una soluzione Git basata su cloud per il controllo versioni e consente al team di importare istantaneamente i progetti in Altium Designer. In alternativa, puoi implementare Altium Concord Pro nell’ambiente locale, fornendo al team una serie completa di funzioni di controllo versione e di gestione dei dati che si integrano con Altium Designer.

Altium Designer su  Altium 365 sta introducendo un livello di integrazione senza precedenti nel settore dell’elettronica che è stato relegato al mondo dello sviluppo software, consentendo ai designer di lavorare da casa e raggiungere livelli impareggiabili di efficienza.

Abbiamo solo scalfito la superficie di ciò che è possibile fare con Altium Designer su Altium 365. Per una descrizione più approfondita della funzione puoi dare un’occhiata alla pagina del prodotto o partecipare a uno dei Webinar on-demand.