Come unire le modifiche da una copia di sviluppo del sito al sito live senza perdere nuovi contenuti?

40

Qual è la procedura migliore per unire il lavoro svolto su una copia di sviluppo di un sito con la copia di produzione live? Spesso sono stati aggiunti molti nuovi contenuti al sito da quando è iniziato lo sviluppo delle funzionalità più recenti. E la maggior parte delle aggiunte a un sito comporterà modifiche al database. Quindi copiare qualsiasi nuovo file è facile, ma per quanto riguarda il database? Come unire le modifiche al database di produzione esistente senza perdere il nuovo contenuto aggiunto dall'ultima volta che hai aggiornato il sito di produzione? Ci sono dei moduli che aiutano in questo?

database updating

— Chaulky
fonte

2

Rimuovi confusione: Unisci e migra sono due parole diverse. Hai usato entrambi nella tua domanda. Se il sito live è vuoto, è necessario migrare la copia di sviluppo sul sito / host live. Se il sito live ha già dei contenuti, è necessario unire nuovi contenuti dalla copia di sviluppo al sito live (L'unione è alquanto difficile). Che cosa devi fare?

— user931

16

Per i tipi di contenuto, le visualizzazioni e le modifiche alla struttura sul sito di sviluppo, consultare l'utilizzo delle funzionalità per esportare il database in codice.

Per la migrazione dei contenuti ci sono molte opzioni, ma non un'unica soluzione solida. Un esempio è la suite di distribuzione .

— budda
fonte

la suite Demployment sembra decisamente interessante, anche se è ancora in Dev (non ancora nemmeno una Beta). L'hai usato tu stesso? Sai qualcosa che non coprirebbe?

— Chaulky

2

Ho adottato fondamentalmente due scuole di pensiero qui (una terza scuola di pensiero, facendo differenze nel database, non discuterò perché la complessità è abbastanza alta).

1) Distribuire rilasciando il database di produzione e importando un mysqldump del database di sviluppo. Facoltativamente, esegui in anticipo un regex trova / sostituisci su tutti i collegamenti assoluti codificati che fanno riferimento all'URL di sviluppo nel dump SQL. Dopo aver importato dev db in prod, esegui automaticamente le istruzioni SQL (di solito tramite script) in seguito per modificare eventuali impostazioni diverse per prod che dev (ad esempio, forse hai nella tabella delle variabili alcune impostazioni di connessione per la connessione a sistemi esterni che devi passare a puntare a sistemi esterni prod invece che alla versione dev).

2) Utilizzare il modulo Funzionalità , come indicato da budda, per le impostazioni dell'amministratore e utilizzare il modulo Esportazione nodo per l'esportazione / importazione del contenuto in combinazione con il modulo Elimina tutto . Quindi il flusso di lavoro è:

usa node_export e caratteristiche per esportare nodi / caratteristiche in file
Opzionalmente (e si spera) controllo della versione
Carica file sul sistema prod
Usa l'interfaccia Drush o Admin per caricare le funzionalità
Utilizzare drush delete-all o l'interfaccia di amministrazione per eliminare tutti i nodi dei tipi che si desidera importare
Utilizzare drush ne-import o l'interfaccia di amministrazione per importare i nodi dal file dei nodi esportato.

Una nota, suggerirei vivamente di adottare un flusso di lavoro standard, in cui il contenuto va solo in una direzione. Dev - Dev o Prod -> Dev (preferisco questo).

L'ho fatto e lo sto facendo su alcuni grandi sistemi, con risultati abbastanza buoni, ma ci saranno sempre molti modi per tagliare questa mela, scegli il modo in cui funziona meglio per te.

— coderintherye
fonte

Nell'opzione 1, come stai ricreando il contenuto che è stato aggiunto al sito live che non si trova nel sito di sviluppo? Sembra che tu stia sovrascrivendo tutto con dev db e quindi cambiando alcune impostazioni / variabili. Inoltre, quale scuola di pensiero stai attualmente usando sui tuoi siti? Pro e contro di ogni approccio?

— Chaulky

Nell'opzione 1, ora utilizziamo node_export per inviare regolarmente il contenuto (dopo aver rimosso il contenuto precedente). Abbiamo usato per apportare modifiche ai contenuti sia su sviluppo che su prod. Questo è in realtà uno scenario comune in alcuni posti che ho visto, anche se ovviamente non è l'ideale. Questo è il motivo per cui aggiungo, adotto una direzione e mi attengo, entrambi i contenuti vanno dev -> prod o prod -> dev, ma provo a non fare entrambi. E sì, praticamente sovrascriviamo, anche se più come cancellare e ricostruire. Nel mio nuovo lavoro facciamo il n. 2, nel mio vecchio lavoro abbiamo fatto il n. 1 ma stiamo passando al n. 2 (sto ancora consultando per loro).

— coderintherye,

1

Dump dei database della copia del sito live e della copia di sviluppo del sito nel file SQL (utilizzare gli stessi parametri e impostazioni per entrambi i dump).
Quindi, confronta entrambi i file SQL utilizzando un piccolo strumento di confronto ExamDiff . Visualizzerà le differenze dei file fianco a fianco con colori diversi. Puoi anche saltare direttamente alle differenze (senza scorrere). Esamina le differenze e aggiungi / modifica le righe nel file SQL del sito live. Assicurati che non ci sia percorso / URL assoluto dell'ambiente di sviluppo in quel file. Fatto! Tempo di ripristinare il database per il sito live.
Semplifica la tua vita:Nel primo passaggio, scaricare solo le tabelle che vengono modificate. Ad esempio, se hai modificato un modulo nella copia di sviluppo che ha come target una tabella separata, scarica solo questa tabella. Se non si è sicuri di una tabella particolare, l'intero dump del database va bene.

— user931
fonte

Questa tecnica presenta gravi limitazioni in alcune circostanze importanti. Ad esempio, se il sito di sviluppo ha nuovi nodi, i due database conterranno entrambi voci con gli stessi ID nodo e non sarà possibile risolvere i riferimenti e unirli da un dump di testo del database sql. Questo tipo di operazione viene gestita meglio tramite funzionalità e distribuzione, come indicato in altre risposte.

— greg_1_anderson,