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.
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. –
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. –