Un'introduzione a Git per l'hardware con Altium Designer

Introduzione

Qualche anno fa, sono passato temporaneamente dal lavorare in un ambiente di startup iper-caffeinato a un lavoro di ingegneria in un'azienda più matura e con più esperienza. Ho quindi realizzato la connessione binomiale tra cultura tecnica e strumenti. Il modo in cui pensiamo e lavoriamo è plasmato dagli strumenti a nostra disposizione, poiché le nostre esigenze e abitudini influenzano gli strumenti che scegliamo.

La nuova azienda per cui lavoravo non era abituata a stampanti 3D, software interno per il tracciamento dei bug, o persino un buon CMS. Era tutto piuttosto antiquato. Questo ha avuto un'influenza significativa su ciò che io e i miei colleghi creavamo quotidianamente.

Un esempio potrebbe includere gli ultimi due decenni, in cui l'industria è passata dai pacchetti TO220 ai D2PAK. Allo stesso tempo, gli ingegneri si sono equipaggiati con saldatori ad alta potenza di picco, come quelli prodotti da JBC.

Un giovane ingegnere che accede a un laboratorio ben attrezzato considererebbe oggi un qualsiasi popolare IC in un TO220? Non credo. È molto più facile lavorare con i D2PAK e non doversi preoccupare di viti, rondelle e fogli isolanti, a patto di avere un saldatore di ultima generazione. Questo semplice cambiamento può indirizzare un ingegnere verso la progettazione di schede più piatte, che spesso possono portare a prodotti esteticamente più piacevoli secondo gli standard moderni.

Git è un raro esempio di uno strumento che ha rivoluzionato un'intera industria. Dieci anni fa, i manager dell'ingegneria del software avrebbero considerato folle adottare un approccio di tipo muoviti velocemente e rompi le cose. Git per l'hardware e la progettazione di PCB lo ha reso possibile, abilitando il tracciamento delle revisioni, il controllo delle versioni e il rollback delle modifiche al design. Gli sviluppatori sono ora certi che i loro sforzi nei progetti open source possano sempre essere attribuiti e verificati, grazie a una funzionalità chiamata Git blame. Un decennio fa, essere riconosciuti per il proprio contributo ai progetti open source era lasciato alla politica. Questi sono tutti esempi di cambiamenti per cui possiamo ringraziare Git.

Sebbene per sua natura l'industria elettronica si muova più lentamente del software, molte delle innovazioni stanno filtrando nel nostro lavoro quotidiano. Altium Designer®, con l'introduzione di Altium 365® e Concord Pro™ quest'anno, ha guidato la strada nell'industria, con altri attori importanti che faticano a tenere il passo, a volte con funzionalità rilasciate più di un decennio fa. Git per l'hardware e la progettazione di PCB è una delle tecnologie che alimentano questo cambiamento.

Cos'è Git?

Molto semplicemente, Git è un sistema di controllo versione (VCS). È un pezzo di software (inclusi i protocolli sottostanti e i formati dei dati) utilizzato dagli sviluppatori di software per tracciare e gestire le modifiche al codice. Se sei uno sviluppatore software che lavora in questo decennio, non duplichi cartelle sul tuo desktop per provare le cose, molto probabilmente utilizzi un VCS basato su Git.

Anche se Git è estremamente popolare per il tracciamento delle modifiche al codice nello sviluppo software, può essere utilizzato per tenere traccia delle modifiche a qualsiasi insieme di file. Questi file non devono necessariamente contenere codice, possono essere i tuoi file di progettazione PCB, documentazione di progettazione, file di produzione PCB e qualsiasi altro file di cui avrai bisogno per il tuo progetto. Git per l'hardware è un'estensione naturale dell'ecosistema Git al design meccanico, alla progettazione PCB, al firmware e molto altro ancora.

Git è liberamente disponibile per uso commerciale. È open-source e distribuito sotto la licenza pubblica generale GNU. Ogni directory Git è un'entità separata ed è, essa stessa, un repository contenente una storia completa dei suoi elementi. Ogni file inserito in un repository Git è completamente tracciabile fino a ogni bit, da chi e quando. I repository Git non richiedono accesso alla rete, con ogni repository completamente indipendente dai server(i) che prendono il nome di remote(i).

Non dovrebbe quindi sorprendere che attualmente sia il VCS più popolare al mondo. La maggior parte delle analisi di quota di mercato mostra Git oltre il 75%, e l'alternativa più popolare, SVN, è in declino dal 2012. Anche il numero di offerte di lavoro che richiedono SVN (un VCS legacy, supportato anche da Altium Designer) è in calo mentre Git sta guadagnando popolarità.

Storia di Git

