2010-09-06 5 views
5

Souvent, après le lancement d'un site Drupal (6.x), des personnes commencent à s'inscrire et à entrer leur propre contenu. Chaque fois qu'une mise à niveau est nécessaire, la base de données sur la production est copiée dans dev, puis le développement est fait sur dev, plus tard, on le pousse à la mise en scène pour l'approbation du client. Lorsque le site est prêt à être mis en ligne, il y a un problème. Le serveur de production a le dernier contenu entré par l'utilisateur, le développement et le stockage intermédiaire ont les dernières fonctionnalités. Le simple écrasement de la base de données en production ne fonctionnera pas. Ce que je fais habituellement est d'écrire ce qui a été fait pour dev et de suivre les étapes pour aller encore plus loin dans la mise en œuvre de la production. À mesure que le système s'agrandit, une seule erreur sur la production peut entraîner une perte d'activité. Je ne peux pas fermer le site pendant plusieurs heures. Je ne peux pas dire combien de personnes utilisent le site à un moment donné, même s'il est impossible d'attendre un moment où personne n'est sur le site pour faire la mise à niveau.Synchronisation du site Drupal entre le développement, la mise en scène et la production

Quelqu'un a-t-il une bonne idée?

Merci d'avance.

Répondre

4

Vous devez examiner deux concepts: Le premier est "Exportables" qui est généralement un moyen d'exporter toute la configuration d'un module donné. La seconde est "Features" (terriblement nommée, oui) qui est un moyen de grouper un ensemble d'exportables dans un changeset donné pour le contrôle de version, la mise à jour, le déploiement, le rollback, etc

Pour plus de clarté, de nombreux modules implémentent leur propre La méthodologie «Exportables» à laquelle j'ai fait référence ci-dessus était le module Exportables. Voici une stratégie plus large pour cela - http://www.sthlmconnection.se/tips-and-tweaks/exportable-configuration-your-drupal-module-ctools

4

C'est la question à un million de dollars: Comment transférer du code, de la configuration et du contenu entre différents sites Drupal? Dans Drupal, le code est stocké dans des fichiers (ou du moins il devrait l'être) alors que la configuration et le contenu sont généralement dans la base de données. Transporter votre code d'un serveur à un autre n'est pas si difficile, et le code a un autre avantage: il est facile à stocker et à gérer dans un système de contrôle de version comme SVN ou GIT. C'est pourquoi la plupart des solutions se concentrent sur l'extraction de données de la base de données et leur insertion dans le code.

Déjà mentionné par CaseySoftware, le module Features est ce dont vous avez besoin pour stocker la configuration dans le code. Features dispose d'une version stable depuis quelques semaines et la communauté semble être d'accord que Features est la voie à suivre.

Le déplacement du contenu entre les sites est un peu plus difficile, car le contenu peut être ajouté ou modifié simultanément sur le développement, la mise en scène et la production. Exportables est une tentative pour résoudre cela, mais ce n'est pas le seul. Assurez-vous également de consulter les modules Deploy et les modules UUID Features Integration basés sur les fonctionnalités. Aucun de ces modules n'est encore stable et le temps dira lequel est la meilleure solution.

+0

Thx. C'est exactement ce que j'essaie de résoudre, mais je ne sais pas si il y a une solution faite là-bas. Assez intéressant, je pense que j'ai juste pris Drupal comme tout ce que j'ai pensé de faire avec Drupal, il y a un module pour ça. Je lis et j'écris il y a un moment en utilisant Feature and Context pour gérer ce problème. Après avoir essayé pendant un moment, je trouve que le module Context n'est pas très stable. L'exportation est la voie à suivre, mais le problème est que chaque module possède ses propres outils d'exportation. Au fil du temps, je dois toujours garder une trace de la chance qui a été faite pour chaque mise à jour. –

+1

L'article que je mentionne souligne le point fondamental de la réalisation de cet objectif en séparant la configuration et le contenu, dans d'autres cas, SVN gère la configuration et les dernières données doivent toujours venir de la base de données en production.À mon avis, cela ne pose aucun problème si les configs sont dans la base de données tant que Drupal peut établir une convention de nommage qui sépare clairement les tables qui contiennent uniquement des configs et les tables qui contiennent uniquement des données utilisateur. –

Questions connexes