Industrialisation / Staging

Notes de Fabien Séries

Point clés :

• Backup and migrate
• Features
• Drush

Drush permet d'automatiser des tâches.
Pour déployer n fois :
-> features
-> Drush script

Principale problématique :
-> migration de contenus (versionning)
-> features
features : export / import

Backup and migrate = dernier recours
Doit être uniquement utilisé pour exporter ce qui n'est pas prévu pour l'être (structure de base)
CCK partagés -> evil !
Strongarm = export de config (=> éviter de se farcir 1000 cases à cocher à chaque déploiement)
features : Attention aux dépendances
=> Indépendance : e.g. CCK image -> 1 par content type
Grosse feature : déployer puis décocher si besoin

Feeds / Migrate / Deploy

• Feeds + Migrate = déplacer du contenu en masse
• Deploy = push / déplacement à l'unité

Exemple de staging :
• Drupal contrib
• Drupal publi
• Syncro au milieu

Avantages :
Si la contrib tombe, on peut consulter
Si la publi tombe, on peut bosser
Workflow seulement en contrib => publi plus léger

Déploiement : 2 features

• Tronc commun
• Contrib

Remarque : penser à désactiver les CCK dans Features si ils ont été supprimés (pas automatique)
sinon hook_update()

Jenkins / Hudson
RQ : les Features doivent toujours revenir en default (pas surchargées/ non-overriden)
drush help --filtered
drush cc all !!
GIT !!
Features stable ! (Yay !)
/!\ Traductions
export de vues avec rôles et taxos
/!\ Valeur dynamique de l'UID voir UUID (cf. DRUUID dans D8)
Feature = module généré automatiquement

Notes de Pierre Dureau

Timing
6 mois après sa sortie, ça commence à être OK pour Drupal 7. PA rapprot à la migration de D5 à D6, la migration de D6 à D7 peut être plus difficile car le développement a été plus long et a intégré de grosses modifications.
Il reste encore des Drupal 5 et il vaut mieux ne pas sauter une version lors des migrations, comme le montre l'exemple de « Rue 89 ».
Une migration peut être l'occasion d'une refonte du site, graphique ou fonctionnelle.

Migration de site ou migration de données ?
Entre le code d'hier et celui d'aujourd'hui, ce n'est pas que de nouvelles API et fonctionnalités, c'est aussi une question de philosophie avec des sauts de concepts. Par exemple : les « faux nodes » sont aujourd'hui des entités.
De même, on peut utiliser désormais des fonctionnalités du core (actions, triggers...) plutôt que les modules dédiés auxquels nous étions habitués.
Pour ces raisons, on peut envisager une migration de données au sein d'un nouveau site mieux bâti, plutôt qu'une migration de site brute.

Précautions
Avant de migrer, il faut prendre de nombreuses précautions, dont les suivantes :
Le partage de table peut être très problématique ! A éviter.
Attention aussi à CCK qui n'est pas ISO-fonctionnel avec Fields Core
Attention à la gestion des images dont 2 modules sont passés en core : les mainteneurs des modules D6 n'ont donc pas prévus de version 7, mais ils n'ont pas prévu non plus de chemin de migration. C'est pareil pour Content Profile.

Méthode
La règle d'or : il faut bien suivre les instructions ! Il faut aussi scripter au fur et à mesure les actions réussies, pour pouvoir recommencer depuis le début si nécessaire. Pour ceci, Drush est l'outil idéal, surtout en version 4 ou 5.
Pour les modules, il y a le module coder upgrade (packagé dans le projet upgrade).
Et le futur... D8 ?
Une seule certitude pour se préparer à Drupal 8 : il ne faut pas faire n'importe quoi avec les entités comme on a fait n'importe quoi avec les nodes pendants des années. C'est pourtant ce qui est en train de se passer !

Olivier Pierre

Eternel problème avec Drupal, on fait face à 2 problèmes: La migration de la configuration, et la migration des contenus.

Migration de configuration
Features, hook_update, backup_migrate, le tout avec drush, et des scripts bash.

Features (enfin en version stable!) permet de packager un ensemble fonctionnel sous la forme d’un module drupal (des types de contenus, de la taxonomie, des menus, des vues, des profiles imagecache …).
Les hook_updates permettent d’effectuer des actions en base de données qui n’ont pu être exportées avec une feature. En gros les « cases a cocher » dans l’interface d’admin de drupal.
Backup’n'migrate, avec des profils spécifiques, permet d’exporter uniquement quelques tables. C’est utile, par exemple, pour les tables de la traduction, ou pour la table des permissions. De l’avis général, on utilise backup_migrate en dernier recours.

Migration de contenu
Pour la migration de contenu d’une instance à une autre, on utilise les modules Feeds, Migrate, ou Deploy. Ces modules peuvent aussi être utilisé pour migrer d’un autre CMS à Drupal.