Le problème d'organisation de drupal

J’ai rencontré ce problème à différentes reprises. Nous avons récemment travaillé à partir de différents environnements : un environnement de production, de développement et d’intégration. Chez software développement, cette démarche classique se fait appeler upstream de la production au développement et downstream du développement à la production.

Upstream
Dans le upstream process, les nouveaux utilisateurs, contenus et configurations d’utilisateurs sont déplacés. Ceci est le plus souvent causé par le transfert des database dumps. Dans certains cas, il peut se produire que la base de données soit trop volumineuse pour être transférée en un morceau. Si vous possédez par exemple 3,5 millions de nodes dans votre base de données, vous n’imaginez probablement pas télécharger le tout…

La solution
Si vous désirez seulement les configurations d’utilisateurs d’un environnement de production (par exemple http://drupal.org/project/homebox dispositions) une solution possible est d’utiliser le module http://drupal.org/project/backup_migrate. Avec celui-ci vous pouvez sélectionner vous-même les tableaux qui doivent être exportés. De cette façon, vous introduisez uniquement les tableaux contenant des configurations.
Bien que ceci demande une connaissance approfondie de drupal (parce qu’il faut savoir quels tableaux sont correctes pour être exportés), il est facile de réitérer la méthode grâce à l’enregistrement du tableau de sélection.
Vous pouvez automatiser ce module en utilisant cron, il y a aussi quelques demandes drush de prêtes de manière à garder les upstream sites à jour.
Quand vous avez uniquement des contenus créés, des configurations drupal ou des views, utilisez le module http://drupal.org/project/deploy. Cette vidéo vous explique tout sur le sujet http://www.youtube.com/watch?v=7PjwT0HWHxw

Downstream
Le processus downstream qui introduit le nouveau code et les dispositions dans la chaîne de développement est un problème dans drupal. Vous avez la manière grossière avec laquelle vous transférez le database dump. Ceci est néanmoins à éviter si votre site est constamment mis à jour. Une possible variante est d’utiliser la méthode mentionnée préalablement en ne déplaçant que les tableaux contenant des dispositions concernant des sauvegardes et migrations. Les problèmes accourent dès le moment où vous installez des modules qui réagissent au contenu.
Un exemple simple est un nouveau champ dans un content type. Ceci change le tableau du content type. Le fait est aussi que toutes les bases de données …( Ook is het zo dat alles database overdrachtgerelateerd slechte rollback mogelijkheden en change logging heeft.)
Effectuer un transfert de bases de données en même temps qu’une mise à jour manuelle d’affaires semble être une stratégie de mise à jour utilisée du temps des dinosaures...

Pour résoudre le problème d’une manière plus élégante, il vaut mieux installer un système utilisant les trois différentes composantes suivantes :

Features
Le module http://drupal.org/project/features a comme qualité d’exporter les structures de données qui apparaissent sous forme codée dans la base de données. Ce qui est pratique car cela permet d’examiner les changements dans le version control et de revoir par la même occasion les modifications. Ce qui en fait un module réellement ‘libérateur ‘ MAIS il faut tenir compte du fait que ce module ne soutient pas toutes les structures de données. Il soutient les menus, permissions, contenus types, vues, affichages, règles,… (Lisez la page du projet pour plus d’informations).Utilisez donc les features pour les structures de données qui les soutiennent. Espérons que toutes les structures de données seront soutenues dans drupal. Ceci est uniquement nécessaire pour que le problème d'organisation de drupal puisse être résolu. Comment ça marche ? Installez-le, créez un où plusieurs features, exportez-les et au moment d’avoir des mise à jours dans votre structure de données, celles-ci apparaîtront. Utilisez drush fu [name-feature] pour les mettre à jours, ajoutez-les à votre repository. Quand le svn up dans l’environnement du downstream s’effectuera, votre site utilisera ces nouvelles structures de données.

Deploy
Vous reconnaissez celui ci-dessus, utilisez-le quand vous avez développé des contenus. Un système de repositionnement est installé, donc pour revenir en arrière vous devez supprimer manuellement les contenus créés. La raison pour laquelle je ne l’utilise pas pour transférer des dispositions, vues et semblables est qu’il n’y a pas de fonction de repositionnement.

Hook update
Utilisez http://api.drupal.org/api/function/hook_update_N/6 quand les changements ne peuvent pas se faire à l’aide des deux précédants. Un exemple est une structure de données custom ou contrib qui se trouve dans la base de données et qui ne peut être exportée pour être disposée ou déployée. Si vous désirez un repositionnement, vous devrez les écrire vous-même avec un extra hook_update. Espérons que vous ne devrez pas le faire trop souvent :)

Hook update s’utilise aussi pour les mises à jour spécifiques à leur environnement. Par exemple, vous ne voulez pas que devel soit possible à la production.
Dans settings.php vous pouvez configurer un variable environnant. Parce que settings.php est différent dans chaque environnement, il faut le configurer de manière à ce que Drupal sache de quel environnement il s’agit. Un exemple de production dans settings.php.

In hook_update maak je nu:

Conclusion
Le plus important est de prendre certaines habitudes. A chaque fois que vous désirez changer la base de données, il faudra dès lors introduire ces changements dans les codes. Utiliser la stratégie ci-dessus prendra plus de temps quand plus de hook updates sont nécessaires. Cela prendra même encore plus de temps lorsqu’un rollback est présent. Mais cela vous donnera aussi plus de contrôle.
Il faut donc peser le pour et le contre, choisir une méthode permettant soit un plus grand contrôle, soit plus de temps de développement. Cela devrait être clair pour chacun –du client, responsable du projet au développeur et entreteneur- que l’installation et l’entretien de ce workflow dans un projet prend énormément de temps.

L'avenir
Le vrai problème réside dans le manque de soutien de la part du core. Il faudrait agir sur un système core capable de registrer toutes les structures de données et un stage de marquage des contenus. Ce système devrait être capable de faire la connexion avec toutes les sortes d’environnement et de montrer le statut du contenu et des structures. Dans ce cas, il serait possible de planifier, d’effectuer, de rappeler, d’enregistrer,… les releases.
A ce moment là naturellement, nous pourrons intégrer toutes les structures contribuantes des modules contrib avec ce système core :)

Momentanément, il semble qu’un tel système ne soit pas pour tout de suite. Je crois que les features viendront plus s’appuyer sur les configurations et structures de données et que deploy ira s’appuyer sur le contenu. J’ai peur que nous devrons supprimer le hook update pour les prochaines années.