Come gestire i principali aggiornamenti framework/dipendenza?

Question

Ricerca di alcune best practice sulla gestione di un aggiornamento delle dipendenze principali all'interno di un progetto, presupponendo l'uso di uno strumento di gestione delle dipendenze (ad esempio, Maven 2).

In particolare, mi interessa:

• Come ottenere un'applicazione ereditata up-to-date (ad esempio, 1.2.x primavera per 2.5.x)
• Quali pratiche possono essere messi in posto dopo tale revisione per mantenere le applicazioni un po 'aggiornate

Le tue esperienze o qualsiasi articolo/documento che hai trovato/trovato utile sono i benvenuti.

MODIFICA: L'aggiornamento di un numero di versione di dipendenza è banale. Sono più interessato a come affronti le modifiche che devi apportare, in base alle modifiche alla dipendenza (deprecazione, eliminazione, modifiche ai tipi nei parametri/valori di ritorno, ecc ...). E se c'è un buon modo per facilitare queste modifiche in futuro, come mantenere aggiornate le proprie dipendenze dovrebbe consentire di rimanere in cima alle modifiche e prevenire un sacco di tempo sprecato solo per ottenere funzionalità 'più sicuro x 2.1 '.

Answer 1

Nella mia esperienza, gli aggiornamenti delle dipendenze sono implementati a causa di una funzionalità necessaria di proprietà della dipendenza, come correzione di un bug nella dipendenza che interessa direttamente il proprio codice, per supportare una nuova release Java o per mantenere il proprio codice conforme a uno standard particolare (rispetto alle dipendenze che incidono sulla sicurezza). Se il tuo codice non rientra in una di queste aree di necessità, non mi preoccuperei di tenerle aggiornate, ma invece di aggiornarle solo se necessario, poiché l'aggiornamento da release a release potrebbe introdurre bug nella tua applicazione.

Ho sempre trovato che la best practice inizia con il completamento della produzione sull'applicazione per il ciclo, rilasciandolo come una build stabile e aggiornando manualmente le dipendenze nella successiva iterazione di sviluppo. La centralizzazione delle versioni nel POM padre comporterà modifiche alle versioni con una dipendenza minima e maggiore estensibilità. Supponendo che stai usando Maven:

<dependency> 
    <groupId>your.dep.group</groupId> 
    <artifactId>your-artifact-id</artifactId> 
    <version>${desiredVersion}</version> 
</dependency> 

Answer 2

Le buone pratiche per la gestione delle modifiche di dipendenza sono le stesse buone pratiche per la progettazione dell'applicazione. Si vuole stratificare la propria architettura e minimizzare l'accoppiamento diffuso del proprio codice su ciascuna dipendenza al fine di mantenere isolate le modifiche, in modo che l'aggiornamento di una dipendenza non interrompa ogni parte della propria applicazione. Codice per interfacce e mantenere la business logic separata dal codice dell'infrastruttura.

Per aggiornamenti minori (aggiornamento di release point di una dipendenza), è utile se si dispone di un set completo di test unitari per rilevare errori dovuti alle modifiche API. Questa è una delle ragioni principali per cui a volte aiuta a scrivere test banali che sembrano in superficie per funzionare sempre. Un esempio di ciò è scrivere un semplice test dell'unità JDBC per eseguire una query semplice. Questo sembra uno spreco di energie finché non si rileva un problema di runtime con il driver JDBC dopo un aggiornamento del database (è successo a me).

Per modifiche più grandi (come l'aggiornamento tra versioni incompatibili di un framework come Spring), è utile se si dispone di alcuni test funzionali o di integrazione automatizzati o almeno di una specifica funzionale che le persone QA possono eseguire per verificare il livello elevato funzionalità. I test unitari probabilmente non saranno più rilevanti se l'API del framework che si sta aggiornando è abbastanza diversa da richiedere modifiche al codice.

L'effettiva parte tattica della gestione di una migrazione da una versione di dipendenza a un'altra incompatibile dipende in realtà da ciò che si sta facendo. Una libreria matura fornirà un qualche tipo di percorso di migrazione e, si spera, non richiederà di riscrivere tutto. È una buona idea separare le modifiche al codice relative ad un aggiornamento del framework dalle modifiche relative all'implementazione di una nuova funzionalità. In questo modo se qualcosa si rompe saprai che ha a che fare con l'aggiornamento del framework e non qualcosa che hai rotto durante l'implementazione di una nuova funzionalità.

Parte di ciò che rende questo così difficile è che in fase di esecuzione è possibile avere solo una versione di una particolare dipendenza nella JVM, quindi è necessario aggiornare tutto il codice contemporaneamente. OSGi affronta questo particolare problema consentendo a diversi bundle OSGi in esecuzione nello stesso di dipendere da diverse versioni di dipendenze, quindi è possibile dipendere da diverse versioni di dipendenza in fase di runtime. Ecco come Eclipse gestisce le dipendenze per i plugin senza interrompere altri plugin.