Git è stato creato e scritto nel 2005 da Linus Torvalds, l'uomo, la leggenda, il creatore e sviluppatore del kernel Linux, per tenere traccia dello sviluppo del kernel stesso. La comunità Linux aveva ottenuto l'uso gratuito di un pezzo di software commerciale chiamato BitKeeper. Nel aprile 2005, l'autore di Bitkeeper ritirò la licenza dopo che un membro prominente del team Linux e inventore del server di file Samba, Andrew Tridgell, iniziò a lavorare su un client open-source basato sul protocollo BitKeeper (presumibilmente) ingegnerizzato al contrario. La licenza BitKeeper proibisce espressamente la reverse-engineering.

Così, Linus Torvalds decise di creare il proprio sistema di controllo versione, ispirato non troppo liberamente da BitKeeper, poiché nessuna delle alternative rimanenti era nemmeno lontanamente in grado di soddisfare i suoi requisiti.

Torvalds decise che il nuovo software sarebbe stato molto diverso dai popolari CVS (Concurrent Version Systems) in uso all'epoca. Si rese conto che i sistemi correnti potevano impiegare molto tempo per applicare le patch e, dato che aveva bisogno di applicare centinaia di patch contemporaneamente quando si sincronizzava con il suo team, la loro performance era tutt'altro che accettabile. Elaborò una serie di requisiti:

• Un flusso di lavoro distribuito simile a quello abilitato da BitKeeper. L'utente dovrebbe essere in grado di lavorare offline e sincronizzarsi in seguito.
• Protetto contro incidenti come la corruzione dei dati
• Sicuro contro attacchi malevoli
• In grado di calcolare le patch in meno di due secondi

Il lavoro sulla scrittura di Git è iniziato all'inizio di aprile 2005. Il 16 giugno 2005, è stata rilasciata la versione 2.6.12 del kernel Linux, motivo per cui il software era necessario in fretta. Lo sviluppo e la manutenzione di Git sono stati poi affidati a Junio Amano, che ha contribuito e contribuisce ancora allo sviluppo, ed è ampiamente riconosciuto per aver reso il software facile da usare; Git 1.0 è stato rilasciato nel dicembre 2005.

Convenzione dei Nomi

Perché Git? Un nome strano, a dir poco! Come molte persone nel Regno Unito sanno, il termine è spesso attribuito a qualcuno che è un po' sfacciato o, secondo l'Oxford Online Dictionary, "una persona spiacevole o spregevole". Altri significati riportati sono "sciocco" (slang del 18° al 19° secolo (UK)) o "figlio bastardo" (slang di metà 18° al 19° secolo (USA)), entrambi i quali si adatterebbero piuttosto poeticamente al suo mito del genio solitario eremita che si nasconde per creare un'opera d'arte che cambierebbe il mondo.

Torvalds ha dato diverse ragioni per aver chiamato il suo sistema "Git", da scegliere in base a ciò che l'utente sta provando nel giorno, o probabilmente come si sentiva lui in diversi momenti durante la scrittura del sistema! Spesso lo descrive come "il tracker di contenuti stupido" nella documentazione ufficiale, e la definizione di Git come:

• "Una combinazione casuale di 3 lettere che non può essere pronunciata".
• Una pronuncia errata di "get"!
• Tracker globale di informazioni se funziona secondo i piani
• Stupido, spregevole e disprezzabile quando non funziona.

Ah, l'umorismo dei programmatori.

Svantaggi

Git non è perfetto, tuttavia, e presenta alcuni svantaggi. La struttura dei dati difficile da comprendere e la nomenclatura strana sono senza dubbio tra questi. Ciò include Git per i progetti hardware, dove la stessa struttura dei file e le operazioni sono forzate.

Cherry-picking, Checkout, Index, Clone, Push, Stash, Pull/Richiesta di Pull, Tag, Upstream, Fork, Rebase, Origin, Fetch e HEAD (sempre scritto tutto in maiuscolo, non ho idea del perché) sono tra alcuni dei termini più strani che ci si può aspettare di trovare nel mondo del software.

Può essere difficile capire come configurare un repository come software lato server, e comprendere la relazione tra repository locali e remoti insieme alle operazioni per mantenerli sincronizzati. Git tende ad essere molto più complesso da imparare e usare rispetto a SVN, in parte a causa della sua maggiore potenza ed efficienza.

Fortunatamente, Altium Designer e Concord Pro si prendono cura della maggior parte di questi problemi. Mentre abbiamo pieno accesso alla potenza di Git tramite la riga di comando, l'interfaccia utente e l'integrazione rigorosa di Concord Pro lo rendono facile e intuitivo da utilizzare. Allo stesso tempo, Altium 365 si prende cura di tutti i problemi lato server.

