GITおよび展開戦略Magento2プロジェクト

92

Magento 1では、GITリポジトリをプルするデプロイツールを使用し、次のようなコマンドを実行modman deploy-allして、varディレクトリが書き込み可能であることを確認しました。のために.gitignore私はかなりうまくいったこれを使用しました。

しかし、Magento 2はどうでしょうか？

gitignoreが最適に機能するもの、プロジェクトをどのようにデプロイするか、どのコマンドをデプロイの前後に実行する必要があるか。コミュニティからいくつかの洞察を聞くことを楽しみにしています。

質問はしばらくの間開いたままになります

magento2

— サンダーマンジェル
ソース

Mangel @sander良い質問

— アミットベラは

1

定義上、これに対する標準的な回答はあり得ないため、あまりにも広範であり、サイトのQ＆Aの性質に適合しない可能性があります。メタである可能性があります。しかし、あなたはすでにこれを知っています。とはいえ、賞金の期限が切れるまで許可します。

— philwinkle

@philwinkleそれは広いかもしれませんが、すでに3つの答えが与えられたので、明らかに広すぎません。ここで説明したように：meta.magento.stackexchange.com/questions/745/…メタは、ランダムな投稿/質問ではなく、MageSEに関する質問に使用されることになっています。人々は質問に興味があり、私の意見では、それは有効なものです。

— サンダーマンジェル

2つのこと：まず、SanderはMetaについて正しいです-Magento SEに関連するSEプラットフォームに関する質問にのみ使用する必要があります（NB：この規則を強化するのに十分なMetaをポリシングしていない可能性があります）。第二に、質問に「多くの人々が興味を持っている」ことは、質問に正答できるかどうかとは関係ありません（したがって、StackExchange形式への質問の適合性と）。それは確かにイライラします（私はこれに自分で思いついた）。私はこのQ / Aスレッドがどこに行くのか見てみたいです。おそらく、Aは...排他的に「右」であることが十分に述べることができる

— benmarks

@benmarksその場合、私は賞金の間違った理由や主題を選びました。その背後にある私の動機は、このための完全な答えを書き留めるのに時間をかけた人に報いることでした。このスレッドがここに属していない場合は、コピーして、オンラインのどこかに投稿します。削除する前に私に通知してください

— サンダーマンジェル

56

以下の手順では、本番環境ではなく、カスタムモジュール開発用の環境を設定する方法について説明します。

プロジェクトの初期化

repo.magento.com資格情報とgithubアクセストークンをcomposerホームディレクトリのauth.jsonに追加します
次のコマンドを使用してプロジェクトを作成します。

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .
テイクこの.gitignoreをし、プロジェクトのルートに入れました。ほとんどすべてのコア・ファイル/ディレクトリはすでにルートに追加されている.gitignoreが、同様に、以下の2を追加した方がよい/updateと/phpserver（ちょうど.gitignoreするには、これらの2行を追加します）
プロジェクトルートで新しいgitリポジトリを初期化する
すべての追跡されていないファイルをgitに追加してコミットします
通常どおりモジュールの開発を開始します（それらをに置きますapp/code/VendorName/ModuleName）。これで、gitリポジトリにカスタムコードのみが作成されます。

Magentoのインストール

公式ガイドに概説されているように、すべてのファイルシステムのアクセス許可が設定されていることを確認してください
コマンドラインを使用してMagentoをインストールします。例：

${project_root}/bin/magento setup:install \ --db-host=localhost \ --db-name=magento \ --db-user=root \ --backend-frontname=admin \ --base-url=http://base.url.goes.here/ \ --language=en_US \ --timezone=America/Chicago \ --currency=USD \ --admin-lastname=Admin \ --admin-firstname=Admin \ --admin-email=admin@example.com \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1
インデクサーcronジョブを有効にします（Ubuntuなど）：

echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -
Magentoはdefaultモードで実行され、欠落しているすべてのコンテンツは最初の要求時に自動生成されます。そのため、コンパイラーや静的コンテンツのデプロイを実行する必要はありません
[オプション] PHP Stormを使用している場合、次のコマンドを実行してXSDサポートを有効にします。

bin/magento dev:urn-catalog:generate .idea/misc.xml

— アレックス・パリアーシュ
ソース

こんにちは、アレックス。プロジェクトの初期化手順3-少し拡張してもらえますか？そのサブディレクトリをルートに手動でコピーする必要がありましたか？（正しく機能していないものがあるかどうか疑問に思っています

— アランケント

@AlanKentは現在、Magento関連のすべてのファイルをにダウンロードします。これには、新しいプロジェクトのスケルトンであるがvendor含まれますmagento2-base。このステップが作曲家によって自動的に実行されるように構成されていない理由がわからない場合、見つけようとします。.gitignore別のレポジトリからのコピーに関しては、このステップを削除/簡素化する方法について既に議論されています。

— アレックスPaliarush

手順3は不要です。ファイル/フォルダのマーシャリングは、ステップ2の間に行われる

— マディ

@Maddyに感謝します。@AlanKent、magento2-baseルートへのコピーはもう必要ありません（検証されたばかり）、最近修正されたようです。このステップを回答から削除しました。

— アレックスPaliarush

1）レポジトリにすべてのコードを配置し、すでに失速しており、そのレポジトリからプルし、管理パンゲとdb資格情報の設定を変更すると、すべてが正しく動作しますか？2）プッシュ中にvar /およびpub /フォルダーを除外するのを忘れたため、リモートリポジトリで削除できるように完全に削除できますか？ありがとう。

— ラチェザールRaychev

25

初期化とインストールについては、Alexのほとんどのステップの答えを参考にしてください。違いだけをお勧めします。

