Comment empêcher l'installation du module Devel sur les environnements de production

26

À l'aide du nouveau gestionnaire de configuration Drupal 8, comment puis-je l'empêcher d'installer le module Devel sur certains environnements? Pour autant que je sache, l'installer sur mon local signifie que la prochaine fois que j'exporterai la configuration et la déplacerai vers mes autres environnements (dev, test, prod), elle sera automatiquement activée.

cambraca
la source
Est-ce que l'utilisation est drushacceptable? J'ai découvert l'autre jour drush config-export --skip-modules=devel. Il pourrait y avoir quelque chose de similaire sans utiliser drush, mais je ne sais pas.
mradcliffe
Il faudrait donc que je fasse ça à chaque fois que j'exporte la config? Il doit y avoir un meilleur moyen: |
cambraca
Vous pouvez peut-être ajouter des fichiers de configuration à votre .gitignore.
digitaldonkey
2
Je pense que cette question est trop large rétrospectivement. Il existe probablement de nombreuses bonnes réponses, car cela dépend du processus de création et de développement du site.
mradcliffe

Réponses:

18

Méthode: Drush

  • Drush peut ignorer les états activés des extensions lors de la synchronisation de la configuration.

    drush cex --skip-modules=devel

    drush cim --skip-modules=devel

  • Avec les outils Drush CMI, vous pouvez utiliser une liste de configurations à ignorer.

    drush cexy --ignore-list=/path/to/config-ignore.yml

    drush cimy --delete-list=/path/to/config-ignore.yml

Méthode: modules

  • Vous pouvez utiliser le module Configuration Split qui vous permet de:

    1. Répartir une configuration dans un dossier dédié
    2. Configuration de la liste noire
    3. Ignorer un ensemble de configuration
    4. Configuré par des entités de configuration
  • Configuration Module en mode lecture seule

    Ce module permet de verrouiller toutes les modifications de configuration effectuées via l'interface d'administration Drupal. Cela peut être utile dans des scénarios où, par exemple, les modifications de configuration ne doivent pas être effectuées sur l'environnement de production, mais uniquement sur les environnements intermédiaires ou locaux.

    $settings['config_readonly'] = TRUE;

  • Et un autre module est la configuration de l' environnement qui vous permet de remplacer la configuration en fonction de l'environnement.

Adrian Cid Almaguer
la source
2
Je n'aime vraiment pas avoir toutes les dépendances de bibliothèque pour le module de développement sur mes serveurs de production, donc je l'ajoute à composer à l'aide composer require --dev drupal/devel. Le bonus supplémentaire est que l'installation de composer est plus rapide, ce qui accélère le déploiement de prod.
Duncanmoo
6

Mise à jour : la fonctionnalité décrite ci-dessous a été supprimée récemment https://www.drupal.org/project/config_split/issues/2926505


Si vous utilisez drush dans votre processus de déploiement, vous pouvez effectuer les opérations suivantes:

Créez un drushrc.phpfichier dans le même répertoire que votre settings.php(par exemple:) docroot/sites/defaultet mettez ce qui suit:

$drush_ignore_modules = array(
  'devel',
  'webprofiler',
  'devel_generate',
  'kint',
  'yaml_editor',
);

$command_specific['config-export']['skip-modules'] = $drush_ignore_modules;
$command_specific['config-import']['skip-modules'] = $drush_ignore_modules;

Cela signifie que vous pouvez manipuler les commandes drush cex/ drush cimpour ignorer les modules pendant leur processus.

Vous pouvez en savoir plus sur l' utilisation du filtre du module de configuration dans Drush 8 .

ssibal
la source
5

drush cex --skip-modulesa été supprimé en faveur de config_split comme expliqué dans ce numéro, donc les solutions basées sur drush n'ont pas fonctionné pour moi.

Voici la solution basée sur la solution Duncanmoo utilisant le module config_exclude

1. Installez config_exclude à l'aide de Composer require --dev et configurez-le

$ composer require --dev drupal/config_exclude
$ drush en config_exclude -y
$ nano sites/default/setting.php

autorisez settings.php à être utilisé sur votre environnement de développement local

if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
  include $app_root . '/' . $site_path . '/settings.local.php';
}

Ajouter des paramètres config_exclude dans un fichier local

$ nano sites/default/setting.local.php

