ドキュメントCommerceCommerce on Cloud

デプロイのベストプラクティス

最終更新日： 2026年6月2日

作成対象：

  • {"id":"c66ffd68-0f65-42bb-aa23-b4020f12e0bd"},{"id":"ff6a42d2-313e-452e-93a6-792e4fad9ff8"}

コードをリモート環境にマージする際にアクティブになるスクリプトをビルドおよびデプロイします。 これらのスクリプトでは、環境設定ファイル ​とアプリケーションコードを使用して、適切なデータとサービスを使用してクラウドインフラストラクチャをプロビジョニングします。 また、これらのスクリプトは、Adobe Commerce アプリケーション、サードパーティサービス、およびカスタム拡張機能をクラウド環境にインストールまたは更新するために使用されます。

ビルドとデプロイのプロセスは、プランごとに少しずつ異なります。

  • スタータープラン – 統合環境では、すべてのアクティブなブランチが構築され、アクセスとテストのために完全な環境にデプロイされます。 staging ブランチにマージした後、コードを完全にテストします。 サイトを起動するには、stagingをmasterにプッシュして、実稼動環境にデプロイします。 Cloud ConsoleおよびCLI コマンドを使用して、すべてのブランチに完全にアクセスできます。

  • Pro プラン – 統合環境では、すべてのアクティブなブランチが構築され、アクセスとテストのために完全な環境にデプロイされます。 ステージング環境と実稼動環境に結合する前に、コードをintegration ブランチに結合します。 Cloud Consoleを使用するか、SSHおよびmagento-cloud CLI コマンドを使用して、ステージング環境と実稼動環境に統合できます。

プロセスの追跡

ビルドおよびデプロイのアクションは、デプロイメントプロセス中にターミナルまたはCloud Console ステータスメッセージ（in-progress、pending、success、またはfailed）を表示してリアルタイムで追跡できます。 ログファイルで詳細を表示できます。 ​ ログの表示を参照してください。

外部GitHub リポジトリを使用している場合、操作のログはGitHub セッションに表示されません。 ただし、外部リポジトリとCloud Consoleのインターフェイスのアクティビティを引き続き実行できます。 統合を参照してください。

NOTE
統合環境では、Cloud Consoleのデプロイ ログを表示できません。 この機能は、実稼動環境とステージング環境でのみ使用できます。 ただし、​ ビルドとデプロイ ​のログを使用すると、任意の環境でデプロイメントの各フェーズのログを表示できます。 トラブルシューティング情報については、​ デプロイメントエラーリファレンス ​を参照してください。

New Relicでデプロイメントを追跡を有効にして、デプロイメントイベントを監視し、デプロイメント間のパフォーマンスを分析できます。

ビルドとデプロイメントのベストプラクティス

