デプロイメントの概要
ここでは、Adobe Commerce バージョン 2.2以降の実稼動サイトにCommerce アプリケーションをデプロイするプロセスについて説明します。 Adobeでは、大規模なサイトを持ち、デプロイメント中にダウンタイムが発生したくない場合は、このデプロイメント方法をお勧めします。
1台のマシンにCommerceをデプロイし、デプロイメント中にダウンタイムを許容できる場合は、1台のマシンのデプロイメント を参照してください。
パイプラインの展開
Commerce バージョン 2.2では、Adobeは、ダウンタイムを最小限に抑えながら実稼動にデプロイする新しい方法として パイプラインのデプロイメント を導入しました。 このデプロイメントプロセスは、様々なシステムで実行され、すべてのパイプラインデプロイメントシステムの一貫した設定を維持する方法を提供します。 これは、通常の設定を、システム固有の設定（ホストやポートなど）または機密性の高い設定（名前やパスワードなど）から分離できる、シンプルで強力なモデルです。
パイプラインのデプロイメントを使用する場合、Adobeでは次のことを前提としています。
- Adobe Commerceの設定オプションに関する優れた知識を備えた経験豊富なシステムインテグレーター。
- 大規模なCommerceサイト（数千ものSKU）を管理し、実稼動サイトのダウンタイムを最小限に抑えたい場合。
- PHP プログラミングに関する知識。
- ソース管理手法の活用。
- コードはソース管理リポジトリにあります。 このガイドでは、Git ベースのリポジトリを使用していることを前提としています。
ダウンタイムの削減
静的アセットをデプロイし、実稼動システムとは別のマシンでコードをコンパイルすると、ダウンタイムを最小限に抑えることができます。 実稼動システムのダウンタイムは、静的ファイルとコンパイル済みコードをサーバーに転送するために必要な時間に制限されます。
デプロイメントシステム
デプロイメントに関するシステムについては、次の用語を使用します。
-
開発システム – 開発者がコードのカスタマイズに取り組むコンピューター。また、Commerce Marketplaceから拡張機能、テーマ、言語パッケージをインストールします。 さらに、開発システムですべての設定変更を行います。 多くの開発システムを持つことができます。
-
ビルド システム – 静的アセットをデプロイし、実稼動システムのコードをコンパイルする1つのシステム。 これらのアセットは本番環境にないシステムで構築されるため、本番システムのダウンタイムは最小限に抑えられます。
ビルドシステムにCommerceがインストールされている必要はありません。 Commerce コードのみが必要ですが、データベースへの接続は必要ありません。 また、ビルドシステムは物理的に別のサーバーである必要はありません。
-
ステージング システム—オプション。 オプションとして、ユーザー受け入れテスト（UAT）を含むすべての統合コードの最終テストに使用するステージングシステムを設定できます。 ステージングシステムの設定は、実稼動システムの設定と同じように行います。 ステージングはライブストアではなく、顧客からの注文を処理しないという事実を除いて、本番環境と同じです。
-
実稼動システム – お客様の実店舗。 ここでは直接設定の変更は最小限に抑える必要があります。ステージングインスタンスでテストされていないものは何もテストしないでください。 可能であれば、ステージング/開発インスタンスでテストされた データパッチ を使用して設定を変更します。
その他のデプロイ方法
必要に応じて、次のような他のデプロイメント方法を使用できます。
- SCPまたはrsyncによる安全なコピー
- Capistrano
- デプロイツール
設定の管理
12 ファクターアプリデザイン 🔗の ファクター3以降のモデリングでは、Commerceはシステム自体の各システムの設定を保存するようになりました。 （開発設定は開発システムに保存され、実稼動設定は実稼動システムに保存されます）。
システムの設定を同期する方法を提供します。
-
共有設定 - システム固有でも機密性もない設定。
共有設定は、開発システムと実稼動システムで一貫性を持たせたい設定です。 開発環境（またはAdobe Commerce on cloud infrastructure integration）システムの管理者で、共有設定を設定します。
共有設定ファイル
app/etc/config.phpは、開発、ビルド、および実稼動システム間で共有できるように、ソース管理に含める必要があります。 -
システム固有の設定 – 検索エンジンのホスト名やポートなど、システムによって異なる設定です。
-
機密設定 – 個人を特定できる情報（PII）またはAPI キーやパスワードなどの設定を公開するため、notに設定をソース管理に含める必要があります。
システム固有の設定ファイル
app/etc/env.phpは、notをソース管理に含めるか、システム間で共有する必要があります。 代わりに、magento config:setおよびmagento:sensitive:setコマンド を使用して、実稼動システムでこれらの設定の値を指定します。
ほとんどの場合、共有、システム固有、または機密性の高い設定で設定した設定オプションは、管理者で編集できません。 これにより、すべてのシステムで設定の一貫性を保つことができます。 （管理者で編集可能な設定を設定するには、--lock オプションを使用せずにmagento config:set コマンド をオプションで使用できます）。
各Commerce設定オプションには、一意の 設定パス があります。 設定オプションの値を設定するには、CLI コマンドまたは環境変数を使用して、特定のシステムでその設定パスの値を設定します。