Migrazione alla versione 5.5 di PHP

19 settembre 2013 Lascia un commento
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ù.

Il nostro talk al codemotion 2013: Let’s test

Anche quest’anno ho avuto il piacere di partecipare come speaker al codemotion insieme al mio collega Andrea. A dirla tutta è lui che ha spinto per proporre un talk. Era talmente tanto entusiasta di quello che ha appreso in un anno ( da quando si è trasferito in dnsee) sulla pratica del “testing automatico” che aveva voglia di condividere con quante più persone possibile… e c’è riuscito. Continua a leggere…

Categorie: eventi Tag:, , , ,

Orient inglobato in Doctrine

21 gennaio 2013 1 commento

Pochi giorni prima del 2013 il progetto orient, iniziato senza alcuna pretesa, è entrato a far parte di doctrine-project.

doctrine-project

Per chi si fosse collegato solo ora:

The Doctrine Project is the home of a selected set of PHP libraries primarily focused on providing persistence services and related functionality. Its prize projects are a Object Relational Mapper and the Database Abstraction Layer it is built on top of….

Doctrine è l’organizzazione sotto la quale sono raccolte tutte le migliori librerie (in PHP) che riguardano la persistenza dei dati. Esempi sono ORM per i database relazionali, così come gli ODM per i database documentali.

Il progetto di cui sto parlando si chiamava Orient, ora rinominato orientdb-odm. Una libreria scritta in PHP per interfacciarsi con OrientDB. Il primo commit risale ormai a circa due anni fa, quando Alessandro, ancora ignaro del grande risultato che avremmo raggiunto, cominciava a buttare giù qualche riga di codice. Non ci è voluto poi molto prima che mi tirasse dentro al progetto.

Già ancora prima di essere inglobati, avevamo avuto l’opportunità di presentare la nostra libreria in diverse conferenze come il codemotion, la poland phpconf e altre minori. Avevamo avuto più volte la sensazione che la qualità del codice scritto fosse molto alta e attendibile, ma quest’ultimo evento ce ne dà la conferma.

Ringraziamento dovuto anche al nostro terzo compagno d’avventura Daniele, portato a noi grazie a github. Non siamo riusciti ancora a vederci in faccia … ma è uno dei prossimi obiettivi :D.

Il 2012 è finito alla grande. Di cose da fare ce ne sono ancora molte. Vedremo cosa ci porterà il 2013

Categorie: GraphDB, NoSQL, php Tag:, , , , ,

Passare da php 5.3 a php 5.4 e viceversa facilmente con brew

19 agosto 2012 2 commenti

Per qualcuno questo articolo potrebbe sembrare un pochino acerbo. Che bisogno c’è di passare ora al php54? “C’è tempo…” potrebbe rispondere qualcuno. Ma prima o poi quel momento (come ogni volta) arriva prima del previsto e ci piacerebbe tanto passare alla versione successiva del linguaggio, perché quella sua caratteristica proprio ci sarebbe comoda, ma chissa cosa potrebbe succedere passando alla versione nuova. Meglio non rischiare, qualcuno dice tipicamente, rimaniamo dove siamo.
Ora, questo è lo scenario che abitualmente ci circonda, non ditemi che non vi è capitato di vedere php4 ancora su qualche applicativo un po’ datato.

L’alternativa è che se fosse “molto facile” cambiare la versione del PHP sulla propria macchina di sviluppo, allora far girare di tanto in tanto i test dell’applicativo anche su questa istanza non sarebbe così complicato, nulla di impegnativo, ma almeno si potrebbe sapere fin dall’inizio in caso di incompatibilità, di cosa si tratta e scegliere come comportarsi.

Bhe questo modo “molto facile” esiste. Io l’ho trovato sul Mac attraverso un comando di brew. Sicuramente questo comportamento esisterà anche su Linux.

Comunque tornando a noi. E necessario aver installato php53 e php54, come si farebbe con i normali pacchetti (ormai uso brew praticamente per tutto) :

brew install php53

poi

brew install php54

Ed è a questo punto che scatta la magia. Utilizzando il comando switch, brew è in grado di scambiare la versione del pacchetto scelto. È quindi sufficiente eseguire: Continua a leggere…

Categorie: php Tag:, , , , ,

Uno schermo che fa la differenza: quello di Jenkins

12 luglio 2012 Lascia un commento

Capita di portare avanti un progetto con molte persone, parliamo di 6/7 persone, che magari sono distribuite in differenti team di lavoro (frontend/backend) e che per rendere le cose più semplici ( si fa per dire ) sono anche dislocate in diversi settori dell’ufficio. In questo contesto, quando i  tempi stringono ed è necessario tenere tutto sotto controllo, è molto produttivo mettere in piedi un sistema di continuous integration (da qui in poi CI) che sia in grado di stabilire quando c’è qualcosa che non va nell’eseguire la suite di test.

Bene, non è la prima volta che parlo di CI e soprattutto non è la prima volta che la metto in pratica per un progetto delicato. Ma questa volta c’è qualcosa di diverso, qualcosa di semplice, una mossa in più (anzi, due) che cambia tutto.

Continua a leggere…

Il nostro talk al codemotion 2012: GraphDB, time for serious staff

12 aprile 2012 Lascia un commento

Seppur con estremo ritardo metto a disposizione le slide dell’interveto che abbiamo fatto il mio collega Alessandro ed io al Codemotion 2012 che si è tenuto come al solito a Roma alla facoltà di ingegneria di Roma Tre.

Continua a leggere…

EuHackaton 2011

12 novembre 2011 Lascia un commento

eu hackaton

Sono le 6 di mattina, già 12h di fila che stai davanti a quello schermo. La stanchezza si fa sentire … e ormai già da più di qualche ora. I caffè non fanno praticamente più effetto e quando sei li li per chiederti chi te l’ha fatto fare, le carte in tavola cambiano: I componenti che i vari reparti del team stanno progettando cominciano a dialogare tra di loro. Ci siamo, “funziona”, beh ci vuole ancora qualche ritocco ma “funziona”.

Ecco, quello è stato il momento in cui le cose sono cambiate: la stanchezza è passata, l’adrenalina è entrata in circolo e tutto quello che prima sembrava opaco adesso non lo è più. Anzi è tutto molto chiaro come se aveste aggiustato la messa a fuoco del vostro obiettivo. Continua a leggere…

Iscriviti

Ricevi al tuo indirizzo email tutti i nuovi post del sito.

Unisciti agli altri 831 follower

%d blogger cliccano Mi Piace per questo: