Dès que vous touchez le sujet des modifications en parallèle, vous touchez le domaine de la gestion de la configuration. Avec beaucoup de patterns, propres communautés (http://www.cmcrossroads.com/) et outils, pas tant pour la gestion de version (comme svn / git), mais pour le support de la gestion de configuration (patterns) comme clearcase. (zones totalement différentes).
Dans ce cas, la situation est toujours simple et vous constaterez que cela fonctionne avec certaines limitations, du travail manuel et des listes.
Le scénario auquel je pense doit être plus descriptif de la solution idéale: plusieurs développeurs travaillant sur la même base de code, plusieurs environnements de test, plusieurs environnements d'acceptation, plusieurs environnements d'acceptation de production éventuellement aux quatre coins du monde.
Si vous voulez faire cela un peu plus professionnel:
a) écrivez une liste de tous les éléments de configuration que vous rencontrez; il peut s’agir du code WordPress lui-même, des plugins provenant d’externaux, du contenu, des métadonnées et décidez lequel de ceux-ci vous souhaitez placer sous une sorte de "gestion", lesquels importent.
b) décrire les flux de travail qui peuvent survenir, par exemple ce qui se passe avec un correctif, ce qui se passe avec quelque chose de nouveau en cours de développement, dans quel cas changez-vous le contenu de votre côté, comment s'appelle-t-il, et qui le fait, qui en est le propriétaire par exemple un nouveau post ou un nouveau plugin.
c) pour le travail en parallèle, décrivez d’abord les CI que vous souhaitez gérer, puis décidez si le flux va toujours du développement à la production ou s’il est vraiment nécessaire de le faire de deux manières différentes.
d) pour chaque type de CI sous (a), écrivez une résolution. Par exemple, pour ALL, il s'agit d'un texte (ou d'un texte exporté tel que des fichiers php mais AUSSI du texte brut dans des fichiers XML), la fusion est possible. Ce n'est vraiment pas un problème mais vous avez besoin d'un bon outil de fusion. Par exemple, avec ClearCase, vous obtiendrez une fusion à 3 voies dans les situations suivantes: 1) des fusions triviales: il les fera automatiquement 2) non automatique automatique: il les fera automatiquement MAIS vous devez le vérifier 3) non trivial non automatique: est un conflit, par exemple sur une ligne, plusieurs modifications ont été apportées. Les éléments non triviaux sont la partie minimale dont vous devez vous occuper manuellement. Un bon outil de fusion vous guidera, par exemple celui de Clearcase (qui fusionne également des mots et permet de lier d'autres fusions commerciales ou non commerciales pour un fichier spécifique). les types). De plus, si vous avez identifié sous (a) des fichiers qui doivent être copiés uniquement, leur comportement sera de ne pas être fusionné mais simplement copié d’une manière qui écrase l’autre version sans fusion (par exemple, des plugins que vous n’avez pas modifié). Beaucoup de ces types sont possibles avec différents comportements. Mais écrivez les relations entre les CI,
Ensuite, pour les fusions non textuelles, vous devez décider comment les gérer, par exemple des images qui ont été modifiées à deux endroits. Vous pouvez décider ici que la production a toujours une préférence (du moins c'est ce que je pense), ce qui la rend simple.
Donc ... pour résoudre ce problème, vous avez besoin d'un outil de gestion de version qui prend en charge différents flux. Chaque flux représenterait une partie. (Cela peut être extrêmement complexe en fonction de vos besoins, mais dans ce cas, je pense que c'est très simple).
Si vous parvenez maintenant à avoir ces flux sous vos installations WordPress et à les synchroniser également avec le contenu de la base de données, etc., vous pouvez alors effectuer les fusions dans l'outil de gestion des versions / CM, puis l'exporter dans l'autre environnement.
La chose est ... vous devez écrire ceci en premier. Ce n'est pas un hack technique. C'est un modèle par défaut autour de la gestion de la configuration, donc rien d'étrange ici aussi, mais vous devez l'écrire. Vous pouvez par exemple constater qu'un plug-in installé apporte des modifications à la base de données avec des données différentes dans un autre environnement. Vous devez donc prévoir une procédure supplémentaire à ce sujet.
Techniquement, presque toujours, tout est possible. Consultez http://www.cmcrossroads.com/forums pour des scénarios qui sont des dizaines ou des centaines de fois plus complexes, tout en utilisant toujours la même approche et en utilisant le même ensemble de modèles CM.
en bref: placez une couche de gestion de versions, automatisez les fusions et gérez les conflits, puis importez dans l'environnement cible. Imaginez une stratégie de flux qui convient ici et écrivez-la. Effectuer une gestion minuscule très petite CM. Ce serait la solution professionnelle, sinon installez une copie de la copie de base de données, des scripts, etc.