Come mantenere aggiornate le librerie di terze parti?


28

Diciamo che ho un progetto che dipende da 10 librerie, e nel bagagliaio del mio progetto sono libero di usare qualsiasi versione di quelle librerie. Quindi inizio con le versioni più recenti. Quindi, ognuna di quelle librerie riceve un aggiornamento una volta al mese (in media). Ora, mantenere il mio baule completamente aggiornato richiederebbe l'aggiornamento di un riferimento alla libreria ogni tre giorni.

Questo è ovviamente troppo. Anche se di solito la versione 1.2.3 è un sostituto drop-in per la versione 1.2.2, non si può mai sapere senza test. I test unitari non sono sufficienti; se si tratta di un motore DB / file, è necessario assicurarsi che funzioni correttamente con i file creati con versioni precedenti e forse viceversa. Se ha qualcosa a che fare con la GUI, devi ispezionare visivamente tutto. E così via.

come fai a gestirlo? Alcuni possibili approcci:

  • Se non è rotto, non aggiustarlo . Resta con la tua versione attuale della libreria fintanto che non noti nulla di sbagliato quando viene utilizzato nella tua applicazione, indipendentemente dalla frequenza con cui il fornitore della libreria pubblica gli aggiornamenti. Piccoli cambiamenti incrementali sono solo uno spreco.
  • Aggiorna frequentemente per mantenere piccole le modifiche. Dato che dovresti aggiornare un giorno in ogni caso, è meglio aggiornarlo spesso in modo da notare presto eventuali problemi quando sono facili da risolvere, invece di saltare su diverse versioni e lasciare accumulare potenziali problemi.
  • Qualcosa nel mezzo. C'è un punto debole?

1
+1: Mi chiedo se come "caccia ai bug", potresti avere un'iterazione di "Update Sprint" in un progetto. Curioso di risposte :)
Matthieu il

Risposte:


25

Sono scioccato - e davvero sconvolto - dal numero di risposte qui che dice "non aggiornare a meno che non sia necessario". L'ho fatto, e mentre è più facile a breve termine, brucia come l'inferno a lungo termine. Aggiornamenti più frequenti e più piccoli sono molto, molto più facili da gestire rispetto a quelli occasionali, e ottieni il vantaggio di nuove funzionalità, correzioni di bug e così via.

Non compro questa idea secondo cui le modifiche alla libreria sono in qualche modo più difficili da testare rispetto alle modifiche al codice. È lo stesso: stai apportando una modifica alla base di codice e devi convalidarla prima di eseguire il commit e più approfonditamente prima di rilasciare. Ma devi già disporre di processi per farlo, poiché stai apportando modifiche al codice!

Se stai lavorando in iterazioni, della durata di due o quattro settimane, suggerirei di aggiornare le librerie una volta per attività di iterazione, da eseguire il prima possibile dopo l'inizio, quando le cose sono un po 'più rilassate rispetto a poco prima di un'iterazione scadenza e il progetto ha una maggiore capacità di assorbire il cambiamento. Chiedi a qualcuno (o a una coppia se fai la programmazione di coppia) di sedersi, guarda quali librerie sono state aggiornate e prova a coinvolgerle tutte ed eseguire una ricostruzione e un test. Budget da mezza giornata a un giorno per ogni iterazione, forse. Se le cose funzionano, controlla le modifiche (presumo che tu mantenga le librerie nel controllo del codice sorgente, come facciamo noi; non sono sicuro di come propagheresti le modifiche in modo controllato se no). Questo sarà ovviamente molto più semplice se si dispone di test automatici che se il test è interamente manuale.

Ora, la domanda è cosa fai se un aggiornamento rompe le cose: passi il tempo a ripararlo o lo lasci fuori? Suggerirei di sporgermi verso quest'ultimo; se può essere risolto in un'ora, fallo, ma se un aggiornamento richiederà un lavoro significativo da integrare, quindi sollevalo come compito di sviluppo, da stimare, stabilire le priorità e pianificare come un altro. È probabile che, a meno che non apporti qualche correzione o miglioramento cruciale, la priorità sarà bassa e non ci si potrà mai aggirare. Ma non si sa mai, al momento che il prossimo giorno di aggiornamento ripetutamente scorre, il problema potrebbe essersi risolto da solo; anche se no, almeno ora sai che c'è un blocco sul percorso di aggiornamento e non ti sorprenderà.

