19 Dicembre, 2018 | Di

Come bonificare un sito web in Drupal

Bonifica di un progetto Drupal

Cosa vuol dire bonificare un sito web in Drupal

Spesso ci si trova a lavorare su progetti web già avviati o messi in produzione da altri, nei quali non sono state rispettate le best practice della programmazione e del mondo Drupal. Come possiamo fare per evitare di dover rifare tutto il lavoro da capo? Dobbiamo bonificare il sito web.

In questo articolo analizzeremo i classici problemi nei quali si può incorrere in queste situazioni, le soluzioni per risolverli e le best practices da seguire.

Versionamento e gestione degli ambienti

Tra gli errori più comuni vi è sicuramente la mancanza di strumenti di versionamento del codice. Al giorno d'oggi, soprattutto per chi sviluppa progetti in Drupal, è impensabile gestire la codebase senza mantenere traccia delle modifiche al codice. Si rischia, infatti, di incorrere in bug o regressioni che possono mandare offline il sito per svariate ore. 

Ad esempio, supponiamo di aver fatto una modifica al codice in locale, dopo una serie di test più o meno approfonditi, e di aver portato il nuovo codice in produzione.  Se questa modifica aggiunge una regressione (o un bug legato all'ambiente di produzione) che incide sul corretto funzionamento del portale, finché non riusciremo a capire dove è stato introdotto il bug, il sito non funzionerà. Con un sistema di versionamento possiamo, in pochi minuti, portare il codice presente in produzione alla versione precedente. In questo modo, possiamo continuare in locale la ricerca del bug mentre il sito in produzione continua a funzionare correttamente.   Un sistema di versionamento (come ad esempio Git) fornisce diverse possibilità:

  • Reversibilità del codice (come abbiamo già visto);
  • Sviluppo concorrente: due o più sviluppatori possono lavorare sullo stesso file per poi integrare le varie versioni;
  • Manutenzione e gestione del codice.

Versionare il codice già esistente e in produzione, è semplicissimo. Infatti, una volta installato in locale uno strumento come Git, bastano un paio di semplici comandi:

  • git init: per inizializzare il progetto;
  • git remote add origin path-del-repo;
  • git add: per aggiungere tutti i file da versionare;
  • git commit -m "first commit": per aggiungere allo stage i file da portare i file su di un repository;
  • git push origin master: per portare il codice sul repository.

Un secondo problema è quello di avere ambienti configurati in modo diverso. Nell’esempio precedente abbiamo supposto che un bug possa dipendere dall’ambiente di produzione. Ciò può essere causato dal disallineamento della versione del PHP locale con quella in produzione. Questa situazione può portare a malfunzionamenti e bug in produzione che in locale non si sono manifestati.

Per ovviare a tale problema consigliamo di utilizzare Docker come strumento per la gestione dell'ambiente locale ed eventualmente dell'ambiente di produzione.

Gestione delle configurazioni

Il terzo problema sul quale ci concentreremo è legato alle configurazioni del sito che vengono fatte in backend.

Per configurazioni fatte in backend intendiamo:

  • Creazione dei Content Type;
  • Creazione delle viste;
  • Creazione e gestione dei permessi;
  • Gestione dei blocchi.

Nella maggior parte dei siti che ci siamo ritrovati a bonificare, venivano generate tutte le configurazioni in fase di sviluppo (ambiente locale o dev), per poi essere portate in produzione mediante dump e restore del database.

Questa soluzione permette di portare in produzione configurazioni e contenuti la prima volta che viene eseguita. Il problema si crea nelle successive release dell'applicazione.

Supponiamo di dover creare un nuovo Content Type e una vista su di un sito che ormai è in produzione da diversi mesi. Di prassi lo facciamo in locale, poi per portare tutto in produzione, per evitare bug o malfunzionamenti. Di certo, in una situazione del genere, non possiamo fare un dump e restore del database: perderemmo i contenuti aggiunti in produzione. In questo caso l'unica soluzione sarebbe ripetere gli stessi step fatti in locale anche sulla produzione, oppure reinserire tutti i contenuti mancanti. Però, per portare al termine lo sviluppo, impiegheremmo il doppio del tempo.

La soluzione ideale è quella di usare il modulo Feature per Drupal 7 e la gestione delle configurazioni per Drupal 8.

In Drupal 7, bisognerà:

  1. Installare il modulo;
  2. Configurarlo creando le feature per ogni aspetto da gestire tramite backend;
  3. Versionare il modulo risultante con Git;
  4. Allineare la codebase di produzione con il nuovo modulo creato da feature;
  5. Abilitare il modulo feature e il mulo generato sul sito di produzione;

Così facendo potremo spostare le configurazioni dall'ambiente di sviluppo a quello di produzione mediante il processo di versionamento del codice.

Per Drupal 8 esiste la possibilità di esportare le configurazioni tramite drush, senza installare componenti aggiuntivi.  Le configurazioni esportate sono gestite mediante dei file .yml, quindi anch'essi gestibili mediante strumenti di versionamento.

Per Drupal 8, bisognerà:

  1. Esportare le configurazioni sull'ambiente locale mediante drush: drush cex;
  2. Versionare le configurazioni;
  3. Allineare la codebase di produzione con le configurazioni esportate;
  4. Importare le configurazioni sull'ambiente di produzione: drush cim

Gestione dei contenuti

L'ultimo annoso problema che affrontiamo è la gestione dei contenuti. Supponiamo di dover fare un restyling del sito, oppure delle modifiche strutturali che richiedono svariati giorni di lavoro. Nel nostro ambiente locale (o in sviluppo), iniziamo con il building per poi passare al codice. Nel mentre, l’ambiente di produzione va avanti con il suo normale flusso di content management. Una volta finito il lavoro, dobbiamo portarlo in produzione, ma senza perdere i contenuti. Nel caso in cui siano stati usati gli accorgimenti precedenti (versionamento del codice e gestione delle configurazioni), il problema non si pone. In caso contrario, invece, bisogna trovare un metodo per riportare tutto il nuovo lavoro in produzione o tutti i contenuti di produzione sull’ambiente locale (sviluppo). Per evitare di reinserire a mano tutti i contenuti o riprodurre tutte le configurazioni a mano sull’ambiente, possiamo utilizzare i seguenti approcci:

Per Drupal 8

Se stiamo lavorando su Drupal 8, possiamo scrivere una migrazione per spostare portare i contenuti tra i vari ambienti. Metodo sicuramente efficace, che richiede un’ottima conoscenza di Drupal e dello sviluppo custom, ma anche molto lento. Per le nuove versioni di Drupal 8, dalla versione 8.3 in poi, si può usare la suite Deploy, unita a Workspace, che ci permette di spostare i contenuti tra ambienti diversi. Metodo abbastanza veloce ed efficace. Infine, l’ultimo metodo, applicabile anche per versioni precedenti a Drupal 8.3, è l’utilizzo del modulo Default Content unito a Default Content Deploy. Questi due moduli permettono di esportare i contenuti (e le entità in generale) come file .json. Una volta versionati e spostati sull’ambiente di produzione, possono essere re-importati.

Per Drupal 7

Se stiamo lavorando su Drupal 7, possiamo utilizzare il modulo Feed Import che alla stessa stregua del modulo Migrate (per Drupal 8), permette di importare contenuti in entità (come nodi, utenti, termini di tassonomia, etc) da vari tipi di file o database. Mette a disposizione molte funzionalità, ma richiede buona dimestichezza nell’utilizzo di Drupal e nella programmazione. L’alternativa meno complicata, ma ovviamente più limitata, è l’utilizzo del modulo Node Export. Permette agli utenti di esportare i nodi e quindi importarli in un'altra installazione Drupal o sullo stesso sito (appartenente ad un altro ambiente).