Preprod -> prod

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Submitted by drupalfrance on

Hello,

Si vous avez déjà un peu utilisé Drupal, vous savez qu'une de ces lacunes est la synchronisation entre 2 instances du même site.

Cette synchronisation est nécessaire dans plusieurs cas :

  • Vous avez un site Drupal en prod (sur lequel des contenus continuent d'être créés), et vous faites une copie en préprod que vous modifiez. Comment synchroniser preprod et prod sans perdre certains contenus ?

  • Idem si vous avez plusieurs développeurs qui travaillent chacun sur une copie locale du même site. Comment gérer la fusion des modifications effectuées par chaque développeur sur une instance unique du site (je ne parle pas des modifs de scripts PHP qui peuvent être gérées par CVS ou SVN, mais des modifs de config faites dans l'admin) ?

En gros, le pb porte sur la synchro de la base de données (pour les fichiers, on a SVN ou CVS). Plus précisément, il faudrait pouvoir isoler les données de contenu des données de paramétrage.

Je poste ce message pour savoir si d'autres ont rencontré le même problème et l'ont résolu. C'est une demande récurrente que j'ai sur plusieurs projets et je n'ai pas trouvé de solution satisfaisante pour le moment.

Forum : 
Discussion générale

Soumis par Damien Tournoud le 29 Juin, 2007 - 14:20

Tu mets le doigt à mon sens sur une des inconvénients majeurs des solutions qui ne séparent pas correctement configuration et contenu. La plupart des CMS ont d'ailleurs ce même problème.

A y regarder d'un peu plus près, d'ailleurs, cette distinction configuration/contenu peut être assez délicate. Les menus relèvent-ils de la configuration ou du contenu? L'arborescence des catégories (éventuellement modifiée par du freetagging) relève-t'elle de la configuration ou du contenu? etc.

Du coup, pour faire cette synchronisation il faudrait être capable de gérer toute une série de cas particuliers, et eventuellement pouvoir résoudre les conflits à la main. Pas évident non?

Le mieux à mon sens, en développement, est de s'interdire d'utiliser l'interface d'administration, et d'écrire "un fichier d'update" qui effectue les modifications requises de manière programmatique. Après la phase de développement, il suffira de copier la base de production en intégration et d'appliquer l'update. Après vérification que tout s'est bien passé, il suffit d'appliquer l'update directement en production.

Soumis par Captain_FLAM le 30 Juin, 2007 - 15:36

Je planche sur ce problème en ce moment ...

Le configs sont apparemment enregistrées dans la table Cache->Variables , et il y a une clef de vérification, donc : si modif direct du Blob, les modifs se retrouvent écrasées, et remplacées par leur "default"

Voilà où j'en suis de mes conclusions, tout en étant pas sûr du pourquoi et du comment ...

Quelques retours d'expériences seraient bien appréciables.

Soumis par tostinni le 30 Juin, 2007 - 18:40

2 Tables sont importantes: variable (pour pas mal de variables definies par les modules) et system (pour la gestion des modules et des themes).

Mais c'est clair que de toute maniere a part manuellement je vois pas comment resoudre les conflits...

Soumis par drupalfrance le 1 Juillet, 2007 - 12:32

Yep, sauf que comme l'a souligné damz, c'est bcp plus complexe que ça : que faites-vous des tables qui stockent les définitions de vues, de noeuds CCK, du menu, de la taxonomie... ? Tout ça, c'est aussi la config d'un site.

Si aucun module n'existe alors que c'est un besoin très répandu, il y a sûrement une raison (trop complexe). J'en arrive au même point que damz : vérouiller l'admin et reproduire la config via scripting....

Soumis par Captain_FLAM le 4 Juillet, 2007 - 00:53

Bon, résultat de mes investigations :

Le problème vient de drupal_private_key dans la table variables et dans la table cache->variables (Blob) :

  • si on copie cette variable de l'installation locale vers le serveur web , et qu'on bloque le changement de cette clef dans includes/common.inc en mettant en commentaire ces 2 lignes :

function drupal_get_private_key() {
if (!($key = variable_get('drupal_private_key', 0))) {
// $key = md5(uniqid(mt_rand(), true)) . md5(uniqid(mt_rand(), true));
// variable_set('drupal_private_key', $key);
}
return $key;
}

ça marche !!

MAIS on ne peut plus faire de modifs par l'admin, ni par les users !!!!

(étant donné, je suppose, que cette clef qui sert à valider les tokens est calculée d'après le Host)

Voilà où je me suis arrêté ...

Quant à moi, je passe à un autre CMS (après en avoir testé plein, dont Xoops & Drupal) :

MODx , qui est certes moins complet au niveau des modules et réservé aux programmeurs PHP (dont je fais partie), mais qui permet cette jonglerie entre local/serveur sans trop de difficultés et qui est assez intelligemment construit.

Bon courage à vous tous.

Soumis par Damien Tournoud le 4 Juillet, 2007 - 10:48

A vrai dire, je ne comprends rien du tout à ton message.

Pour clarifier les choses :

  • les variables sont enregistrées dans la table variables (comme son nom l'indique). Une copie de ces variables est enregistrée dans la clé "variables" de la table cache, mais ce n'est que pour améliorer les performances au chargement de la page (cela évite à PHP d'avoir à générer une structure transitoire pour chaque ligne de la table).
  • la fonction drupal_get_private_key() génère une clé qui permet à Drupal de valider les saisies des formulaires. Cette clé est générée une seule fois, puis est stockée dans la base de données (comme variable). Lors de la copie de la base de données, cette variable "suit" donc toutes les autres.

Le problème posé par Vincent dans ce fil de discussion n'est comment déplacer un site en local et le mettre ensuite sur un serveur. Vincent demande des conseils pour gérer les nouveaux développements sur site alors que celui-ci est en production. Les contenus évoluant au fur et à mesure, et la structure du site pouvant changer, cela nécessite un peu d'organisation, sur Drupal comme sur d'autres CMS.

Soumis par Captain_FLAM le 4 Juillet, 2007 - 13:32

Le problème posé par Vincent dans ce fil de discussion n'est comment déplacer un site en local et le mettre ensuite sur un serveur.

Il me semblait pourtant avoir compris ça :

* Idem si vous avez plusieurs développeurs qui travaillent chacun sur une copie locale du même site. Comment gérer la fusion des modifications effectuées par chaque développeur sur une instance unique du site (je ne parle pas des modifs de scripts PHP qui peuvent être gérées par CVS ou SVN, mais des modifs de config faites dans l'admin) ?

Soumis par Damien Tournoud le 21 Août, 2007 - 13:53

Dans ce post (1), l'auteur semble sous-entendre que le contenu de la base de données est dumpé et mis en versionning dans le subversion. Cela pourrait être une manière intelligente de s'assurer que l'environnement de développement/recette/intégration est bien à jour (à supposer que la base de prod ne soit pas trop volumineuse, bien sûr).

(1) http://lists.drupal.org/pipermail/development/2007-August/025937.html