Controllo della versione su librerie standalone (interne)?

Vorrei mantenere ciascuna libreria nel proprio repository. Inizia a tenere traccia delle versioni della libreria, ad esempio con git tag .

Un grosso problema con il semplice controllo di ogni libreria nel repository di ciascuna applicazione, è che in pratica hai fatto il copia e incolla, e quindi ottieni tutti gli svantaggi che ciò comporta. I bug corretti nella copia della libreria in una sola applicazione non necessariamente si adattano alle copie in altre applicazioni.

Avendo un posto in cui la biblioteca può ufficialmente vivere, puoi facilmente assicurarti che tutte le tue applicazioni possano trarre vantaggio dalle correzioni di bug e dalle nuove funzionalità.

Per gestire il modo in cui ogni applicazione ottiene una copia per scopi di costruzione effettivi, consiglierei qualcosa di simile a ciò che fa il gestore di pacchetti Cargo. Includere un file di configurazione (xml, json, toml, ecc.) Nel repository di ciascuna applicazione. In quel file di configurazione, specifica di quali librerie ha bisogno e quali versioni di quelle librerie richiede. Potresti anche voler specificare le posizioni di tali librerie.

Quindi, lo sviluppatore o, preferibilmente, un gestore di pacchetti, può leggere il file e clonare le librerie appropriate, estrarre il tag corretto e crearli. Potresti clonarli in una sottodirectory .gitignore d dell'applicazione. Una directory di libreria dedicata può essere migliore, in quanto più applicazioni che utilizzano la stessa versione della stessa libreria possono condividere una copia.

Ci sono due approcci di base che puoi adottare.

1. Mantiene le versioni sulle librerie. Monitora attentamente le dipendenze. alla fine sperimenterai l'inferno di dipendenza.
2. Mantieni sempre aggiornate tutte le librerie. vorrà bisogno di ottimi test unitari e una strategia di implementazione che fornisca un target bloccato per la produzione.

Ho lavorato in aziende che usano entrambi gli approcci. Ad esempio, Amazon tiene traccia attentamente delle dipendenze, mentre Google tiene aggiornato il mondo.

La mia opinione parziale è che il primo approccio spinge i punti di dolore, ma a lungo andare è più doloroso del secondo approccio. Se segui il secondo approccio, è fondamentale eseguire automaticamente i test unitari e raccomando vivamente un buon processo di revisione del codice. Se desideri copiare Google, puoi utilizzare link per la revisione del codice e link per un sistema di compilazione. Vedi link per avere un'idea di come questo si riduca a una grande organizzazione.

Ti suggerisco di sviluppare le tue librerie di supporto interne con lo stesso rigore che applicheresti se dovessi pubblicare queste librerie pubblicamente. Cioè, sviluppa ogni libreria come un progetto autonomo con il proprio repository, il tracker dei problemi, la documentazione, il packaging, il sistema di compilazione, i test, il controllo delle versioni e il programma di rilascio. Se sei l'unico utente della libreria, hai un po 'più libertà quando cambi le cose, ma le API stabili di alta qualità sono comunque preziose.

I progetti applicativi che consumano quelle librerie possono quindi inserirli proprio come qualsiasi altra libreria di terze parti. Il meccanismo con cui funziona dipenderà normalmente dalla tecnologia. Per una libreria scritta in C o un altro linguaggio compilato in modo nativo, si fornisce un archivio che può essere decompresso, configurato, compilato e installato. Un piccolo script che fa questo automaticamente tornerà utile. Altre tecnologie potrebbero avere il proprio modo di soddisfare le dipendenze e creare strumenti che potrebbero supportare il recupero automatico. (Come Maven fa per Java.) In ogni caso, si avrà un server FTP o altra risorsa internamente condivisa in cui i sistemi di compilazione possono recuperare le dipendenze di cui hanno bisogno. Ogni volta che ti senti pronto per "rilasciare" una nuova versione di una libreria, creane un archivio di distribuzione e caricala su questo server. (Sotto un nome univoco, quindi le vecchie versioni sono ancora disponibili.)

Se le tue applicazioni utilizzano sempre la versione più recente della libreria o lo switch meno spesso può essere deciso in base alle singole applicazioni. Probabilmente sarà una buona idea "rilasciare" presto e spesso e fare in modo che le applicazioni adottino nuove versioni il prima possibile, ma se la tua data di scadenza e una biblioteca dovessero introdurre cambiamenti improvvisi, potresti essere felice di non dover aggiornare adesso .

A proposito, hai considerato di rendere pubbliche le tue librerie interne rilasciandole come software libero? In genere viene segnalato che questo aiuta a migliorare la qualità del codice e potresti trovare altre persone che hanno gli stessi bisogni e iniziare a collaborare con te.