Le module Features fait partie des solutions d'industrialisation que nous présentons dans notre formation Drupal pour les développeurs.

Un peu d'histoire

Le module Features a été créé en Drupal 6, par la société Development Seed. Le besoin couvert était d'exporter facilement des types de contenus et des vues pour pouvoir déployer ces "configurations" sur d'autres sites Drupal.

L'usage était double : d'une part réutiliser des types de contenus (actualité, événement, …) d'un site à un autre ; d'autre part, déployer en pré-production puis en production les fonctionnalités réalisées en développement.

Couverture fonctionnelle

Initialement limité, l'utilisation du module s'est vraiment répandue avec Drupal 7 pour devenir LA méthode privilégiée de déploiement de configuration d'un environnement de développement à un environnement de production. Le module s'est donc peu à peu enrichi pour exporter :

• Types de contenus & champs
• Vues (du module Views)
• Panneaux (du module Panels)
• Rôles
• Permissions
• Vocabulaires de taxonomie (pas les termes)
• Configuration d'import de flux (du module Feeds)
• Variables (à l'aide du module Strongarm)
• Nodequeues, formats de date et blocs (à l'aide de Features Extra)
• Contenus (à l'aide de Node Export ou UUID Features integration)
• Et tout ce qui peut-être exporté grâce à l'interface CTools Exportables

On peut donc pratiquement tout exporter (et importer) !

Processus de développement

Le gros intérêt de Features est de permettre la construction de son site en s'appuyant sur les possibilités de Drupal, puis d'exporter en une fois de nombreux éléments du site (soit en utilisant l'interface, soit, plus pratique pour les développeurs, la commande drush feature-export (aliasée en drush fe)).

Autre avantage : tout est dans du code, il est donc facile de constater les différences entre plusieurs versions de la Feature, notamment en utilisant le système de diff de votre outil de gestion de versions.

Une fois la Feature créée, c'est un module Drupal, on peut donc l'activer sur le site sur lequel on veut déployer les éléments.

Quand la Feature est installée, vous pouvez :

• Modifier à nouveau l'interface, et mettre à jour le code pour ré-exporter cette Feature (drush feature-update ou drush fu) ;
• Modifier le code (par exemple, déployer en production une nouvelle version de la Feature), et mettre à jour l'interface depuis le code (drush feature-revert ou drush fr).

Ce processus vous est bien détaillé dans cette présentation. Le seul (mais important) problème se pose quand les éléments de la Features sont modifiés à la fois d'un côté (le développement) et de l'autre (par le client en production).

Tous les clients sont différents

Nous rencontrons des clients avec tous les profils, techniques ou pas du tout. Cependant, une des forces de Drupal est de permettre aux utilisateurs, avec un minimum de compétence, de modifier de nombreux paramètres du site.

Makina Corpus met un point d'honneur à former tous les clients pour qui nous réalisons des sites, afin de leur fournir un maximum d'autonomie sur leurs sites, le but ultime étant qu'ils soient complètement autonomes.

Bien sûr, il est confortable de penser maitriser l'intégralité de la construction du site, mais nous ne maitrisons jamais vraiment ce que va faire le client. Dès lors, il devient pénible de mettre dans une Feature tout ce que le client va essayer de modifier, puisque il nous faudra alors sans cesse comparer l'état de la production avec notre code en cours de développement, et donc prendre plus de temps pour de (normalement) simples modifications. Nous devons donc adapter nos processus de développements en fonction du profil du client auquel nous sommes confrontés.

Une bonne idée pour reprendre petit à petit le contrôle précis de nos actions est de ne JAMAIS faire de revert global de nos Features : bannissez la pourtant si utile commande drush fra -y. Par contre, rétablissez une partie spécifique de la Feature : drush feature-revert ma_feature.views_view ne rétablira que les Views. Ainsi, si le client a modifié autre chose, ce ne sera pas impacté par vos modifications, même si c'était inclus dans la Feature initiale.

Pour ne pas oublier de faire ces commandes ciblées lors du déploiement, qui intervient parfois longtemps après le développement, mettez les dans un hook_update :

module_load_include('inc', 'features', 'features.export');
features_include();
$revert = array(
  'feature1' => array('field'),
  'feature2' => array('views_view'),
  'feature3' => array('field', 'field_group'),
);
features_revert($revert);

Et voilà, votre procédure de déploiement est désormais :

git pull && drush updb

Ce que je ne mets plus dans Features

Les permissions

Les permissions sont des données qui peuvent changer très souvent au long de la vie du site : le client va ajouter des rôles et leur donner des droits. Autant ne pas les fixer dans une Feature, et laisser toute liberté au client de les modifier. Vous pouvez d'ailleurs les fixer initialement avec lui lors d'une discussion en direct, c'est l'occasion de le former aux permissions Drupal.

Les variables

Très peu de temps après la sortie de Features, le module Strongarm est venu ajouter le support des variables et est aujourd'hui utilisé par la plupart des distributions Drupal.

Il y a 2 types de variables :

• Les variables "techniques", qui NE doivent PAS être modifiées par le client, et qui n'ont alors rien à faire dans une Feature : leur place est directement dans le fichier settings.php (ou, mieux, dans un env.settings.php dépendant de l'environnement) ;
• Les variables fonctionnelles, qui relèvent plus de la configuration du site, et qui, parfois, peuvent être modifiées par le client. Leur place n'est alors pas non plus dans un fichier .strongarm.inc, mais vous pouvez (devez ?) fournir une configuration par défaut fonctionnelle en utilisant des variable_set() dans le fichier .install de vos features.

Le contenu

Déployer proprement du contenu d'un environnement à l'autre est toujours un souci en Drupal et cette opération mériterait à elle seule un (voire plusieurs) article(s) de blog. Je peux simplement vous dire qu'en utilisant le module Node Export, le contenu est facilement exporté dans la Feature. Mais chaque revert de cette Feature va recréer le contenu. C'est donc utilisable pour un import initial de site, mais pas pour des mises à jour régulières.

De manière générale, le contenu est de la responsabilité du client, et c'est bien pour cela que nous le formons à utiliser son site.

Il faut parfois apprendre à lâcher prise

Développeurs, si après tout ça, vous souhaitez encore tout contrôler et ne laisser aucune possibilité à votre client de changer quoi que ce soit dans le site, il est possible que Drupal ne soit pas la solution que vous auriez dû choisir pour réaliser le site.

Il faut savoir parfois perdre un peu de contrôle pour offrir la meilleure expérience possible au client.