パブリッシングのベストプラクティス

Tealium iQは、堅牢な開発努力と承認プロセスをサポートしています：

• 複数の同時プロジェクト
  開発者はプロファイルの別々のバージョンで作業し、その後、一つのバージョンから別のバージョンに変更をマージすることができます。一人の開発者がプロジェクトを終了したら、そのバージョンを本番環境に公開します。他の開発者は、まだ開発中のバージョンに更新をマージすることができます。複数の開発者が同じプロファイルで作業している場合、プラットフォームは公開された変更を開発者に通知します。開発者は新しいバージョンをロードするか、新しいバージョンを現在の作業にマージして作業を続けることができます。

  詳細については、Concurrent Usersを参照してください。

• ブランチング、マージ、反復
  開発者は以下の方法で変更を保存することができます：

  • Save Asは、現在のバージョンから新しいバージョンをブランチします。
  • Mergingは、一つのバージョンから別のバージョンに変更を引き出します。
  • Save/Overwriteは、変更を保存するときに現在のバージョンを置き換えます。

  詳細については、About Savingとバージョンのマージを参照してください。

• マージの競合解決
  複数の開発者がプロファイルの同じオブジェクトを変更した場合、パブリッシャーは公開前に優先するバージョンを選択することができ、これにより誤ったバージョンの公開を避けることができます。

  詳細については、Resolving merge conflictsを参照してください。

• 開発とテスト環境

  デフォルトでは、Tealium iQは開発、QAテスト、本番環境を提供しています。開発者とテスターは環境を切り替えてサイトのパフォーマンス、ユーザーエクスペリエンス、データ収集をテストすることができます。進行中の複数の開発プロジェクトをサポートするために、必要に応じてカスタム環境を作成することができます。

  詳細については、Publish environmentsを参照してください。

• テストツール
  Tealiumは、開発者とテスターがタグとイベントが期待通りに発火すること、データレイヤーオブジェクトが必要なデータを含んでいること、データが正しく処理されていることを確認するためのテストツールのセットを提供しています。問題がある場合、これらのツールは問題を診断し、バージョンが本番環境に移行する前に解決するのに役立ちます。

  詳細については、Tealium Toolsを参照してください。

• 承認構造
  アカウント管理者は、アカウント上で権限レベルとワークフローを構成することができます。これにより、開発者、QAテスター、プロダクトマネージャーは、彼らの役割を果たすために必要なアクセスと権限を得ることができますが、彼らが行うべきでないタスクを行うことは防ぎます。例えば、開発者はQAテストとプロジェクトマネージャーの承認なしに直接本番環境に公開することは許されるべきではありません。

  詳細については、Publishing Workflowを参照してください。

• バージョン追跡マップ
  バージョン追跡マップは、開発、QAテスト、本番環境のすべてのバージョンを表示します。ユーザーは、バージョンが互いにどのようにブランチするか、diffツールでバージョンを比較し、一つのバージョンから別のバージョンに変更をマージすることができます。

  詳細については、Version Historyを参照してください。

公開手順

以下のステップは、Tealium IQプロファイルへの更新を管理するための簡略化されたワークフローをまとめたものです：

1. アカウント上で公開環境、権限、ワークフローを構成します。
2. Prodバージョンをロードします。
3. 新しいバージョンをSave Asし、それをDevに公開します。
4. 変更を加え、バージョンを保存し、そのバージョンをDevに公開します。
   • 必要に応じて前のバージョンに戻ることができる新しいバージョンを作成するためにSave Asを使用します。
   • 新しいバージョンに変更をSave/Overwriteし、それをテストするためにDevに公開します。
   • 他の開発者がProdバージョンを更新した場合、それらの変更を新しいバージョンにマージします。
5. テストする準備ができたら、新しいバージョンをQAに公開します。
6. QAテストを実行します。
7. バージョンがテストに合格したら、Prodへの公開をリクエストします。
8. プロジェクトマネージャーがProdへの公開を承認します。

例

アカウントの構成

開発が始まる前に、アカウント管理者はアカウントの公開ワークフローと構成を構成します。

