Bienvenue au pays de F ONCTIONS C onfiguration M estion, alias FCM ! Il ne s'agit pas seulement de fonctionnalités , et non de gestion de la configuration (comme introduit dans Drupal version 8). , Il est plutôt un cas particulier de S oftware C onfiguration M estion , alias SCM . Principalement parce que les fonctionnalités peuvent être considérées comme un générateur de code, alors que le code généré doit être migré dans plusieurs environnements. Lire la suite pour plus de détails.
1 - Avantages et inconvénients de l'utilisation des fonctionnalités
Avantages de l'utilisation des fonctionnalités
- Automatisez le déploiement des modifications appliquées à un site de développement Drupal sur un ou plusieurs sites de (pré) production Drupal cibles (au lieu du déploiement manuel).
- Facilite le partage (expédition) du développement Drupal en cours entre les développeurs / constructeurs de sites Drupal (par exemple, pour mettre certaines vues créées par un expert des vues à la disposition d'un Drupal Themer travaillant dans un autre site de développement pour thématiser cette vue).
- Excellente intégration avec GIT et Drush pour expédier une copie du code généré par les fonctionnalités (sur le site de développement) aux sites de (pré-) production cibles sélectionnés.
Inconvénients de l'utilisation des fonctionnalités
- Éviter les conflits de fonctionnalités et / ou gérer les dépendances de fonctionnalités peut être difficile!
- Il n'est pas facile de commencer à utiliser les fonctionnalités sur un site (de production) existant.
- L'installation / activation du module Fonctionnalités est facile (juste un module), mais apprendre à utiliser correctement les fonctionnalités est un défi majeur.
2 - Techniques de packaging des fonctionnalités
À l'aide des fonctionnalités, il appartient à votre imagination d'imaginer (composer) le contenu d'une fonctionnalité. Voici quelques techniques qui peuvent être utilisées pour cela.
Une seule super fonctionnalité
Il s'agit d'une technique d'emballage assez simple: tout est emballé ensemble dans une seule fonctionnalité (certains l'appellent la fonctionnalité "Dieu" ...). Cela semble facile, assez avancé, etc. Mais cette technique conduit aussi à des "conflits" (comme expliqué ci-dessous) plus ou moins tout de suite ...
Un bon cas d'utilisation semble être lors de la création d'une "distribution Drupal", où tous les utilisateurs de celle-ci sont supposés utiliser le même ensemble de modules, de configuration, etc. "fonctionnalités" ...), il semble plus approprié de diviser ces fonctionnalités en plusieurs fonctionnalités, comme expliqué ci-dessous.
Basé sur la fonctionnalité du site Web
Cette technique de packaging crée une fonctionnalité séparée pour chaque fonctionnalité d'un site Web, telle que:
- Fonctionnalité A = implémenter une " * Galerie ".
- Fonction B = implémentation d'un " * Blog ".
- Fonctionnalité C = implémenter un " * Calendrier des événements ".
Basé sur les sections d'administration Drupal
Cette technique de packaging crée des fonctionnalités séparées pour chacune des (principales) sections d'administration d'un site Web Drupal utilisé pour créer le site, telles que:
- Tous les modules requis sont contenus dans la fonction A,
- Toutes les définitions de champ de base sont contenues dans la fonction B,
- Tous les types de contenu sont contenus dans la fonctionnalité C,
- Toutes les autorisations sont contenues dans la fonctionnalité D,
- Tous les rôles sont contenus dans la fonctionnalité E,
- Toutes les variables sont contenues dans la fonction F,
- Toutes les vues (personnalisées) sont contenues dans la fonction G,
- Toutes les règles (personnalisées) sont contenues dans la fonction H,
- Etc.
La liste ci-dessus est pratiquement illimitée: au final, vous pourriez même la considérer comme une fonctionnalité pour chaque option du menu d'administration Drupal ... si vous voulez aller aussi loin.
L'OMI est également l'approche la plus recommandée pour les fonctionnalités de package.
3 - Réduire la probabilité de conflits dans les fonctionnalités et / ou GIT
Ne réutilisez pas les champs
Un bon nombre de conflits semblent être causés par la réutilisation des champs parmi plusieurs types de contenu. Par exemple, dans le type de contenu A, vous avez un champ avec le nom de la machine field_somefield, qui est également utilisé comme champ dans le type de contenu B avec le même nom de machine field_somefieldmais qui comme un autre type de champ et / ou d'autres paramètres de champ différents.
En ne réutilisant pas les champs parmi les types de contenu, vous évitez d'exécuter ce problème. Jetez un œil à une convention de dénomination intéressante pour le nom de machine de vos types de contenu et de vos champs, comme indiqué dans le tableau de Wrapping Information Architecture and Documentation , qui fait partie des articles sur " Modèle de relativité pour Drupal ". Pour plus de détails à ce sujet, reportez-vous à ma réponse à " Comment modéliser le contenu (types) d'un point de vue centré sur la base de données? ".
Diviser les fonctionnalités en fonction de qui travaille sur quoi
Si plusieurs personnes travaillent sur un même site, le nombre de conflits peut être réduit en organisant (= en créant des fonctionnalités distinctes) en fonction de qui travaille sur quoi. Une illustration de ceci pourrait être comme dans cet exemple:
- Les vues vont dans la fonction A,
- Les règles vont dans la fonction B,
- Les graphiques vont dans la fonction C,
- Tout ce qui concerne Theming va dans la fonction D,
4 - Environnements Drupal recommandés
Tout ce qui précède devrait aider à faciliter l'utilisation des fonctionnalités . Cependant, pour vous assurer que les choses fonctionnent comme prévu (conçu), vous devez également disposer d'un ensemble approprié d'environnements (sites Web Drupal liés logiquement) pour essentiellement ces raisons:
- fusionner les fonctionnalités fournies par plusieurs fonctionnalités.
- prévoir et résoudre les conflits.
- test par l'utilisateur final de toutes les fonctionnalités fusionnées certifiées sans conflit.
Dans le monde idéal, ces sites Web Drupal logiquement liés devraient être configurés et utilisés, comme ceci:
- Site de développement personnel - chaque développeur de site Web a un site de développement séparé. Lorsqu'une partie du développement est prête à être partagée avec quelqu'un d'autre, une fonctionnalité appropriée est créée, qui est envoyée à l'environnement de transfert.
- Site Sandbox - il s'agit d'un environnement Drupal qui ne contient que le noyau Drupal, utilisé pour tester à l'unité l'exhaustivité d'une seule fonctionnalité. Si une fonctionnalité, accidentellement, présente des dépendances inattendues (par exemple, un module dont dépend la fonctionnalité, qui n'est pas activé dans le bac à sable), c'est là que cette dépendance deviendra claire.
- Site intermédiaire - c'est ici que sont livrées une ou plusieurs fonctionnalités (créées dans un site de développement). Ce pourrait être juste un correctif pour un problème de production, ou ce pourrait être l'endroit où tout le développement d'une nouvelle version du site Web est consolidé. S'il existe des conflits entre plusieurs fonctionnalités, c'est dans cet environnement qu'ils apparaîtront d'abord ... et doivent être résolus d'une manière ou d'une autre.
- Site QA - une fois que l'environnement de staging est considéré comme stable, il est temps de passer aux fonctionnalités pertinentes et de les rendre disponibles également à un niveau supérieur où elles peuvent être utilisées pour les tests QA, les tests d'acceptation, les tests de volume, etc. À ce niveau, vous devrait être extrêmement prudent en autorisant tout changement supplémentaire (le cas échéant). Parce qu'une telle modification peut invalider tous les efforts de test antérieurs déjà effectués dans cet environnement.
- Site de production fantôme - Pour préparer l'activation en production réelle, vous souhaiterez peut-être d'abord promouvoir davantage les fonctionnalités pertinentes dans un environnement qui est considéré comme une copie (ombre) de votre environnement de production réel. Si, à ce stade du processus de migration, quelque chose ne fonctionne toujours pas, il s'agit d'un indicateur rouge pour annuler certaines de vos étapes précédentes. Faites-le réparer et réessayez jusqu'à ce que toutes les parties concernées approuvent les modifications.
- Site (s) de production - Si vous avez terminé toutes les étapes précédentes, cette étape devrait être explicite et assez simple. En fonction de vos besoins, il peut s'agir d'un site unique, ou de quelque chose d'équivalent aux Multi-sites de Drupal alors que tous les sites impliqués utilisent les mêmes versions de toutes les fonctionnalités.
- Site de base - D'après mon expérience, il n'y a pas beaucoup (voire pas du tout) d'implémentations Drupal où ce type de site est utilisé (également). Il s'agit simplement d'une copie du ou des sites de production, mais disponible pour les développeurs Drupal, les testeurs, etc. qui peuvent être utilisés pour vérifier à quoi ressemblent les sites de production, ou pour effectuer une formation utilisateur, etc. Et chaque fois qu'un nouveau développement cycle est démarré, les composants d'un site qui seront impactés (doivent être modifiés) doivent être "copiés d'une manière ou d'une autre" en utilisant ce site de référence comme entrée, avec comme cible un site de développement personnel .
De toute évidence, l'inventaire ci-dessus des types de sites Drupal est comme le monde idéal. Selon la taille de votre équipe de développement et / ou les budgets disponibles pour les créer et les maintenir, ils ne peuvent pas tous être utilisés (ou abordables). Cet inventaire est calqué sur les meilleures pratiques dans le domaine de la GCA, utilisées dans la plupart des grandes sociétés mondiales (banques, compagnies aériennes, etc.).
5 - Modules associés
Bras fort
Le module Strongarm permet d'exporter des variables (des modules qui stockent leurs paramètres dans des variables) avec le module Fonctionnalités.
Exportation de noeud
Le module d' exportation de noeud permet aux utilisateurs d'exporter des noeuds puis de l'importer dans une autre installation Drupal.
Exportation de rôle
Le module d' exportation de rôles permet aux rôles d'avoir des noms de machine et génère un identifiant de rôle unique (rid) basé sur le nom de machine. Les rôles peuvent être exportés avec les fonctionnalités et obtenir exactement la même suppression s'ils sont importés sur d'autres sites.
Caractéristiques Banish
Le module Bannir les fonctionnalités permet d'exclure complètement les composants des fonctionnalités individuelles de l'interface utilisateur des fonctionnalités et des exportations de fonctionnalités. Voici une citation à ce sujet à partir de sa page de projet:
Ce module est utile lorsqu'il existe des composants de fonctionnalités que vous souhaitez vous assurer de ne JAMAIS exporter. Si vous utilisez des fonctionnalités pour la création ou le déploiement de sites, vous avez probablement rencontré le problème de l'exportation accidentelle de variables d'horodatage telles que cron_last ou update_last_check. Vous pouvez également vouloir bannir les autorisations pour les modules de développement afin qu'ils ne soient pas rattrapés par les autres autorisations de site que vous souhaitez exporter. Les éléments bannis n'apparaîtront pas dans votre module de fonctionnalité OU AUCUN AUTRE MODULE DE FONCTIONNALITÉS, alors utilisez-le avec prudence. Pour une liste centrale des fonctionnalités qui ne devraient jamais être exportées, voir https://www.drupal.org/node/2400531
HARICOT
Le module Bean rend vos blocs exportables. Voici une citation à ce sujet à partir de sa page de projet:
Considérez un Bean comme une méthode pour fournir de nouveaux types (par rapport au nœud, ce serait un type de contenu) qui fournit ensuite une interface d'ajout de contenu pour créer autant de blocs que vous le souhaitez (voir capture d'écran ci-dessous). Le contenu du bean peut ensuite être placé autour du site comme n'importe quel autre bloc.
Ce module fonctionne également très bien en combinaison avec les modules UUID et UUID Features Integration . Ce module n'a commencé qu'à partir de D7, mais il a déjà été inclus avec le noyau Drupal 8. Le didacticiel vidéo Didacticiel du module Drupal Bean - à l'aide de l'interface utilisateur d'administration Bean fournit une excellente introduction pour vraiment comprendre la puissance de ce module et le genre de choses que vous pouvez faire avec lui (en utilisant uniquement des techniques de création de site, aucun codage personnalisé impliqué).
Habitat
Le Habitat module permet plus de sens dans un Caractéristiques flux de travail basé. Voici une citation à ce sujet à partir de sa page de projet:
Dans une configuration multi-environnement (par exemple prod, test, dev, local), il y a certains modules que vous souhaitez toujours activer ou désactiver dans certains environnements. Chaque fois que vous synchronisez une base de données, vous devez réactiver / désactiver les mêmes modules. Pire, vous devenez paresseux et conservez les modules de développement activés en production.
Habitat fournit des paramètres pour activer ou désactiver certains modules sur chaque environnement (habitat). Définissez simplement une variable avec par exemple $ conf ['habitat'] = 'local'; dans votre fichier settings.php (la variable réelle à utiliser est configurable pour votre workflow actuel). La désactivation / activation des modules se fait sur hook_init.
6 - Ressources recommandées:
7 - Alternatives possibles à l'utilisation des fonctionnalités
Si vous n'êtes pas en mesure ou désireux (encore) d'utiliser les fonctionnalités , vous pouvez vérifier dans quelle mesure les approches / modules ci-dessous peuvent fournir un certain type d'alternative.
Exportation / importation manuelle
Ce sont les installations communément connues (pour éviter le mot fonctionnalités ...) disponibles via l'interface d'administration, pour des modules tels que les règles , les vues , etc. (liste incomplète!).
Copie de bundle
Certaines personnes considèrent le module de copie de bundle comme une alternative possible. Il prend en charge l'exportation / importation pour:
- Types de nœuds.
- Taxonomie.
- Utilisateur.
- Champs de l'API de champ.
- Groupes de terrain.
Les conflits de fusion vont probablement être acquis lorsque plusieurs développeurs intègrent leur configuration dans une fonctionnalité. J'ai rédigé plusieurs lignes directrices pour l'examen du code de fonctionnalité, mais je pense que le plus important est le suivant:
Validez uniquement les modifications de code prévues.
Qu'est-ce que ça veut dire? Cela signifie que chaque développeur doit revoir le code avant de s'engager. Il n'y a pas de "magie" pour empêcher les modifications de code involontaires sans qu'un développeur soit prudent.
git diff.git diff > blah.patchet modifiez manuellement le correctif pour n'inclure que les modifications de configuration prévues.10dddans vim supprime le changement dans un patch (par exemple).featurename.features.field_base.inc."git commit -a. C'est une terrible pratique qui devrait être supprimée. Ajoutez et engagez toujours explicitement!git rebasesur les branches git locales pour vous assurer que la fonctionnalité est la plus à jour.git merge -s recursive -X patience(nécessite git 1.7+ iirc).Enfin, envisagez d'ajouter des restrictions sociales aux développeurs afin qu'un développeur doive revoir son code avant de le fusionner dans trunk / stable avec une révision de patch ou une demande de pull. Les gens seront fâchés par les restrictions sociales, mais ils devraient être fâchés contre eux-mêmes pour ne pas avoir révisé leur code.
la source
git add -puniquement des morceaux spécifiques.