Come Funziona Git per l'Hardware?

Git può sembrare... molto strano! La nomenclatura, principalmente, riflette un flusso di lavoro che si differenzia sostanzialmente dal classico copia-incolla, zippare e inviare email a cui molti ingegneri sono abituati.

Branching (e Merging)

Il modello di branching è forse la caratteristica più popolare che separa Git da altri VCS come SVN. Git può avere più branch, sia locali che remoti. Come i rami di un albero si biforcano dal tronco o l'uno dall'altro, così i branch di Git germogliano da altri branch. Il "tronco" dell'albero, o il branch principale, è chiamato master. I branch possono essere facilmente creati, uniti e cancellati. Ecco come funzionano queste operazioni:

• Ogni branch è indipendente, e quando si lavora in remoto, non è necessario pestare i piedi a nessuno. È possibile avere anche più branch personali, ognuno contenente una variazione leggermente diversa del proprio software o progetto hardware, e possono essere cambiati nella stessa directory senza dover chiudere e riaprire i file manualmente.
• Nel mondo del software, la regola generale è avere un branch di produzione, chiamato master, e un secondo branch di lavoro in corso chiamato develop e quanti più branch piccoli necessari per nuove funzionalità e correzioni. Lo stesso approccio può essere adottato con i progetti hardware. Infatti, ci sono molti repository GitHub con progetti di PCB e altri progetti specificamente per l'hardware.
• Non tutti i branch devono essere uniti al branch master. Spesso gli sviluppatori scoprono che la nuova funzionalità non è proprio un lampo di genio, e il branch può semplicemente essere cancellato quando non è più necessario.

[Modalità nerd ATTIVA]

Quindi, come funziona questa caratteristica intelligente? Un branch è essenzialmente un puntatore a un commit. Un commit è un insieme di modifiche ai file, aggiunte o rimozioni inviate al repository. Il commit ha un checksum crittografico SHA-1 di 40 caratteri che viene scritto su un file. Ogni commit include anche un puntatore al commit genitore da cui ha avuto origine.

Ci sono molti passaggi intermedi aggiuntivi, per esempio, i file vengono convertiti in blob binari checksummati e organizzati in directory attraverso un albero binario. Anche il checksum dell'albero viene calcolato. Poiché tutto è criptato criptograficamente, non c'è modo di alterare (o corrompere) i dati o la storia senza cambiare il hash dell'ultimo commit. Il hashing crittografico rende la storia di Git in qualche modo permanente, quindi siate educati quando scrivete i messaggi di commit!

[Modalità nerd DISATTIVA]

Workflow in Git per l'Hardware

Grazie alla natura distribuita di Git per l'hardware e al sistema di branching avanzato, così come a una serie di altre caratteristiche, gli utenti sono liberi di adottare qualsiasi workflow.

Tra i più popolari, il modello di *Workflow Centralizzato* è uno spesso utilizzato quando le persone che hanno esperienza con i sistemi di controllo versione centralizzati iniziano a usare Git (che è *decentralizzato*) per la prima volta. Il *Workflow Centralizzato* si basa quasi esclusivamente sul branch master, dove tutti i commit sono inviati e da cui sono prelevati, facendo sì che Git imiti il comportamento di SVN e dei filesystem remoti.

Il workflow di Feature Branching è un'evoluzione del *Centralised Workflow*. Il lavoro di sviluppo viene svolto su rami separati che vengono poi uniti in un master. Sono un fervente sostenitore di questo modello nell'ingegneria elettronica, e sto aspettando con ansia che Altium annunci il loro supporto ai branch per poterne approfittare. Esempi di branch di funzionalità potrebbero essere “fix_current_generator_oscillation”, “upgrade_microcontroller”, “lower_power_consumption” o “reduce_thermal_drift”.

Nel workflow GitFlow, forse il più complesso tra i workflow popolari, il ramo master contiene solo le versioni complete del design, puoi pensarla come board_v_1.0, board_v_1.1, ecc. Lo sviluppo viene effettuato su un ramo separato chiamato develop, e le funzionalità e le correzioni nascono dal ramo develop. Solo develop può essere unito al master una volta che è pronto.

Decentralizzazione e Velocità

Git è più veloce di altri sistemi di controllo versione per diverse ragioni. Ogni utente può clonare il repository originale, e i commit possono essere fatti regolarmente sui rami locali e inviati al remoto meno frequentemente. Altri VCS che non sono così decentralizzati sono limitati dalla capacità del server remoto, che deve rallentare considerevolmente per soddisfare tutte le loro richieste.

