VCSのapp / etc / config.phpかどうか

fileに関する質問がありますapp/etc/config.php。

このファイルはここで説明され、定義されています：

Magento base dir/app/etc/config.php。インストールされたモジュール、テーマ、および言語パッケージのリストが含まれています。

app/etc/modules/*Magento 1のようです（通常、これらのファイルはVCSにあります）。

ただし、Magento 2では、VCS（Official .gitignore）では共有しないことをお勧めします。

VCSで共有するための質問があるか、事例を使用していますが、VCSに追加することは推奨されないため、理解したいです

1. 実稼働環境（展開システムを使用Capistrano/Deployer, etc）
   • あなたは新しい展開を作る...そして、あなたは必要が有効新しい/ sのモジュール/ sのphp bin/magento module:enable VendorName_NewModule前にsetup:upgrade
     • この状況をどのように管理しますか？
   • 新しいデプロイメントを作成し、前に（すべての状況で）new / sモジュールを無効にする必要がありますphp bin/magento module:disable VendorName_NewModulesetup:upgrade
     • この状況をどのように管理しますか？

2. ローカル環境

   • チームで特定のモジュールを有効/無効にしたくない場合
     • この状況をどのように管理しますか？

3. ステージング環境

   • 共有しない場合、実稼働対応/無効化モジュールの同じ構成をどのように実現できますか？ app/etc/config.php
     • この状況をどのように管理しますか？手動で作成する必要がありますか？

あなたの視点は何ですか、またはこれらの状況をどのように管理しますか？

ありがとう

* VCS：バージョン管理システム、例：git、svnなど

config.phpさまざまな環境、特にモジュールのオン/オフ状態で設定が同じであることに基づいている場合、VCSに含めることには何の問題もありません。これを行うことの副作用は、それぞれに同じテーマ、言語パックなどを持たせるという点であなた自身に課す制限です。

Magento 2.2では、さまざまな展開ワークフローをサポートするために、構成管理の柔軟性を高めるためにいくつかの改善を行う予定です。すべての共有構成app/etc/config.php（すべての環境で同じであり、VCSで保持される可能性が高い構成の意味）を含むことを目的としたファイルがあります。システム固有の構成を含むことを意図した別のファイルがありますapp/etc/env.php（dev、ステージング、および実動システム間で異なる可能性が高い構成を含むことを意味します）。

それまでの間、コミュニティからのいくつかの展開アプローチをキュレートしました。このアプローチが役立つ場合に備えて、このページで見つけることができます。