Data 360 設定を展開して検証する
学習の目的
この単元を完了すると、次のことができるようになります。
- 変更セット、Salesforce CLI、DevOps ツールなど、さまざまな展開メソッドを比較する。
- 展開前チェックリストを適用して、対象組織の準備状況を確認する。
- データストリームを有効化し、本番環境でのデータ取り込みを確認する。
- データマッピングと ID 解決のプロセスを検証する。
最後の仕上げ
展開はプロセスの半分に過ぎません。有効化と検証によって、設定が本番環境の規模で正しく機能することを確認します。メタデータは家電製品のようなものです。移動させた後に、電源につないでスイッチを入れる必要があります。
この最後の単元では、適切な展開ツールの選び方、DevOps データキットを本番環境に転送する方法、エンドツーエンドのデータパイプラインを検証する方法を学びます。DevOps 開発者の Vijay Lahiri とシステムアーキテクトの Jamal Cooks が、Cloud Kicks ロイヤルティプログラムの最後の仕上げを実行する様子を見ていきましょう。
展開前チェックリストを確認する
大規模なデータキットの展開には、エンタープライズレベルのガバナンスが必要です。Vijay がメタデータを本番環境に移行する前に、Jamal は準備状況チェックを行います。展開の失敗を防ぐため、Jamal は次の展開前チェックリストに従って対象環境の準備を確認します。
-
データスペースの整合性: マッピングの失敗を防ぐため、Sandbox と本番組織でデータスペースが同じように設定されていることを確認します。Sandbox で作成したデータスペースが本番環境に存在しない場合は、展開前に本番環境で手動作成する必要があります。
-
機能の一致: Sandbox で有効になっているすべての Data 360 機能が、本番環境でも有効になっていることを確認します。
-
組織間の展開戦略: 異なる本番組織間でメタデータを移行する必要がある場合は、厳格なパスに従います。本番組織 1 から Sandbox 組織 1 にデータを展開します。次に、Sandbox 組織 1 から本番組織 2 にリンクされている Sandbox に変更を展開し、最後に本番組織 2 に反映させます。
-
展開の公開シーケンス: 連動関係の欠落エラーを防ぐために、データキットページの公開シーケンスを確認します。たとえば、セグメントが計算済みインサイトに連動している場合は、セグメントより前に計算済みインサイトが展開されるように設定されていることを確認します。
-
再展開のルール: 展開済みのコンポーネントを更新して再展開する場合は、必ず新しいデータキットを作成して更新済みコンポーネントを展開します。
-
変更セットの連動関係: 変更セットを使用する場合は、アップロードを試みる前に、必要なコンポーネントの連動関係がすべて手動で追加されていることを確認するために事前チェックを実施します。
適切な展開ツールを選択する
DevOps データキットを大規模に展開するには、複数の展開方法を理解し、エンタープライズレベルのガバナンスを計画する必要があります。移行に万能な方法はありません。複雑さに応じて、Vijay は Cloud Kicks のロイヤルティプログラムの設定を本番環境に移行するために、さまざまなツールを使用する可能性があります。
ツール |
使用事例 |
アーキテクトメモ |
制限事項 |
|---|---|---|---|
変更セット |
シンプルな移行 |
シンプルな管理には適していますが、複数コンポーネントのデータキットには推奨されません。 |
接続された組織間でのみ機能します。バージョン管理がなく、すべてのメタデータ種別を展開することもできません。 |
Salesforce CLI/メタデータ API |
バージョン管理された展開。 Sandbox で DevOps データキットを作成したら、CLI を使用してメタデータマニフェストを取得し、バージョン管理システムにコミットします。 |
Salesforce CLI (Salesforce コマンドラインインターフェース) は、繰り返し可能なメタデータ展開のゴールドスタンダードです。Data 360 の設定をコードとして扱うことで、データキットのマニフェストを Git などのバージョン管理システムに保存できます。 |
CLI の知識と、スクリプトまたは展開パイプラインの手動設定が必要です。 これらの課題により、現時点ではソース管理インテグレーションの完全なメリットを最大限に活用できない場合があります。 |
外部 DevOps ツール |
エンタープライズ CI/CD パイプライン |
Copado、Gearset、GitLab などのツールは、CLI 上にビジュアルな抽象化レイヤーを提供します。バージョン管理インテグレーション、自動テスト、順次昇格など、パイプライン全体を管理します。 |
ライセンスコストと学習曲線が発生します。インテグレーションの設定が必要になる場合もあります。 |
具体的な展開コマンドを使用する前に、これらのツールがより広いパイプラインの中でどのように機能するかを理解しておくと役立ちます。以下は、典型的な DevOps 展開パイプラインのビジュアル例です。変更が個々の Developer Sandbox から、インテグレーションとユーザー受け入れテスト (UAT) を経て、最終的に本番環境に到達するまでの流れに注目してください。
変更セットを使用して展開する
シンプルな移行には、標準の Salesforce 変更セットを使用できます。Vijay は前の単元ですでに DevOps データキットを作成しているため、それを変更セットにパッケージ化して本番環境に移行できます。次の手順を実行します。
-
接続を認証する: 本番 (対象) 組織で展開接続を作成し、Sandbox からの受信変更セットを使用できるようにします。
-
送信変更セットを作成する: Sandbox 組織で [Setup (設定)] に移動し、送信変更セットを作成します。
-
データキットを追加する: [Component Type (コンポーネントの種別)] 項目で [Data Package Kit Definition (データパッケージキット定義)] を選択し、DevOps データキットを追加します。
-
連動関係を追加する: [View/Add Dependent Components (連動コンポーネントを参照/追加)] をクリックして、必要な DMO リレーションを含めます。すべてのページをスクロールして、漏れなく取得します。
キー修飾子ファイルはすべて削除し、統合個人などの派生オブジェクトのリレーションは追加しないでください。これらは自動的に処理されます。
-
アップロードして展開する: 送信変更セットをアップロードします。次に、本番組織にログインし、[Inbound Change Sets (受信変更セット)] に移動して、[Deploy (リリース)] をクリックすると、変更セットとその機能が自動的に展開されます。
Salesforce CLI を使用して展開する
ミッションクリティカルなロイヤルティプログラムとその多くの構成要素を管理するために、Vijay は Salesforce CLI を選択し、Cloud Kicks のバージョン管理システムと統合します。Salesforce CLI を使用して展開するには、次の手順に従います。
- Sandbox 組織で [Data Cloud Setup (Data Cloud 設定)] に移動し、[Data Kits (データキット)] をクリックします。
- DevOps データキットを選択し、[Download Manifest (マニフェストをダウンロード)] をクリックします。ダウンロードした package.xml ファイルには、DevOps データキットに関連するすべてのメタデータエンティティが含まれています。このファイルを Salesforce DX プロジェクトで使用して、データキットのメタデータを取得します。
- DevOps データキットのメタデータを Sandbox 組織に取得するには、次のコマンドを実行します:
sf project retrieve start --manifest manifest/package.xml。
- このコマンドが完了すると、データキットのメタデータを含む新しいプロジェクトフォルダーが表示されます。バージョン管理とコラボレーションを円滑に進めるために、プロジェクト全体を GitHub またはその他のソース管理システムにアップロードすることを検討します。
重要:
このステップはスキップしないでください。 展開に進む前に、プロジェクトに関連するキー修飾子ファイルをすべて削除してください。
- 本番組織への展開を開始するには、次のコマンドを実行します:
sf project deploy start --manifest manifest/package.xml。
CLI とソース管理の制限事項を理解する
Vijay が Cloud Kicks の展開を拡大するにあたり、以下の既知の CLI の制限事項を慎重に管理する必要があります。
-
新しいファイルの生成: 同じ基盤となるコンポーネント (同じデータストリーム、計算済みインサイト、セグメントなど) が複数のデータキットに追加され、複数回取得された場合でも、命名の不一致により毎回まったく新しい XML ファイルが生成されます。
-
変更のトラッキング不可: 毎回新しいファイルが作成されるため、開発者は 1 つのコンポーネントへの変更を時系列で追跡することが困難です。既存ファイルに対してクリーンな
diffが表示される代わりに、新しいファイルが作成されるため、git diff、git blame、git mergeなどの標準コマンドが機能しなくなります。
-
マージの競合と冗長性: 複数の開発者が同じコンポーネントで作業する場合、または開発者が複数のデータキットを作成する場合、一貫性のない名前のファイルが増えることで、深刻なマージの問題が発生し、リポジトリが煩雑になります。
-
テンプレート名の競合: 同じ計算済みインサイトが複数のデータキットに追加された場合、生成されるテンプレート名が競合する可能性があります (CI、CI1、CI2 などと表示されます)。これにより、特定と管理がさらに複雑になります。
-
マージの失敗: 複数の開発者がそれぞれの Sandbox で同じ名前のデータキットを作成し、変更をマージした場合、公開シーケンスはマージされません。さらに、データキット内のコンポーネントは、同じコンポーネントに対する複数のテンプレートへの参照が競合するため、正常にマージされません。
展開エラーのトラブルシューティング
アーキテクトの仕事に終わりはありません。監視とトラブルシューティングは、スムーズな展開のための重要なスキルです。以下は、Cloud Kicks チームで発生する可能性のあるサイレントエラーと、その解決方法です。
エラー |
根本原因 |
修正 |
|---|---|---|
互換性のないマッピング |
DMO の項目のデータ型が組織間で異なっています。 |
ソース組織の項目のデータ型を揃えて、データキットを再バンドルします。 |
データスペースが見つからない |
データキットが参照しているデータスペースが作成されていません。 |
対象組織にデータスペースを手動で作成し、再展開します。 |
結果が Null である |
ID 解決がまだ実行されていません。 |
[Identity Resolution (ID 解決)] タブで手動でトリガーします。 |
展開後チェックリストを完了する
メタデータが本番環境に届きました。ただし、Vijay の仕事はまだ終わっていません。データが正しく流れ始めるよう、厳格な展開後のワークフローに従う必要があります。
-
展開履歴を表示する: データを確認する前に、展開が正常に処理されたことを確認します。[Data Cloud Setup (Data Cloud 設定)] に移動し、[Data Kits (データキット)] を選択して、展開済みのキットを開きます。[Deployment History (リリース履歴)] タブで、すべてのコンポーネントが順番どおりに正常に公開されていることを確認します。
-
データストリームの展開動作を管理する: 展開されたデータストリームは「ドラフト」状態で届くため、実際のデータを処理するには有効化する必要があります。ただし、有効化の手順はソースシステムによって異なります。
-
CRM データストリーム: 展開時に CRM コネクタは展開されますが、接続がすぐに有効でない場合、関連するデータストリームのインストールが失敗することがあります。CRM データストリームが失敗した場合は、まず対象組織でコネクタを手動で有効化し、その後データキットを再度展開する必要があります。この 2 回目の展開を行って初めて、関連するデータストリームが正常に展開されます。
-
非 CRM データストリーム: 外部ソース (Amazon S3 など) の場合、コネクタとデータストリームはどちらも正常に展開されますが、無効の状態で届きます。非 CRM データストリームが失敗した場合は、コネクタに移動して [activate (有効化)] をクリックするだけで対応できます。再展開は不要です。
-
取り込み開始: コネクタが有効になったら、[Data Streams (データストリーム)] タブに移動し、展開済みのストリームを選択して、[Start Ingestion (取り込みを開始)] をクリックします。
ID 解決の監査を実行する
展開後、新たに取り込まれたデータストリームが環境に流れ込みます。ただし、システムはこの新しいメタデータに対して ID 解決プロセスを自動的に実行しません。統合プロファイルは運用データとして扱われるため、新しい環境でゼロから構築する必要があります。
Jamal の ID 解決監査は、重要なチェックポイントです。
-
[Data Cloud Setup (Data Cloud 設定)] の [Identity Resolution (ID 解決)] タブに移動します。
-
[Run Ruleset (ルールセットを実行)] をクリックして、新しく展開された一致ルールと調整ルールを適用します。
- [Metrics (メトリクス)] セクションを監視します。処理された入力レコードの数と、結果として生成された統合プロファイルが、想定される許容範囲内であることを確認します。
パイプラインを検証する
最後のステップは、エンドツーエンドの検証を実施することです。Jamal は、ロイヤルティプログラムの検証チェックとして使用するために、既知の属性を持つ少数のテストプロファイルを使用します。
-
[Data Profile (データプロファイル)] タブに移動し、テスト顧客の「Cody the Bear」など、既知のプロファイルを検索します。
-
データマッピングを確認する: メールアドレスやロイヤルティ ID などのコア項目が、ソースデータストリームから正確に入力されていることを確認します。
-
ID 解決を確認する: 「Cody the Bear」が正しく統合され、すべての関連データレコードが 1 つのプロファイルの下に表示されていることを確認します。
-
計算済みインサイトを確認する: プロファイルの [Calculated Insights (計算済みインサイト)] セクションを確認します。高度にパーソナライズされたロイヤルティプログラムのために、Jamal は [Cody the Bear] にテストデータに基づいて [Gold Tier (ゴールドランク)] のロイヤルティ状況が正しく表示されていることを確認します。
検証プロファイルがこれらのチェックに合格すれば、展開は成功です。
まとめ
新しい設定の展開と検証が成功したことで、Cloud Kicks はリアルタイムのスタイルおすすめ機能を正式にリリースできるようになりました。DevOps データキット、Sandbox の同期、マルチツール展開を活用することで、Jamal と Vijay は本番環境のダウンタイムを回避し、すべての顧客が適切なタイミングで最適なおすすめを受け取れるようにしました。あなたも Data 360 の Sandbox で同じことを実現できます。
リソース
- Salesforce 開発者ガイド: Use CLI to Deploy Changes from Sandbox to Data 360 (CLI を使用して Sandbox から Data 360 に変更を展開する)
- Salesforce ブログ: Master Data Cloud Metadata and Process Definition Deployments with SFDX CLI and Metadata API (SFDX CLI と Metadata API を使用した Data Cloud メタデータとプロセス定義の展開をマスターする)
- Salesforce ヘルプ: 組織全体での Data 360 の変更のリリース