Comment utiliser le module Fonctionnalités dans un environnement 3 dev?

Question

Travaillant sur un projet, faisant un usage intensif de Fonctionnalités , il y a parfois 3 devs pour cette application.

Nous avons essayé quelques approches, mais lorsque nous fusionnons nos branches git, il semble que nous `` écrasons '' souvent les changements de fonctionnalités les uns des autres. Les conflits abondent, cassant le module de fonctionnalité le rendant pénible à utiliser, semble-t-il.

Les fonctionnalités sont vraiment un gain de temps impressionnant pour la configuration d'un projet, et je suis sûr qu'il existe un moyen de résoudre ce problème.

Existe-t-il un flux de travail ou une procédure qui réduit les risques de conflits et d'écrasements?

Tous les indices sur les fonctionnalités sont les bienvenus.

Answer 1

Bienvenue au pays des [~ # ~] f [~ # ~] mangeurs [~ # ~] c [~ # ~] onfiguration [~ # ~] m [~ # ~] gestion, 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 s'agit plutôt d'un cas spécial de [~ # ~] s [~ # ~] oftware [~ # ~] c [~ # ~] onfiguration [~ # ~] m [~ # ~] gestion , alias [~ # ~] scm [~ # ~] Principalement parce que Fonctionnalités peut être considéré comme un générateur de code, alors que le code généré doit être migré à travers plusieurs environnements. Lisez 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) vers un ou plusieurs sites cibles Drupal (pré-) production (au lieu du déploiement manuel).
• Facilite le partage (expédition) du développement en cours Drupal entre Drupal développeurs/constructeurs de site (par exemple, pour rendre certaines vues créées par un expert des vues disponibles pour un Drupal Themer travaillant dans un autre site de développement pour thématiser cette vue).
• Grande intégration avec GIT et Drush pour l'expédition d'une copie du code généré par Fonctionnalités (sur le site de développement) vers les 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 peuvent être difficiles!
• Il n'est pas facile de commencer à utiliser Fonctionnalités sur un site (de production) existant.
• L'installation/activation du module Fonctionnalités est facile (juste un module), mais apprendre à utiliser correctement Fonctionnalités est un défi majeur.

2 - Techniques de packaging des fonctionnalités

En utilisant Fonctionnalités c'est à votre imagination de savoir comment empaqueter (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 également à 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 sont supposés utiliser le même ensemble de modules, la configuration, etc. Si toutefois cette distribution se compose de plusieurs fonctionnalités de site Web (pour ne pas utiliser Word "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 ".
• Fonctionnalité B = implémentation d'un " * Blog ".
• Fonctionnalité C = implémenter un " * Calendrier des événements ".

Basé sur Drupal sections d'administration

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,
• Tous (personnalisés) Vues sont contenus dans la fonctionnalité G,
• Tous (personnalisés) Règles sont contenus dans la fonctionnalité 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 de menu Drupal admin ... 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 d'ordinateur field_somefield mais qui comme un autre type de champ et/ou un ou plusieurs autres paramètres de champ qui sont 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 Wrapping Information Architecture and Documentation , qui fait partie des articles sur " Relativity Model 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:

• Vues va dans la fonction A,
• Rules va dans la fonction B,
• Graphiques va 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 de 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 (liés logiquement Drupal) 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 suit:

1. 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.
2. Site Sandbox - il s'agit d'un environnement Drupal qui ne contient que Drupal core, utilisé pour tester à l'unité l'exhaustivité d'une fonctionnalité unique. 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.
3. Site intermédiaire - voici où une ou plusieurs fonctionnalités (créées dans un site de développement) sont livrées. 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.
4. Site QA - une fois que l'environnement de transfert 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é pour les tests d'assurance qualité, les tests d'acceptation, les tests de volume, etc. À ce niveau, vous devez être extrêmement prudent lorsque vous autorisez des modifications supplémentaires (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.
5. 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 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.
6. 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 exécutent les mêmes versions de toutes les fonctionnalités.
7. Site de base - D'après mon expérience, il n'y a pas beaucoup (voire pas du tout) Drupal implémentations où ce type de site est également utilisé. Il s'agit simplement d'une copie du ou des sites de production, mais disponible pour les développeurs Drupal, testeurs, etc.) qui peuvent être utilisés pour vérifier l'apparence des sites de production comme, ou pour effectuer une formation utilisateur, etc. Et chaque fois qu'un nouveau cycle de développement 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 base comme entrée, avec comme ciblez 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, pas tous) Cet inventaire est calqué sur les meilleures pratiques dans le domaine de la GCA, utilisé 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 Node export permet aux utilisateurs d'exporter des nœuds puis de l'importer dans une autre installation Drupal.

