introduction

L'une des plus grandes améliorations apportées à Drupal 8 a été le système de gestion de la configuration (CM). Le déploiement d'un site d'un environnement à un autre implique en quelque sorte la fusion du contenu généré par l'utilisateur sur le site de production avec la configuration générée par le développeur à partir du site de développement. Par le passé, la configuration était exportée en code à l'aide du module Features, dont je suis le responsable principal.

À l'aide du système de gestion de configuration D8, la configuration peut maintenant être exportée vers des fichiers de données YAML en utilisant la fonctionnalité principale de Drupal. C'est encore mieux que Features parce que a) YAML est un format de données approprié au lieu du code PHP qui a été généré par Features, et b) D8 exporte * all * de la configuration, vous assurant de ne pas manquer quelque chose dans votre exportation Features .

    
"Les sites Drupal 8 utilisent toujours des fonctionnalités pour le déploiement de la configuration
    
besoin de passer au workflow de base plus simple. "

Les sites complexes utilisant des fonctionnalités pour une configuration spécifique à l'environnement ou des configurations multisites doivent examiner le module Config Split. Les sites utilisant des fonctionnalités pour regrouper des fonctionnalités réutilisables doivent déterminer si leurs solutions sont réellement réutilisables et étudier de nouvelles options telles que les actions de configuration.

Caractéristiques dans Drupal 8

Lorsque nous avons porté des fonctionnalités sur Drupal 8, nous voulions tirer parti du nouveau système D8 CM et replacer Features dans son cas d'utilisation original de la configuration de l'empaquetage dans des modules pour une fonctionnalité réutilisable. Une nouvelle fonctionnalité a été ajoutée aux fonctionnalités dans D8 pour aider à suggérer quelle configuration doit être exportée ensemble en fonction des dépendances. L'idée était d'arrêter d'utiliser les fonctionnalités pour le déploiement de la configuration et de simplement l'utiliser pour organiser et empaqueter votre configuration.

Nous avons constaté que malgré le nouveau système de gestion de la configuration de base conçu spécifiquement pour le déploiement, les utilisateurs utilisent toujours les fonctionnalités pour déployer la configuration. Il est temps d'arrêter, et à quelques exceptions près, il est peut-être temps d'arrêter complètement d'utiliser les fonctionnalités.

Problèmes d'utilisation de fonctionnalités

Voici une liste de certains problèmes que vous pourriez rencontrer lors de l'utilisation de Features pour gérer votre configuration dans D8:

  •     Les fonctionnalités suggèrent une configuration à exporter avec votre type de contenu, mais après l'exportation, puis l'activation de votre nouveau module, vous obtenez des erreurs de "dépendance non corrigée".
  •     Vous apportez des modifications à la configuration, réexportez votre module de fonctionnalité, puis créez correctement un hook de mise à jour pour "rétablir" la fonctionnalité sur vos autres sites, pour constater que vous obtenez toujours des erreurs pendant le processus de mise à jour.
  •     Vous divisez correctement votre configuration Field Storage à partir de votre instance de champ afin que vous puissiez avoir plusieurs types de contenu partageant le même espace de stockage, mais lorsque vous rétablissez votre fonctionnalité, elle se plaint que la zone de stockage n'existe pas encore. C'est parce que vous ne vous êtes pas rendu compte que vous deviez rétablir la configuration de stockage de champ * first *.
  •     Vous essayez de refactoriser votre configuration en éléments plus modulaires, mais vous rencontrez toujours des erreurs de dépendances circulaires car vous ne vous êtes pas rendu compte que Features n'a pas supprimé les anciennes dépendances de votre fichier module.info (et ne devrait pas le faire).
  •     Vous décidez d'essayer le processus CM principal en utilisant les commandes Drush config-export et config-import, mais après avoir rétabli vos caractéristiques, votre configuration config-export rapporte beaucoup de modifications uuid. Vous ne savez même pas de quoi il parle ni quels changements d'uuids vous devriez accepter.
  •     Vous mettez à jour une partie de votre configuration et réexportez votre module. Lorsque vous rétablissez votre fonctionnalité sur votre serveur de contrôle qualité, vous découvrez qu'il a également écrasé d'autres modifications de configuration effectuées via l'interface utilisateur que quelqu'un a oublié d'ajouter à une autre fonctionnalité.
  •     La liste continue.

