Magento2-ローカル/ステージング/プロダクションデプロイメント＆gitignore

これは質問というよりも一種の議論かもしれません。

Magento2とローカル > ステージング > 本番環境で従うデプロイメントポリシーを知りたい

何度か試した後、最善の（または、少なくとも最も確実な）アプローチは、git内のベンダーフォルダーを含むこのgitignoreファイルになると判断しました。

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

そのため、composerはローカル環境でのみ実行されます。新しい拡張機能やソフトウェアのアップグレードはローカルでテストされ、検証およびコミットされます。おそらく、gitにもapp / etc / config.phpファイルを含めますが、そのファイルは実行時に書き換えられますsetup:upgradeよね？

ベンダーを含めると、リポジトリのサイズが（おそらく）推奨よりも大きくなりますが、この方法でコードをデプロイするときは、シーケンスを実行するだけです。

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

関連情報：http : //www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

オプションのMagento 2としてコンパイルコマンドを選択する理由をご覧ください-setup：di：compile？

更新

真実は、公開されたMagento 2プロジェクトにコード変更をデプロイするときに問題が発生していることです

変更はローカルとステージングで機能します（開発者モードとプロダクションモードの両方でチェックされますが、その環境は概念的には開発者モードで構成されています）が、一部はプロダクション環境（プロダクションモード）では機能しません。ですから、私たちが正しい戦略に従っているかどうかはわかりません。割り当てられたコマンドシーケンスとは何か、そのコマンドの順序の関連性を確認したい

実際、プロジェクトで何も変更しないのでない限り、Magento 2プロダクションモードの有用性について毎日確信が持てません。私の考えを変えてもらえますか？

実際、プロジェクトで何も変更しないのでない限り、Magento 2プロダクションモードの有用性について毎日確信が持てません。私の考えを変えてもらえますか？

私はあなたが修正理解している場合、私はわからないんだけど、それは生産モードがあるため、正確に何を：生産システムあなたは何も変化しません（コード賢明に）。次の展開までです。

すべての前処理が原因で、使用しているGitベースのデプロイメントはMagento 1の場合よりもMagento 2に適していません。ビルドとデプロイはより複雑であり、私見では自動ビルドプロセスを回避する方法はありません

私がお勧めするもの：

• デプロイを繰り返し可能にします。つまり、生成されたファイルを含めて、ステージングされていたものとまったく同じコードが本番環境で確実に終了するようにする必要があります。

• これを実現するには、ビルドとデプロイメントを分離し、ビルドプロセスで以下を実行します。

  • composer install（vendor代わりにリポジトリに追加することも可能ですが、デプロイ中にサーバーでcomposerが実行されないようにするために、ビルドステップでそれを実行composer.lockし、リポジトリにのみ保持してください）

  • コード生成（YMMV）：

    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy

  • アーカイブ（作成ビルドアーティファクトを、フルMagentoのディレクトリから）を除くmediaとvar、しかし含めvendor、pub、var/generated及びvar/di。以降でMagentoの-2.2、var/generatedおよびvar/diに移動しているgenerated/codeとgenerated/metadata、それが簡単の残りの部分からそれらを分離することができた、var展開のために無視されるべきです。

• デプロイメントで、ビルドアーティファクトをターゲットサーバーにコピーし、それを新しいディレクトリに抽出します。

  • それに永続的なディレクトリをリンク（media、var/session、var/log、...）
  • メンテナンスモードを有効にする
  • ドキュメントルートの切り替え（通常、docrootは最後のリリースへのシンボリックリンクです。新しいリリースに変更してください）
  • キャッシュをフラッシュする
  • 走る setup:upgrade
  • メンテナンスモードを無効にする

• このデプロイメントプロセスは、Capistranoに似ていますがPHPであるDeployerを使用して簡単に実装できます。デプロイヤーに基づくMagento 2の完全な展開ソリューションは、https：//github.com/mwr/magedeploy2（netz98に感謝！）で見つかります。ここでは、使用する別のソリューションを示します。https：//github.com/staempfli / magento2-deployment-tool

• 維持app/etc/config.phpリポジトリには、有効および無効にモジュールを追跡するのに良いです。

これは段階的な説明ではありませんが、現在のプロセスのより強力な代替手段の概要を説明しています。リンクされたツールを見て、完全なソリューションがどのように見えるかを確認してください。

私の考えでは、Magento 2.2を待つか、同様のアプローチを実装してみてください。

Magento 2.2では、たとえば、ビルドサーバーと本番サーバーを分離することにより、パイプラインのデプロイメントが導入されています。

ここに公式のドキュメントがあります：http : //devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

さらに、現在私はAnsibleを使用して、構成テンプレートと複数の環境設定による自動デプロイメントを管理しています。