Quel est le flux de travail suggéré pour la configuration (CMI) de migration de dev -> stage -> production?

41

Il y a quelques mois, nous avions un drupalcamp. Quelqu'un a posé des questions sur la gestion des déploiements avec le nouveau système de configuration (CMI). Un flux de travail idéal possible consisterait à conserver la configuration dans le contrôle de version et à pouvoir encore migrer la configuration entre les membres de l'équipe.

Le mieux que nous ayons pu comprendre dans la salle (en partie sur la base de la présentation à la DrupalCon Portland) était:

Indiquez au contrôle de version d'ignorer le répertoire de configuration actif.
Copiez toute la configuration dans le répertoire intermédiaire et validez le contrôle de version.

Et utilisez settings.php pour inverser le répertoire actif / intermédiaire entre les 2 environnements. Cependant, bien qu’il soit complexe mais réalisable de définir un flux de travail de déploiement d’un serveur à l’autre, quel est le flux de travail suggéré de plusieurs environnements locaux (c-à-d. Plusieurs développeurs) dans dev (ou entre eux) - Un problème possible serait celui de chaque membre de l’équipe partagerait le même environnement ou un environnement similaire alors comment les modifications sur la machine d’un équipier sont-elles prises en compte?

migration 8 version-control

— btmash
source

5

Je ne suis pas vraiment d'accord avec les votes serrés actuels. Comme CMI est une priorité pour Drupal 8, je pense que nous pouvons avoir de bonnes réponses ici.

— mpdonadio

3

D'accord, c'est la très bonne question. Je pense que la tâche critique drupal.org/node/1703168 concerne ce sujet et d’autres sujets et n’est pas encore complètement résolue. Par conséquent, une solution ici pourrait aider à faire avancer ce problème.

— Berdir

Je m'excuse si ma question m'a semblé négative à l'égard de l'initiative CMI (ce qui n'était pas du tout mon intention). J'ai mis à jour la question pour que ça sonne plus neutre.

— btmash le

2

J'allais presque dire "Avez-vous essayé des fonctionnalités". Peut-être que le "D8" devrait figurer dans le titre de la question? La balise "8" est un peu invisible.

— Donquixote

1

Révision du titre afin que la question puisse être vue à la fois par tag ou via le titre :)

— btmash

19

Après avoir discuté un peu avec les responsables de CMI, la discussion sur la meilleure approche n'est pas terminée, mais voici ce qui est le plus logique pour le moment.

En essayant de le garder concis pour le moment, nous essaierons de nous développer en fonction des questions / lorsque le problème référencé sera résolu avec une réponse officielle.

Alors, d'abord, les faits ...

Comme déjà mentionné, il y a le répertoire actif et intermédiaire. Active est entièrement géré par Drupal, les modifications qui y sont effectuées directement (indirectement en passant à un autre emplacement) ne sont pas prises en charge.
Staging est l'endroit où Drupal recherche la configuration à importer et ne s'en soucie pas autrement.
Le processus d'importation est important, les modifications de configuration peuvent affecter un site d'une certaine manière et doivent être vérifiées pour en vérifier la validité. Vous ne pouvez pas changer le type de champ d'un champ de texte en une référence d'entité, par exemple, cela ne fonctionne tout simplement pas.
L'importation de configuration doit toujours s'exécuter sur toutes les configurations. Vous ne pouvez pas importer une seule vue ou un type de nœud. Cela a été essayé, mais essayer de gérer les dépendances, supprimer / renommer, etc. a abouti à un système très compliqué et cela n'a pas fonctionné.
Le seul moyen de réinstaller la configuration par défaut consiste à réinstaller ce module. Ce qui signifie qu’il essaiera d’abord de supprimer toutes les configurations (comme les champs). Donc ce n'est pas vraiment une option. Des modifications manuelles et spécifiques des fonctions de mise à jour sont possibles mais trop fastidieuses pour cela, je pense.
Comme le module de fonctionnalités le décrit, il se concentrera sur la fourniture de fonctionnalités réutilisables, et non sur des déploiements continus de configuration. C'est ce pour quoi il a été conçu en premier lieu.

