Non appena si tocca l'argomento di apportare modifiche in parallelo, si tocca l'area della gestione della configurazione. Con molti modelli, proprie community (http://www.cmcrossroads.com/) e strumenti non tanto per la gestione delle versioni (come svn / git) ma per il supporto della gestione della configurazione (pattern) come clearcase. (aree totalmente diverse).
In questo caso è ancora una situazione semplice e troverai che funziona con alcune limitazioni, alcuni lavori manuali e alcune liste.
Lo scenario a cui sto pensando di renderlo più descrittivo della soluzione ideale: più sviluppatori che lavorano sulla stessa base di codice, più ambienti di test, più ambienti di accettazione, più ambienti di accettazione della produzione possibilmente in tutti gli angoli del mondo.
Se vuoi farlo un po 'più professionale:
a) annota un elenco di tutti gli elementi di configurazione che incontri, questo potrebbe essere il codice WordPress stesso, plugin da esterni, contenuti, metadati e decidere quali di questi vuoi portare sotto una sorta di "gestione", quali sono importanti.
b) descrivere i flussi di lavoro che possono verificarsi, ad es. cosa succede con una correzione, cosa succede con qualcosa di nuovo in fase di sviluppo, in che caso cambi contenuto dalla tua parte, come si chiama e chi lo fa, chi ne è il proprietario ad esempio un nuovo post o un nuovo plug-in.
c) per il lavoro in parallelo, descrivere innanzitutto quali elementi della configurazione si desidera gestire, decidere se il flusso va sempre dallo sviluppo alla produzione o se è realmente necessario farlo in due modi.
d) per ciascuno dei tipi di CI sotto (a) scrivere una risoluzione. Ad esempio per TUTTI quelli che sono testo (o testo esportato come file php ma ANCHE testo normale in file XML) è possibile la fusione. Questo non è davvero un problema, ma è necessario un buon strumento di unione. ad es. con ClearCase si unirebbero in 3 modi le seguenti situazioni: 1) banali fusioni: le farà automaticamente 2) non banali automatiche: le faranno automaticamente MA è necessario verificarle 3) non banali non automatiche: questo è un conflitto, ad es. su 1 riga sono state apportate diverse modifiche. Le cose non banali sono la parte minima di cui devi occuparti manualmente, un buon strumento di fusione ti guiderà in questo ad esempio quello in clearcase (che fa anche la fusione di parole e dove puoi collegare altre fusioni commerciali o non commerciali per un file specifico tipi). Inoltre, se hai identificato sotto (a) file che dovrebbero essere copiati, il loro comportamento sarebbe quello di non essere unito ma semplicemente copiato in un modo sovrascrivendo l'altra versione senza unire (ad esempio plugin che non hai modificato). Molti di questi tipi sono possibili con comportamenti diversi. Ma annota le relazioni tra CI,
Quindi per le fusioni non basate su testo è necessario prendere una decisione su come gestirle, ad esempio immagini che sono state modificate in 2 punti. Potresti decidere qui che la produzione ha sempre la preferenza (almeno è quello che penso), il che la rende semplice.
Quindi ... per risolvere questo problema è necessario uno strumento di gestione delle versioni che supporti diversi flussi. Ogni flusso rappresenterebbe una parte. (questo può essere immensamente complesso a seconda delle tue esigenze, ma in questo caso penso che sia molto semplice).
Se ora riesci ad avere questi flussi sotto le tue installazioni di WordPress e sincronizzali anche con il contenuto del database, ecc ... allora puoi eseguire le fusioni nello strumento CM / versioning e quindi esportarlo nuovamente nell'altro ambiente.
Il fatto è ... devi prima scrivere questo. Questo non è un trucco tecnico. Si tratta di un modello predefinito in Config Management quindi niente di strano qui, ma è necessario scriverlo. Ad esempio, è possibile che un plug-in installato apporti modifiche al database con alcuni dati diversi in un altro ambiente, quindi è necessario disporre di una procedura aggiuntiva al riguardo.
Tecnicamente quasi sempre tutto è possibile controllare http://www.cmcrossroads.com/forums per scenari che sono dozzine o centinaia di volte più complessi, sempre usando lo stesso approccio e usando lo stesso set di schemi CM.
in breve: mettere un livello di gestione delle versioni al di sotto di esso, automatizzare le fusioni e gestire i conflitti, quindi importare nell'ambiente di destinazione. Pensa a una strategia di streaming che si adatta qui e scrivila. Esegui una gestione del CM un po 'strana. Sarebbe la soluzione professionale altrimenti installare qualche copia di db hack, script ecc ...