Migrazione alla versione 5.5 di PHP

Il problema

Molti di voi dopo aver letto il titolo di questo post, probabilmente avranno detto: “Mbhe, qual’è il problema ???”. Qualche tempo fa l’avrei detto anche io. Togli la versione corrente e installi l’ultima versione… e il gioco è fatto. È vero, questa è una soluzione, la più banale e lineare, ma non sempre applicabile, soprattutto quando la migrazione non va fatta per un’unico progetto e per un’unico sviluppatore, ma per tutta un’azienda e per tutti i progetti in manutenzione, evoluzione e progettazione.

Alcune Valutazioni

Partiamo dalle motivazioni che mi spingono verso la scelta di migrare ad una nuova versione del linguaggio. In prima istanza si tratta di performance. Da alcuni test che ho potuto svolgere e da altri riscontrati in rete l’ultima versione del PHP ha delle prestazioni superiori anche fino al 40% rispetto alla precedente. Già questa potrebbe essere una motivazione più che valida per affrontare il problema. La seconda motivazione, ed è quella che gioca un ruolo portante, è la compatibilità con le librerie. Con il tempo sempre più librerie, probabilmente quelle migliori, avranno come requisito questa ultima versione di PHP. Non allinearsi potrebbe realmente significare non poter utilizzare qualcosa di già pronto. Oggi è una libreria, domani magari un framework e quello che potervi fare in due ore sei costretto a dovertelo rifare da capo, per di più, con qualità anche inferiore. Non vorrei certo fare la fine di qualche società che sta ancora su PHP4 con la quale qualsiasi tipo di integrazione è impossibile.

Bene, abbiamo stabilito che effettivamente ne vale la pena. Allora da domani passiamo su tutti i computer aziendali (sviluppatori e frontendisti) ed installiamo la 5.5. Eh già, ma tutti i progetti che non potranno migrare ? Non si può sviluppare sulla 5.5 e poi la macchina di produzione è vincolata alla 5.3 (perché la macchina non è tua e non ci puoi mettere le mani) sarebbe un tantinello rischioso. Fino a che tutti i progetti 5.3 non saranno andati nel dimenticatoio o saranno stati migrati alla 5.5 sarà necessario far passare il proprio ambiente di sviluppo da una versione all’altra.
Tirando le somme ci troviamo a dover risolvere due problemi:

  1. Switchare agilmente dalla 5.3 alla 5.5 nel proprio ambiente di sviluppo per adattarsi ai diversi progetti e viceversa
  2. Migrare i progetti possibili dalla 5.3 alla 5.5
Soluzioni

Per quanto riguarda la prima, purché attraverso l’utilizzo di homebrew ( package manager per mac ) ci semplifichi la vita (avevo scritto anche un articolo), non è un’operazione che tutti sanno portare a termine facilmente. Ovvero se per uno sviluppatore potrebbe essere una cosa banale, non è detto che lo sia anche per un frontendista. E non vogliamo assolutamente che qualcuno sbagli ambiente ed esegua un deploy di qualche funzionalità  non compatibile in produzione, vero ?
La prima soluzione è quella di creare una macchina virtuale per ogni progetto. Con l’aiuto di vagrant questa attività si semplifica notevolmente. Ovvero con un semplice file di testo, contente tutte le direttive per quel progetto, è possibile configurare una macchina virtuale. Quindi basta pushare nel repository questo file e tutti saranno in grado di replicare l’ambiente di produzione sulla propria macchina di sviluppo.
Da una parte abbiamo disaccoppiato l’ambiente di sviluppo dalla nostra macchina. Dall’altra abbiamo invece legato un determinato ambiente di sviluppo con un progetto. Diciamo che se prima avevamo un’unico ambiente di sviluppo per tanti progetti, in questo modo abbiamo tanti ambienti di sviluppo quanti sono i progetti.

Per quanto riguarda la seconda. Ok, il progetto può migrare alla vesione 5.5, ma chi ci assicura che la codebase girerà correttamente senza dare problemi? La risposta è una sola: “test automatici”. Ecco qui servito un’altro vantaggio dello sviluppare attraverso i test che a “sorpresa” ci aiutano ancora. Basterà far eseguire la suite di test di un progetto su un ambiente di sviluppo 5.5 per sapere se la compatibilità è garantita o meno e i cambiamenti necessari per raggiungerla. Ovviamente i test devono essere pre-esistenti e ben scritti. La “continuos integration” di jenkins ci fornisce il suo aiuto [ne parlavo qui]. Senza scomodare il proprio ambiente di sviluppo sarà sufficiente far switchare alla 5.5 direttamente jenkins. Eseguire tutti i job normalmente schedulati e raccogliere i risultati.
Il realtà, se necessario possiamo fare ancora meglio. Jenkins è li per tutti i progetti, quindi anche lui dovrà adattarsi alle diverse versioni, 5.3, 5.4, 5.5. Sfruttando la distribuibilità di jenkins possiamo creare delle macchine slave con delle diverse configurazioni. Praticamente ci sarà una macchina principale master che si occuperà di veicolare i task su tutte le altre macchine slave.
Basterà indirizzare un progetto su uno slave piuttosto che su un’altro per verificare la compatibilità con una specifica versione del linguaggio.

Conclusioni

Rimanere ancorati ad una versione del linguaggio a lungo andare potrebbe comportare non pochi svantaggi. Tanto vale organizzarsi per tempo e prevedere delle procedure che, tra l’altro, andranno bene anche per il futuro (rimanendo sullo stesso stack tecnologico). Abbiamo visto che attraverso l’utilizzo di due pratiche, che purtroppo non tutti hanno tra i propri strumenti , riusciamo in sicurezza a venirne fuori.

Ovviamente se siete freelance e lavorate completamente soli soletti, questo articolo, magari vi avrà fatto conoscere qualcosa di nuovo, ma alla fine vi sbrigate tutto in autonomia. Se invece come me vi dovete preoccupare di far collaborare una decina di sviluppatori ed un vasto insieme di progetti allora probabilmente questo spunto potrebbe darvi qualche idea in più.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...