Le premier projet en Drupal 8

Le premier projet que vous allez faire est l'occasion de monter en compétences, de découvrir l'éco-système, il est courant pour des "shops" Drupal de refaire leur site, sans pression d'un client. Certaines sociétés sont également en train de chercher le "parfait" projet pour se lancer en Drupal 8 : beaucoup de gestion de contenu, peu de fonctionnalités, un petit projet, par exemple.

Faute de ce premier projet, vos équipes restent plus compétentes sur Drupal 7, et cela restera probablement un critère de décision sur la version de Drupal à utiliser.

Cela dit, l'état du développement du cœur est actuellement rassurant, de plus en plus de fonctionalités sont stables, puissantes, utilisables. Pour un site vitrine / brochure, aujourd'hui, les fonctionnalités de gestion de contenus du cœur sont tout à fait opérationnelles, et même meilleures que Drupal 7 (WYSIWYG bien intégré, beaucoup de champs nativement).

Une initiative prudente parlait de réaliser son site Drupal 8 en "Headless", pour pouvoir éventuellement débrancher le back-end Drupal en cas de problèmes de stabilité et le remplacer par un autre système, minisant la perte éventuelle.

Et si les clients l'imposent ?

Actuellement, l'état des modules communautaires n'est pas suffisant pour implémenter un gros site (200 - 300 k€) en Drupal (et ne le sera pas pour plusieurs mois). La plupart des clients (sinon tous) ne sont pas prêts à payer le coût de port des modules en Drupal 8. Selon la date de livraison du projet, Drupal 7 reste un très bon choix pour les projets actuels : c'est stable, beaucoup de modules sont disponibles, les équipes de développement sont compétentes, et Drupal 7 sera maintenu pendant encore quelques années.

Pour un plus petit projet, il est éventuellement possible de démarrer sur Drupal 8, et d'ajouter ensuite des choses petit à petit quand elles seront disponibles.

Certains clients n'ont pas de notion de "version", ils veulent juste du Drupal, et dans ce cas, c'est à vous de choisir selon la version la plus adaptée au besoin du client.

Quelle version du cœur utiliser ?

Les projets choisis par les différentes sociétés qui participaient à cette discussion sont différents et dépendent en grande partie de l'équipe de ces sociétés : ceux qui possèdent beaucoup de développeurs du cœur ont tendance à utiliser la toute dernière version de développement du cœur (et même à ne plus du tout faire de projet D7, pour rentabiliser leur investissement en Drupal 8, quitte à éventuellement faire de légères pertes sur les premiers projets), tandis que les autres sociétés utilisent plutôt la toute dernière version beta (plus stable, et donc moins "risquée"), d'autant que les modules de la communauté se réfèrent régulièrement à une version fixe du cœur.

Certains clients sont prêts à participer au surcoût de développement actuellement généré par utiliser Drupal 8 (entre 50 et 150%), parce qu'ils en voient la valeur ajoutée.

En règle générale, on recommendera pour des raisons de stabilité d'utiliser la dernière version "fixée" (actuellement, beta), mais au final, la décision dépend effectivement de votre équipe, et de ses compétences.

Quels sont les problèmes les plus courants ?

Le workflow de travail avec la Configuration Management Interface n'est pas encore très utilisé, et on rencontre par exemple un problème lors de la suppression de données de configuration (git va supprimer le fichier lors du merge, il n'y a pas de statut "surchargé" en production). Heureusement, un port du module Features basé sur CMI est en cours. A tester également, la nouvelle commande drush config-merge.
En fait, plus simplement, il y a une API CMI, mais aucun workflow standard pour l'utiliser n'a été défini. Cela dit, comparer et réviser les fichiers YML est plus simple que les exports PHP de Features.

Beaucoup de modules communautaires sont actuellement en développement sur GitHub, et reversés périodiquement sur drupal.org quand ils sont stabilisés. Ils sont donc parfois plus difficile à localiser. Vous pouvez cependant en trouver un certain nombre sur le dépot de MD-Systems.

La migration depuis des versions précédentes

Depuis Drupal 8

Si votre site est déjà en Drupal8, il est plus facile de mettre à jour votre site de version beta en version beta (et, le temps passant, de plus en plus facile à chaque beta) que de suivre les versions de développement, d'autant que certaines migrations sont facilitées par le module HEAD to HEAD (et surtout son sous-module beta to beta).

Il est courant pour certains de disposer d'un profil d'installation (évoluant à chaque beta de D8) et de se contenter de (re-)charger le contenu à chaque nouvelle bêta (depuis des fichiers ou des web-services).

Il est cependant difficile de planifier les migrations de versions, parce que leur fréquence dépend des mises à jour du cœur, et les coûts associés à chaque migration dépendent du volume (et de la criticité) des changements.

Depuis Drupal 7 (ou un autre système)

Depuis Drupal 7, certaines sociétés contribuent leurs scripts de migration, c'est le cas par exemple pour AmazeeLabs.

De façon plus générale, la plupart des sociétés ayant déjà réalisé une migration l'ont fait en montant le site depuis rien en Drupal 8, en exposant des web-services sur le site original, et en consommant ces web-services pour remplir le contenu depuis le site Drupal 8. L'avantage de cette stratégie est qu'elle fonctionne depuis n'importe quel site, qu'il soit en Drupal (quel que soit sa version) ou dans une autre technologie.

En conclusion

Des critères comme un site multilingue, fonctionnellement simple, basé sur du contenu, permettent de déjà se décider pour lancer des projets en D8. Cela permettra notamment une montée en compétence le plus tôt possible, mais également un feedback pour la communauté permettant d'accélérer la stabilisation de Drupal 8 en remontant des anomalies de cas concrets de mise en place de sites.

Suite à cette discussion, un groupe Drupal a été créé, pour ceux qui souhaitent suivre les évolutions des idées et discussions.

Merci à tous les participants à cette discussion : @dasjo, @Schnitzel, @OSInet, @miro_dietiker, @berdir, @mariancalinro, @nlisgo.