Se non stai eseguendo iterazioni di tale lunghezza, imposterei una sorta di programma autonomo per gli aggiornamenti - non più di un mese. C'è qualche altro ritmo di progetto a cui potresti legarlo, come una revisione mensile dello stato o una riunione del consiglio di architettura? Payday? Pizza Night? Luna piena? In ogni caso, devi trovare qualcosa di molto più breve di un ciclo di rilascio tradizionale, perché cercare di aggiornare tutto in una volta ogni 6-18 mesi sarà doloroso e demoralizzante.

Inutile dire che se si eseguono rami di stabilizzazione prima delle versioni, non si applica questa politica a loro. Lì, aggiorneresti solo le librerie per ottenere correzioni critiche.


3
+1. Ho lavorato a un progetto in cui gli sviluppatori hanno applicato la politica "se non è rotto non aggiustarlo". Quindi abbiamo riscontrato un problema con una libreria di terze parti (relativamente minore ma era necessario per una nuova funzionalità), che è stato risolto solo in una versione molto successiva, che a sua volta dipendeva da una jvm molto successiva. Con il jvm successivo, abbiamo riscontrato problemi con altre librerie di terze parti, che ora dovevano essere aggiornati a turno. Abbiamo anche dovuto aggiornare il nostro hardware, poiché Oracle non ha più un jvm a 32 bit per Solaris. Era un disastro e avrebbe potuto essere facilmente evitato semplicemente mantenendo le cose aggiornate.
firtydank,

+1 per "mentre è più facile a breve termine, brucia come l'inferno a lungo termine". Ho sperimentato entrambi gli approcci e mentre molti piccoli aggiornamenti possono sembrare fastidiosi, non eseguire aggiornamenti e quindi dover aggiornare 10 librerie da versioni che hanno 2 anni spesso non è possibile in un ragionevole lasso di tempo. Si finisce con un sistema che dipende da librerie obsolete e non mantenute, non è possibile utilizzare alcune altre librerie poiché richiedono una versione più recente di quella libreria che non è possibile aggiornare e ad un certo punto si perde la possibilità di risolvere alcuni problemi tutti.
Michał Kosmulski,

@firtydank Sono curioso di sapere cosa avete fatto voi ragazzi per risolvere questo fatto, avete implementato nuove politiche? Qual è stato il cambiamento funzionale nell'organizzazione?
buddyp450,

10

Lo valuto.

  • Innanzitutto cerco i bug che abbiamo sollevato contro quella libreria e vedo se sono stati corretti.
  • In secondo luogo cerco qualsiasi altra correzione di bug nella libreria di cui potremmo beneficiare (forse qualcosa che è un possibile caso d'angolo).
  • In terzo luogo, cerco miglioramenti nella lib / API e quindi studio l'impatto della modifica del nostro codice per utilizzarlo e il giusto compromesso. In passato ho aggiornato troppo spesso le librerie senza utilizzare le loro nuove funzionalità, davvero sciocco!

Quindi soppesare tutto ciò contro il rimanere con la lib esistente.

Test sempre : speriamo che i test unitari / di integrazione assicurino che non si verifichino regressioni importanti.


7

Il problema principale con le librerie di terze parti è che devi ripetere il test della TUA applicazione quando le aggiorni, prima che possa andare in produzione. Quindi, a meno che tu non abbia un bug segnalato, che richiede l'aggiornamento di una libreria, non li tocchi fino a quando non hai il tempo di fare un ciclo completo di garanzia della qualità.

Questo di solito viene fatto quando si rilascia una nuova versione.

Tuttavia, suggerirei di disporre di una suite di test per la generazione continua che consenta di aggiornare le librerie nel ramo di sviluppo e di farlo automaticamente. Questo ti assicurerà di scoprire presto quando si rompe, quindi puoi presentare segnalazioni di bug al progetto.


3

Parzialmente, come descritto nelle filiali del fornitore svn . La procedura qui descritta è molto utile, quando continui a utilizzare librerie di terze parti open source per lungo tempo e hai apportato modifiche per adattarle alle tue esigenze.


2
Per favore, non rilasciare i collegamenti. I collegamenti tendono a svanire. Si prega di considerare almeno di riassumere a cosa si sta collegando. Se quel collegamento si interrompesse, quanto sarebbe utile ... forse tra qualche anno?
Tim Post

E votato in alto :)
Tim Post

