Magento 2の導入プロセス

現在composer.lock、リポジトリにコミットしてからcomposer install --no-dev、本番サーバーで実行します。composerがすべてのファイルを生成するのに数分かかり、危険を伴うため、これが最良の方法だとは思いません。

本番モードで実行するために必要なすべてのファイルをリポジトリにコミットする方が良いのではないでしょうか。

他の人はどのようにしてmagento 2で展開プロセスを管理しますか？

ベンダーをコミットしないこと、および本番環境でcomposerインストールを実行しないことについて、claudiu-creangaと100％同意します。

これを処理する方法は、ライブフォルダーとリリース候補フォルダーを持つことです。git pullコマンドとcomposer install --no-devを実行するのはリリース候補フォルダーです。私たちのプロセスは次のように要約できます：

1. リリース候補フォルダー：

   • 予期しない変更を確認する
   • リポジトリを更新
   • Composerのインストール

2. ファイルをライブサイトフォルダーに同期

3. ライブサイトフォルダー：
   • 静的ファイルをデプロイする
   • メンテナンスモードを有効にする
   • モジュールを有効にする
   • セットアップスクリプトを実行する
   • コンパイルDI
   • キャッシュの消去
   • メンテナンスモードを無効にする
   • 権限を更新する

私は実際のコマンドとこれの背後にある理由を提供するより長いブログ記事を書きました：https : //www.c3media.co.uk/blog/c3-news/deploying-magento-2-production-environment/

更新：ライブデータベースをステージングデータベースにコピーし、これを使用してセットアップスクリプトを実行し、静的ファイルを展開し、DIをすべてオフラインでコンパイルします。これは、pub / staticファイルとvarを含めてライブにデプロイできます。セットアップスクリプトが実行されている場合は、サイトを一時的に停止しますが、それ以外の場合はサイトをそのままにしておきます。詳細については、https：//www.c3media.co.uk/blog/c3-news/magento-2-deployment-without-downtime/をご覧ください。

更新：ベンダーフォルダーのコミットについて私の考えを変更しました-フォルダーをコミットすることで、これらのファイルの変更履歴を追跡する機能が得られ、誤って何かを変更したかどうかを確認できます。最も重要なのは、composerを実行する必要がないことです。展開時。リポジトリの外部サプライヤーに依存している今、後者は非常に重要です。それらの1つが利用できない場合はどうなりますか？突然展開できなくなります。欠点は、リポジトリが大きくなり、コアハックを行うリスクがあり、私のような開発者がひどく嫌いになることです:)

これまでのところ、ベンダーフォルダーもコミットしています。もちろん、これにより、リポジトリにたくさんのファイルが追加されます。（ベンダーコンポーザーファイル内の.gitフォルダーは必ず削除してください。そうしないと、フォルダーの内容がコミットされません。たとえば、firegentoなど）。しかし、vendorフォルダーのシンボリックリンクは機能せず、vendor_path.phpファイルのパスを編集することも機能せず、これまでのところ、より良い解決策を探す時間がありませんでした。

ビルドサーバーがなく、サーバーでcomposerを実行していません。すべての更新をローカルで実行してテストし、コミットします。これにより、デプロイメントスクリプトがトリガーされます。

配備スクリプトはenv.phpファイルを置き換え、いくつかのカスタム処理を実行してから、ライブリンクを新しいフォルダーに切り替える前にトリガーsetup:upgradeしsetup:static-content:deployます。

シンボリックリンクする唯一のフォルダはpub / mediaです。

最後にdeploybot（http://deploybot.com/）のようなサービスをオプトアウトしました。capistrano無料で使用できます。Deploybotは、composerのインストールの実行中にDockerコンテナーを作成し、コマンドが成功した場合はコードをデプロイします。それ以外の場合は何もデプロイしないため、運用環境は安全です。

私はこれが最良のアプローチであると考えています：

1）gitリポジトリにベンダーフォルダーを置くことは、正当な理由により、作曲家たちにはお勧めできません。

The general recommendation is no. The vendor directory (or wherever your dependencies are installed) should be added to .gitignore/svn:ignore/etc.

詳細：https : //getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

2）composer install in productionセーフティネットなしでの実行は危険です。パッケージがダウンしている可能性があります（npmを参照）。メモリの問題が発生したり、composerがファイルを生成しているときにエラーが発生したり、壊れた本番環境に対処したりする必要があります。

私もこれを調べています、これまでに取ったアプローチは次のとおりです：

サーバーのブートストラップ：

1. セットアッププロジェクトcomposer --create-project ... --no-devにsrcフォルダ（私はまだ通じてくるのdevの嫌なものの多くを見るが）
2. アプリのセットアップ、静的ファイルのコンパイル、dbのアップグレードなど。
3. すべての正しい権限を設定する

私のsrcディレクトリからストック、実行中のストアを取得します（ただし、私のwebrootはそこを指していません）

次に、私の展開プロセス：

1. 新しいリリースフォルダを作成する
2. srcファイルを私のリリースにrsyncします（cruftを除く）
3. カスタマイズを展開して展開します（少数のテーマファイルとモジュール）
4. magento connectを介してサードパーティのmagentoモジュールをインストールします
5. 私のホストのウェブルートが私の新しいリリースを指すようにします（シンボリックリンク付き）
6. ウェブサーバーを適切に再読み込みします

これにより、Magentoコアコードを自分のものとは別に維持し、composerを使用して最新の状態に保つことができます。39,102を出荷する必要はありません!!! 各デプロイのファイル、またはデプロイ時にcomposerコマンドを実行します。

...他のアプローチやこれに関するベストプラクティスを聞きたがっています。また、idは、実際にどのファイルが本番環境に必要で、どのファイルが開発に必要かを知るのが大好きなので、ウェブルートをクリーンに保つことができます。

完了したら、ansibleプレイブックと、構成と展開を調整するためのいくつかのFabricコマンドがあります。

それが役に立てば幸い