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?
la source
Réponses:
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 ...
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).
la source
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.
la source
sites/default/files/config_HASH
dossier de configuration avec un suffixe de hachage, par exemple, config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5HzhcrJe 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:
Vous pouvez créer des modules personnalisés (avec sa propre configuration) pour chaque environnement si vous le souhaitez.
la source
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
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.)
la source