dev-> stage-> productionから移行（CMI）構成に推奨されるワークフローは何ですか？

数か月前にdrupalcampがあり、誰かが新しい設定（CMI）システムを使用した展開の管理について質問しました。考えられる理想的なワークフローの1つは、構成をバージョン管理に保持し、チームメンバー間で構成を移行できるようにすることです。

部屋で私たちが理解できた最高の部分は（部分的にはDrupalConポートランドでのプレゼンテーションに基づいて）でした：

• アクティブな設定ディレクトリを無視するようバージョン管理に指示します。
• すべての構成をステージングディレクトリにコピーし、バージョン管理にコミットします。

また、settings.phpを使用して、2つの環境間でアクティブ/ステージングディレクトリをリバースします。ただし、あるサーバーから次のサーバーへの展開ワークフローを把握することは複雑でありながら実行可能ですが、複数のローカル環境（つまり、複数の開発者）からdev（または相互）への推奨されるワークフローは何ですか？同じまたは類似の環境を共有している場合、あるチームメイトのマシンでの変更はどのように反映されますか？

CMIのメンテナーと少し話し合った後、最善のアプローチについての議論は終了していませんが、現時点では次のことが最も理にかなっています。

今のところ簡潔にしようとすると、質問に基づいて/参照された問題が公式の回答で解決されたときに拡張しようとします。

だから、最初に、事実...

• 既に述べたように、アクティブなステージングディレクトリがあります。アクティブはDrupalによって完全に管理されており、そこで直接（別の場所への切り替えによる直接または間接の）変更を行うことはサポートされていません。
• ステージングは​​、Drupalがインポートする構成を探し、それ以外の場合は気にしません。
• インポートプロセスは重要です。構成の変更は特定の方法でサイトに影響を与える可能性があるため、有効性を確認する必要があります。たとえば、機能しないテキスト参照のフィールドタイプをエンティティ参照に変更することはできません。
• 構成のインポートは常にすべての構成で実行する必要があり、単一のビューまたはノードタイプをインポートすることはできません。試されましたが、依存関係、削除/名前の変更などに対処しようとすると、システムが非常に複雑になり、機能しませんでした。
• デフォルト設定を再インストールする唯一の方法は、そのモジュールを再インストールすることです。つまり、最初にすべての構成（フィールドなど）を削除しようとします。したがって、それは実際にはオプションではありません。更新機能の手動で特定の変更は可能ですが、これには面倒です。
• 機能モジュールで説明されているように、構成の継続的な展開ではなく、再利用可能な機能の提供に焦点が当てられます。これがそもそものために設計されたものです。

そのため、現時点での推奨事項は、ステージングディレクトリをバージョン管理することです。その後、各開発者は、Active Directory全体をコピーするか、特定の構成ファイルをコピーするだけで、そこに置くものを完全に制御できます。その後、ステージングディレクトリの変更がコミットされ、運用環境にプッシュされ、構成のインポートが実行されます（UIまたはdrushを使用）。

これまでのところ素晴らしい。どうもありがとう！

Drupal 8プロジェクトを最近開始し、次のワークフローを実装しました。

ステージングとエクスポートの3つのフォルダーがアクティブになっています。開発者はそれらをエクスポートしてダンプします。私はステージングでそれを維持したくありません。共有構成がステージングフォルダーに直接保存されていない場合、作業が簡単になると思います。これはただの伐採であり、これに関する確固たる事実はありません...

現在のdrupal 8プロジェクトテンプレートは、githubで入手できます。また、開発者のワークフローを高速化するための便利なブラシコマンドをいくつか作成しました。アクティブからエクスポートへの手動コピーは不要です。

• プロジェクトテンプレート：https : //github.com/webflo/d8-project-template
• 追加のDrushコマンド：https : //github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

私はまだこれを試していませんが、私の計画は、関心のある構成のみを含む「デフォルト」構成ファイルを含むカスタムモジュールを作成することです。他のモジュールには、他のモジュールをオーバーライドする構成を含めることができると思います。（そうでない場合、これを可能にする必要があります）。

configフォルダーはそのままにしておく必要があると思います。それを無視します。インストール時に、個々のモジュールのすべての構成ファイルから自動生成されます。パスは長くランダムです。これらすべてをレポジトリに保存した場合、別のレポジトリが必要になり、大量のデフォルトの不要な設定ファイルを運ぶことになります。

カスタムモジュールに設定を入れると、メインコードベースの一部になります。

展開プロセスは次のとおりです。

1. Git pullまたは新しいファイルを取得するもの。
2. キャッシュをクリアします。
3. デフォルト設定をリセットします。（カスタムモジュールのファイルから）

必要に応じて、環境ごとにカスタムモジュールを（独自の構成で）作成できます。

注： これは質問に関する厳密な意味での回答ではないことを感謝していますが、とにかくここに置いており、機能が8.xリリースになり、ダストがもう少し落ち着きました。これはコメントするには大きすぎたため、0.02ポンドを取得したかったのです:-)

Featuresの大ファンとして、FeaturesモジュールのD8インカネーションに注目することをお勧めします。

プロジェクトページから取得

Drupal 8の新しい構成管理システムと統合するために、フィーチャーの3.xバージョンが計画されています。単純なサイト構成をエクスポートするだけの場合は、機能の代わりにD8構成管理システムを使用する必要があります。D8の機能を使用して、バンドルされた機能（「フォトギャラリー機能」など）をエクスポートします。

私は道ちょっとそれを見るが、このアイデアは、DEVのためにそれが容易になりますということであるチームサイトの小さな部分に仕事に。まだあまり多くの未知の変数があるので、まだワークフローに入るつもりはありませんが、現在の機能の展開手順とは大きく異なることがわかりません。

私は助けることができませんが、はい、CMIは素晴らしいです。しかし、私のサイトのほとんどはまだ機能モジュールで終わります（ただし、コンテンツタイプや許可などをすべてエクスポートする必要がないため、量は少なくなります）