デプロイメントのベストプラクティス
ビルドおよびデプロイスクリプトは、コードをリモート環境に結合する際にアクティベートされます。 これらのスクリプトは、環境 設定ファイルとアプリケーションコードを使用して、クラウドインフラストラクチャに適切なデータとサービスをプロビジョニングします。 また、これらのスクリプトは、クラウド環境でAdobe Commerce アプリケーション、サードパーティのサービスおよびカスタム拡張機能をインストールまたは更新するために使用されます。
ビルドとデプロイのプロセスは、計画ごとに少し異なります。
-
スタータープラン – 統合環境の場合、アクティブなすべてのブランチは、アクセスとテストのために完全な環境にビルドおよびデプロイされます。
staging分岐に結合した後、コードを完全にテストします。 サイトを起動するには、stagingをmasterにプッシュして、実稼動環境にデプロイします。 Cloud Console および CLI コマンドを使用して、すべてのブランチに対するフル アクセスが可能です。 -
Pro プラン：統合環境では、アクティブな各ブランチが構築され、アクセスとテスト用の完全な環境にデプロイされます。 ステージング環境と実稼動環境に結合する前に、コードを
integrationブランチに結合します。 Cloud Console を使用するか、SSH およびmagento-cloudCLI コマンドを使用して、ステージング環境と実稼動環境に結合できます。
プロセスのトラッキング
ターミナルまたは Cloud Console Status メッセージ（in-progress、pending、success、failed）を使用して、ビルドおよびデプロイのアクションをリアルタイムで追跡できます。これらのメッセージは、デプロイメントプロセス中に表示されます。 ログファイルに詳細を表示できます。 ログを表示を参照してください。
外部 GitHub リポジトリを使用している場合、操作のログは GitHub セッションに表示されません。 ただし、外部リポジトリと Cloud Console のインターフェイスでアクティビティをフォローすることはできます。 統合を参照してください。
New Relicでデプロイメントを追跡を有効にして、デプロイメントイベントを監視し、デプロイメント間のパフォーマンスを分析できます。
ビルドとデプロイメントのベストプラクティス
デプロイメントプロセスに関する以下のベストプラクティスと考慮事項を確認します。
-
ece-toolsパッケージの最新バージョンを実行していることを確認してくださいECE ツールのリリースノートを参照してください。
-
ビルドおよびデプロイプロセスに従う
環境間でコードを結合する際に設定が上書きされるのを避けるために、各環境に正しいコードが用意されていることを確認します。 例えば、設定の変更をすべての環境に適用するには、リモート統合環境にデプロイする前に、ローカル環境で変更を変更およびテストします。 次に、実稼動環境にデプロイする前に、ステージング環境で変更をデプロイしてテストします。 ある環境から別の環境に結合すると、環境固有の設定を除き、デプロイメントによって環境内のすべてのコードが上書きされます。
-
環境全体で同じ変数を使用する
これらの変数の値は、環境によって異なる場合があります。ただし、通常は各環境で同じ変数が必要です。 ストア設定の設定の管理を参照してください。
-
環境固有の変数に機密性の高い設定値とデータを保持する
これらの値には、Cloud CLI や Cloud Console を使用して指定された変数、または
env.phpファイルに追加された変数が含まれます。 変数レベルを参照してください。 -
環境ブランチですべてのコードが使用可能であることを確認します
プライベートブランチなどの他のブランチからコードを参照すると、ビルドおよびデプロイプロセス中に問題が発生する可能性があります。 例えば、非公開ブランチからテーマを参照する場合、テーマにはアクセスできず、アプリケーションコードを使用してテーマを作成することもできません。
-
反復されたブランチへの拡張機能、統合およびコードの追加
変更をローカルで作成およびテストし、
integrationにプッシュしてから、stagingとproductionにプッシュします。 更新を次の環境に結合する前に、各環境の問題をテストして解決します。 一部の拡張機能と統合は、依存関係により、特定の順序で有効にして設定する必要があります。 グループで追加とテストを行うと、ビルドとデプロイのプロセスがはるかに容易になり、問題が発生する場所を判断するのに役立ちます。 -
サービスのバージョンと関係、および接続機能の確認
アプリケーションで使用可能なサービスを確認し、最新の互換性のあるバージョンを使用していることを確認します。 インストールガイドの サービスの関係および 必要システム構成 を参照してください。
-
ステージング環境および実稼動環境にデプロイする前に、ローカルおよび統合環境でテストする
ステージング環境および実稼動環境にデプロイする際にダウンタイムが長くならないように、ローカル環境と統合環境の問題を特定し修正します。
note tip TIP クラウドプロジェクト設定が、静的コンテンツのデプロイメント（SCD）戦略を含む、ビルドおよびデプロイメント設定のベストプラクティスに従っていることを検証するために使用できる スマートウィザードコマンドがあります。 -
ローカル環境と統合環境でのテストが完了したら、ステージング環境でデプロイしてテストします
ステージングと実稼動のテストを参照してください。
-
実稼動環境の設定の確認
実稼動環境にデプロイする前に、次のタスクを実行します。
-
デプロイプロセスの監視
デプロイメントステータスメッセージを確認し、必要に応じて問題を軽減します。 詳細なログメッセージについては、クラウドの logs を確認してください。
統合のビルドとデプロイメントの 5 つのフェーズ
統合環境およびローカル開発環境では、次のフェーズが行われます。 Pro プランの場合、これらの初期フェーズでは、コードはステージング環境または実稼動環境にデプロイされません。
フェーズ 1：コードと設定の検証
プロジェクトを最初に設定するときは、 クラウドインフラストラクチャテンプレートがコードファイルの基礎となります。 このコードリポジトリは、master ブランチとしてプロジェクトに複製されます。
- スターターの場合 -
masterのブランチは実稼動環境です。 - Pro の場合:
masterは統合環境のオリジンブランチとして開始されます。
カスタムコード、拡張機能およびモジュール、サードパーティの統合用に、master からブランチを作成します。 クラウド内のコードをテストするためのリモート統合環境があります。
コードをローカルワークスペースからリモートリポジトリにプッシュすると、ビルドスクリプトとデプロイスクリプトの開始前に、一連のチェックとコード検証が完了します。 組み込みの Git サーバーが、プッシュ内容の検証と変更を行います。 例えば、OpenSearch サービスを追加すると、組み込みの Git サーバーによって、クラスターのトポロジが適切に変更されたかどうかが確認されます。
設定ファイルに構文エラーがある場合、Git サーバーはプッシュを拒否します。 保護ブロックを参照してください。
このフェーズでは、composer install も実行して依存関係を取得します。
フェーズ 2：構築
このフェーズでは、コードベースを構築し、.magento.app.yaml の build セクションでフックを実行します。 デフォルトのビルドフックは php ./vendor/bin/ece-tools のコマンドで、次の操作を実行します。
vendor/magento/ece-patchesでパッチを適用し、m2-hotfixesでオプションでプロジェクト固有のパッチを適用しますbin/magento setup:di:compileを使用して、コードおよび 依存関係の挿入設定（generated/codeとgenerated/metapackageを含むgenerated/ディレクトリ）を再生成します。- コードベースに
app/etc/config.phpファイルが存在するかどうかを確認します。 Adobe Commerceは、ビルドフェーズでこのファイルが検出されず、モジュールと拡張機能のリストが含まれている場合、このファイルを自動生成します。 存在する場合、ビルドフェーズは通常どおり続行され、静的ファイルは GZIP で圧縮されてデプロイされるので、デプロイメントフェーズでのダウンタイムが短縮されます。 ファイル圧縮のカスタマイズまたは無効化については、 ビルドオプションを参照してください。
アプリケーションのビルド後、アプリケーションは 読み取り専用のファイルシステム にマウントされます。 読み取り/書き込み可能にする特定のマウントポイントを設定できます。 サーバーに FTP で接続したり、モジュールを追加したりすることはできません。 代わりに、ローカルリポジトリにコードを追加して、環境のビルドとデプロイを行う git push を実行する必要があります。 プロジェクト構造については、 ローカルプロジェクトディレクトリ構造を参照してください。
フェーズ 3：スラグを準備する
ビルドフェーズの結果、slug と呼ばれる読み取り専用のファイルシステムが生成されます。 このフェーズでは、アーカイブが作成され、スラグが永続的なストレージに配置されます。 次回コードをプッシュするときに、サービスが変更されなかった場合は、アーカイブのスラグが使用されます。
- 変更されていないコードを再利用することで、継続的な統合ビルドを迅速に実行
- コードが変更された場合、再利用するために次のビルド用にスラグを更新します
- 必要に応じて、デプロイメントを即座に元に戻すことができます。
- コードベースに
app/etc/config.phpファイルが存在する場合、静的ファイルを含める
スラグには、magento.app.yaml で設定されたすべてのファイルとフォルダー 以下を除く マウントが含まれます。
"var": "shared:files/var""app/etc": "shared:files/etc""pub/media": "shared:files/media""pub/static": "shared:files/static"
フェーズ 4：スラグとクラスターのデプロイ
アプリケーションとすべての バックエンドサービスは、次のようにプロビジョニングされます。
- Web サーバー、OpenSearch、RabbitMQ などのコンテナ内の各サービスをマウントします
- 読み取り/書き込み可能なファイル・システムをマウントする（高可用性の分散ストレージ・グリッドにマウント）
- サービスが相互に（そして互いに対してのみ）見ることができるようにネットワークを設定します。
フェーズ 5：デプロイメントフック
最後の手順では、デプロイメントスクリプトを実行します。このスクリプトを使用して、開発環境のデータの匿名化、キャッシュのクリア、外部の継続的統合ツールのクエリを行うことができます。 このスクリプトを実行すると、Redis などの環境内のすべてのサービスにアクセスできます。
app/etc/config.php ファイルがコードベースに存在しない場合、静的ファイルは gzip を使用して圧縮され、このフェーズでデプロイされます。これにより、デプロイフェーズとサイトメンテナンスの長さが長くなります。
デプロイフックは 2 つあります。 pre-deploy.php フックは、ビルドフックで生成されたリソースとコードの必要なクリーンアップと取得を完了します。 php ./vendor/bin/ece-tools deploy フックは、一連のコマンドとスクリプトを実行します。
-
Adobe Commerceが インストールされていない 場合は、
bin/magento setup:installと共にインストールされ、デプロイメント設定、app/etc/env.phpおよび指定した環境用のデータベース（Redis や Web サイト URL など）が更新されます。 重要： セットアップ中に 初回のデプロイメントを完了すると、Adobe Commerceがインストールされ、すべての環境にデプロイされました。 -
Adobe Commerce インストール済み の場合は、必要なアップグレードを実行します。 デプロイメントスクリプトは、
bin/magento setup:upgradeを実行してデータベーススキーマとデータを更新します（これは、拡張機能またはコアコードの更新後に必要です）。また、デプロイメント設定、app/etc/env.php、お使いの環境のデータベースも更新します。 最後に、デプロイメントスクリプトによって Adobe Commerceのキャッシュがクリアされます。 -
スクリプトはオプションで、コマンド
magento setup:static-content:deployを使用して静的 web コンテンツを生成します。 -
静的コンテンツ
-sプロイメント戦略で、デフォルト設定がquickのスコープ（ビルドスクリプトのフラグ）を使用します。 環境変数SCD_STRATEGYを使用して、戦略をカスタマイズできます。 これらのオプションと機能について詳しくは、 静的ファイルのデプロイメント戦略および 静的表示ファイルのデプロイの-sフラグを参照してください。
.magento ディレクトリの設定ファイルで定義された値を使用してから、ディレクトリとその内容を削除します。 ローカル開発環境は影響を受けません。Postのデプロイメント：ルーティングの設定
デプロイメントの実行中、プロセスはエントリポイントでの受信トラフィックを 60 秒間停止し、新しく作成したクラスターに web トラフィックが到達するようにルーティングを再設定します。
デプロイメントが成功すると、メンテナンスモードが削除され、通常のアクセスが可能になり、app/etc/env.php と app/etc/config.php の設定ファイルのバックアップ（BAK）ファイルが作成されます。
SCD_ON_DEMAND 変数を使用して静的コンテンツ生成を有効にし、post_deploy フックを設定します。これによりキャッシュがクリアされ、コンテナが接続の受け入れを開始し、送信中 通常の受信トラフィックがキャッシュに事前に読み込まれ ウォーム します。
ビルドおよびデプロイのログを確認するには、 ログの表示を参照してください。