Vous êtes ici

Dries Buytaert à la DrupalCon de Barcelone - Processus de développement de Drupal 8

Dries Buytaert durant la Driesnote au DrupalCamp de Barcelone

La semaine dernière a eu lieu la DrupalCon de Barcelone. Drupal 8 étant sur le point de sortir (en RC1 du moins), j’attendais pour ma part avec impatience l’intervention de Dries Buytaert - le créateur de Drupal - lors de sa "Driesnote" pour avoir la vision du maitre autour de Drupal 8 : Quid de la difficile mise au point de celui-ci, Quels axes d’évolution pour l’avenir, et de quelle façon dont ceux-ci vont être être mis en œuvre.

Je n'ai malheureusement pas pu assister à l'évènement, mais la vidéo de l'intervention est disponible sur la chaîne YouTube de la Drupal Association.

La présentation de Dries se présente en en 3 parties :

  • Processus de développement
  • Position marketing
  • Pertinence technique

Voici donc une petite synthèse de la première partie « Processus de développement »


Processus de développement

Drupal est-t-il en perte de vitesse ?

Oui, c’est vrai en ce moment, mais c’est une conséquence de l’effet Osbourne qui veut que toute annonce d’une nouvelle version d’un produit génère un recul sur la version actuelle du produit (puisque son obsolescence est annoncée). Ceci est déjà arrivé pour Drupal 6 lors de la sortie de Drupal 7, mais une fois la version de Drupal 7 sortie, elle a créé un véritable appel d’air et Drupal 7 a largement dépassé Drupal 6 en termes de nombre de sites réalisés. Drupal 8 devrait produire le même effet et Dries est confiant sur ce point :

Le conseil de Dries : Commencez à développer vos sites en Drupal 8 dès maintenant quand vous le pouvez : Même si celui-ci n’est pas officiellement sorti,  pour certains types de projets simples n’ayant besoin que du core, il peut être utilisé dès maintenant !

Pourquoi  Drupal 8 n’a-t-il pas été prêt à temps ?

Au jour de la keynote, il reste un 1 seul bug vraiment bloquant en relation avec TWIG, et la date prévue par Dries pour la release de la RC1 est le 7 octobre 2015 (Applaudissements dans la salle)

Mais ce fut un long (et pénible) voyage :

  • 1024 jours - soit presque 3 ans - depuis la « Feature Freeze » (définition des fonctionnalités intégrant Drupal 8)
  • Sur les (presque) 15 ans d’existence de Drupal, (presque) 5 ans ont été passés au développement et à la mise au point de Drupal 8 ce qui est énorme par rapport aux autres versions de Drupal.
  • Ce n’est pas sain et c’est beaucoup trop long !

Premier constat : Personne n’est à blâmer sur ce point (excepté peut-être Dries  lui-même, dit-il dans un petit élan d’autocritique) : L’effort de la communauté fut énorme et doit être salué !

La première raison du retard pris fut un manque de maitrise du périmètre fonctionnel du projet Drupal 8 qui a subi de nombreux changements durant toute sa phase de mise au point :

Dries  évoque également un manque de réalisme par rapport au temps nécessaire au développement des fonctionnalités, Par ailleurs, il pointe aussi des erreurs de choix organisationnels dans la stratégie de sortie de Drupal 8 : Dans le modèle d’organisation actuel, toutes les fonctionnalités de Drupal 8 doivent être prêtes pour pouvoir sortir Drupal 8. Celui-ci aurait pu sortir il y a déjà plusieurs mois si certaines fonctionnalités avaient été mise de côté et certaines fonctionnalités sont stables depuis déjà bien plus d’un an.

Aujourd’hui, seule la fonctionnalité TWIG est encore réellement bloquante pour la sortie de Drupal 8.

Conclusion : Il ne faut plus travailler ainsi !

Drupal devrait désormais adopter une autre stratégie pour ses releases basées sur des cycles plus courts intégrant les lots de fonctionnalités terminées sans nécessairement attendre que tout soit prêt (voir ) : Si une ou plusieurs fonctionnalités sont en retard : elles pourront être reportées dans une version ultérieure. Cela n’est pas sans poser quelques problèmes (notamment parce que certaines fonctionnalités peuvent avoir des dépendances entre elles) mais globalement il peut être plus avantageux de reprendre le code d’une fonctionnalité A qui est terminée pour supprimer les parties relatives une fonctionnalité B non terminée plutôt que d’attendre que la fonctionnalité B soit terminée : Un arbitrage entre impact sur la version et bénéfice pour celle-ci devrait permettre de figer des versions mais l’objectif sera avant tout de fluidifier le cycle de publication de Drupal et de conserver une branche principale toujours fonctionnelle et distribuable. Dries juge que ce point est absolument fondamental pour la survie de Drupal.