Develモジュールが実稼働環境にインストールされないようにする方法

新しいDrupal 8構成マネージャーを使用して、特定の環境にDevelモジュールがインストールされないようにするにはどうすればよいですか？私の知る限り、ローカルにインストールするということは、次に設定をエクスポートして他の環境（dev、test、prod）に移動するときに、自動的に有効になることを意味します。

方法：ブラシ

• Drushは、構成を同期するときに拡張機能の有効な状態を無視できます。

  drush cex --skip-modules=devel

  drush cim --skip-modules=devel

• Drush CMIツールあなたは無視する設定のリストで動作することができます。

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

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

方法：モジュール

• あなたは使用することができます設定スプリットにあなたを可能にするモジュールを：

  1. 一部の構成を専用フォルダーに分割します
  2. ブラックリスト設定
  3. 一連の構成を無視する
  4. 構成エンティティによって構成されます

• 構成読み取り専用モードモジュール

  このモジュールを使用すると、Drupal管理UIを介して行われた設定変更をロックできます。これは、たとえば、実稼働環境ではなく、ステージング環境またはローカル環境でのみ構成の変更を行う必要があるシナリオで役立ちます。

  $settings['config_readonly'] = TRUE;

• もう1つのモジュールは、環境ごとに構成をオーバーライドできる環境構成です。

更新：下記の機能は最近削除されました https://www.drupal.org/project/config_split/issues/2926505

展開プロセスでdrushを使用している場合、次のことができます。

drushrc.php自分と同じディレクトリにファイルを作成しsettings.php（例docroot/sites/default：）、以下を配置します。

$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;

これは、プロセス中にdrush cex/ drush cimコマンドを操作してモジュールをスキップできることを意味します。

Drush 8での構成モジュールフィルターの使用に関する詳細をお読みください。

drush cex --skip-modulesこの問題で説明されているようにconfig_splitを支持して削除されたため、ここでのブラシに基づく解決策はうまくいきませんでした。

config_excludeモジュールを使用したDuncanmooソリューションに基づくソリューションを次に示します。

1. Composer require --devを使用してconfig_excludeをインストールし、構成します

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

ローカルの開発環境でsettings.phpを使用できるようにします

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

ローカルファイルにconfig_exclude設定を追加

$ nano sites/default/setting.local.php

ここにいくつかのサンプル設定があります

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

注1：config_filterはconfig_exclude依存関係であるため、実稼働環境で必要ない場合は上記で除外できます

注2： これsettings.local.phpは要件ではありません。VCSによって制御されているかどうかによって異なります。

2. Composerには--devが必要です

純粋に開発用のモジュールを有効にする場合は、-devフラグを使用します。

$ composer require --dev drupal/devel

これにより、require-devの下のcomposer.jsonファイルにこれらの依存関係が追加されます。

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

したがって、使用する開発モジュールなしでサイトをインストールする場合：

$ composer install --no-dev

注：ステージング環境とprod環境では、常に--no-devを実行する必要があります

3. drush cexを通常どおり使用します

$ drush cex 

除外されたモジュール設定はエクスポートされません

注：私は気づいているcore.extensionの設定は、上記のコマンドを実行した後に変更されているように見えるが、対応する.ymlが（でも確認した後にハードドライブに書き込まれることはありませんwill be deleted and replaced with the active config）ので、コミットすべき事項はありません、私はそれが依存すると思いますconfig_excludeモジュールの内部

Drupal 8.3.xには興味深い問題があります：開発モジュールがconfig-exportをオプトアウトできるようにします。一般的なコンセンサスは、現在、構成分割が最適なソリューションであるということです。

swentelによるコメント：

config_splitがどのように機能するかを簡単に文書化したかっただけです：config split configエンティティは、ブラックリストに登録されるものを定義し、モジュールや設定オブジェクトをブラックリストに登録できるようにします。develの標準的な例には、すでに興味深い使用例があります。system.menu.develが付属しています。これは、develをブラックリストに登録する場合、依存関係がないためメニュー設定ファイルは削除されません。重大な問題ではありませんが、config splitを使用すると個別に選択できるため、環境から削除されます。

geerlingguyによるコメント：

環境固有の設定を管理するいくつかの異なる方法を試してみましたが、config_splitはこれまでのところ、適切なユーザビリティと追加のオーバーヘッドバランスのベストを達成しているようです。シンプルで軽量ですが、特定の環境でのみ特定の構成をマーク（および継続使用）できます。

構成分割は、一部の人にとって実行可能なソリューションである可能性があります。

Drupal 8構成管理は、サイト構成のセット全体をインポートおよびエクスポートするときに最適に機能します。ただし、開発者は、CMの堅牢性をオプトアウトし、開発マシンでアクティブな構成のセットをアクティブにし、サブセットのみを展開することがあります。これの標準的な例は、開発モジュールを有効にするか、開発環境でいくつかのブロック配置またはビューを使用し、展開する構成のセットにエクスポートせずに、開発構成を同僚と共有することです。

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

これを行うきちんとした方法があります。便宜上、composerで開発モジュールをコミットし、それらのモジュールの構成は構成エクスポートに追加されません（2つの部分があります）。

1. Composer require --dev 開発専用のモジュールを有効にする場合は、-devフラグを使用します。

$ composer require --dev drupal/devel

これにより、require-devの下のcomposer.jsonファイルにこれらの依存関係が追加されます。

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

したがって、開発モジュールなしでサイトをインストールすると、次のようになります。

$ composer install --no-dev

注意：ステージング環境と製品環境では、常に--no-devを実行する必要があります

2. config_splitモジュールを使用します

構成分割モジュールを使用すると、環境内で有効または無効にできる構成エクスポートのグループを作成できます。

私は実際に3つのスプリットを持っています：

1. メインサイトの構成（どこでも有効、開発およびステージングと運用）
2. ステージング構成（開発およびステージングで有効）- メールの再ルーティングモジュールを含む
3. Dev config-devel、kint ...を含みますが、devで有効にされたステージングconfigが付属しているため、電子メールを再ルーティングしません。

すべてを一発で実行する小さなスクリプトを作成しました。

#!/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

Config Ignoreモジュールも表示できます。

このモジュールは、必要な構成を所定の場所に保持するためのツールです。

system.site構成（そのサイト名、スローガン、電子メールなどを含む）を、エクスポートフォルダーの構成に関係なく、ライブサイトでそのままにしておきたいとしましょう。

または、設定をインポートするたびにdevel.settingsを変更するのにうんざりしていませんか？

これには展開オーバーライドモジュールを使用できます。詳細については、次のリンクをお読みください。

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

ただし、これを行う最適な方法は、ローカルでモジュールを無効にしてから構成をエクスポートすることです。

Drupalは、の構成設定をオーバーライドする方法を提供しますが、settings.phpモジュールの無効化/有効化には無効です。

から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.
 */