Dans ces conditions, il est actuellement recommandé de placer le répertoire intermédiaire dans le contrôle de version. Chaque développeur a ensuite un contrôle total sur ce qu'il y met, soit en copiant tout le répertoire actif, soit simplement un fichier de configuration spécifique. Les modifications apportées au répertoire intermédiaire sont ensuite validées, poussées en production et l'importation de la configuration est exécutée (dans l'interface utilisateur ou avec drush).

— Berdir
source

Le répertoire de transfert dans le contrôle de version, je reçois cette partie. Les autres parties sont ce que mon esprit tente de traiter. Ainsi, si quelqu'un apporte une modification, il la copie dans le répertoire intermédiaire et le valide. À partir de ce moment, les autres développeurs / serveur suivant reçoivent les modifications et les synchronisent avec Active Directory. Et rincez et répétez l'opération pour toutes les autres chaînes de serveurs en cours de route (stockage intermédiaire, production, etc.). Et comme il y a toujours une mise en scène, il n'y a plus de changement de répertoire. Cela serait-il exact?

— btmash

Oui. Il ne doit y avoir aucune commutation d'annuaire. Chaque modification de configuration doit passer par le processus d'importation, sinon vous risquez de vous retrouver avec un site endommagé. Par exemple, la liste des modules est également une configuration. Son déploiement signifie que les modules doivent être installés / désinstallés (Remarque: cela ne fonctionne pas encore, mais il existe un problème pour le résoudre).

— Berdir

Ok, donc encore plus de questions maintenant (divisées en 2 commentaires) :) Tout d’abord, vous mentionnez les modules comme configuration. Donc, même si un module est ajouté à un référentiel et n'est pas activé / désactivé, il doit être installé / désinstallé pour rester assis là?

— btmash

Et la suite: (A) Y aura-t-il un mécanisme pour copier les modifications du répertoire actif -> staging (pour simplifier par rapport à une personne allant dans le répertoire config de ces composants - éventuellement un moyen de sélectionner certaines variables). (B) Le répertoire de stockage intermédiaire est-il vidé après la synchronisation des modifications entre le stockage intermédiaire -> actif? (B1) Si tel est le cas, la stratégie du point de vue de devops consiste-t-elle à réinitialiser ce répertoire avant un pull git? (B2) Si ce n'est pas le cas, est-il correct de supposer que, même si la synchronisation intermédiaire> active a lieu, il ne devrait y avoir aucun effet sur la configuration qui n'a pas changé?

— btmash

Le statut d'installation du module est la configuration. Pas le module lui-même :) C'est ce que vous déployez. a) Il existe une interface utilisateur pour télécharger un fichier tar.gz de l'annuaire actif, une pour télécharger ledit fichier tar.gz dans le répertoire intermédiaire et une autre pour effectuer l'importation, avec aperçu et diff des modifications. B) Je crois qu’à présent il est vidé, mais je suppose que vous pouvez facilement revenir en arrière avec git. Pas sûr, facile à vérifier. Tout ce matériel est enfichable, il pourrait donc y avoir une implémentation légèrement différente qui ne supprime pas. B2) Je ne comprends pas celui-ci mais je pense que oui.

— Berdir

4

Super répondu jusqu'à présent. Merci à tous!

Nous avons récemment lancé un projet Drupal 8 et mis en œuvre le flux de travail suivant.

Nous avons trois dossiers actifs, de stockage intermédiaire et d’exportation. Les développeurs abandonnent leurs exportations. Je ne veux pas le garder en stage. Je pense qu'il est plus facile de travailler avec lorsque la configuration partagée n'est pas directement stockée dans le dossier intermédiaire. C'est juste un sentiment que je n'ai pas de faits concrets à ce sujet ...

Notre modèle de projet Drupal 8 actuel est disponible sur github. J'ai également écrit quelques commandes drush pratiques pour accélérer le flux de travail de Devleoper. Aucune copie manuelle active à l'exportation requise.

Modèle de projet: https://github.com/webflo/d8-project-template
Commandes Drush supplémentaires: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— webflo
source

1

Jusqu'à présent, je suis d'accord avec cette approche. J'ai ajouté toutes les fonctionnalités des liens de cet article aux commandes Drush config-export et config-import. J'espère que d'autres personnes se joindront à moi et à @florian pour explorer cette solution à 3 répertoires.

— Moshe Weitzman

Comment gérer le sites/default/files/config_HASHdossier de configuration avec un suffixe de hachage, par exemple, config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow Il est possible de remplacer l'emplacement de ces dossiers. Il suffit de chercher "Emplacement des fichiers de configuration du site". Dans settings.php, j'utilise l'extrait suivant. Cela signifie que la configuration est stockée en dehors du répertoire racine de Drupal. $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);

— Webflo

Merci @webflo j'ai vu cela. Quel serait l’avantage de gérer une base de code et une configuration séparément? Je pense que cette séparation est un peu artificielle car code et config (en yaml) déterminent le comportement et dépendent l'un de l'autre. Dans Drupal 7, la configuration en code (ou pouvant être suivie par Git) était réalisée avec le module Features créant un module pour chaque configuration particulière devant faire l'objet d'un suivi en code. Dans Drupal 8, il existe Features 3.x qui, si je comprends bien, fait de même, mais utilise YAML pour stocker la configuration et les modules générés ne dépendent pas du module Features.

— therobyouknow

Je pense que vous m'avez mal compris, le répertoire de configuration est toujours dans git, mais mon site Drupal ne se trouve pas dans la racine git repo. Le site est stocké / web. So / config et / web sont au même niveau.

— webflo

2