1. Workflow Managementを有効にし、構成して、誰がProd環境に変更を提出でき、誰がそれらの変更を公開するために承認できるかを制御します。
2. Publish Notify Emailを有効にすると、ユーザーや開発者はTealium iQにログインしていないときに新しいバージョンが公開されたことを知ることができます。
3. 複数のプロジェクトが同時に開発され、テストされる場合は、開発者がWeb CompanionとEnvironment Switcherツールを通じてウェブサイトに追加の環境と構成をロードできるようにCustom Publish Environmentsを構成します。

詳細については、以下を参照してください：

• Publish Configuration
• Publish Workflow Management
• Custom Publish Environments

Prodに基づいた新しいバージョンの作成

開発者#1は新しいタスクを受け取ります：プロファイルに新しいタグを構成します。開発者が最初に行うことは、変更を加えるためのワークスペースとしてバージョンを作成することです。これにより、彼らは最新の本番環境からの更新を持つクリーンな開発環境を確保し、彼らの作業が本番環境にクリーンにマージできることを確保します。

デフォルトでは、Tealium iQはプロファイルの最新バージョンをロードするため、開発者は現在Prodとして公開されているバージョンに切り替える必要があります：

1. 開発者はプロファイルのProdバージョンをロードします。
2. 開発者は新しいバージョンをSave Asし、新しいバージョンに意味のあるTitleとNoteフィールドの説明を付けます：New Tag For 2023 1Q
   • 開発者が新しいバージョンを上書きするたびに、それをDev環境に公開します。

詳細については、以下を参照してください：

• About Saving
• About Publishing.

開発チームが複数の開発環境を必要とする場合、アカウント管理者はDEV A、DEV Bなどの名前のカスタム環境を作成することができます。詳細については、Custom Publish Environmentsを参照してください。

したがって、もし別の開発者がプロファイルのロードルールをクリーンアップする作業をしている場合（それをバージョンLoad Rule Cleanup For 2023 1Qと呼びましょう）、その開発者は最初の開発者との競合を避けるためにカスタムDev環境を要求することができます。

変更の開発

開発者は新しいバージョンで変更を行い、各変更でそのバージョンを上書きします：

1. 開発者はプロファイルに変更を加えます。
2. 開発者はSaveを使用し、Overwrite existing versionオプションを選択してバージョンに変更を保存します。バージョンの名前は依然としてNew Tag For 2023 1Qです。
   • 開発者がロールバックできる変更を加えたい場合、新しいバージョンをSave Asすることができます（例えば、New Tag For 2023 1Q - B）

いくつかの役立つ開発のヒント：

• オブジェクトに意味のある説明的な名前とノートを付けることで、バージョンで何が変更されたかを特定し、それらの変更を追跡することができます。
• タグ、変数、イベント、拡張機能にラベルを追加して、公開環境、地理的位置、キャンペーンごとにグループ化します。これにより、変更を整理し、QAテスト中にチェックする必要があるオブジェクトを特定するのに役立ちます。
• 変更を頻繁に保存します。

詳細については、以下を参照してください：

• About labels
• About saving.

開発者のテスト

新しいバージョンの変更を作業している間、開発者は新しいバージョンをDev環境でテストしたり、テスト用のカスタム環境を作成したりできます。テストにより、新しいバージョンが期待通りに動作し、サイトのパフォーマンスに影響を与えないことが確認されます。

Tealiumは、この作業を支援するための多くのツールを提供しています。それらには以下のものが含まれます：

• Tealium Tools - Web Companion: このブラウザアプリを使用して、ウェブページにロードされるタグを検査し、検証します。問題を診断するための複数のツールが含まれています。
• Universal Tag Debugger: このツールを使用して、UDOとイベントトラッキングデータを検証します。
• Version diff tool: このツールを使用して、開発中のバージョンと別のバージョンを比較し、変更が分散ユニバーサルタグファイルにどのように影響を与えるかを確認します。
• Tealium Tools - Environment Switcher: このツールを使用して、Dev環境に切り替えてサイトのパフォーマンスを確認します。
  • Environment Switcherでは、開発者がウェブサイトでカスタム環境を使用することも可能です。

また、ブラウザの開発コンソールを使用して、ページ要素、ネットワーク呼び出し、その他を検査することもできます。