Pourquoi les fonctionnalités sont toujours utilisées

Compte tenu de toutes les complications frustrantes avec les fonctionnalités de D8, pourquoi certains l'utilisent-ils encore? Après tout, jusqu'à il y a quelques mois, c'était le flux de travail par défaut même dans des outils tels que Acquia BLT.

La plupart des personnes qui utilisent encore les fonctionnalités appartiennent généralement à deux catégories:

    
"Mon ancien flux de travail D7 utilisant Fonctionnalités semble toujours fonctionner, je suis habitué et je fais face aux nouveaux problèmes, et je n'ai pas les ressources pour mettre à jour mes outils / processus de construction."

    
«Je construis une plate-forme / un site multi-site complexe qui nécessite une configuration différente pour différents sites ou environnements et avoir des fonctionnalités qui rendent tout cela possible. Je n'ai pas à m'inquiéter des UUID de site qui ne correspondent pas. "

Les personnes de la première catégorie ont juste besoin d'apprendre le nouveau workflow de base, plus simple, et de gérer correctement la configuration dans Drupal 8. Ce n'est pas difficile à apprendre et vous épargnerez beaucoup de chagrin pendant la durée de votre projet. Cela vaut vraiment la peine d'investir du temps et des ressources.

Jusqu'à récemment, les personnes de la deuxième catégorie avaient des préoccupations valides parce que le système de CM de base ne gère pas très bien plusieurs environnements, profils, distributions, ou multi-sites. Heureusement, il existe maintenant de meilleures solutions à ces problèmes.

Gestion de la configuration spécifique à l'environnement

Plutôt que d'essayer d'activer différents modules de fonctionnalités dans des environnements différents, utilisez le module Config Split relativement nouveau. Config Split vous permet de créer plusieurs répertoires "sync" de config au lieu de simplement décharger toute votre config dans un seul emplacement. Au cours du processus normal d'importation de configuration, il fusionnera la configuration de ces différents emplacements en fonction de vos paramètres.

