Comment puis-je fusionner les modifications d'une copie de développement du site sur le site en direct sans perdre du nouveau contenu?

Question

Quelle est la meilleure procédure de fusion travail effectué sur une copie de développement d'un site à la copie de la production en direct? Souvent, il y a eu beaucoup de nouveau contenu sur le site depuis le développement a commencé sur les nouvelles fonctionnalités. Et la plupart des ajouts à un site impliquera des changements de base de données. Ainsi, la copie de nouveaux fichiers est facile, mais qu'en est-la base de données? Comment pouvez-vous fusionnez vos modifications avec la base de données de production existante sans perdre du nouveau contenu qui a été ajouté depuis la dernière fois que vous avez mis à jour le site de production? Y a-t-il des modules qui aident à cela?

Answer 1

Pour les types de contenu, des vues et des changements de structure sur l'aspect du site dev à utiliser Caractéristiques pour exporter la base de données à code.

Pour la migration de contenu, il y a beaucoup d'options, mais pas une seule solution solide. Un exemple est la suite du déploiement .

Answer 2

J'ai adopté essentiellement deux écoles de pensée (une 3ème école de pensée, la base de données faisant diffs, je ne discuterai pas parce que la complexité est assez élevé).

1) Déployer en laissant tomber la base de données de production et l'importation d'un mysqldump de la base de développement. En option, exécutez une découverte regex / remplacer au préalable sur les liens absolus codés en dur qui font référence à l'URL dev dans le dump SQL. Après avoir importé le dev db dans prod, exécuter automatiquement des instructions SQL (généralement via le script) après pour modifier les paramètres qui sont différents pour prod que dev (par exemple, peut-être que vous avez dans le tableau des variables des paramètres de connexion pour la connexion à des systèmes externes que vous devez changer de point des systèmes externes de prod au lieu de la version dev).

2) Utilisez le Caractéristiques module, comme mentionné par Budda, pour les paramètres d'administration, et utilisez le < a href = "http://drupal.org/project/node_export" rel = "nofollow"> module de noeud d'exportation pour l'exportation contenu / importation en combinaison avec le Supprimer tout le module . Donc, flux de travail est:

1. Utilisation node_export et fonctionnalités aux nœuds d'exportation / caractéristiques des fichiers
2. le contrôle de version en option (et je l'espère)
3. Charger des fichiers sur le système prod
4. Utiliser l'interface drush ou admin à la charge caractéristiques
5. Utilisez drush suppression-tout ou interface d'administration pour supprimer tous les noeuds des types que vous souhaitez importer
6. Permet d'importer les noeuds des noeuds que vous ne fichier exporté de l'importation ou l'interface d'administration.

Une note, je suggère fortement l'adoption d'un flux de travail standard, où le contenu va une seule direction. Soit Dev -> Prod ou Prod -.> Dev (je préfère celui-ci)

Je l'ai fait, et je suis en train de faire cela sur quelques grands systèmes, avec des résultats assez bons, mais il y aura toujours beaucoup de façons de découper cette pomme, choisir de quelque façon qui fonctionne le mieux pour vous.

Answer 3

bases de données de vidage de copie du site en direct et copie de développement d'un site dans le fichier SQL (utiliser les mêmes paramètres et réglages pour les décharges).
Ensuite, comparez les deux fichiers SQL à l'aide d'un petit outil de comparaison ExamDiff . Il afficherez côte à côte les différences de fichiers avec des couleurs différentes. Vous pouvez directement sauter aux différences aussi (sans défilement). Examiner les différences et ajouter / modifier des lignes dans le fichier SQL de site en direct. Assurez-vous qu'il n'y a pas de chemin / URL absolue de l'environnement de développement dans ce fichier. Ça c'est fait! Il est temps de restaurer la base de données pour le site en direct.
Faites votre vie plus facile: Dans la première étape, vider uniquement les tables qui sont changés. Par exemple, si vous avez modifié un module en version de développement qui cible une table séparée, vider uniquement ce tableau. Si vous n'êtes pas sûr de table particulière, vidage de base de données tout est très bien.