Sincronizzazione del database tra ambiente di sviluppo/staging e produzione

Se si tratta semplicemente dello stesso tipo di dati (nuovi articoli del blog, nuovi commenti) non sono sicuro del perché tu abbia bisogno di sincronizzarli davvero. Non è che cambierà il modo in cui funziona il codice sul sito, visto che è semplicemente più dello stesso tipo di contenuto. Di solito non mi preoccupo a meno che non si tratti di un nuovo tipo di dati.

Mi assicuro sempre di avere un buon campione rappresentativo dei dati per il sito, non ogni singolo post, pagina o commento del sito live.

Non appena tocchi l'argomento di apportare modifiche in parallelo, tocchi il campo della gestione della configurazione. Con molti schemi, comunità dedicate (http://www.cmcrossroads.com/) e strumenti non tanto per la gestione delle versioni (come svn/git) ma per il supporto della gestione della configurazione (schemi) come clearcase. (aree totalmente diverse).

In questo caso è ancora una situazione semplice e scoprirai che funziona con alcune limitazioni, un po' di lavoro manuale e alcune liste.

Lo scenario che ho in mente per renderlo più descrittivo della soluzione ideale: più sviluppatori che lavorano sullo stesso codice base, più ambienti di test, più ambienti di accettazione, più ambienti di accettazione produzione possibilmente in ogni angolo del mondo.

Se volessi farlo in modo un po' più professionale:

a) scrivi una lista di tutti gli Elementi di Configurazione che incontri, potrebbe essere il codice WordPress stesso, plugin esterni, contenuti, metadati e decidi quali di questi vuoi portare sotto una qualche forma di "gestione", quali sono importanti.

b) descrivi i flussi di lavoro che possono verificarsi, ad esempio cosa succede con una correzione, cosa succede con lo sviluppo di qualcosa di nuovo, in quale caso modifichi contenuti dalla tua parte, come si chiama, chi lo fa, chi è il proprietario, ad esempio un nuovo post o un nuovo plugin.

c) per il lavoro parallelo descrivi prima quali EC vuoi gestire, decidi se il flusso è sempre dallo sviluppo alla produzione o se è davvero necessario farlo in entrambi i sensi.

d) per ogni tipo di EC sotto (a) scrivi una risoluzione. Ad esempio, per TUTTO ciò che è testo (o testo esportato come file php ma ANCHE testo semplice in file XML) il merge è possibile. Questo non è davvero un problema ma hai bisogno di un buon strumento di merge. Ad esempio, con ClearCase otterresti nelle situazioni di merge a 3 vie: 1) merge banali: li fa automaticamente 2) non banali automatici: li fa automaticamente MA devi verificarlo 3) non banali non automatici: questo è un conflitto, ad esempio su 1 linea sono state apportate diverse modifiche. I non banali sono la parte minima di cui devi occuparti manualmente, un buon strumento di merge ti guiderà in questo, ad esempio quello in clearcase (che fa anche merge a livello di parola e dove puoi collegare altri strumenti commerciali o non commerciali per tipi di file specifici). Inoltre, se hai identificato sotto (a) file che dovrebbero essere solo copiati, il loro comportamento sarebbe di non essere sottoposti a merge ma solo copiati in un senso sovrascrivendo l'altra versione senza un merge (ad esempio plugin che non hai modificato). Molti di questi tipi sono possibili con comportamenti diversi. Ma annota le relazioni tra EC.

Poi per i merge non basati su testo devi prendere una decisione su come gestirli, ad esempio immagini che sono state modificate in 2 posti. Potresti decidere qui che la produzione ha sempre la precedenza (almeno è quello che penserei io), il che lo rende semplice.

Quindi... per risolvere questo problema hai bisogno di uno strumento di gestione delle versioni che supporti flussi diversi. Ogni flusso rappresenterebbe una parte. (questo può essere immensamente complesso a seconda delle tue esigenze ma in questo caso penso sia molto semplice).

Se ora riesci a gestire questi flussi sotto le tue installazioni WordPress e sincronizzarli anche con il contenuto del database, ecc... allora puoi eseguire i merge nello strumento di CM/versioning e poi esportarli nell'altro ambiente.

Il fatto è... devi prima scriverlo. Questo non è un hack tecnico. È uno schema standard intorno alla Gestione della Configurazione quindi niente di strano ma devi scriverlo. Potresti scoprire ad esempio che un plugin installato apporta modifiche al database con alcuni dati che sono diversi in un altro ambiente, quindi hai bisogno di una procedura extra attorno a questo.

Tecnicamente quasi tutto è sempre possibile, controlla http://www.cmcrossroads.com/forums per scenari che sono decine o centinaia di volte più complessi, anche se usando sempre lo stesso approccio e lo stesso insieme di schemi CM.

In breve: metti uno strato di gestione delle versioni sotto, automatizza i merge e gestisci i conflitti, poi importa nell'ambiente di destinazione. Pensa a una strategia di flusso che si adatti qui e scrivila. Esegui un pochino di gestione CM. Questa sarebbe la soluzione professionale altrimenti installa qualche hack di copia db, script ecc...

Ho appena pubblicato un post su come sincronizzo i dati di produzione con l'ambiente di staging, dai un'occhiata al mio articolo del blog su: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database-from-production-to-staging-enviorment/

Se vuoi sincronizzare anche il codice e altri elementi, ti consiglio di creare un repository git o mercurial con il relativo file .ignore.

Se invece vuoi effettuare aggiornamenti differenziali dalla staging alla produzione, allora credo che creare script di migrazione sia il metodo più sicuro e migliore.