Par exemple, vous divisez votre configuration commune dans votre répertoire principal "sync", votre configuration spécifique à la production dans un répertoire "prod" et votre configuration locale spécifique au développement dans un répertoire "dev". Dans votre settings.php vous indiquez à Drupal quel environnement utiliser (typiquement basé sur des variables d'environnement qui vous indiquent sur quel site vous êtes).

Lorsque vous utilisez config-import dans votre environnement de production, il fusionnera le répertoire "prod" avec votre dossier config / sync par défaut, puis importera le résultat. Lorsque vous utilisez config-import dans votre environnement de développement local, il fusionnera le répertoire "dev" avec votre configuration par défaut et l'importera. Ainsi, chaque environnement de site obtient sa configuration correcte. Lorsque vous utilisez config-export pour réexporter votre config, seule la configuration courante dans votre dossier config / sync principal est exportée; il ne contiendra pas la configuration spécifique à l'environnement de votre environnement "dev".

Pensez à cela comme de mettre toutes vos fonctionnalités "dev" dans un répertoire, et vos "prod" fonctionnalités dans un autre répertoire. En fait, vous pouvez même dire à Config Split quels modules activer dans différents environnements et gérer la complexité de la configuration core.extension qui détermine normalement quels modules sont activés.

Acquia a récemment mis à jour ses outils de construction (BLT) pour prendre en charge Config Split par défaut et n'a plus besoin de jouer à ses propres jeux pour décider quels modules activer sur quels sites. Espérons qu'un jour, nous verrons des fonctionnalités comme Config Split ajouté au système de CM de base.

Installation de config via les profils

Un cas d'utilisation courant pour Features consiste à fournir des fonctionnalités packagées communes à un profil ou à une plateforme / distribution multi-site. Les fonctions supprime les identificateurs uniques (UUID) associés aux éléments de configuration exportés vers un module personnalisé, ce qui vous permet d'installer la même configuration sur différents sites. Si vous utilisez simplement config-export pour stocker votre configuration de site dans votre référentiel git pour votre profil, vous ne pourrez pas utiliser config-import pour charger cette configuration dans un site différent car les UUID ne correspondront pas. Ainsi, l'exportation de la configuration spécifique au profil dans les fonctionnalités était un moyen courant de gérer cela.

Drupal 8 core manque encore d'un excellent moyen d'installer un nouveau site en utilisant une configuration préexistante d'un site différent, mais plusieurs solutions sont disponibles:

Correctifs de base

Plusieurs problèmes de base abordent la nécessité d'installer Drupal à partir d'une configuration préexistante, mais dans le cas spécifique d'importation de configuration à partir d'un * profile *, le correctif du numéro 2788777 est actuellement le plus prometteur. Ce correctif principal détectera automatiquement un dossier config / sync dans votre répertoire de profil et importera cette configuration lors de l'installation du profil et définira correctement les UUID de site et les UUID de configuration afin que le site corresponde à ce qui a été exporté. Essentiellement, vous avez un vrai clone du site original. Si vous ne souhaitez pas déplacer votre dossier config / sync dans le profil, vous pouvez également spécifier son emplacement à l'aide de la clé "config_install" dans le fichier profile.info.yml.

Ce correctif n'est pas idéal pour les distributions publiques (telles que Lightning) car il rendrait les UUID du site et la config serait identique sur tous les sites utilisant la distribution. Mais pour les profils spécifiques au projet, cela fonctionne bien pour garantir que tous vos développeurs travaillent sur le même ID de site, quel que soit l'environnement.

Utiliser Drush

Une autre alternative consiste à utiliser une version récente de "drush site-install" en utilisant sa nouvelle option "--config-dir = config / sync". Cette commande va installer votre profil, puis patcher l'UUID du site, puis effectuer une importation de configuration à partir du dossier spécifié. Toutefois, cela pose toujours un problème lors de l'utilisation d'un profil qui crée sa propre configuration, car les UUID de configuration créés au cours du processus d'installation ne correspondent pas à ceux du dossier config / sync. Cela peut conduire à des problèmes obscurs que vous ne détecteriez peut-être pas au début, car Drupal détectera les modifications du schéma d'entité uniquement après l'exécution de cron.

Projet d'installation de configuration

Le projet d'installation de configuration a été une bonne tentative initiale et a permis de sensibiliser les gens au problème et au cas d'utilisation. Il ajoute une étape au processus d'installation D8 normal qui vous permet de télécharger une exportation de configuration / synchronisation archivée à partir d'un autre site ou de spécifier l'emplacement du dossier config / sync à partir duquel importer la configuration. Cela fonctionne pour les sites simples, mais parce que c'est un profil lui-même, il a souvent du mal à installer des sites basés sur des profils plus complexes, tels que les sites créés à partir du Lightning.

Config réutilisable, le cas d'utilisation des caractéristiques d'origine

Lors de la création d'une distribution ou d'un profil de plateforme complexe, vous souhaitez souvent modulariser les fonctionnalités de votre distribution et permettre aux utilisateurs de choisir les pièces qu'ils souhaitent utiliser. Ainsi, vous voulez stocker différents bits de configuration avec les modules qui fournissent réellement les différentes fonctionnalités. Par exemple, en plaçant le type de contenu "blog", les champs et autres config dans le module "blog" de la distribution afin de pouvoir les réutiliser sur plusieurs instances de site. Cela a souvent été accompli en créant une "fonctionnalité de blog" et en utilisant les fonctionnalités pour exporter toute la configuration "blog" liée à votre module personnalisé.

N'est-ce pas ce que Features a été conçu? Pour empaqueter des fonctionnalités réutilisables? La réalité est que, bien que ce soit l'intention, les modules d'entités sont intrinsèquement * non * réutilisables. Lorsque vous exportez la configuration "blog" vers votre module, tous les noms de machine de vos champs et types de contenu sont exportés. Si vous avez correctement nommé vos noms de machines avec votre préfixe de projet, votre préfixe de projet fait maintenant partie de votre fonctionnalité.

Lorsqu'un autre projet tente de réutiliser votre "fonctionnalité de blog", il doit soit laisser les noms de vos machines spécifiques au projet, soit modifier manuellement tous les fichiers pour les modifier. Cela limite la possibilité de réutiliser correctement la fonctionnalité et de l'améliorer de manière incrémentielle sur plusieurs projets.

Créer des fonctionnalités réutilisables sur des sites complexes du monde réel est un problème très difficile et propager des mises à jour sans casser ou perdre les améliorations qui ont été faites le rend encore plus difficile. Parfois, vous aurez besoin de dépendances croisées, comme un champ «contenu connexe» qui est utilisé à la fois sur les articles et les blogs et qui doit faire référence à d'autres nœuds article et blog. Cela peut ressembler à une dépendance circulaire (ce n'est pas le cas) et vous oblige à diviser vos fonctionnalités en composants plus petits. Cela rend également beaucoup plus difficile la modularisation en une solution réutilisable. Comment votre fonctionnalité «contenu connexe» est-elle censée savoir quels types de contenu sont sur votre site spécifique et dont elle pourrait avoir besoin?