voici quelques exemples de paramètres

$settings['config_exclude_modules'] = [
    'devel', 
    'config_exclude',
    'config_filter',
    ...
    'stage_file_proxy',
];

NOTE 1: config_filter est une dépendance config_exclude donc si vous n'en avez pas besoin de production vous pouvez l'exclure ci-dessus

REMARQUE 2: le settings.local.phpn'est pas une exigence. Cela dépend si est contrôlé par votre VCS ou non.

2. Le compositeur requiert --dev

Lorsque vous activez un module qui est purement pour le développement, utilisez le drapeau --dev:

$ composer require --dev drupal/devel

Cela entraîne l'ajout de ces dépendances dans le fichier composer.json sous require-dev:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

Donc, si vous installez le site SANS vos modules de développement que vous utilisez:

$ composer install --no-dev

REMARQUE: Sur vos environnements de production et de production, vous devez toujours faire --no-dev

3. utilisez drush cex comme vous l'utilisez normalement

$ drush cex 

n'exportera aucun des paramètres des modules exclus

REMARQUE: j'ai remarqué que les paramètres core.extension semblent avoir été modifiés après avoir exécuté la commande ci-dessus mais le .yml correspondant n'est jamais écrit sur le disque dur (même après confirmation will be deleted and replaced with the active config) donc il n'y a rien à commettre, je suppose que cela dépend de la internes du module config_exclude

GiorgosK
la source
J'ai eu une expérience très similaire à @GiorgosK en suivant les suggestions ci-dessus. Cette solution a parfaitement fonctionné pour moi et contient également des conseils bien pensés. J'ai également remarqué des faux négatifs de core.extension mais cela n'a en effet PAS changé de statut pour git donc tout va bien. Merci
vrwired
2

Il y a un problème intéressant pour Drupal 8.3.x: permettre aux modules de développement de désactiver la configuration-export . Le consensus général est que Configuration Split est actuellement la meilleure solution.

Commentaire de swentel :

Je voulais juste documenter brièvement le fonctionnement de config_split: l'entité config split config définit ce qui est sur liste noire, vous permettant de mettre sur liste noire les modules et / ou les objets de configuration. L'exemple canonique, étant devel, a déjà un cas d'utilisation intéressant: il est livré avec system.menu.devel qui, dans le cas où vous mettez sur liste noire devel, le fichier de configuration du menu ne sera pas supprimé car il n'y a pas de dépendance. Bien que ce ne soit pas un problème majeur, le partage de configuration vous permet de le sélectionner individuellement afin qu'il soit supprimé sur l'environnement.

Commentaire de geerlingguy :

J'ai essayé quelques méthodes différentes de gestion de la configuration spécifique à l'environnement, et config_split semble atteindre le meilleur niveau de convivialité par rapport à la surcharge supplémentaire. C'est simple et léger, mais cela me permet de marquer (et de continuer à utiliser) certaines configurations uniquement dans certains environnements.

Wim Mostrey
la source
2

Configuration Split pourrait être une solution viable pour certains.

La gestion de la configuration de Drupal 8 fonctionne mieux lors de l'importation et de l'exportation de l'ensemble de la configuration des sites. Cependant, parfois, les développeurs aiment se retirer de la robustesse de CM et avoir un super-ensemble de configuration actif sur leur machine de développement et déployer uniquement un sous-ensemble. L'exemple canonique pour cela est d'avoir le module de développement activé ou d'avoir quelques emplacements de bloc ou vues dans l'environnement de développement, puis de ne pas les exporter dans l'ensemble de configuration à déployer, tout en étant toujours en mesure de partager la configuration de développement avec des collègues.

https://www.drupal.org/project/config_split

Kevin
la source
+1 pour le partage de configuration, je l'utilise toujours pour que Devel et d'autres modules comme Field UI et Views UI soient désactivés dans prod. Voir Désactiver les modules à l'aide de la configuration config .
leymannx
2

Il y a une bonne façon de le faire, où vous vous retrouvez avec vos modules de développement commis dans le compositeur pour plus de commodité et la configuration de ces modules n'est pas ajoutée à votre exportation de configuration (il y a 2 parties):

1. Le compositeur requiert --dev Lorsque vous activez un module uniquement pour le développement, utilisez le drapeau --dev:

