# Gestion de la configuration sous Drupal 7
Sous Drupal 7 et antérieurs, la configuration (entités, champs, vues etc) est exclusivement stockée en base de données. Cela pose des problèmes que tout développeur Drupal a rencontré : toute modification de configuration doit être rejouée manuellement sur les différents environnements : local, développement, recette, production etc.

Pour palier à ces lacunes, l'utilisation de features a été massivement adoptée et, bien qu'imparfaite, cette méthode à longtemps été une référence.

Fort de ce constat, la Configuration Management Initiative a été lancée lors du développement de Drupal 8 de manière à sortir cette configuration de la base de données.

# Drupal 8 et CMI

Avec la Configuration Management Initiative (CMI), Drupal 8 apporte Configuration Management (CM), un module qui gère l'import / export des configurations de Drupal de la base de données vers des fichiers et vice / versa.
Configuration Management permet de versionner une configuration pour un environnement serveur donné. Il est ainsi possible d'avoir des configurations spécifiques pour chaque environnement ou au contraire, partager ces mêmes configurations.

Malheureusement, il ne va pas plus loin en ne permettant qu'un import/export global de la configuration.

Certes, chaque module peut déclarer ses configurations dans son répertoire config/install, mais celui-ci n'est joué qu'à l'installation du module. Lors de l'installation du module, la configuration est ajouté au CM et à la base de données puis ne sera plus utilisé.

Nous avons donc une implémentation partielle des attentes de gestion de la configuration d'un site Drupal durant son développement, sa maintenance, son évolution. Les process auparavant mis en place avec l'aide de Features sur Drupal 7 ont fait leurs preuves et devraient être conservés avec Drupal 8 à condition de trouver les modules adéquats.

# Config Development ou Features

À l'heure actuelle, 2 modules complètent CM de manière à conserver ces process: [Config Development](https://www.drupal.org/project/config_devel) (config_devel) et [Features](https://www.drupal.org/project/features) (features).

## Features
Features a la volonté de se recentrer sur ce pourquoi il a été développé : fournir des fonctionnalités pré-construites à intégrer lors du développement à un site. Exemple: ajouter les bundles, views et autre "configurations" nécessaires à l'ajout d'une fonctionnalité, comme un blog ou un carousel.

Malgré cela, les habitudes ont la peau dur, et il est toujours possible de l'utiliser comme c'était le cas avec Drupal 7.

Pour l'anecdote, Features a dans un premier temps utilisé le module Config Development (qui était en dépendance), avant de le retirer et de suivre sa propre voie.

### Avantages de l'utilisation de Features

* Features intègre toujours son interface très complète qui permet en quelques clics de générer une feature et donc d'isoler des configurations en fichier.
* Feature met à disposition des commandes drush pour gérer l'import / export de configuration pour l'ensemble des features, par module ou par composant.
* L'utilisation de feature pour les développeurs Drupal 7 est identique et ne perdra personne.
* Features n'ajoute qu'un fichier: MONMODULE.features.yml contenant 'true' pour dire que le module intègre des configurations à gérer avec Features. Il s'occupe alors de l'ensemble des fichiers de configurations présents dans le config/install du module.
* Possibilité de voir la différence entre l'état de la configuration du site et la configuration souhaitée pour le module via une commande drush ou l'UI.
* Features permet de visualiser via drush ou UI les configurations du site.
* Features permet de visualiser via drush ou UI les configurations du site qui ne sont pas encore exportées.

### Inconvénients de l'utilisation de Features

* Features nécessite un second module : config_update pour fonctionner.
* Il est impossible de différencier les fichiers de configuration qui doivent être gérés lors d'import / export. Par défaut, tous les fichiers de configuration du module seront écrasés ou rejoués.
* Features ne permet pas d'exporter des configurations qui sont fournies par d'autres modules ou par le core, comme c'est le plus souvent le cas lorsque l'on créé des bundles ou des champs via l'UI.

## Config Development
Config Development fournit des outils pour étendre le module Configuration Management. Il a pour objectif de combler les lacunes de CM.

### Avantages de l'utilisation de Config Development

* Il est possible de voir en un coup d'oeil les configurations gérées par config_devel via la clé config_devel dans le fichier MONMODULE.info.yml.
* Les fichiers de configuration non listés dans la clé config_devel conserveront le fonctionnement initial de CM (prise en compte uniquement à l'installation du module).
* Un seul module à installer.
* Config Development met à disposition des commandes drush pour gérer l'import / export de configuration pour l'ensemble des modules, par module ou par composant.
* Config Development permet d'écraser des configurations mises en place par d'autres modules ou par le core.
* Config Development permet de spécifier les configurations que l'on souhaite mettre à jour automatiquement. Attention toutefois, cette fonctionnalité est à proscrire en production.

### Inconvénients de l'utilisation de Config Development

* Config Development n'embarque pas d'interface tel que Features UI. Il faut se contenter de l'interface par défaut de Configuration Management pour une visualisation UI des configuration disponibles.
* Config Development ne permet pas de savoir, ni par l'UI, ni en ligne de commande, quelles configurations sont déjà exportées dans des modules.
* Toutes les configurations à prendre en compte par le module doivent être listées dans la clé config_devel du fichier MONMODULE.info.yml.
* Config Development ne permet pas de lister via drush les configurations du site. Il est donc obligatoire de passer par l'interface et le formulaire "Simple import" pour connaitre le nom de la configuration à exporter. Autrement, il faut installer le module config_update et utiliser la commande drush config-list.
* Les répertoires config/install doivent déjà exister pour que l'export fonctionne. [Issue en cours #2558299](https://www.drupal.org/node/2558299)

## Le moment du choix

Devant les avantages et inconvénients de chacun, il n'y a pas de choix qui s'impose directement.

Connaissant l'historique de Features, on connait le sérieux de ce module. Il bénéficie déjà d'une très bonne interface et de bons outils.

Config Development, né avec Drupal 8, n'a pas d'interface et a encore quelques lacunes pour pouvoir être utilisé quotidiennement, comme le fait de pouvoir lister les composants disponibles. Il est alors obligatoire de passer par l'interface native a Drupal 8 ce qui est vite laborieux, ou de passer par un module tiers tel que config_update.

Le seul point qui fait pencher la balance en faveur de Config development au détriment de Features est le problème d'export de configurations "Provided by" par Features. Ce point sera une épine énorme au moment du développement, bien dommage étant donné les nombreux avantages qu'aurait pu apporter Features. C'est donc un choix par défaut en faveur de Config Development, à épauler par le module Config Update qui permettra de lister les composants disponibles.

# Autres modules
Les modules suivant n'ont pas attirés mon attention car encore en développements ou étant en deçà au premier regard de ce que pourraient apporter Config Development ou Features.

* [Config Tools](https://www.drupal.org/project/config_tools)
* [Config Reset](https://www.drupal.org/sandbox/jianhe/2165677)
* [Config Synchronizer module](https://www.drupal.org/sandbox/nedjo/2424835)