スタータープロジェクトワークフロー

Adobe Commerce on cloud インフラストラクチャには、を持つ 1 つの Git リポジトリーが含まれます。 master 実稼動環境のブランチ。テストおよび開発作業用にステージング環境と複数の統合環境を作成するために分岐できます。 次の環境を含む最大 4 つのアクティブな環境を持つことができます master 実稼動サーバーの環境。 参照： スターターアーキテクチャ を参照してください。

お使いの環境で、次の手順を実行します Development > Staging > Production サイトを開発およびデプロイするためのワークフローです。

ブランチの場合は、任意の開発手法に従うことができます。 例えば、スクラムなどのアジャイル手法に従って、スプリントごとに分岐を作成できます。

各スプリントから、各ユーザーストーリーの分岐を作成できます。 すべてのストーリーがテスト可能になります。 スプリントの分岐に継続的に結合し、その分岐を継続的に検証できます。 スプリントが終了したら、スプリントのブランチをに結合できます master テストのボトルネックに対処することなく、すべてのスプリント変更を実稼動環境にデプロイする。

開発ワークフロー

スタータープランでの開発とデプロイメントは、最初のプロジェクトから始めます。 「空白のサイト」（クラウドインフラストラクチャテンプレート上のAdobe Commerceのコードリポジトリ）を使用してプロジェクトを作成し、完全に準備されたストアを含めます。 これにより、が作成されます master 実稼動環境のコードのコピーを使用して分岐します。

開発ワークフローには以下が含まれます。

また、コードとストアデータの開発とテストに役立つオプションの手順もあります。

このプロセスは、 ローカル開発者ワークスペース.

クローンとブランチ

新規スタータープランプロジェクトの場合、 master ブランチはAdobe Commerce on cloud infrastructure Git リポジトリから複製されました。 コードのブランチと操作を開始するには、 master ローカル環境に分岐します。

Git clone コマンドの形式は次のとおりです。

git fetch origin

git pull origin <environment-ID>

スタータープロジェクトのブランチで初めて作業を開始するときは、を作成します staging 分岐。 これにより、に一致するコードブランチが作成されます master ステージング環境にデプロイするブランチで、実稼動環境にデプロイする前に設定とコードの変更をテストします。

次に、からブランチを作成します。 staging コードを開発し、拡張機能を追加して、サードパーティ統合を設定します。 カスタムコードを開発したり、拡張機能を追加したり、サードパーティのサービスと統合したりするたびに、から作成された開発ブランチで作業します。 staging 分岐。 4 つのアクティブな統合環境を使用できます。 アクティブなブランチをプッシュすると、これらの統合環境の 1 つがテストするコードを自動的にデプロイします。

Git ブランチ コマンドの形式は次のとおりです。

git checkout <branch-name>

Cloud CLI の形式 branch コマンド：

magento-cloud environment:branch <environment-name> <parent-environment-ID>

コードの開発

クラウドインフラストラクチャコード上のAdobe Commerceのベースブランチを使用すると、拡張機能のインストール、カスタムコードの開発、テーマの追加などを開始できます。

開発作業でブランチ戦略を使用します。 1 つのブランチですべての作業を一度に行うと、テストが難しくなる場合があります。 例えば、継続的統合とスプリントの方法論に従って作業できます。

ストアを完全に構築、設定し、ローンチする準備ができるまで。 ただし、ストアとコードの設定には多くのオプションがあります。

ストアの設定

ストアを設定する準備が整ったら、すべてのコードをにプッシュします。 integration 環境。 ローカル環境ではなく、統合環境用に管理者からストアの設定を指定します。 URL を見つけるには、 サイトへのアクセス が含まれる Cloud Console

設定に関する最適な情報については、Adobe Commerceのドキュメントとインストールされている拡張機能を参照してください。 開始に役立つリンクとアイデアを次に示します。

ストアの設定だけでなく、複数のサイトやストア、設定されたサービスなどをさらに設定できます。 参照： ストアの設定.

構成管理ファイルの生成

Adobe Commerceに精通しているユーザーは、開発環境のデータベースからステージング環境および実稼動環境に設定を取得する方法を気にする必要があります。 以前は、すべての設定を紙またはファイルにコピーしてから、手動でその設定を他の環境に適用する必要がありました。 または、データベースをダンプし、そのデータを別の環境にプッシュした可能性があります。

クラウドインフラストラクチャー上のAdobe Commerceには、次の 2 つの機能があります 設定の管理 環境設定を環境からファイルに書き出すコマンド。 これらのコマンドは、次の場合にのみ使用できます クラウドインフラストラクチャー 2.2 以降でのAdobe Commerce.

生成されるファイルは以下のとおりです。 app/etc/config.php.

Adobe Commerceを設定した統合環境にファイルを生成します。 ファイルを生成し、ブランチに追加してデプロイするプロセスを順を追って説明します。

重要な注意事項 設定管理で、次の操作を行います。

