Siti di gestione temporanea, come gestite la sincronizzazione degli aggiornamenti nel DB?

È ampiamente riconosciuto che gli sviluppatori dovrebbero testare gli aggiornamenti attraverso un sito di staging prima di rilasciarli sul server live, tuttavia una volta che gli aggiornamenti di sviluppo richiedono modifiche in Wordpress DB, le cose si complicano, poiché anche gli utenti del sito live aggiorneranno il DB.

L'unico flusso (confuso) che posso immaginare è il seguente:

1. Test su un server locale (WAMP, XAMP, ecc.)
2. Una volta pronto per la distribuzione, mettere il sito live in modalità manutenzione
3. Sito live di backup (duplicatore, sqldump, ecc.)
4. Creare un clone del sito live bloccato sul sito di staging
5. Carica le modifiche dall'ambiente locale sul sito di gestione temporanea
6. Testare il sito di gestione temporanea
7. Spingere il sito di gestione temporanea per vivere.
8. Rimuovere la modalità di manutenzione

Svantaggi del flusso sopra:

• i tempi di inattività possono essere più lunghi del previsto per gli utenti mentre lo sviluppatore sta testando attentamente gli aggiornamenti nel sito di gestione temporanea;
• può richiedere la gestione manuale delle modifiche: ad esempio, i layout di pagebuilder siteorigin sono memorizzati nel db, quindi una volta modificato un layout, deve essere importato manualmente nel sito di staging; in questo caso potrebbe essere sufficiente rilasciare e importare semplicemente le pagine nel sito di staging e, se funziona, importarle nel sito live

Mi chiedo se esiste un modo migliore e più automatizzato per raggiungere questo obiettivo.

Cosa ne pensi?

EDIT, come richiesto, alcune soluzioni sono state proposte in passato ma nessuna offre una soluzione definitiva:

• 9/2010 - Sincronizzazione del database tra sviluppo / gestione temporanea e produzione
• 12/2011 - Distribuzione di plugin aggiornati o nuovi che modificano la tabella wp_options
• 9/2014 - Come caricare le modifiche locali su un server live senza sovrascrivere nuovi post / pagine?
• 1/2015 - Come mantenere i blog dei siti wordpress nella produzione e messa in scena?

I provider di hosting più recenti che si rivolgono specificamente a WordPress di solito dispongono di strumenti per alleviare questo dolore. Ho messo i miei clienti su Pantheon, che ha questo flusso di lavoro abilitato per Git , in cui il codice si sposta solo verso l'alto (dallo sviluppo alla gestione temporanea alla produzione) e il materiale DB si sposta solo verso il basso (viceversa dal codice). Copiare un database dalla produzione alla stadiazione è un clic con la loro interfaccia. Se questo flusso di lavoro viene rispettato, ciò elimina praticamente il problema di incasinare il database di produzione, permettendomi di testare sempre le mie modifiche su un nuovo clone di dati di DB di produzione in entrambe le fasi dello sviluppo.

Non è necessario utilizzare Pantheon: è possibile adottare un approccio simile nel processo utilizzando i propri strumenti (Git + un plug-in di clonazione DB come WP Migrate DB). Trovo che questo modo funzioni bene per me.

Domanda: perché mettere il sito di produzione in modalità di manutenzione durante il test della stadiazione? Non dovrebbe esserne necessario nella maggior parte dei casi. L'unico caso a cui riesco a pensare è avere una sorta di sistema molto fragile molto sensibile agli ulteriori dati dell'utente che vengono inseriti in esso, con un bug catastrofico da avviare - ma sarebbe probabilmente indicativo di un problema diverso, più ampio, in cui uno avrebbe bisogno ripensare l'intera architettura del loro prodotto.

Dai un'occhiata a VersionPress che porta il versioning GIT all'intero processo (file e database)

Come descritto sul loro sito:

VersionPress offre una messa in scena indolore . Ciò significa che è possibile creare facilmente un ambiente di test sicuro per le modifiche e ricollegarle solo quando sono pronte. Unisci è la parola chiave qui - VersionPress gestisce le situazioni in cui il tuo sito live ha avuto nuovi contenuti nel frattempo senza soluzione di continuità.