Binari nel controllo del codice sorgente

Quando si sviluppa per dispositivi embedded e altri mondi strani, è molto probabile che il processo di compilazione includa più binari proprietari, usando versioni molto specifiche di essi. Quindi la domanda è: fanno parte del tuo controllo del codice sorgente? I miei uffici seguono la regola del "check out dal controllo del codice sorgente include tutto il necessario per compilare il codice" e questo ha portato ad alcuni argomenti seri.

Gli argomenti principali che vedo contro questo sono gonfiore del DB di controllo del codice sorgente, la mancanza di file binari diversi ( vedi domande precedenti sull'argomento) . Questo è contro la possibilità di controllare, costruire, sapendo di avere l'ambiente preciso previsto dallo sviluppatore precedente e senza cercare i file appropriati (con versioni specifiche non meno!)

L'idea di VERSION CONTROL (nome improprio: controllo del codice sorgente) è quella di consentire di tornare indietro nella cronologia, recuperare l'effetto delle modifiche, vedere le modifiche e perché apportate. Questa è una serie di requisiti, alcuni dei quali hanno bisogno di cose binarie, altri no.

Esempio: per il funzionamento del firmware incorporato, avrai normalmente una toolchain completa: un compilatore proprietario che costa molto denaro o una versione di gcc. Per ottenere l'eseguibile per la spedizione hai bisogno della toolchain e della fonte.

Controllare le toolchain nel controllo della versione è una seccatura, le utility diff sono orribili (se non del tutto), ma non ci sono alternative. Se vuoi che la toolchain sia preservata per il ragazzo che viene a vedere il tuo codice tra 5 anni per capire cosa fa, allora non hai scelta: DEVI avere anche la toolchain sotto controllo della versione.

Ho scoperto negli anni che il metodo più semplice per farlo è creare un'immagine ZIP o ISO del CD di installazione e verificarlo. Il commento del check-in deve essere il numero di versione specifico del produttore della toolchain. Se gcc o simili, raggruppa tutto ciò che stai utilizzando in un grande ZIP e fai lo stesso.

Il caso più estremo che ho fatto è Windows XP Embedded in cui la "toolchain" è una VM Windows XP in esecuzione, che includeva (allora) SQL Server e una pila di file di configurazione insieme a centinaia e centinaia di file di patch. L'installazione dell'intero lotto e l'aggiornamento è stato necessario in circa 2-3 giorni. Preservare ciò per i posteri significava controllare TUTTA la VM nel controllo della versione. Visto che il disco virtuale era composto da circa 6 x 2 GB di immagini, in realtà è andato abbastanza bene. Sembra esagerato, ma ha reso la vita molto facile per la persona che è venuta dopo di me e ha dovuto usarla - 5 anni dopo.

Riepilogo: il controllo versione è uno strumento. Usalo per essere efficace, non rimanere impiccato per cose come il significato delle parole e non chiamarlo "controllo del codice sorgente" perché è più grande di così.

Neal Ford sostiene in The Productive Programmer che dovresti tenere i binari nel controllo del codice sorgente:

Perché mantenere i binari? I progetti oggi dipendono da una serie di strumenti e librerie esterne. Supponiamo che tu stia utilizzando uno dei framework di registrazione più diffusi (come Log4J o Log4Net). Se non si creano i file binari per quella libreria di registrazione come parte del processo di compilazione, è necessario mantenerli nel controllo della versione. Ciò ti consente di continuare a creare il tuo software anche se scompare il framework o la libreria in questione (o, più probabilmente, introduce una modifica in una nuova versione). Mantieni sempre l'intero universo richiesto per creare il tuo software nel controllo della versione(meno il sistema operativo e anche questo è possibile con la virtualizzazione; vedere "Usa la virtualizzazione" più avanti in questo capitolo). È possibile ottimizzare i file binari di mantenimento mantenendoli sia nel controllo della versione che su un'unità di rete condivisa. In questo modo, non è necessario gestirli su base oraria, ma vengono salvati nel caso in cui sia necessario ricostruire qualcosa un anno dopo. Non sai mai se dovrai ricostruire qualcosa. Lo costruisci fino a quando non funziona, quindi dimenticalo. È il panico che induce a rendersi conto che è necessario ricostruire qualcosa di due anni fa e non avere tutte le parti.

Non potrei essere più d'accordo; mentre questo sta probabilmente sovvertendo il VCS per un'attività per cui non è stato progettato (mantenere i binari), penso che i benefici siano superiori ai potenziali svantaggi. Ma, come nota l'autore in seguito, a volte tenere i binari in VCS potrebbe non essere una soluzione pratica, quindi dovrebbero essere prese in considerazione altre opzioni, come tenerle su un'unità di rete mappata.

Se i binari non fossero troppo grandi, li terrei sicuramente in VCS. Questo sembra essere ancora più vero nel tuo caso, poiché i binari sono probabilmente piccoli e lavori con versioni molto specifiche. Potrebbero anche essere difficili da trovare, a causa di una serie di motivi (gli autori hanno chiuso il loro sito Web o la versione di cui hai bisogno non è più elencata per il download). Sebbene improbabile, non si sa mai cosa accadrà tra qualche anno.

Vorrei leggere questo libro qualche anno fa, mentre stavo lavorando a un gioco usando una libreria grafica (che era un file dll); Ho interrotto lo sviluppo per un po 'e quando volevo continuare non riuscivo a trovare di nuovo la DLL perché il progetto era morto.

In linea di principio, apprezzo il campo "Controlla tutto il necessario per incorporare il controllo del codice sorgente", ma la gestione delle dipendenze si è evoluta un po 'negli ultimi anni, con strumenti come Maven, Ivy e NuGet.

Inoltre, in pratica, trovo il controllo nei file binari per creare una serie di spiacevoli effetti collaterali. Git / Mercurial non sono davvero ottimizzati per questo, ad esempio, e Subversion e Perforce possono farti impazzire quando si uniscono rami che contengono file binari.

Con una soluzione di gestione delle dipendenze, si specifica in un file controllato dal codice sorgente nel progetto da quali nomi di pacchetto e da quali versioni dipende il progetto. Quasi tutti gli strumenti di gestione delle dipendenze consentono di creare un repository privato delle dipendenze, seguendo una sorta di convenzione di controllo delle versioni e dei nomi; quando si esegue una build, lo strumento di gestione delle dipendenze risolverà tutte le dipendenze open source e proprietarie da un elenco di origini approvate, quindi le inserirà nella cache locale. La prossima volta che costruisci con le stesse dipendenze della versione, tutto è già lì e va molto più veloce.

È quindi possibile eseguire il backup del repository privato con strumenti di backup del filesystem convenzionali.

Questo evita i rallentamenti che ho riscontrato quando un sacco di file binari viene estratto dall'albero dei sorgenti e impedisce al tuo repository di avere molti file difficili da diff. C'è solo una posizione per ogni dipendenza, per nome e numero di versione, quindi non ci sono conflitti di unione da affrontare, e la memorizzazione nella cache del filesystem locale significa che non devi affrontare i costi di valutazione se la tua copia locale è cambiata quando tiri aggiornamenti.

Il controllo del codice sorgente è per le fonti. Le fonti sono ciò che non puoi costruire da altre cose. Alcuni file che si qualificano come fonti sono binari.

Il mio VCS ha molti binari controllati, ma ognuno è l'unità di rilascio di un prodotto che non ho scritto e che non gestisco. Questo potrebbe essere qualcosa come GNU ccRTP, che viene rilasciato come tarball compresso. Quel tarball è la mia fonte ed è verificato insieme a qualsiasi infrastruttura di cui ho bisogno per trasformarlo in un prodotto finito (un Makefile e una specifica RPM nel mio caso) in un unico passaggio automatizzato. Quando c'è una nuova versione di ccRTP, considero il nuovo tarball come sorgente cambiata: va in una copia di check-out, viene compilato, testato e ricollegato al VCS. Ho fatto lo stesso con prodotti commerciali che non vengono forniti con i sorgenti (compilatori, librerie, ecc.) E funziona allo stesso modo. Invece di unpack-configure-compile-package, è solo unpack-package. Il software che esegue le build notturne nonmake e ottenere prodotti finiti.

La maggior parte dei VCS ha funzionalità che rendono la fonte leggibile dall'uomo più facile da gestire e più efficiente da archiviare, ma dire che non sono adatti ai binari non è proprio vero se i binari inseriti tornano fuori non controllati. Il modo in cui un VCS gestisce i binari internamente dipende interamente dal fatto che i suoi autori abbiano pensato che tentare di memorizzare solo le differenze valesse la pena. Personalmente, penso che archiviare copie complete di una distribuzione ccRTP a 600K un pop sia più che compensato dalla possibilità di taggarne una versione insieme a tutte le altre mie fonti.

Questo mi ricorda il problema dei "vasetti nel repository" che Java ha avuto qualche tempo fa. Le persone che costruivano app Java erano usate per trasferire le loro dipendenze (file jar binari) nei repository. Tutti erano contenti di questo, perché avremmo il sistema di build "one click" e lo spazio su disco è economico, quindi chi se ne frega. Poi è arrivato Maven e potresti sbarazzarti di tutta quella cruft binaria e con il repository solo cache locale mantengono comunque build bullet-prof. Tuttavia hai un sistema di compilazione "one click", ma il controllo del codice sorgente non deve mescolare i file binari che non hanno senso lì.

Quindi sì, puoi estrarre i file binari dal controllo del codice sorgente, ma ciò richiederà di modificare il sistema di generazione, per ottenerli al momento della creazione. Senza software dedicato (come Maven) questo potrebbe essere un grande sforzo per farli uscire.

Il controllo del codice sorgente mantiene le risorse su ciò che fai. Se un determinato BLOB binario può essere ricostruito dalle origini, non è un'origine e non deve essere inserito nel repository del codice sorgente. Solo i BLOB non ricreabili devono essere nel controllo del codice sorgente.

Di solito si dispone di un'altra cartella di rete del repository di BLOB binari creata nel tempo delle origini. Questi possono essere distribuiti ai clienti o utilizzati nei progetti (invece di creare ogni volta tutto da zero).

Quindi, inseriscilo se è una fonte. Altrimenti no.

L'obiettivo è quello di essere in grado di ottenere il codice più recente e crearlo senza dover installare / configurare nulla (quindi, una build "single click").

In molti posti in cui sono stato, ciò significa fare il check-in nei binari delle dipendenze. In altri, ciò significa che gli script di build scaricano e ottengono automaticamente le dipendenze.

Vedi questo post sul blog di Derek Greer sull'argomento.

Sto lavorando a un progetto con due diverse fasi di costruzione

• la "build del programma principale" richiede solo pochi file binari, rispetto alle migliaia di file di testo del codice sorgente, quindi i file binari vengono registrati nel repository. Funziona benissimo.

• la build del programma di installazione richiede molti componenti di terze parti (alcuni di essi vengono semplicemente copiati sul CD di installazione, come Adobe Reader). Non li stiamo inserendo nel repository. Invece, quei componenti risiedono su un'unità di rete (anche versioni precedenti di essi) e gli script di build li copiano nel posto giusto. Naturalmente, per avere build riproducibili, chiunque deve fare attenzione a non modificare alcuna cartella in cui sono memorizzati i componenti di terze parti.

Entrambe le strategie funzionano bene e soddisfano il requisito "checkout dal controllo del codice sorgente include tutto il necessario per compilare il codice".

Devi conservare tutto ciò che ti servirà per ricostruire versioni specifiche del prodotto in futuro.

Tuttavia non devi tenere tutto nel controllo del codice sorgente.

Una società ha conservato un rack di server bloccato (poiché il sistema operativo era in esecuzione solo su quell'hardware specifico e la toolchain funzionava solo su quel sistema operativo e l'origine dipendeva da quella toolchain). Non è possibile verificarlo nel controllo del codice sorgente.

Se è necessario suddividere i requisiti per un build, si ha il problema contabile di mantenere sincronizzati due sistemi di controllo della versione. ad es. la scatola hardware in questo armadio, o la VM o i binari in questo volume di backup conservato, vanno con questa revisione del codice sorgente SVN, ecc. Questo è più complicato che usare un sistema di controllo a sorgente singola, ma risolvibile.

Nella mia mente è molto caos fare il check-in binario su SCM. Avevo condotto un progetto molto complesso, che ha molte dipendenze dalle librerie di terze parti. I principi che abbiamo adottato:

1. Tutto il codice sorgente è gestito con SCM
2. Tutte le dipendenze sono gestite con Ivy, che ha una grande integrazione con l'eclissi.

Funziona abbastanza bene. Abbiamo un file di configurazione sulla versione di ogni libreria esterna con cui è possibile compilare il codice sorgente. Questo file di configurazione viene archiviato in SCM, quindi si evolve con l'evoluzione del codice sorgente. Applicando questo approccio, possiamo esattamente riprodurre una build senza fare confusione con la versione di librerie esterne.

Personalmente, filosoficamente, sono propenso a consentire al controllo del codice sorgente di controllare i puntatori ai file binari di grandi dimensioni (le risorse binarie di piccole dimensioni sono OK) e non il contenuto del file. Questo puntatore conterrebbe un hash del contenuto del file binario.

Il file binario stesso non sarebbe gestito dal controllo del codice sorgente. Sarebbe archiviato in una specie di libreria dove può essere recuperato usando il puntatore o l'hash in particolare.

Git LFS e git annex lo fanno, ma cercano anche di gestire i file binari in una certa misura, non voglio che lo facciano. Voglio che Git memorizzi solo i checksum e mi dica se i miei file binari sono cambiati o meno, ma non voglio che tenti di gestirli e archiviarli. Voglio farlo da solo.

Penso che git sia in grado di gestire file binari di piccole e medie dimensioni, ma non sono sicuro che sia lo strumento giusto per gestire file binari di grandi dimensioni.