Déploiement des mises à jour de contenu du serveur de transfert vers le serveur en direct

8

Nous essayons de déployer des mises à jour de contenu de notre serveur de transfert vers notre serveur en direct, mais nous avons du mal à trouver un bon moyen de le faire. Nous devons être en mesure de déployer de nouvelles pages, des mises à jour de pages et parfois des suppressions de pages. Notre site utilise également largement le module livre, de sorte que le module Déployer ne fonctionne pas pour nous pour le moment. Nous utilisons des fonctionnalités pour les mises à jour de grandes structures. Donc, notre préoccupation est simplement les mises à jour quotidiennes du contenu.

Y a-t-il des modules qui peuvent faire cela et gérer les pages de livre?

antiant
la source
Je pense que cela est quelque peu lié à drupal.stackexchange.com/q/137/134 . Vous pouvez y jeter un coup d'œil et voir si cela peut aider, ou clarifier votre question pour savoir pourquoi elle est différente.
Chaulky
Aucune de ces réponses ne fonctionne pour les pages de livre ou ne les supprime. Ces deux éléments sont très importants pour nous. De plus, faire un vidage complet de la base de données et des fichiers à chaque fois semble être une exagération sérieuse.
antgiant
Pouvez-vous établir un gel du contenu sur la production pendant que vous modifiez le système de transfert?
BetaRide

Réponses:

3

Les fonctionnalités UUID et UUID vous permettent d'exporter un nœud vers une fonctionnalité, ce qui pourrait être exactement ce que vous recherchez, ce qui signifie qu'il n'est pas nécessaire de jouer avec la base de données.

Déchiffrer
la source
1

Je suppose que Drupal 6 est ici, et je ne sais pas personnellement si cela fonctionnera avec le module livre, mais avez-vous étudié le déploiement ?

justintime
la source
0

Vous pouvez également essayer Phing , avec lequel vous pouvez automatiquement:

  • Vider la base de données intermédiaire à l'aide de mysqldump.
  • Copiez le fichier mysqldump d'un serveur à un autre à l'aide du cryptage SCP et de la clé publique-privée.
  • Importez le mysqldump du système de fichiers dans la base de données.
  • Exécutez la commande Feature Revert All ( drush fra -y) pour que votre serveur de production récupère les paramètres de production (tels que les blocs, les vues, les contextes, etc.) trouvés dans votre code de fonctionnalités.

Problèmes que je vois avec cette approche:

Vous devrez effectuer une exportation de base de données à grain très fin, ce qui signifie prendre uniquement les tables node, node_revisions, cck et menu.

Sur ce dernier point (liens de menu), à moins que vous n'accédiez à la fois à votre scène et à votre serveur de prod en utilisant les mêmes alias d'URL, vous aurez différentes entrées d'élément de menu, et ce sera un problème grave.

barista amateur
la source
3
J'essaie de rester avec les modules Drupal si possible. Et, franchement, cette idée semble être un accident de corruption de données qui attend de se produire.
antgiant
0

En fait, j'aime la méthode complète de vidage de base de données, qui peut être scriptée et peut souvent se terminer en quelques secondes. (Garder vos révisions sous contrôle et exclure les tables de cache, etc. peut réduire considérablement la taille.) Vous pouvez même créer un module simple pour fournir une interface aux éditeurs de contenu pour déclencher ce processus.

Vous devez tenir compte de tout contenu que vous pourriez accepter des utilisateurs de votre site en direct, comme les commentaires ou les soumissions de formulaire de contact. S'il y en a - étonnamment souvent il n'y en a pas - vous pouvez soit utiliser un service externe, comme Disqus pour les commentaires ou Marketo pour les formulaires de génération de leads, séparer soigneusement ces soumissions dans une base de données Drupal distincte qui n'est pas écrasée, ou soigneusement ne pas les écraser tables affectées pendant le processus d'exportation / importation.

Là où elle peut fonctionner, elle peut finir par être la méthode la plus simple, la plus rapide et la plus fiable. Et un site qui n'accepte jamais les commentaires des utilisateurs (sauf dans les services externes) ouvre de nombreuses portes pour être rendu beaucoup plus rapide et plus sûr.

matthewv789
la source