Personal tools
Migrazione a Plone 4: alcuni utili tips and tricks

Manuale di sopravvivenza a una migrazione a Plone 4

Feb 12, 2013

Migrazione a Plone 4: alcuni utili tips and tricks

Devi migrare un sito a Plone 4? Hai paura di non riuscirci? Ecco una breve guida che può aiutarti a uscire (quasi) indenne da questa avventura

Con l’uscita di versioni aggiornate di un software (Plone nel nostro caso), ci si ritrova spesso a dover aggiornare le vecchie installazioni per tenerle al passo con le ultime versioni rilasciate e godere delle migliorie apportate e delle nuove funzionalità.

Negli ultimi mesi, il mio lavoro è stato principalmente quello di “aggiornare” dei vecchi siti e migrarli da Plone 3 a Plone 4 (lo so, in ritardo di un paio d'anni).

Esistono sostanzialmente due modalità per migrare un sito Plone:

  • esportazione dei soli contenuti dal vecchio sito (per esempio con strumenti come transmogrifier) e importazione di questi in un nuovo ambiente immacolato.
  • migrazione del portale così com'è mediante il tool interno fornito da Plone stesso.

La migrazione con transmogrifier, di cui abbiamo già parlato precedentemente, in linea di massima è consigliata in quei casi in cui il vecchio portale potrebbe avere diverso “sporco” al suo interno, dovuto a svariati motivi (errori di gioventù dei programmatori, prodotti installati e mai utilizzati o mal rimossi, ecc.), oppure se si decide che parte dei contenuti attuali non servono più e si vuole portare dietro solo alcune sezioni.

Nel nostro caso avevamo degli ambienti abbastanza controllati, dove conoscevamo bene i prodotti installati (in parte sviluppati da noi e in parte trovati su pypi ma utilizzati da tempo) e il livello di sporcizia era minimo, ma soprattutto i portali dovevano essere migrati per intero.

Per questo motivo abbiamo deciso di utilizzare il tool di migrazione nativo di Plone.
L’utilizzo del tool è molto semplice, basta un click e fa tutto da solo, però il difficile è stato “preparare” i vari portali alla migrazione.
Il nostro problema era che dovevamo migrare una ventina di portali in sequenza e il rischio era di rimanere impantanati nelle varie procedure.
Dopo diverse prove e migrazioni fallite, abbiamo trovato una serie di linee guida che ci hanno aiutato a sopravvivere e che sono tornate utili anche in successive migrazioni.

sherlockAnalisi della situazione

Come prima cosa, bisogna fare un’analisi approfondita dell’utilizzo del portale, dei prodotti installati e dei contenuti creati.
In questo modo si può avere una panoramica su quanti e quali contenuti sono stati effettivamente creati, quali prodotti sono veramente utilizzati e bisogna portarsi dietro, e quali sono inutilizzati e si possono rimuovere per ottimizzare ulteriormente il portale.

Compatibilità dei prodotti su Plone 4

Dopo l’analisi preliminare, è utile testare il corretto funzionamento dei prodotti da mantenere, su un buildout Plone 4.
Per quelli di terze parti scaricati da pypi, di solito non c’è bisogno di fare molto: basta una veloce ricerca su pypi o su plone.org e il gioco è fatto. Se poi non sono compatibili, vuol dire che o sono stati superati da altri prodotti più evoluti (e forse è meglio informarsi meglio sull'eventualità di sostituirli), oppure possiamo sempre aggiornarli noi, in modo da dare un utile contributo alla comunità.
I prodotti sviluppati appositamente per i clienti, invece, vanno per forza sistemati. In generale, se non si deve fare un refactoring pesante ma solo un aggiornamento, un buon inizio è quello di controllare se presi e messi su un Plone 4 girano correttamente, ed eventualmente correggere a mano a mano gli errori che si riscontrano.
Molto probabilmente diversi template o importazioni si romperanno, perché alcune cose in Plone 4 sono cambiate; nessun problema, visto che sul sito di plone.org c'è una guida dedicata: http://plone.org/documentation/manual/upgrade-guide - in alternativa, Google o le varie mailing-list tornano sempre utili.

Rimozione dei prodotti inutilizzati

Il passo successivo consiste nella rimozione dei prodotti vecchi e/o inutilizzati.
E’ un passo importante, poiché non è consigliato portarsi dietro dei prodotti che non vengono utilizzati, o che già sappiamo non essere compatibili su Plone 4. Per questo vanno rimossi prima di effettuare una migrazione.

Promemoria: fare sempre i profili di disinstallazione!

Se un prodotto non è dotato di un profilo di disinstallazione fatto correttamente (e per esperienza posso dire che purtroppo molti sono così), potrebbe lasciare dei “residui” indesiderati nel nostro Data.fs.
Questi possono generare dei semplici warning  nel nuovo sito, come per esempio dei CSS o Javascript registrati e non più disponibili, ma nella maggior parte dei casi il problema riguarda adapter o persistent utilities che non vengono rimossi correttamente e rischiano di vanificare la migrazione.
Come per l’aggiornamento dei prodotti, se questi sono stati scaricati da pypi, una buona prassi è quella di sistemare i profili di disinstallazione dando un contributo alla comunità.
cleanDi solito le risorse che sono registrate e non vengono disinstallate correttamente sono quelle gestite con i profili di GenericSetup, come per esempio dei CSS o javascript, ma anche controlpanel e skin layers. Per avere degli esempi di come eseguire una corretta disinstallazione, basta cercare diversi prodotti nella collective (ad esempio redturtle.smartlink).
Se malauguratamente il prodotto non mette a disposizione il repository con i sorgenti (e può capitare), o sistemare il profilo di disinstallazione risulta troppo complicato, si riescono a rimuovere parecchie risorse anche manualmente.
Tutte quelle relative a GenericSetup si possono rimuovere da ZMI nei vari tool, ma i nostri nemici più agguerriti sono state le persistent-utilities, che sono persistenti ma non si riescono a visualizzare da ZMI.
Nessun problema, ci sono venute in aiuto due preziose risorse:

  • wildacard.fixpersistentutilities, un prodotto che aiuta a riconoscere e rimuovere da interfaccia utente eventuali persistent-utilities presenti nel sito
  • un'utilissima guida di Nathan Van Gheem che spiega come rimuovere manualmente adapters, utility e subscribers.

Blob Blob Blob

Su Plone 4 è diventato di default il supporto ai blob, per ovvi motivi di miglioramento delle prestazioni e di separazione di file e immagini dal Data.fs vero e proprio.
Per questo motivo, la migrazione di Plone 4 include uno step apposito che provvede in autonomia a migrare i contenuti di tipo file e immagine presenti nel sito ai blob.
Se i vostri prodotti prevedono contenuti che contengono immagini o file, è buona norma dotarli del supporto ai blob (procedura spiegata in un paragrafo della guida alla migrazione precedente) e di una procedura che permetta di migrare a blob i contenuti già presenti nel sito (ovviamente post-migrazione a Plone 4). Un buon esempio è fornito da redturtle.smartlink.

E per finire... la migrazione

Arrivati a questo punto, dopo aver verificato che tutti i prodotti siano compatibili con Plone 4 e aver ripulito il nostro Data.fs, possiamo procedere alla migrazione vera e propria.
Non serve altro che copiare i nostri dati nel nuovo buildout, farlo partire e andare nella ZMI del sito da migrare: un testo avvertirà che il sito è obsoleto e va aggiornato. Seguendo il link si avrà la possibilità di eseguire la migrazione in due modi:

  • dry-run, cioè eseguendo tutti i passi della migrazione, ma non committando le modifiche alla fine: serve se si vogliono prima fare delle prove
  • migrazione vera e propria: esegue tutti i passi e, una volta terminati, committa le modifiche e le scrive nel db.

laptopOvviamente il tempo impiegato dipende da molti fattori, come per esempio la potenza della macchina, la dimensione del Data.fs e il fatto di avere già i file sui blob.
Non sempre la migrazione andrà a buon fine al primo colpo. Fortunatamente quasi sempre il traceback dei fallimenti ci dà buone informazioni su cosa è andato storto, in modo da poterlo sistemare e ritentare. Nella mia esperienza, spesso i problemi erano proprio con utility mal rimosse o classi non più trovate.

Alla fine di tutto il procedimento, quando avremo un sito aggiornato e funzionante, prima di effettuare i vari test è buona norma fare un giro nel pannello di gestione dei prodotti aggiuntivi, in modo da vedere se ci sono degli upgrade-step da lanciare per sistemare alcuni prodotti. Altra operazione importante da fare è il pack del db, perché consente di guadagnare diverso spazio, visto lo spostamento all’esterno di file e immagini.

Conclusioni

In conclusione, se si prepara per bene il db da migrare, rimuovendo correttamente tutti i componenti inutilizzati, il tool di migrazione funziona discretamente bene.

Abbiamo solo avuto alcuni problemi durante la migrazione dei blob di un sito, come riportato anche da Ross Patterson in un suo post. Dopo una lunga analisi, abbiamo notato che il poskey Error veniva lanciato durante il commit finale, ma non siamo riusciti (come l'autore) a risalire all'origine del problema. La soluzione è stata quella di effettuare dei commit intermedi alla fine della migrazione dei file e alla fine delle immagini, anziché alla fine di tutta la procedura.

Seguendo questa sorta di check-list, siamo riusciti a migrare abbastanza agilmente una ventina di siti, e l'abbiamo riutilizzata anche per successivi lavori.

Filed under: , ,
comments powered by Disqus