2

Penserei di aggiornare tutte le librerie di un progetto subito prima o subito dopo un rilascio. Questo, tuttavia, potrebbe sfuggire di mano se si fa affidamento su più di 10 o 15 librerie, nel qual caso una sorta di meccanismo di controllo degli aggiornamenti sarebbe di grande aiuto. Il vantaggio di questo è che hai un tempo dedicato a testare le tue librerie e puoi risolvere qualsiasi problema in un solo passaggio. Inoltre, non è necessario tenere costantemente traccia degli aggiornamenti da ogni singola libreria, è sufficiente controllare un determinato giorno per eventuali aggiornamenti.

Vorrei anche andare contro qualsiasi tipo di funzione di aggiornamento automatico anche in un ramo di sviluppo. Sarebbe frustrante se nel mezzo di me stessi lavorando a qualcosa il progetto si è rotto perché una libreria si è auto-aggiornata, o all'improvviso ho ricevuto avvisi di ammortamento per l'utilizzo di un'API che è stata sostituita da qualcos'altro.


2

Devi chiedere, cosa vuoi davvero dall'aggiornamento? La maggior parte delle correzioni di sicurezza sono in realtà banali banali, sotto forma di correzione:

  • Off da uno errori in cui il codice arbitrario può essere copiato in uno spazio inutilizzato in un buffer
  • Puntatori ciondolanti o qualcos'altro che innesca comportamenti indefiniti ma (piuttosto) deterministici
  • Bug che consentono una sorta di DoS
  • Bug che rendono accidentalmente ficcanaso i dati privati
  • Errori matematici
  • I manutentori toccano cose che non dovrebbero (bug SSL Debian, nessuno?)

Se osservi la maggior parte dei CVE negli ultimi cinque anni, le patch che li risolvono sono in genere piuttosto banali, se stai usando librerie aperte, che spero tu stia facendo.

Quindi hai correzioni di bug reali, che probabilmente vuoi, ma forse l'hai già risolto da solo. Se non è rotto, non ripararlo.

Infine, hai nuove funzionalità .. e forse funzionalità obsolete. È necessario esaminare attentamente le note sulla versione e le differenze. Puoi usarli, anche se rompono un'API da cui dipendono molte altre cose? Se sì, è tempo di un intervento chirurgico .. in caso contrario, scegli quello che vuoi e vai avanti.

Alcuni potrebbero non essere d'accordo con me, ma mi rifiuto di utilizzare una libreria senza codice sorgente.


Sicuramente preferisco le librerie open source, ma utilizzo anche alcune librerie commerciali che costano $ 100 senza sorgente o $ 10k con fonte, quindi ...
Joonas Pulakka,

2

Varia a seconda di cose come le librerie, a cosa servono, quanto sono pervasive nel tuo codice, il costo (in termini di tempo e denaro) di eseguire l'aggiornamento e così via.

Idealmente, avresti sempre le ultime novità per tutto il tempo, ma se la nuova versione non è compatibile con le versioni precedenti, cosa succede? Potrebbe essere necessario archiviare tale aggiornamento per una versione futura fino a quando non è possibile gestire attentamente la modifica. Potrebbero esserci alcuni lievi cambiamenti nel comportamento (come "ora è necessario impostare la proprietà X prima di chiamare il metodo Y o si ottiene una perdita di memoria lenta") che è difficile da verificare nei test.

D'altra parte, la nuova versione potrebbe avere alcune serie correzioni di sicurezza, quindi è necessario tenerne conto anche.

Versione breve: prendilo caso per caso.


1

Ciò dipenderebbe dalle vostre schede di rilascio.

Ma il mio consiglio sarebbe di installare un set di librerie su tutte le macchine degli sviluppatori. Consideralo un gold standard se desideri chiamarlo qualcosa, quindi inizia lo sviluppo per quella versione.

Solo una volta che il rilascio è stato distribuito e si è in fase di post rilascio, riesaminare le librerie, le loro versioni e funzionalità. Se offrono alcuni miglioramenti significativi o nuove funzionalità, installare quindi prima dell'inizio del successivo ciclo di sviluppo.

Installa le nuove versioni solo se c'è un grosso problema o bug che deve essere risolto prima di distribuire il software.

Significa che ti mancheranno alcune versioni, ma dovrebbe salvare alcuni mal di testa e problemi di versione che ti permetteranno di concentrarti sullo sviluppo della tua applicazione.


1

Subversion Externals

La cosa fantastica di questa funzione è che puoi specificare la revisione che desideri.

Si noti che gli aggiornamenti saranno più lenti se si dispone di molti esterni.


In realtà li sto usando e sono molto utili e molto lenti X-) Ma non risolvono il problema di quando dovrei aggiornare alla versione più recente.
Joonas Pulakka,

Possono essere molto lenti sì. Di solito aggiorno librerie esterne quando: (è disponibile una versione principale O una correzione di bug che mi riguarda) E sono nella prima metà dell'iterazione.

1

Attualmente sto configurando qualcosa del genere:

  • 1 repository mercuriale per ogni estensione della mia domanda
  • un repository mercuriale che raccoglie versioni specifiche di diverse librerie di terze parti
  • un repository SVN per risorse / opere grafiche (ma potrebbe cambiare in qualcos'altro)
  • un repository mercuriale per la mia applicazione, che utilizza la funzione di repository mercuriale per utilizzare la versione specifica del 3 ° repository pary e alcune delle estensioni di base

Ora, quando ho bisogno di lavorare su un'estensione che non è "di base" (implicitamente inclusa come sottorepo nel repository dell'applicazione), ottengo semplicemente clonare il repository nella cartella delle estensioni e lasciare che CMake generi i progetti e le soluzioni per l'intera applicazione.

In questo modo, posso:

  • cambiare le terze parti in un clone, verificare che funzioni con l'app, inviarle nel repository di terze parti, quindi aggiornare la versione del sottorepo del repository dell'applicazione alla nuova versione del repository di terze parti
  • lavorare su estensioni in modo indipendente, tutti insieme o semplicemente sceglierne uno specifico
  • non devi preoccuparti di dover collegare insieme i progetti, questo è fatto da Cmake semplicemente facendo scansionare i sottosposi dei progetti con l'intero repository dell'applicazione.

Non ho ancora molta esperienza con questa organizzazione, ma penso che sia abbastanza utile.


1

Se il tuo software è critico per la sicurezza, devi aggiornarlo il prima possibile, senza scuse. Non vuoi un piccolo bug in una libreria grafica per rendere vulnerabile l'intero programma.

Altrimenti, quando la libreria è matura, è "Se non è rotto, non aggiustarlo". per me. Prima o poi, potrei aver bisogno di una funzionalità di una versione successiva e non ho altra scelta che aggiornare, ma fino ad allora, lo sforzo è difficile da giustificare. D'altra parte, quando lavoro con una lib o un framework relativamente nuovi, come Grails o ExtJS, rimango aggiornato con l'ultima versione perché questi prodotti non sembrano ancora completamente maturi, quindi è probabile che l'aggiornamento mi salvi dall'incontro con uno di questi bug la versione successiva è stata corretta.


1

Uso NuGet per mantenere aggiornate le mie librerie di terze parti.

Quando un amico, un collega o un blog mi avvisa che una delle mie DLL di terze parti non è aggiornata, NuGet rende molto semplice aggiornarlo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.