Je n'ai pas encore essayé cela, mais mon plan est de créer un module personnalisé contenant des fichiers de configuration "par défaut" contenant uniquement la configuration qui me tient à cœur. Je crois que d'autres modules peuvent contenir des configurations qui remplacent d'autres modules. (Sinon, cela devrait être possible).

Je pense que vous devez laisser le dossier config. Ignore le. Il est généré automatiquement lors de l'installation à partir des fichiers de configuration de tous les modules. Le chemin est long et aléatoire. Si vous gardiez tout cela dans un repo, vous auriez besoin d'un repo séparé et vous emporteriez avec lui des tonnes de fichiers de configuration par défaut et inutiles.

Mettre config dans un module personnalisé en fait une partie de votre base de code principale.

Le processus de déploiement serait:

Git pull ou quoi que ce soit pour obtenir de nouveaux fichiers.
Effacer les caches.
Réinitialiser la configuration par défaut (À partir des fichiers de votre module personnalisé)

Vous pouvez créer des modules personnalisés (avec sa propre configuration) pour chaque environnement si vous le souhaitez.

— jonpugh
source

Cela ressemble beaucoup à des fonctionnalités, n'est-ce pas? Ou y a-t-il une différence significative qui me manque?

— Létharion

C'est une approche intéressante et j'aime bien l'idée. Cependant, l'un des avantages les plus importants mentionnés dans le cadre de l'initiative CMI est la possibilité de passer de la configuration aux répertoires de configuration. Et d'après ce que je vois, le fichier settings.php vous permet de dicter l'emplacement des répertoires actif / intermédiaire (c.-à-d. Qu'ils ne doivent pas obligatoirement être des chemins générés automatiquement). Par conséquent, je pense qu'un flux de travail avec la configuration actuelle devrait être possible sans avoir besoin de créer une fonctionnalité comme le mentionne @Letharion ci-dessus.

— btmash le

2

Note: Je comprends que ce n’est pas une réponse au sens le plus strict du terme, mais je l’ai mise ici quand même et je reviendrai et éditerai / effacerai une fois que Feature a une version 8.x et que la poussière a réglé un peu plus. C'était trop gros pour un commentaire et je voulais obtenir mon £ 0.02 dans :-)

En tant que grand fan de Features , je vous suggère de garder un œil sur l' incarnation du module D8 de Features .

Tiré de la page du projet

La version 3.x de Features est prévue pour Drupal 8 afin de l’intégrer au nouveau système de gestion de la configuration. Si vous devez simplement exporter une configuration de site simple, vous devez utiliser le système de gestion de la configuration D8 au lieu de Fonctionnalités. Vous utiliserez Fonctions dans D8 pour exporter des fonctionnalités groupées (comme une "fonctionnalité de galerie de photos").

Ce que je vois un peu, c’est que cette idée facilite le travail des équipes de développement sur de plus petites parties d’un site. Je ne vais pas encore entrer dans un flux de travail car il y a encore trop de variables inconnues, mais je ne vois pas cela très différent de la procédure de déploiement de fonctionnalités actuelle.

Je ne peux pas m'empêcher de penser oui, CMI est génial; mais la plupart de mes sites finissent toujours par se retrouver avec des modules de fonctionnalités (bien qu'un montant plus petit en raison du fait de ne pas avoir à exporter TOUS les types de contenu, autorisations, etc.)

— Chapabu
source

Bien que je convienne que les fonctionnalités vont légèrement changer de rôle et (espérons-le) être l'outil permettant de regrouper des composants de configuration (comme la fonctionnalité de galerie de photos que vous mentionnez), la configuration (pour autant que je sache) continue à être conservée via l'interface active. répertoire de configuration. Donc, les fonctionnalités peuvent résoudre un composant donné, mais le vrai problème est de savoir comment le flux de travail du répertoire de configuration est géré dans différents environnements. La procédure de déploiement est légèrement différente de la procédure de déploiement des fonctionnalités en cours, principalement dans la mesure où les données activestore se trouvent dans la base de données et que le magasin de données est constitué de fichiers.

— btmash

... la procédure de déploiement des fonctionnalités d7 implique des données activestore dans une base de données et des banques de données dans des fichiers. Nous passons maintenant aux fichiers et devons simplement nous assurer que cela influe sur les changements de flux de travail.

— btmash

Notez que les fonctionnalités n’ont pas vraiment le concept actif et datastore / staging. Ou du moins pas cohérent, tout dépend du crochet / de la chose avec laquelle il s'intègre. Les vues par défaut sont intégrées au code. Par exemple, les modifications sont immédiatement actives (mis à part la mise en cache), il n'y a pas de processus de déploiement contrôlé avec des fonctionnalités. Cela a toujours été l’un des problèmes majeurs lors de l’utilisation de fonctionnalités pour les déploiements.

— Berdir

Tu as raison. Je ne sais pas comment j'ai mélangé le module de configuration pour D7 avec les fonctionnalités, mais je l'ai fait.

— btmash