Quando devono essere aggiornate le dipendenze?

Abbiamo avuto due grandi crisi legate alla dipendenza con due diverse basi di codice (Android e un'app Web Node.js). Il repository Android doveva migrare da Flurry a Firebase, il che richiedeva l'aggiornamento della libreria di Google Play Services quattro versioni principali. Una cosa simile è accaduta con la nostra app Node ospitata da Heroku in cui il nostro stack di produzione (cedro) era obsoleto e doveva essere aggiornato a cedar-14. Anche il nostro database PostgreSQL doveva essere aggiornato dalla 9.2 alla 9.6.

Ciascuna delle dipendenze di queste app è rimasta stantia per quasi due anni e quando alcune sono state deprecate e abbiamo raggiunto il periodo di "tramonto", è stato un grosso mal di testa aggiornarle o sostituirle. Ho trascorso più di 30 ore nell'ultimo mese o due a risolvere lentamente tutti i conflitti e il codice non funzionante.

Ovviamente lasciar stare le cose per due anni è troppo lungo. La tecnologia si muove rapidamente, soprattutto quando si utilizza un fornitore di piattaforme come Heroku. Supponiamo di avere una suite di test a tutti gli effetti e un processo CI come Travis CI, che elimina gran parte delle congetture dall'aggiornamento. Ad esempio, se una funzione è stata rimossa dopo un aggiornamento e la stavi usando, i tuoi test fallirebbero.

Con quale frequenza devono essere aggiornate le dipendenze o quando devono essere aggiornate le dipendenze? Abbiamo aggiornato perché siamo stati costretti a farlo, ma sembra che una sorta di approccio preventivo sarebbe migliore. Dovremmo aggiornare quando vengono rilasciate versioni secondarie? Versioni principali? Ogni mese se sono disponibili aggiornamenti? Voglio evitare una situazione come quella che ho appena vissuto a tutti i costi.

PS: per uno dei miei progetti personali di Rails, utilizzo un servizio chiamato Gemnasium che tiene traccia delle tue dipendenze in modo da poter essere informato, ad esempio, delle vulnerabilità di sicurezza. È un ottimo servizio, ma dovremmo controllare manualmente le dipendenze per i progetti che ho citato.

In genere, è necessario aggiornare le dipendenze quando:

1. È richiesto
2. C'è un vantaggio nel farlo
3. Non farlo è svantaggioso

(Questi non si escludono a vicenda.)

La motivazione 1 ("quando devi") è il driver più urgente. Alcuni componenti o piattaforme da cui dipendi (ad es. Heroku) lo richiedono e devi metterti in riga. Gli aggiornamenti richiesti spesso escono da altre scelte; decidi di passare alla versione PostgreSQL in questo modo. Ora devi aggiornare i tuoi driver, la tua versione ORM, ecc.

L'aggiornamento perché tu o il tuo team percepite un vantaggio nel farlo è più morbido e più opzionale. Più di un appello di giudizio: "La nuova funzionalità, abilità, prestazione, ... valgono lo sforzo e la dislocazione che la porteranno dentro?" In Olden Times, c'era una forte propensione per gli aggiornamenti opzionali. Erano manuali e difficili, non c'erano buoni modi per provarli in una sandboxo ambiente virtuale, o per ripristinare l'aggiornamento se non ha funzionato, e non ci sono stati test automatici rapidi per confermare che gli aggiornamenti non avevano "sconvolto il carrello Apple". Oggi la tendenza è verso cicli di aggiornamento molto più veloci e aggressivi. I metodi agili amano provare le cose; installatori automatici, gestori di dipendenze e repository rendono il processo di installazione veloce e spesso quasi invisibile; gli ambienti virtuali e il controllo onnipresente della versione rendono semplici rami, forchette e rollback; e i test automatici ci hanno permesso di provare un aggiornamento in modo semplice e sostanziale valutare "Ha funzionato? Ha rovinato qualcosa?" Il pregiudizio si è spostato all'ingrosso, da "se non è rotto, non aggiustarlo" a "aggiorna presto, aggiorna spesso"

La motivazione 3 è la più morbida. Le storie degli utenti non si occupano di "l'impianto idraulico" e non menzionano mai "e mantengono l'infrastruttura non più di N uscite dietro quella attuale". Gli svantaggi della versione vanno alla deriva (approssimativamente, il debito tecnico associato alla caduta dietro la curva) invadono silenziosamente, quindi spesso si annunciano attraverso la rottura. "Spiacenti, l'API non è più supportata!" Anche all'interno dei team Agile può essere difficile motivare l'incrementalismo e "rimanere al passo con" la freschezza dei componenti quando non è visto come fondamentale per completare un determinato sprint o rilascio. Se nessuno sostiene gli aggiornamenti, possono rimanere incustoditi. Quella ruota non può cigolare fino a quando non è pronta a rompersi, o anche fino a quando non si è rotta.

Da un punto di vista pratico, il tuo team deve prestare maggiore attenzione al problema della deriva delle versioni. 2 anni sono troppo lunghi. Non c'è magia. È solo una questione di "pagami ora o pagami più tardi". O affronta il problema della deriva della versione in modo incrementale, oppure soffri e supera le scosse più grandi ogni pochi anni. Preferisco l'incrementalismo, perché alcune delle scosse della piattaforma sono enormi. Un'API o una piattaforma chiave da cui non lavori più può davvero rovinare la tua giornata, settimana o mese. Mi piace valutare la freschezza dei componenti almeno 1-2 volte all'anno. Puoi pianificare esplicitamente le recensioni o lasciarle essere organicamente attivate dai cicli di aggiornamento relativamente metronomici, di solito annuali dei principali componenti come Python, PostgreSQL e node.js. Se gli aggiornamenti dei componenti non attivano fortemente il tuo team, i controlli di freschezza delle versioni principali, sugli altopiani del progetto naturale, oppure possono funzionare anche tutte le versioni di k. Qualunque cosa pone attenzione alla correzione della versione deriva su una cadenza più regolare.

Le librerie devono essere aggiornate quando devono essere aggiornate. Ciò significa che se l'aggiornamento non porta alcun valore, non dovresti.

Nel tuo caso particolare, stavi migrando da un vecchio stack tecnologico a uno nuovo e per farlo eri costretto ad aggiornare le tue dipendenze. Quello stesso momento è il momento giusto per aggiornare le dipendenze.

Se avessi aggiornato le tue dipendenze nel tempo, al fine di "non avere un mal di testa ora", avresti dovuto investire molto tempo di lavoro (codifica) per nessun valore di ritorno. E quando avessi fatto l'ultimo aggiornamento (quello che stai facendo ora, ma aggiornando 1 versione principale anziché 4), probabilmente avresti ancora mal di testa da qualche parte (dopo tutto, la versione principale significa interrompere le modifiche). Quindi penso che tu sia sulla strada giusta.

Tuttavia, se trovi troppo difficile migrare e devi fare molti refactor, è probabile che il problema risieda nella tua base di codice. È abbastanza comune per i progetti Android non avere un'architettura generale in termini di struttura del codice. Un buon framework di iniezione delle dipendenze come Dagger 2 e un paio di principi di ingegneria del software come SOLID avrebbero reso più semplice cambiare l'implementazione del codice mantenendo gli stessi comportamenti / requisiti.

Inoltre, dal momento che stiamo eseguendo il refactoring, leggi un po 'di Unit Testing, poiché ciò sarebbe di grande aiuto quando esegui questo tipo di lavoro.

Se si utilizzano strumenti di gestione dei pacchetti (ad esempio npm, NuGet) e si dispone di una suite di test automatizzata completa, l'aggiornamento delle dipendenze dovrebbe essere un'attività a basso sforzo, è sufficiente aggiornare il pacchetto, eseguire la suite di test e vedere se ci sono problemi. Se ci sono quindi rollback e solleva un oggetto di lavoro per indagare e risolvere il problema.

Finché il costo dell'aggiornamento delle dipendenze è basso, vale la pena tenerlo aggiornato:

• In caso di problemi con l'aggiornamento, è necessario saperlo prima o poi nel caso in cui siano necessarie modifiche a monte.
• Lasciare gli aggiornamenti delle dipendenze all'ultimo minuto spesso significa che si stanno effettuando quegli aggiornamenti al momento della crisi (ad es. In risposta a un bug critico per la sicurezza). Mantenersi in cima alle proprie dipendenze significa avere il controllo di quando si spende tale sforzo e si possono eseguire quegli aggiornamenti in momenti in cui non si è occupati.
• Le versioni più recenti possono avere miglioramenti della produttività, ad esempio migliore documentazione, API più facile da usare, correzioni di errori (anche se è possibile anche il contrario).

Se l'aggiornamento delle dipendenze non è un minimo sforzo (ad esempio perché è necessario testare manualmente l'aggiornamento o perché ci sono problemi noti / interruzioni delle modifiche), è necessario valutare i pro ei contro rispetto alle altre attività. Le vecchie dipendenze sono una sorta di debito tecnico a basso interesse e quindi dovrebbero essere trattate di conseguenza.