デプロイメントプロセスについて、次のベストプラクティスと考慮事項を確認します。

  • 最新バージョンのece-tools パッケージを実行していることを確認してください

    ECE-Tools🔗の リリースノートを参照してください。

  • ビルドとデプロイのプロセスに従う

    環境間でコードをマージする際に設定を上書きしないように、各環境に正しいコードがあることを確認してください。 例えば、すべての環境に設定の変更を適用するには、リモート統合環境にデプロイする前に、ローカル環境の変更を変更してテストします。 次に、実稼動にデプロイする前に、ステージング環境の変更をデプロイしてテストします。 ある環境から別の環境にマージすると、環境固有の設定と設定を除いて、デプロイメントによって環境内のすべてのコードが上書きされます。

  • 環境で同じ変数を使用

    これらの変数の値は環境によって異なる場合がありますが、通常は各環境で同じ変数が必要です。 ストア設定の構成管理を参照してください。

  • 機密性の高い設定値とデータを環境固有の変数に保持

    これらの値には、Cloud CLI、Cloud Console、またはenv.php ファイルに追加された変数が含まれます。 変数レベル ​を参照してください。

  • すべてのコードが環境ブランチで利用できることを確認してください

    プライベートブランチなどの他のブランチからのコードを参照すると、ビルドおよびデプロイプロセス中に問題が発生する可能性があります。 例えば、プライベートブランチからテーマを参照する場合、テーマにアクセスできず、アプリケーションコードでビルドできません。

  • 反復分岐に拡張機能、統合、コードを追加

    変更をローカルで行ってテストし、integrationにプッシュしてから、stagingとproductionにプッシュします。 更新を次の環境に結合する前に、各環境の問題をテストして解決します。 一部の拡張機能や統合は、依存関係により、特定の順序で有効および設定する必要があります。 グループに追加してテストすることで、ビルドとデプロイのプロセスがはるかに簡単になり、問題が発生する場所を判断するのに役立ちます。

  • サービスのバージョンと関係、および接続する機能を確認する

    アプリケーションで使用可能なサービスを確認し、最新の互換性のあるバージョンを使用していることを確認します。 推奨バージョンについては、インストールガイド​の​ サービス関係および必要システム構成を参照してください。

  • ステージングおよび実稼動にデプロイする前に、ローカルおよび統合環境でテストします

    ローカル環境および統合環境の問題を特定して修正し、ステージング環境および実稼動環境にデプロイする際のダウンタイムの延長を防ぎます。

    note tip
    TIP
    クラウドプロジェクトの設定が、静的コンテンツ展開（SCD）戦略を含む、ビルドおよびデプロイメント設定のベストプラクティスに従っていることを確認するために使用できる​ スマートウィザード ​のコマンドがあります。

  • ローカル環境と統合環境でのテストを完了したら、ステージング環境でデプロイしてテストします

    ​ ステージングおよび実稼動テスト ​を参照してください。

  • 実稼動環境の設定を確認

    実稼動にデプロイする前に、次のタスクを実行します。

    • SSHを使用して、実稼動環境内のすべての3つのノードに接続できることを確認してください。

    • インデクサーがスケジュール で​更新に設定されていることを確認します。 拡張機能デベロッパーガイド​の​ インデックス作成モード ​を参照してください。

    • 実稼動コード内の環境固有の変数を更新し、サービスの可用性と互換性を確認し、その他の必要な設定変更を行うことで、環境を準備します。

  • デプロイ プロセスを監視

    デプロイメントのステータスメッセージを確認し、必要に応じて問題を軽減します。 詳細なログメッセージについては、クラウド logsを参照してください。

統合の構築と展開の5つのフェーズ

ローカル開発環境と統合環境では、次のフェーズが実行されます。 Pro プランの場合、コードは、これらの初期フェーズでステージング環境または実稼動環境にデプロイされません。

フェーズ 1: コードと設定の検証

最初にプロジェクトを設定すると、​ クラウドインフラストラクチャテンプレート ​によってコードファイルの基礎が提供されます。 このコード リポジトリは、master ブランチとしてプロジェクトに複製されます。

  • Starter—master ブランチは実稼動環境です。
  • For Pro—masterは、統合環境のオリジン ブランチとして開始されます。

カスタムコード、拡張機能とモジュール、サードパーティの統合用にmasterからブランチを作成します。 クラウドでコードをテストするためのリモート統合環境があります。

ローカルのワークスペースからリモートリポジトリにコードをプッシュすると、ビルドとデプロイのスクリプトが開始される前に、一連のチェックとコード検証が完了します。 組み込みのGit サーバーは、プッシュする内容を検証し、変更を加えます。 例えば、OpenSearch サービスを追加した場合、組み込みのGit サーバーは、クラスターのトポロジが適切に変更されていることを確認します。

設定ファイルに構文エラーがある場合、Git サーバーはプッシュを拒否します。 保護ブロック ​を参照してください。

このフェーズでは、依存関係を取得するためにcomposer installも実行されます。

フェーズ 2：構築

NOTE
ビルド段階では、サイトはメンテナンスモードではなく、エラーや問題が発生した場合もダウンしません。 前のビルド以降に変更されたコードのみがビルドされます。

このフェーズでは、コードベースを構築し、.magento.app.yamlのbuild セクションでフックを実行します。 デフォルトのビルドフックはphp ./vendor/bin/ece-tools コマンドで、次の操作を実行します。

  • vendor/magento/ece-patchesにパッチ、およびm2-hotfixesにプロジェクト固有のオプションのパッチを適用します
  • コードと、bin/magento setup:di:compileを使用して依存関係インジェクション ​設定（つまり、generated/ ディレクトリで、generated/codeとgenerated/metapackageが含まれる）を再生成します。
  • app/etc/config.php ファイルがコードベースに存在するかどうかを確認します。 Adobe Commerceは、ビルド段階でこのファイルを検出せず、モジュールと拡張機能のリストを含む場合、このファイルを自動生成します。 ビルド段階が存在する場合は、通常どおり続行し、GZIPを使用して静的ファイルを圧縮してデプロイします。これにより、デプロイメント段階でのダウンタイムが減少します。 ファイル圧縮のカスタマイズまたは無効化について詳しくは、​ ビルドオプション ​を参照してください。