Questo approccio locale-prima è particolarmente cruciale nell'industria elettronica, poiché i file possono essere piuttosto grandi. Non è raro che un progetto di PCB sia di decine di megabyte, specialmente con centinaia di corpi 3D. I file del codice sorgente, d'altra parte, tendono ad essere di qualche centinaio di KByte al massimo.

Nell'ultima azienda per cui ho lavorato, avevamo un repository SVN ospitato nelle sedi centrali, accessibile tramite una VPN, dove avremmo memorizzato i file del progetto e la documentazione. Ci vorrebbe un'eternità per fare qualsiasi operazione, e la nostra connessione internet limitata era frequentemente intasata da tutte le richieste per gestire migliaia di file.

Git è anche scritto in linguaggio C, il che significa che il suo overhead è minimo rispetto ad altri linguaggi di alto livello. A seconda dell'operazione, Git può essere da qualche volta a centinaia di volte più veloce di SVN.

L'approccio decentralizzato, offline-prima rende anche Git molto più leggero sulla rete. Anche se la tua azienda non ha accesso a banda larga, puoi inviare i dati durante l'ora di pranzo o dopo il lavoro, senza perdita di prestazioni nel lavoro quotidiano.

Su Concord Pro, puoi godere di tutti i vantaggi di Altium 365 quando hai accesso a una connessione internet, poi vagare con la tua licenza di Altium Designer e continuare a lavorare offline.

Aree di Staging

Quando si lavora con Git, è essenziale rendersi conto che i file passano attraverso tre fasi prima che possano essere effettivamente considerati sotto controllo di versione:

1. Non tracciati
2. In Staging
3. Confermati

Non tracciati è quando il file esiste sul disco, ma è fuori dal sistema di controllo versione. Il file non tracciato può poi essere in staging, il che significa che è stato aggiunto al sistema di controllo versione ma non ancora confermato. A questo punto, le modifiche in staging possono essere confermate. Il sistema di staging è utilizzato per prepararsi alla conferma, ma la funzionalità è usata principalmente nell'operazione da riga di comando.

Quando si utilizza Git tramite Altium, grazie all'interfaccia grafica che semplifica l'operazione, l'approccio di staging viene applicato automaticamente in background quando si salvano le modifiche sul server.

Creazione di un Repository

I repository vengono creati automaticamente sul lato server quando si crea un nuovo progetto. Nella finestra qui sotto, sto creando un nuovo progetto PCB da un template all'interno del mio spazio di lavoro Fermium LTD. Non appena creo il progetto, sarà accessibile nel mio spazio di lavoro Altium 365, e la piattaforma creerà automaticamente un repository Git per il nuovo progetto.

Configurazione Iniziale del Repository

I repository creati con Concord Pro sono configurati automaticamente, quindi solo i file essenziali sono già confermati nel repository Git del progetto, mentre i backup locali e i file LOG non lo sono. Tipicamente sarebbe necessario configurare adeguatamente un file chiamato ".Gitignore" e fare attenzione a non confermare file non necessari, ma Concord Pro si occupa di ciò.

Configurazione delle Credenziali

Per accedere ai repository Git, generalmente sarebbe necessario configurare le chiavi SSH e le credenziali utente sia sul lato server che sul lato client. Concord Pro si occupa di ciò automaticamente quando viene aggiunto un nuovo utente.

Clonazione dei Repository

La clonazione è il processo attraverso il quale Git replica il repository remoto in una copia locale. Clonare manualmente grandi repository con file binari, come i file PcbDoc e SchDoc, richiederebbe normalmente un'operazione da linea di comando di livello esperto. Altium Designer e Concord Pro clonano automaticamente il repository sul tuo computer locale in background quando apri un progetto remoto.

Risoluzione dei Conflitti e Confronto delle Modifiche

Concord Pro ti consente di confrontare le modifiche tra diverse revisioni, sia locali che remote, attraverso il pannello del gestore di archiviazione. Nell'esempio seguente, ho aggiunto un oggetto nota di testo e ho eseguito il commit delle modifiche localmente, ma non le ho inviate al remoto.

Questo ci fornisce la funzionalità completa necessaria in una piattaforma Git per l'hardware.

Conclusioni

Git è uno strumento formidabile, e git per l'hardware offre ai progettisti di PCB un flusso di lavoro completo per il controllo di versione, la condivisione e la gestione delle revisioni. Questo sistema popolare ha contribuito a plasmare la cultura dei programmatori moderni. Ora, con Altium Designer® e la piattaforma Altium 365®, i progettisti possono accedere alle funzionalità di Git per la progettazione di PCB.

Puoi iniziare oggi stesso una prova di Altium 365, caricata con progetti di esempio, per vivere pienamente lo sviluppo elettronico in stile ventunesimo secolo. Hai altre domande? Parla oggi stesso con un esperto di Altium.