Ieri, girovagando come al solito tra le discussioni in cerca di idee, ho trovato un post interessante che parlava di come e quando aggiornare un’app Laravel. Mi ha sorpreso molto trovare pareri di ogni tipo:
- “no, ma figurati, non aggiornare se non è strettamente necessario”
- “aggiorna sempre!”
- “io aggiorno solo ad ogni LTS”
… e così via.
Mi sono ricordato che ultimamente ho avuto un’esperienza ravvicinata del terzo tipo con un aggiornamento abbastanza “importante” di un’app Laravel.
Ho pensato di scrivere questo articolo per “riassumere” un po’ questa esperienza, nella speranza che possa essere utile anche ad altri.
Ma è davvero così importante aggiornare?
Partiamo dal fugare il dubbio per quei pochi rimasti: sì, lo è. E non vorrei passasse il semplice concetto del “è importante perché è una buona pratica”.
Semmai, aggiornare un’app Laravel è quasi sempre una buona pratica perché:
- ci mette a disposizione strumenti ulteriori per facilitarci il lavoro. Laravel è uno di quei framework che fornisce una marea di strumenti diversi. Più andiamo avanti e più il suo ecosistema ha una scelta per qualsiasi cosa. Aggiornare significa avere più strumenti a disposizione, pensiamoci;
- l’aggiornamento risolve bug. Il team è abbastanza attivo su questo fronte e vengono corretti un sacco di bug. Probabilmente è la motivazione più scontata, statisticamente è la cosa meno impattante, ma fidatevi che arriva sempre quel momento in cui ti ritrovi alle undici di sera a bestemmiare e alle due di notte “ah ecco, era ‘sto bug segnalato tra le issue risolto nella versione dopo”;
Per il resto, diciamo che tutte le altre considerazioni che si possono fare sono sicuramente meno pragmatiche o comunque, alla fine della fiera, tornano a collegarsi a questi due punti.
Insomma, la risposta è…
Ok, quindi conviene aggiornare sempre? Come faccio?
Qui iniziano ad entrare in gioco vari fattori, che secondo me dobbiamo affrontare uscendo un po’ dalla mentalità “pura” dello sviluppatore.
Primo Fattore: Il Cliente
Ragionare sul cliente e sul rapporto che ho con lui/lei è la prima cosa faccio. Chi ho davanti? Che conoscenze ha? Che rapporto ci ho costruito? Voglio/posso seguirlo per tanto o poco tempo?
Non è questione di essere egoisti: ci sono clienti diversi con esigenze diverse. Di conseguenza, ci sono soluzioni diverse per clienti diversi. Per quanto riguarda questo fattore, cerco sempre di seguire questa regola:
- se voglio/posso seguire il cliente a medio/lungo termine, mi preparo un piano di manutenzione dell’app nel tempo. Può essere un pacchetto di ore o una serie di interventi mirati ad obiettivo. Dipende dall’esigenza e dal progetto. In questa manutenzione ci faccio rientrare anche eventuali aggiornamenti. Piccoli e costanti, così l’effort è minore e spalmato nel tempo;
- se voglio/posso seguire il cliente a breve termine, quello che faccio è includere nel contratto un periodo di tempo sul quale darò assistenza sui bug. Può essere un mese, può essere tre mesi. Occhio, PARLO DEI BUG. Il resto viene quotato a parte, eventuali aggiornamenti inclusi;
Ci sono anche dei clienti a cui tutto questo non interessa, non hanno voglia di parlare di manutenzione, di canone e così via. Non intestarditevi nel cercare di far trovare loro la retta via. A loro non interessa, non è una loro esigenza, la colpa è vostra se vi ci impuntate invece di cercare clienti compatibili con il vostro modo di lavorare.
Secondo Fattore: Il Progetto
Se aggiornare è una buona pratica per i motivi di cui ho parlato sopra, non è detto che sia sempre un qualcosa di fattibile o, paradossalmente, desiderabile.
Dopo aver valutato il cliente che ho davanti, infatti, valuto la natura ed il contesto del progetto. Alla fine, è un dato di fatto: esistono applicazioni più critiche e delicate di altre.
Mi è capitato di lavorare ad app che sarebbero rimaste in una rete interna aziendale, usata da dieci persone, e mi è capitato di lavorare ad app molto più “diffuse” e sicuramente più suscettibili ad alcune problematiche. D’altronde, un bug esce fuori anche in base al contesto in cui opera l’app.
Esempio pratico: supponiamo che il sistema di notifiche di Laravel abbia un bug nella 7.1. Nella 7.2, il problema è stato risolto.
- ho un’app 7.1 che fa uso di notifiche? Ho un problema;
- ho un’app 7.1 che non fa uso di notifiche? Non ho necessariamente un problema;
Quindi, insomma?
Il mio consiglio: quando possibile, anche a costo di programmare del tempo dedicato ogni x giorni / mesi (non arriviamo agli anni, magari), è sempre meglio aggiornare.
I package! Qualcuno pensi ai package!
Qualche mese fa ho aggiornato all’ultima versione di Laravel un’app a cui ho lavorato nell’ultimo anno e mezzo. Giuro che è stato un autentico bagno di sangue.
Perché? Beh, ecco cosa è successo.
L’app a cui ho lavorato è un’app Shopify, si chiama “Ahia! Easy Price Changer“. L’ho scritta in Laravel e la primissima versione era scritta in Laravel 5.8. Tra i vari package che ho usato, uno di questi ha visto un totale refactoring nel corso del tempo.
Qualche mese fa mi sono messo al lavoro per portare quest’app da free a pagamento. Prima cosa da fare: aggiornare framework e package. MAI andare con la versione a pagamento con software obsoleto il giorno uno.
Inizio il lavoro e… BOOM! Rimandando gli aggiornamenti per concentrarmi sul solo aspetto business & feature, mi sono ritrovato con un’app praticamente impossibile da aggiornare.
Ho dovuto riscriverla da capo (per fortuna ci ho messo pochi giorni, complice anche una suite di test notevole che mi ha salvato la vita).
Se avessi aggiornato con più costanza non avrei avuto di certo un problema del genere. Lesson learned.
Confessate i vostri peccati!
Voi aggiornate spesso? Oppure avete fatto lo stesso mio errore? Spero che questo articolo possa esservi stato utile in qualche modo, fatemi sapere che ne pensate nei commenti, sono curioso di sapere come vivete voi questo annoso problema.