Modèles de configuration

Nous avons récemment créé les modules Config Actions et Config Templates pour répondre à ce besoin. Il vous permet de remplacer les noms de machines dans vos fichiers de configuration par des variables et de les stocker en tant que "modèle". Vous pouvez ensuite utiliser une "action" pour référencer ce modèle et fournir des valeurs pour la variable et importer la configuration résultante.

D'une certaine manière, ceci est similaire à la façon dont la fonctionnalité réutilisable est obtenue dans un thème en utilisant SASS au lieu de CSS. Au lieu de coder en dur les noms propres à votre projet dans le CSS, vous créez un ensemble de fichiers SASS qui utilisent des variables. Vous créez ensuite un fichier qui fournit toutes les valeurs de variables spécifiques au projet, puis "incluez" les composants SASS réutilisables. Enfin, vous "compilez" le SASS dans le CSS réel que le site doit exécuter.

Config Actions prend vos modèles et actions et les "exécute" en important la configuration résultante dans votre site D8, que vous gérez ensuite en utilisant le processus normal de gestion de la configuration. Cela vous permet de diviser votre configuration en modèles / actions réutilisables et les valeurs de variables spécifiques au site nécessaires pour votre projet. Les modèles de configuration utilisent en fait l'interface utilisateur des fonctionnalités pour vous aider à exporter votre configuration en tant que modèles et actions afin de la rendre plus utilisable.

Restez à l'écoute de mon prochain blog où j'expliquerai plus en détail comment utiliser Config Actions et Config Templates pour créer des solutions réutilisables et d'autres astuces de gestion de la configuration.

Conclusion

Alors que le système de gestion de configuration de Drupal 8 est un grand pas en avant, il est encore un peu difficile lorsqu'il s'agit de sites complexes du monde réel. Même si j'ai déjà blogué sur les «meilleures pratiques» en utilisant une combinaison de fonctionnalités et CM de base, des outils récents tels que Config Split, l'installation de config avec des profils et des modèles et actions de configuration aident à résoudre ces problèmes. Le module Features n'est vraiment plus nécessaire et ne doit pas être utilisé pour déployer la configuration. Cependant, Features fournit toujours un puissant système d'interface utilisateur et de plugin pour gérer la configuration et, en combinaison avec de nouveaux modules tels que Config Actions, il pourrait enfin réaliser son rêve d'intégrer des fonctionnalités réutilisables.

Pour en savoir plus sur Advanced Configuration Management, venez à ma prochaine session à GovCon 2017 ou DrupalCamp Costa Rica. On se voit là-bas!

Ajouter un commentaire

CAPTCHA

Cette question permet de tester si vous êtes un visiteur humain et d'empêcher les soumissions automatiques de spam.

Selectionnez les trois images avec des arbres:
Creative Commons Licence