詳細については、トラブルシューティングを参照してください。

開発バージョンにProdの更新をマージする

開発者が新しいバージョンの作業をしている間に、別の開発者が現在Prodに公開されているバージョンを変更することがあります：

• 並行して行われる開発作業（他の開発者がLoad Rule Cleanup For 2023 1Qを最初の開発者がNew Tag For 2023 1Qを終える前に完成させる）。
• Prodバージョンへの迅速なバグ修正（他の開発者が最初の開発者の過去のミスを修正している）。

開発者は、Prodバージョンに対して行われた変更を開発中のすべてのバージョンにマージする必要があります。これにより、開発者はメインプロファイルの最新バージョンを使用して作業を行い、開発プロセスの早い段階で潜在的な競合や非互換性を特定することができます。

この例では、もし他の開発者のプロジェクトが最初の開発者のものより先に終了した場合、最初の開発者はNew Tag For 2023 1Qバージョンに他の開発者のProdへの変更をマージする必要があります。

以下の図は、2人の開発者が別々のバージョンで作業を行う開発プロセスを示しています：

開発中のバージョンにProdバージョンの変更をマージするには：

1. プロファイルスイッチャーで、Devバージョンを選択し、Load Versionをクリックします。
2. Client-Side Versionsに移動します。
3. Merge changes into current sessionドロップダウンリストから、Prodバージョンを選択し、Mergeをクリックします。
4. すべての変更が開発バージョンに追加される必要があることを確認します。
5. 新しいバージョンをDevに公開します。

複数の開発者が同じバージョンで作業を行っている場合、プラットフォームは公開された変更を通知し、新しいバージョンをすばやくロードしたり、新しいバージョンの変更を現在の作業にマージしたりすることができます。また、グループがプラットフォーム上で互いにコミュニケーションを取ることを可能にするコミュニケーションツールもあります。

詳細については、以下を参照してください：

• バージョンのマージ: 古いバージョンからの変更を現在公開されているバージョンに取り込む方法。
• バージョン差分ツール: ファイルに公開されたバージョンを比較し、配布ファイルを検査します。これにより、バージョン間で追加、削除、または変更されていない構成を特定することができます。
• 並行ユーザー間での変更のマージ: 同じプロファイルバージョンの並行ユーザーからの変更を取り込む方法。
• 並行ユーザー: 並行ユーザーのコミュニケーションツールと、いくつかの例示されたコラボレーションワークフローシナリオ。

QAテスト

開発者がテストを終えた後、バージョンをQAに公開し、テストスタッフに通知します。専門のテスト部門がない場合、他の開発者がバージョンをピアレビューして、コーディングスタンダードに従っていること、サイトのパフォーマンスに影響を与えないこと、期待通りに機能することを確認します。

1. 開発者はNew Tag For 2023 1QバージョンをQAに公開します。
   • バージョンがテストに失敗した場合、テスターはそれを開発者に返して修正を依頼します。
   • バージョンがテストに合格した場合、テスターはそれを新しいバージョン（New Tag For 2023 1Q - Passed Tests）として保存し、Prodへの公開をリクエストします。プラットフォームは、バージョンが承認待ちであることを適切なユーザーに通知します。

テストについての詳細は、トラブルシューティングを参照してください。

テストスタッフには、すべての開発バージョンを一つのバージョンに統合してテストすることを推奨します。これにより、テストスタッフは一つのステージング環境で保留中のすべての変更をテストすることができ、開発者の作業間の競合をProdへの公開を申請する前に明らかにすることができます。

以下の図は、2人の開発者が別々のバージョンで作業を行い、統合されたテスト環境がある開発プロセスを示しています：

Prod公開の承認

バージョンがProdへの公開待ちになったとき、プロダクトマネージャーに公開リクエストの通知が行われます。プロダクトマネージャーは、広告キャンペーンやプロモーションと一致するようにバージョンを公開することができます。公開が承認されると、バージョンはProdに公開されます。

承認ワークフローの構成方法についての詳細は、公開ワークフロー管理を参照してください。

Prodへの新しい変更を残りの開発バージョンに更新する方法についての詳細は、並行ユーザー間での変更のマージを参照してください。