$ composer require --dev drupal/devel

Cela entraîne l'ajout de ces dépendances dans le fichier composer.json sous require-dev:

...
    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"
    }
}

Donc, si vous installez le site SANS vos modules de développement, vous dites:

$ composer install --no-dev

NB: Sur vos environnements de mise en scène et de production, vous devriez toujours faire --no-dev

2. Utilisez le module config_split

Le module de configuration fractionnée vous permet de créer des regroupements d'export de configuration qui peuvent être activés ou désactivés dans un environnement.

J'ai en fait 3 divisions:

  1. Configuration du site principal (activée partout; développement et mise en scène et production)
  2. Configuration de la mise en scène (activée dans le développement et la mise en scène) - inclut le module de redirection de messagerie
  3. Configuration de développement - inclut devel, kint ... mais pas de redirection de l'e-mail car cela inclut l'activation de la configuration de transfert dans le développement.
Duncanmoo
la source
1
Vous ne devriez vraiment pas utiliser les dépendances de dev de cette façon. Ils sont plus destinés à des outils, tels que le renifleur de code, que vous n'auriez pas besoin d'exécuter en production. S'ils sont activés et que Drupal s'attend à ce que le module soit installé et que le code ne soit pas là, cela pourrait entraîner une instabilité du site. Drupal / Composer peut toujours tenter de charger un fichier qui n'est pas sur le système de fichiers s'il s'agit d'une dépendance de développement.
Frank Robert Anderson,
@FrankRobertAnderson vous ne proposez pas de meilleure solution? Je ne veux pas de module de développement ou de bibliothèques dépendantes sur mon serveur de production, que proposez-vous?
Duncanmoo
Drupal ne propose pas vraiment une bonne option pour cela. Votre plan n'est pas horrible, mais il entraînera des problèmes si vous ne faites pas attention. Le problème que j'ai avec votre plan est que config_split devient la broche sur laquelle repose tout votre site. Je voterais le vôtre si ce n'était pour la dépendance aux développeurs, qui n'était même pas une question dans le PO.
Frank Robert Anderson
1

J'ai fait un petit script pour tout faire en une seule fois.

#!/bin/bash

drush pm-uninstall devel -y
drush pm-uninstall field_ui -y
drush pm-uninstall field_name_prefix_remove -y

drush config-export

drush en devel -y
drush en field_ui -y
drush en field_name_prefix_remove -y
Roebrt Brown
la source
1

Vous pouvez également voir le module Config Ignore .

Ce module est un outil pour vous permettre de conserver la configuration que vous souhaitez, en place.

Disons que vous souhaitez que la configuration de system.site (qui contient le nom, le slogan, l'e-mail, etc.) reste intacte sur votre site en direct, quelle que soit la configuration, dans le dossier d'exportation.

Ou peut-être que vous en avez assez de voir les paramètres devel.settings modifiés à chaque fois que vous importez la configuration?

DRUPWAY
la source
Le module Config Ignore ne convient pas dans ce cas. Depuis la page du module: N'ignorez pas la configuration core.extension car cela vous empêchera d'activer de nouveaux modules avec une importation de configuration. Utilisez le module Config Split pour les modules spécifiques à l'environnement.
bmunslow
1

Vous pouvez utiliser un module de remplacement de déploiement pour cela. Lisez le lien suivant pour une description détaillée:

http://dcycleproject.org/blog/46/continuous-deployment-drupal-style

Cependant , la meilleure façon de procéder serait de désactiver votre module en local puis d'exporter la configuration.

Drupal fournit un moyen de remplacer les paramètres de configuration dans settings.php, mais ils ne sont pas valides pour désactiver / activer les modules.

De default.settings.php:

/**
 * Configuration overrides.
 *  * To globally override specific configuration values for this site,
 * set them here. 
 * 
 *
 * blah..blah...blah
 *
 *  
 * There are particular configuration values that are risky to override. For
 * example, overriding the list of installed modules in 'core.extension' is not
 * supported as module install or uninstall has not occurred. Other examples
 * include field storage configuration, because it has effects on database
 * structure, and 'core.menu.static_menu_link_overrides' since this is cached in
 * a way that is not config override aware. Also, note that changing
 * configuration values in settings.php will not fire any of the configuration
 * change events.
 */
kmdhrm
la source