La migrazione è dall'ambiente locale all'ambiente di produzione. L'ambiente di produzione ha funzionato da tempo e ha creato molti articoli.
Per aggiungere nuove cose al mio sito, ho aggiunto un tema personalizzato e installato CCK, Views e altri moduli nel mio ambiente di test locale. Ora che l'ambiente di test locale è terminato, come posso migrarlo nell'ambiente di produzione, senza distruggere il contenuto del suo database?
Risposte:
Questo è un problema non banale per cui quasi tutti hanno una risposta diversa: non esiste un modo canonico Drupal per gestire la messa in scena alle spinte di produzione. Dries Buytaert, il ragazzo che gestisce lo spettacolo Drupal, l'ha resa una delle iniziative chiave di Drupal 8 . Ovviamente, Drupal 7 è stato appena rilasciato, quindi ci vorrà un po 'prima che possa dare frutti.
Il problema può essere suddiviso in due problemi distinti:
Il primo può essere gestito principalmente dal modulo Caratteristiche , che prenderà la configurazione del tuo sito e lo trasformerà in un modulo che puoi aggiungere alla tua installazione di Drupal: in questo modo, puoi aggiungerlo al tuo sistema di controllo della versione e non devi preoccuparti di esso essere spazzato via quando migra i tuoi contenuti.
Quest'ultimo è davvero complicato, perché su un sito attivo è probabile che il contenuto cambierà durante la produzione anche dopo aver effettuato la sincronizzazione iniziale con l'ambiente di sviluppo. Ciò impedisce la sostituzione all'ingrosso dei contenuti durante la messa in scena, come è possibile fare con la configurazione.
Inoltre, Drupal non utilizza identificatori universalmente univoci (UUID) per il contenuto: ogni volta che viene aggiunto un nodo o un utente, l'ID aumenta di uno. Quindi quello che potrebbe essere il nodo 45 sul tuo sito di sviluppo potrebbe essere il nodo 90 sul tuo sito di produzione.
Sfortunatamente, non ho un'ottima soluzione per questo: la messa in scena dei contenuti è un vero punto debole di Drupal. Quello che faccio personalmente è aggiungere contenuti solo sul sito di produzione. Se un cliente vuole vedere come appare il contenuto prima della sua pubblicazione, imposterò un clone del sito di produzione accessibile solo al cliente. Quindi, una volta approvate, le stesse modifiche vengono quindi apportate direttamente alla produzione.
C'è un'altra alternativa che viene lanciata: il modulo Deploy . Dovrebbe sfruttare i Servizi per rendere i contenuti di gestione temporanea relativamente indolori. Ma non posso garantire la sua efficacia e non ha una versione di Drupal 7.
Nel nostro processo.
Stiamo usando Hudson per ricostruire i nostri rami di sviluppo / stadiazione per sincronizzare i rami live e di sviluppo.
Poiché stiamo usando Git, ogni attività che stiamo svolgendo ha un suo ramo, quindi quando passiamo al QA lo uniamo al master come nostro server di gestione temporanea per i test di regressione.
Quando master è pronto, eseguiamo una versione di prova per il nostro Release Serverche è una replica di live (configurazione, hardware, ecc.).
Usiamo il Featuremodulo per distribuire configurazioni. Alcuni elementi non sono ancora supportati dalla funzione, quindi usiamo hook_update_N quindi eseguiamo updateb.php odrush -vd updb
drush fra --yes) per ripristinare tutte le funzioni di sostituzione.Poiché stiamo usando Boost (passando a Varnish) e Memcache, dobbiamo svuotare la cache ( drush cc all).
Stiamo usando rsync per sincronizzare le nostre immagini / video ecc ...
Per migrare da un server XAMPP a un altro server, ho seguito le istruzioni su questo sito .
Assicurarsi di mantenere la stessa struttura sul server di produzione come sul server di sviluppo. Ho anche dovuto modificare alcuni file nel pannello di amministrazione di Drupal che si trova in: admin / config / media / file-system
Assicurarsi che il percorso del file system pubblico e la directory temporanea abbiano le posizioni corrette impostate.