Apres la sortie de Drupal 7, tout se met en place pour preparer la version 8.

Un des gros changements dans le cycle de développement qui va être mis en place pour Drupal 8 concerne l'apparition des "initiatives". On ne connait pas encore toutes les initiatives qui vont être mises en place, mais celles-ci concerneront sans doute les gros axes de Drupal 8 que Dries a évoqué lors de sa keynote.

La première initiative a été officiellement dévoilée le 28 mars dernier (oui, je sais, j'ai du retard) et concerne la gestion de la configuration de Drupal ("Configuration management" en anglais).
Le terme de "configuration management" peut sembler un peu abstrait pour beaucoup. Dans les faits, il s'agirait, dans l'idéal, d'une sorte de "Settings API" qui permetterait de pouvoir stocker toute la configuration de Drupal de manière plus "propre" qu'actuellement. En deux mots, avoir une sorte de fichier de configuration global.

Depuis features, on se raproche peu-à-peu de ce St Graal Drupalien, néanmoins, features ne couvre pas l'ensemble de nos besoins. Bien sûr, il est désormais facile d'exporter des views, des panels ... et même des variables si on passe via Strongarm. Mais il ne faut pas oublier que ceci n'est possible uniquement si l'auteur du module a pensé à integrer son code avec features.

Le vrai but du "Configuration management" est de proposer un mécanisme permettant de maintenir l'intégrité et la tracabilitée des changements de configuration dans la vie du site. Il serait par exemple possible de :

• "Locker" la configuration d'un site en prod, afin qu'aucun changement ne puisse être effectuté.
• Pouvoir "logguer" les changements de configuration entre le temps t et t+1, rendant alors possible le retour arrière si un soucis est detecté, ou bien encore rendant possible le fait de pouvoir "rejouer" ces changemements sur une autre instance du site

Ces changements ouvriront également la voie un meilleur contrôle du "content staging". Pouvoir fusionner facilement des changements effectués par les utilisateurs du site (les commentaires, les votes, ...) et la configuration d'une instance de dev par exemple, pour y apporter les mises à jour souhaitées, puis ensuite pouvoir reverser tout ceci vers la prod sans soucis majeur.

Comme Dries l'a evoqué lors de sa Keynote, des "Initiative Owner" sont nommé afin de suivre les avancements des ces projets.

Greg Dunlap

C'est Greg Dunlap (heyrocker sur drupal.org) qui sera responsable de cette initiative.
Greg est déjà connu pour avoir énormément contribuer au module Deployment et a déjà beaucoup réfléchi à toutes les problématiques de staging et de déploiement de code.

Espérons qu'il saura réaliser ce que nous attendons tous.

David Strauss

Il sera épaulé par David Strauss, qui sera en charge du suivi de l'architecture et des API à mettre en place.

En attendant, n'oubliez pas de suivre les avancements et reflexions autour de ce projet sur le groups, http://groups.drupal.org/build-systems-change-management