WARNING
この時点では、クラスターは作成されていないので、データベースへの接続を試みたり、アクティブなデーモンプロセスがあると仮定したりしないでください。

アプリケーションのビルド後、読み取り専用の​ ファイルシステム ​にマウントされます。 読み取り/書き込みを行う特定のマウントポイントを設定できます。 サーバーにFTP接続してモジュールを追加することはできません。 代わりに、ローカル リポジトリにコードを追加してgit pushを実行し、環境を構築およびデプロイする必要があります。 プロジェクト構造については、​ ローカルプロジェクトディレクトリ構造を参照してください。

フェーズ 3：スラグの準備

ビルド フェーズの結果は、スラグ​と呼ばれる読み取り専用のファイルシステムです。 このフェーズでは、アーカイブを作成し、スラグを永続的なストレージに配置します。 次回コードをプッシュする際に、サービスが変更されなかった場合は、アーカイブのスラグが使用されます。

  • 変更されていないコードを再利用することで、継続的な統合をより迅速に構築
  • コードが変更された場合は、次のビルドのスラグを更新して再利用します
  • 必要に応じて、デプロイメントを瞬時に元に戻すことができます
  • 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などのコンテナ内の各サービスをマウントします
  • 読み取り/書き込みファイルシステムをマウントします（高可用性の分散型ストレージグリッドにマウント）
  • サービスがお互いを「見る」ことができるようにネットワークを設定します（お互いのみ）
NOTE
ビルドとデプロイメントが完了したら、Git ブランチで変更を加え、再度プッシュします。 すべての環境ファイルシステムは​_読み取り専用_​です。 読み取り専用システムは、決定論的なデプロイメントを保証し、ファイルシステムに書き込むプロセスがないので、サイトのセキュリティを大幅に向上させます。 また、統合、ステージング、実稼動環境でコードが同じであることを確認することもできます。

フェーズ 5：デプロイメントフック

NOTE
このフェーズでは、デプロイメントが完了するまで、Commerce アプリケーションはメンテナンスモードになります。

最後の手順では、デプロイメントスクリプトを実行します。このスクリプトを使用すると、開発環境のデータを匿名化し、キャッシュをクリアし、外部の継続的インテグレーションツールをクエリできます。 このスクリプトが実行されると、Redisなど、環境内のすべてのサービスにアクセスできます。

app/etc/config.php ファイルがコードベースに存在しない場合、静的ファイルはgzipを使用して圧縮され、このフェーズ中にデプロイされます。これにより、デプロイ フェーズとサイト メンテナンスの長さが長くなります。

NOTE
ファイル圧縮のカスタマイズまたは無効化について詳しくは、変数のデプロイ ​を参照してください。

デプロイメントフックは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 フラグを参照してください。

NOTE
デプロイ スクリプトは、.magento ディレクトリ内の構成ファイルで定義された値を使用し、その後、スクリプトによってディレクトリとその内容が削除されます。 ローカル開発環境は影響を受けません。

デプロイメント後：ルーティングの設定

デプロイメントの実行中、プロセスはエントリポイントで受信トラフィックを60秒間停止し、web トラフィックが新しく作成したクラスターに到達するようにルーティングを再設定します。

正常に展開すると、通常のアクセスを許可するメンテナンスモードが削除され、app/etc/env.phpおよびapp/etc/config.php設定ファイルのバックアップ （BAK） ファイルが作成されます。

SCD_ON_DEMAND変数を使用して静的コンテンツ生成を有効にし、post_deploy フック ​を設定して、キャッシュをクリアし、コンテナが接続の受け入れを開始した​ 後 ​にキャッシュをプリロード（ウォーム）し、通常の受信トラフィック中に​します。

ビルドおよびデプロイ ログを確認するには、​ ログの表示を参照してください。

recommendation-more-help
commerce-on-cloud-help-cloud-guide