Exportation de rôle

Le module Export de rôle permet aux rôles d'avoir des noms de machine et génère un identifiant de rôle (rid) unique basé sur le nom de machine. Les rôles peuvent être exportés avec Fonctionnalités et obtenir la même suppression exacte s'ils sont importés sur d'autres sites.

Caractéristiques Banish

Le module Features Banish 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és OR AUCUN AUTRE MODULE DE FONCTIONNALITÉS, utilisez-le donc 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 ID Features Integration . Ce module n'a commencé qu'à partir de D7, mais il a déjà été inclus avec Drupal 8 core déjà. Le didacticiel vidéo Didacticiel du module Drupal Bean - à l'aide de l'interface utilisateur d'administration Bean fournit un excellent introduction pour vraiment comprendre la puissance de ce module, et le genre de choses que vous pouvez en faire (en utilisant uniquement des techniques de création de site, aucun codage personnalisé impliqué).

Habitat

Le module Habitat est plus logique dans un workflow basé sur Features . 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:

• Documentation communautaire sur les fonctionnalités.
• Une partie de cette réponse est basée sur (incroyable je pense) Débat sur les fonctionnalités .
• Tutoriels vidéos:
  • Création d'une fonction .
  • Restauration des fonctionnalités .
  • Mise à jour des fonctionnalités .
  • Faire des fonctionnalités dans le bon sens .
  • Limitations des fonctionnalités .

7 - Alternatives possibles à l'utilisation des fonctionnalités

Si vous n'êtes pas en mesure ou désireux (encore) d'utiliser Fonctionnalités , alors vous voudrez peut-être 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 les fonctionnalités de Word ...) disponibles via l'interface d'administration, pour des modules tels que Rules , Views , etc (liste incomplète!).

Copie groupée

Certaines personnes considèrent le module Bundle copy 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.

Answer 2

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 réviser le code avant de valider. Il n'y a pas de "magie" pour empêcher les modifications de code involontaires sans qu'un développeur soit prudent.

• Vérifiez les modifications de code avec git diff.
• Créez un patch de diff rapide à l'aide de git diff > blah.patch, et modifiez manuellement le correctif pour n'inclure que les modifications de configuration prévues.
  • Des choses telles que "mtime", les commentaires dans les exportations de vues dans le fichier info n'ont pas besoin d'être inclus dans la validation.
  • Je suis devenu assez habile pour examiner les blocs de code de configuration diff au fil du temps. Il est maintenant plus facile de repérer les changements superflus dans les vues ou les panneaux, et un 10dd dans vim supprime le changement dans un patch (par exemple).
  • Je pense "Oh, hé, je n'ai rien changé aux champs, donc je ne m'engage pas featurename.features.field_base.inc. "
• N'utilisez jamais git commit -a. C'est une terrible pratique qui devrait être supprimée. Ajoutez et engagez toujours explicitement!
• Utilisation git rebase sur les branches locales git pour s'assurer que la fonctionnalité est la plus à jour.
• Une stratégie de fusion git peut également aider lors d'une fusion:
  • 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 faire réviser son code avant de le fusionner en trunk/stable avec une révision de patch ou une demande de pull. Les gens seront en colère contre les restrictions sociales, mais ils devraient être en colère contre eux-mêmes pour ne pas avoir révisé leur code.