オンデマンド Sandbox の詳細を知る

学習の目的

この単元を完了すると、次のことができるようになります。

オンデマンド Sandbox と Point of Delivery (POD) ベースの Sandbox の違いを説明する。
オンデマンド Sandbox が開発者や開発チームにもたらす利点を説明する。

現在 Commerce Cloud は Agentforce Commerce に、B2C Commerce は Agentforce Commerce for B2C に名称が変更されています。この移行期間中は、Salesforce アプリケーションやドキュメント内では Commerce Cloud や B2C Commerce という名称が引き続き使用される場合があります。

Commerce for B2C のオンデマンド Sandbox は、Commerce for B2C ソリューションの開発、テスト、リリースに使用できる柔軟で拡張性の高い環境です。オンデマンド Sandbox では、開発やテスト時の環境パフォーマンスが向上し、プロビジョニングが短時間で完了し、利用状況をより細かく制御できます。オンデマンド Sandbox は、継続的インテグレーション (CI) や継続的デリバリー (CD) のプロセスを導入しているチームに適しています。

オンデマンド Sandbox と POD ベースの Sandbox の比較

オンデマンド Sandbox と Point of Delivery (POD) ベースの Sandbox は、どちらも Salesforce エコシステム内で本番環境やほかの環境から切り離して開発、テスト、リリースを行える環境を提供します。オンデマンド Sandbox (ODS) には、従来の POD ベースの Sandbox に比べて、特に柔軟性、拡張性、運用効率の面でいくつかの利点があります。

Sandbox の実装で重要な点を検討すると、通常はオンデマンド Sandbox の方が適しています。

主な考慮事項	オンデマンド Sandbox	POD ベースの Sandbox
柔軟性と拡張性	特定の POD に依存せず、Sandbox を動的に作成して管理します。この柔軟性により、実際の需要に基づいてリソースを割り当て、固定インフラストラクチャへの依存を軽減できます。	特定の物理インフラストラクチャ (POD) に依存するため、柔軟性と拡張性が制限され、固定インフラストラクチャへの依存度が高まります。
リソース使用率	Sandbox を特定の POD から切り離して、Salesforce インフラストラクチャ全体でリソース割り当てを最適化します。これにより、開発やテストの作業中にパフォーマンスが向上し、待ち時間が短縮されます。	特定の POD に起因するリソースの制約を受けるため、パフォーマンスのボトルネックや待ち時間の増加につながる可能性があります。
プロビジョニング	POD ベースの Sandbox より短時間で Sandbox をプロビジョニングできるため、開発ライフサイクルが短縮され、チームは価値の提供に集中できます。	特定の物理インフラストラクチャに依存するため、プロビジョニングに時間がかかり、開発ライフサイクルが遅れる可能性があります。
信頼性	Salesforce のグローバルインフラストラクチャを活用できるため、可用性と信頼性を高め、単一の POD に起因するダウンタイムやパフォーマンスの問題のリスクを軽減できます。	POD 固有の問題が発生すると信頼性に影響し、ダウンタイムやパフォーマンスの問題のリスクが高まります。
コスト効率	POD に関連付けられた固定のリソース割り当てを維持するのではなく、利用状況に基づいてリソースの料金を支払えるため、組織はコストを削減できます。	実際の利用状況に関係なく、特定のインフラストラクチャを維持するための固定費が発生します。
管理	利用状況の監視、アクセス権の管理、組織のポリシーへの準拠確認などの管理タスクを一元化して、管理を簡素化します。	特定の POD インフラストラクチャとの調整が必要になるため、Sandbox の管理が複雑になります。

Commerce for B2C のオンデマンド Sandbox の利点

オンデマンド Sandbox は、動的な開発ニーズがある組織や分散チームに適しており、Commerce for B2C 環境の俊敏性とコスト効率の向上に役立ちます。

ODS には、次のような利点があります。

セルフサービス管理: セルフサービス API や、SFCC-CI など開発者コミュニティ提供のコマンドラインツールを使用して、Sandbox を管理できます。
設定可能な項目: Sandbox の作成時に、Open Commerce API (OCAPI) と Web-based Distributed Authoring and Versioning (WebDAV) の設定をカスタマイズできます。
有効期間オプション: 指定した期間が経過すると Sandbox が自動的に削除されるように設定することで、コストを削減できます。
利用状況ベースの価格設定: Sandbox の稼働時間と停止時間に応じて消費されるクレジットに基づいた価格モデルで、コストを管理できます。
迅速なプロビジョニング: Sandbox をすばやく作成して設定することで、開発サイクルを短縮できます。Commerce for B2C Developer Sandbox REST API と Commerce for B2C Control Center には、柔軟なプロビジョニングと管理のオプションが用意されています。
拡張性: プロジェクトのニーズに応じて、複数の短期 Sandbox を作成したり、少数の長期 Sandbox を維持したりできます。
パフォーマンスの向上: 従来型の Sandbox よりも高いパフォーマンスが得られるように最適化された Sandbox を使用できます。

Commerce for B2C Sandbox のベストプラクティス

このガイドラインでは、オンデマンド Sandbox を効果的に管理するうえで重要なポイントを説明します。これらのベストプラクティスを継続的に実践することで、パフォーマンスを最大限に高め、コストを管理し、開発環境をクリーンで効率的な状態に保ちながら、組織の目標に沿った状態を維持できます。

Sandbox の用途

Sandbox はデータではなく、コードの単体テストに使用します。Sandbox は本番環境ではありません。
Sandbox に負荷をかけすぎないように、サイト数を最小限に抑え、商品データも一部に絞ります。

データ管理

リソースの利用を最小限に抑えるため、商品、顧客、在庫、価格など、必要不可欠なデータのみをアップロードします。
パフォーマンスを維持するため、古いソースコードバージョンを含む古いデータを削除します。

タスクとジョブの管理

パフォーマンスの問題を最小限に抑えるため、複数のタスクやジョブを同時に並行実行しないようにします。
商品が変更されていない場合の定期的な商品インデックスの再構築など、不要なジョブはオフにします。

開発者のアクセス

競合を防ぐため、1 つの Sandbox を 1 人の開発者だけが使用するように制限します。
使用していないときは、UX Studio パイプラインやスクリプトデバッガーなどのツールを切断します。

リージョンに関する考慮事項

待ち時間を短縮し、自動化されたシステムタスクとの競合を避けるため、自分のリージョンに近い場所にある Sandbox を使用します。

セキュリティとメンテナンス

不要なトラフィックを防ぐため、ストアフロントのパスワード保護を有効にします。
プロジェクトが完了したら、DBINIT を実行し、すべての静的ファイルをクリアします。

CI および CD との整合性

これらのベストプラクティスは CI パイプラインや CD パイプラインを直接対象にしているわけではありませんが、クリーンで効率的な Sandbox 環境を維持するための基盤になります。CI プロセスと CD プロセスでは、次のベストプラクティスに従ってください。

Sandbox へのリリースを自動化し、構造化されたパイプラインに従います。
バージョン管理システムを使用してコード変更を管理し、Sandbox 環境に体系的に統合します。
Sandbox を定期的に更新して本番環境のデータや設定と揃え、環境間の一貫性を確保します。

次のステップ

この単元では、Commerce for B2C のオンデマンド Sandbox と POD ベースの Sandbox の相違点について学習し、ODS を使用して開発プロセスを向上させる方法を習得しました。また、CI プロセスと CD プロセスで ODS を使用する方法についても確認しました。次は、ロールと権限、Sandbox クレジットシステム、ODS を作成するための前提条件について学習します。

予想時間

トピック

ヘルプをお探しですか?