CMI : ... à la pratique

Nous avons précédemment vu la théorie à propos de CMI. C’est maintenant le moment de voir comment s’en servir dans des conditions réelles.

Afin de faire nos tests, je vous propose de monter deux Drupal 8 en parallèle. Appelons les Drupal-Prod et Drupal-Dev. Pour se faire, il suffit d’installer un Drupal 8 d’un côté, de prendre sa base de données et de l’injecter dans un second site.

Pour le moment, allons sur l’instance dite “dev” et faisons un petit changement rapide. Par exemple, allons changer le slogan du site.

Allez maintenant dans Configuration > Configuration Management > Onglet Full import/export > Export et cliquez sur le bouton export. Vous allez obtenir un fichier config.tar.gz

Gardez bien ce fichier au chaud, et allez faire un tour sur le 2ème site.

Sur la page Configuration > Configuration Management > Onglet Full import/export > Import, allez chercher votre config.tar.gz et uploadez le.

Si tout se passe bien, vous allez donc voir la page suivante vous indiquant qu’un élément a été modifié.

Cliquez sur le lien “View differences” et Drupal va vous montrer votre changement sous forme de “diff” directement.

Il suffit maintenant de valider les changements en soumettant le formulaire.
Et voilà, vos changements sont maintenant présents sur votre deuxième site.

Jusqu’ici, on aurait pu se contenter de transférer la base de données de “dev” sur “prod” et nous aurions eu le même résultat.
Néanmoins, n’oubliez pas une chose. Nous transférons ici uniquement de la configuration, et non du contenu. Cela signifie que le site de “prod” peut continuer à être alimenté en contenu, pendant que vous allez transférer la nouvelle configuration en production.

Utiliser CMI au sein d'une équipe

Le point important ici est: comment utiliser ce système afin de collaborer à plusieurs ?

Tout d’abord, il faut savoir que, par défaut, Drupal stocke les fichiers de configuration (les fameux fichiers « yaml ») dans un répertoire situé dans /sites/default/config/ avec une clé de hash. Cela doit ressembler à quelque chose du genre :

sites/default/files/config_1yrma6v3CrXoB35-RirGI9HNjvq1YBRNEHhezKiV6xdE6d4RiG6yrTu4el6LwKci1nuqjKtptA/staging 

Néanmoins, et fort heureusement, ceci est facilement modifiable. En effet, cette clé est stockée dans votre settings.php, sous la forme :

$config_directories['staging'] = 'sites/default/files/config_1yrma6v3CrXoB35-RirGI9HNjvq1YBRNEHhezKiV6xdE6d4RiG6yrTu4el6LwKci1nuqjKtptA/staging’; 

Il suffit donc de changer cette clé ici pour avoir quelque chose de plus « lisible », ou même de placer ce répertoire en dehors du webroot (bonne pratique de sécurité).

Pour notre test, changeons donc les deux clés du settings.php en :

$config_directories['active'] = 'sites/default/files/config_active';
$config_directories['staging'] = 'sites/default/files/config_staging';

Et maintenant, comment collaborer ? C’est une chose relativement simple, à condition que chacun suive la même procédure.

Pour illustrer ceci, nous allons utiliser l’export/import de configuration via drush.

Les commandes importantes sont :

config-export (cex)   Export config from the active directory. 
config-import (cim)   Import config from a config directory.

Pour commencer, lançons un export sur le site de production.

files git:(8.x) drush cex
The current contents of your export directory (sites/default/files/config_staging) will be deleted. (y/n): y
Configuration successfully exported to sites/default/files/config_staging.[success] 

Puis commitez cette configuration initiale dans votre dépôt de code (git, svn …)

Chacun des développeurs va maintenant mettre à jour son dépôt local, puis importer la configuration.

A partir de ce moment, nous allons pouvoir chacun faire nos modifications en local, avant d’exporter à nouveau la configuration via drush, puis de commiter les changements.

L’agrégation des changements va se faire grâce à notre système de versionning de code.

Une fois la configuration d’une partie du site effectuée, la production sera alors mise à jour, la configuration à nouveau importée, et les changements seronts alors présent en production.
Tout simplement.

La solution repose donc, pour l’instant, sur un mélange entre ce qu’offre CMI et les fonctionnalités du gestionnaire de code (on ne le dira jamais assez, même si vous travaillez seul, c’est indispensable).
Personnellement, je ne pense pas que cela va beaucoup changer d’ici à la sortie de Drupal 8. Il va sûrement falloir se tourner vers la contrib afin de voir des solutions tierces, reposant sur ce qu’offre CMI, afin de réaliser ceci sans s’appuyer sur un gestionnaire de versionning de code.

Si vous souhaitez aller encore plus loin, nous ne pouvons que vous recommander la lecture de l'article produit par Nuvole : Packaging and reusing configuration in Drupal 8 [en]