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

Question

Nous avons eu un drupalcamp il y a quelques mois et 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 toujours migrer la configuration entre les membres de l'équipe.

Le meilleur que nous avons pu comprendre dans la salle (basé en partie sur la présentation à 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, alors que déterminer un flux de travail de déploiement d'un serveur à l'autre était complexe mais réalisable, quel est le flux de travail suggéré depuis plusieurs environnements locaux (c'est-à-dire plusieurs développeurs) vers le développeur (ou entre eux) - Un problème possible serait que chaque membre de l'équipe serait de partager le même environnement ou un environnement similaire, alors comment les changements sur la machine d'un coéquipier se produisent-ils?

Berdir · Accepted Answer

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

Essayer de le garder concis pour l'instant, tentera de développer en fonction des questions/lorsque le problème référencé est résolu avec une réponse officielle.

Donc, 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, apporter des modifications directement dedans (direct ou indirect en passant à un emplacement différent) n'est pas pris en charge.
La mise en scène est l'endroit où Drupal recherche la configuration à importer et ne s'en soucie pas autrement.
Le processus d'importation est important, les changements de configuration peuvent affecter un site d'une certaine manière et doivent être vérifiés pour 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, qui 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 seul type de nœud. Il a été essayé, mais essayer de faire face aux dépendances, supprimer/renommer et ainsi de suite a abouti à un système très compliqué et cela n'a pas fonctionné.
La seule façon de réinstaller la configuration par défaut est de réinstaller ce module. Ce qui signifie qu'il essaierait d'abord de supprimer toutes les configurations (comme les champs). Ce n'est donc 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 pour cela qu'il a été conçu en premier lieu.

Compte tenu de cela, la recommandation consiste actuellement à placer le répertoire de transfert dans le contrôle de version. Chaque développeur a alors un contrôle total sur ce qu'il y met, soit en copiant l'intégralité d'Active Directory, soit juste un fichier de configuration spécifique. Les modifications du répertoire intermédiaire sont ensuite validées, poussées en production et l'importation de configuration est exécutée (dans l'interface utilisateur ou avec drush).

webflo · Answer

Excellente réponse jusqu'à présent. Merci à tous!

Nous avons récemment lancé un projet Drupal 8) et implémenté le workflow suivant.

Nous avons trois dossiers actifs, intermédiaires et exportés. Les développeurs les exportent. Je ne veux pas le garder en scène. Je pense qu'il est plus facile de travailler avec lorsque la configuration partagée n'est pas directement stockée dans le dossier de transfert. C'est juste un coup, je n'ai pas de faits concrets à ce sujet ...

Notre modèle de projet actuel drupal 8 est disponible sur github. J'ai également écrit quelques commandes drush pratiques pour accélérer le flux de travail du développeur. Aucune copie manuelle de l'actif à l'exportation n'est requise.

jonpugh · Answer

Je n'ai pas encore essayé cela, mais mon plan est de créer un module personnalisé qui contient des fichiers de configuration "par défaut" contenant uniquement la configuration qui m'importe. 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 seul. Ignorez-le. Il est généré automatiquement lors de l'installation à partir de tous les fichiers de configuration des modules individuels. Le chemin est long et aléatoire. Si vous gardiez tout cela dans un dépôt, vous auriez besoin d'un dépôt séparé et vous emporteriez avec lui des tonnes de fichiers de configuration inutiles par défaut.

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

Le processus de déploiement serait:

Git pull ou autre pour obtenir de nouveaux fichiers.
Vider 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.

Chapabu · Answer

Remarque: J'apprécie que ce n'est pas une réponse au sens strict par rapport à la question, mais je l'ai mis ici de toute façon et je revisiterai et éditerai/supprimerai une fois que les fonctionnalités auront une version 8.x et la poussière se sera un peu plus installée. C'était juste trop gros pour un commentaire et je voulais obtenir mes 0,02 £ en: -)

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

Tiré de la page du projet

La version 3.x des fonctionnalités est prévue pour Drupal 8 pour s'intégrer au nouveau système de gestion de la configuration. Si vous avez simplement besoin d'exporter une configuration de site simple, le système de gestion de la configuration D8 doit être utilisé à la place des fonctionnalités. Vous utiliserez les fonctionnalités de D8 pour exporter des fonctionnalités groupées (comme une "fonctionnalité de galerie de photos").

La façon dont je un peu voit que cette idée permet aux développeurs - équipes de travailler plus facilement sur les petites parties d'un site. Je ne vais pas entrer dans un flux de travail pour le moment car il y a encore trop de variables inconnues, mais je ne vois pas que ce soit TELLEMENT différent d'une procédure de déploiement de fonctionnalités actuelle.

Je ne peux pas m'empêcher de penser que oui, CMI est génial; mais la plupart de mes sites se retrouveront toujours avec des modules de fonctionnalités (bien qu'une quantité plus petite en raison de ne pas avoir à exporter CHAQUE type de contenu, autorisation, etc.)