Non devi rilasciare una versione in cui usi consapevolmente vecchie versioni delle tue dipendenze, a meno che quelle versioni non siano supportate alternative.

cioè se sei su V1 ed è ancora supportato, puoi comunque usare l'ultima versione di v1.

L'unica volta che dovresti essere scaduto è se:

A: Non hai rilasciato una versione da un po 'di tempo.

B: Sei stato su v1 così a lungo che non è più supportato

Gli aggiornamenti vengono rilasciati per un motivo, contengono correzioni di sicurezza che dovresti prendere in considerazione.

Se esce una nuova versione della tua dipendenza, dovresti anche rilasciare una versione

Penso che debba dipendere dalla libreria in questione in una certa misura, ma io stesso ho avuto mal di testa di dipendenza simile.

Il buon senso mi dice che una versione principale è probabilmente il momento giusto per l'aggiornamento, e una versione minore che risolve un grave difetto o include un vantaggio significativo lo sostituirà.

A volte non abbiamo il lusso di lavorare su ogni applicazione che richiede manutenzione o addirittura di non dispiegarne una mission critical, ma alla fine ti morderanno e un'oncia di prevenzione batte spesso un chilo di cura!

Le librerie devono essere aggiornate quando offre un vantaggio che il software utilizzerà per compensare il lavoro speso nella modifica.

Anche gli aggiornamenti di versioni di libreria minori possono interrompere o inserire incoerenze nelle app. Da quella prospettiva non ci sono cambiamenti minori.

Non c'è da vergognarsi nell'usare vecchie librerie. Quando è necessario il cambiamento può essere doloroso, ma fa parte del lavoro.