Adobe Commerce バージョン 2.2 以降を使用している場合、Configuration Management コマンドには、PayPal モジュールのサンドボックス資格情報などの機密データを保護する追加機能が用意されています。 書き出しプロセス中に、機密データを含むすべての値が、別の設定ファイルに書き出されます。env.php が含まれる app/etc/ ディレクトリ。 このファイルはローカル環境に残り、コードを別のブランチにプッシュしてもコピーされません。 また、クラウドインフラストラクチャバージョン上のすべてのAdobe Commerceで、CLI コマンドを使用して環境変数を作成することもできます。

参照： 設定の管理.

コードとテストのプッシュ

この時点で、設定ファイル（config.local.php または config.php）をテストする準備が整いました。

ローカル環境からコードをプッシュするたびに、一連のビルドスクリプトとデプロイスクリプトが実行されます。 これらのスクリプトは、新しいコードを生成して、リモート環境にデプロイします。 例えば、開発ブランチをローカル環境からリモートブランチにプッシュする場合、一致する環境でサービス、コードおよび静的コンテンツが更新されます。

ストア URL、管理者 URL、SSH を使用して、この環境に直接アクセスできます。 これらの環境には、web サーバー、データベース、設定済みサービスが含まれます。 準備が整ったら、ステージング環境でデプロイとテストを開始できます。

詳しくは、を参照してください デプロイメントワークフロー.

オプション：サンプル・データのインストール

ストアの開発時にサンプルデータが必要な場合は、サンプルデータをインストールできます。 このデータは、顧客、製品、その他のデータを含む、アクティブなストアをシミュレートします。 このサンプルデータは、プロジェクトの作成時にクラウドインフラストラクチャテンプレートの「空白のサイト」Adobe Commerceで最適に機能します。 ベストプラクティスとして、運用を開始する前にサンプルデータを削除してください。 参照： オプションのサンプルデータをインストールする.

オプション：実稼動データの取り込み

すべての製品、カタログ、サイトコンテンツなどを production 環境。 このデータを実稼動環境に追加すると、更新された価格、クーポン、在庫在庫、販売のお知らせ、今後のオファーに関する情報などを顧客に提供できます。 このデータには、ローカル開発ブランチで設定した拡張機能の設定は含まれていません。

機能を開発したり、拡張機能を追加したり、テーマをデザインしたりする際に、実際のデータを操作できると便利です。 いつでも、次のことができます データベースダンプの作成 実稼動環境から、必要に応じてステージング環境および統合環境にプッシュします。

実稼働データをテストデータとしてエクスポートし、ステージング環境と統合環境で使用できるようにするには、次の手順に従います。

このデータを移行するには、を参照してください。 静的ファイルおよびデータの移行とデプロイ.

デプロイメントワークフロー

アーキテクチャ情報で詳しく説明しているように、クラウドインフラストラクチャー上のAdobe Commerceは Git 主導です。 クラウドインフラストラクチャへのAdobe Commerceのデプロイは、ブランチの Git プッシュプロセスの一部です。

分岐したコードをローカル環境からリモートブランチにプッシュすると、一連のビルドスクリプトとデプロイスクリプトが開始されます。

ビルドスクリプト：

スクリプトをデプロイします。

完了すると、更新されたすべてのコードと設定を使用して、ストアがオンラインでライブ状態に戻ります。

参照： デプロイメントプロセス.

ステージングおよびテストへのプッシュ

コードは常に以下に繰り返しプッシュします staging 完全なテストの環境。 この環境を初めて使用する場合、次のようないくつかのサービスを設定する必要があります Fastly および New Relic. また、サンドボックスまたはテスト資格情報を使用して、支払いゲートウェイ、配送、通知、その他の重要なサービスを設定します。

ステージングは実稼動前の環境であり、可能な限り実稼動環境に近いすべてのサービスと設定を提供します。 ストアが実稼動の準備ができていると感じられるまで、すべてのサービスを徹底的にテストし、パフォーマンステストツールを検証し、管理者および顧客として UAT テストを実行します。

参照： ストアのデプロイ.

実稼動へのプッシュ

にプッシュした場合 master 分岐、次にプッシュしています： production 環境。 ステージング環境と同様に、実稼動環境での設定およびテストアクティビティを、1 つの重要な違いを除いて完了します。 実稼動環境では、設定とテストにライブ資格情報を使用します。 サイトが立ち上げられた瞬間に、顧客は購入を完了でき、管理者はライブストアを管理できます。

参照： ストアのデプロイ.

サイトの起動

サイトの運用を開始するための明確な手順があります。 これらの手順を完了すると、カスタマイズしたテーマの製品をすぐに販売することができます。

参照： サイトの起動.

継続的統合

ブランチと開発の方法論に従って、新機能を簡単に開発し、変更を設定し、拡張機能を追加して、更新を継続的に開発およびデプロイできます。

すべてのクラウドインフラストラクチャ環境で、継続的な統合をサポートして、継続的なアップデートを実現します。 このワークフローでは、ビジネスニーズに応じて、1 日に複数回、または設定したスケジュールでリリースをサポートします。