Gitの構成

次のファイルのみをGitリポジトリに保存します。

composer.json
composer.lock
app / etc / config.php

プロジェクトのカスタムコードには、composerを通じてインクルードする別のモジュールも使用します。デプロイする特定のバージョン/リリースをロックできるため、この作曲家の管理が簡単になります。これにより、内部モジュールと外部モジュールにも同じアプローチを使用する必要があります。

展開

開発中に、次のコマンドを使用して環境（dev / test）のモジュールを更新します。

composer update

これにより、composer.lockファイルがそのインストールにインストールされているバージョンで更新されます。

ステージング/プリプロダクション/プロダクションで、次のコマンドを使用して同じセットアップを作成/インストールできます。

git pull
composer install

これにより、dev / testで使用されるのと同じモジュールがすべてインストールされ、本番環境への公開前のテストが、開発されたモジュールと同じバージョンで実行されることが保証されます。

インストール後、次のコマンドを実行します。

bin/magento setup:upgrade
bin/magento setup:di:compile (or setup:di:compile-multi-tenant)
bin/magento setup:static-content:deploy

これにより、データベースが更新され（スキーマとデータのアップグレード）、DI構成が生成され、すべての静的ビューファイルが展開されます。

— ウラジミール・ケルホフ
ソース

フィクスチャを生成する代わりにサンプルデータを使用するのは理にかなっているでしょうか？フィクスチャは最も重要なモジュールのみに配置され、パフォーマンステストのみに役立つようです。

— アレックスPaliarush

おかげで、本番でサイトを使用する際には必要ないため、その部分を削除しました。

— ウラジミールケルホフ

これは、私が使用しているアプローチにも非常に近いものです。これはMagento 1でもうまく機能します（ビルドプロセスはそれほど複雑ではありません）コンポーザーに仕事を任せてください、私の経験では展開に非常にうまく機能します。 gitの小さなフットプリントには従わないでください。

— Aepod

このインストールは「インテグレーター」のように見えます。vendor / magento / *にリポジトリを追加します。app / code / ..およびその他のディレクトリにはコードはありません。.zipアーカイブのように、Magento 2コアのディレクトリをどのように作成しますか。composerを介してモジュール（他のgitリポジトリ）を追加し、app / code / ...で自動的に終了することは可能ですか？

— 無名の

4

危険なのは、composerは展開ツールではないということです。本番

— 環境で

3

.gitignoreに関して、2.2以降の公式Magentoの答えは「config.phpはgitになりますが、env.phpはそうなりません」です。

内部開発者を拡張機能開発および顧客サイトに近づけるために、Mediawikiのような作曲家プラグインを検討しています。まだ最終段階ではなく、まだ調査中です。

Composerの「パス」リポジトリタイプを../othergitrepo/app/code/*/*使用してモジュールを選択するのが大好きですが、Unisonなどを使用する開発環境ではあまり機能しないシンボリックリンクを使用します。

— アラン・ケント
ソース

3

別のbuild-server / processを含まない別のアプローチを実行し、本番環境のようにローカルに開発します

次に、実稼働に必要なすべてのファイルをコミットします。次に、変更セットをサーバーに展開し、アップグレードコマンドを実行します。

開発に適しているが本番モードで動作するバージョンに到達することは難しい部分であり、まだ完全ではありませんが、今では機能するレシピがあります。

その理由は、どのコードが本番に入るかを100％制御したいからです。magento2は大量のコードを生成するため、すべての効果を理解し、本番環境のようにデバッグできるように、ローカルで実行する必要があります。

これは多くの人が推奨することではありませんが、私たちにとっては最も効果的であることを認識しています。

フロントエンドのセットアップ手順

これらのスクリプトが機能するには、env.phpでショップを実稼働モードに設定し、でテーマを設定しますdev/tools/grunt/configs/themes.js。（次の手順はansibleプレイブックに追加されました）

削除する var/cache
削除する var/view_preprocessed
削除pub/static/*（.htaccessを削除しないでください）
削除する var/composer_home
走る php bin/magento cache:flush
走る php bin/magento setup:static-content:deploy %your_languages%
pub / static / frontendから実際に使用しないすべてのテーマ/言語を削除します
以下のファイルのハードコピーを削除します pub/static/frontend
走る php bin/magento dev:source-theme:deploy --locale="%your_language%" --theme="%your_theme%" css/styles-m css/styles-l css/email css/email-inline
オプション：bashスクリプトを使用して、手順9で作成された絶対シンボリックリンクを相対的なものに変更し、vmの外部からgruntを実行できるようにします
走る grunt less:your_theme

バックエンド/セットアップ手順

削除する var/cache
削除する var/generation
削除する var/composer_home
削除する var/di
走る php bin/magento cache:flush
走る php bin/magento setup:di:compile

— greenone83
ソース

この@ greenone83のおかげで、これは基本的に採用したアプローチですが、フロントエンドの一部としてバックエンドを生成します。setup：di：compileを使用することは絶対にありません。私が理解していないことの1つは、setup：static-content：deployが生成/コードでファイルを作成する理由です（投稿から場所が変更されました）？生成/コードをすべて削除すると、サイトが実稼働モードの場合、サイトを閲覧するとこれらのファイルが自動的に作成されることがわかりました。

— PedroKTFC

2

これらのファイルも無視してください
/app/etc/config.php
/app/etc/env.php
/.idea/workspace.xml // phpstorm

— mrtuvn
ソース

2

config.phpを無視する場合は、他の環境にプッシュした後、新しい拡張機能を再度有効にする必要があります。したがって、リポジトリに含めることをお勧めします。

— ウラジミールケルホフ