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

Tealium iQは、堅牢な開発プロセスと承認プロセスをサポートするツールを提供しています：

• 複数の同時プロジェクト

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

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

• ブランチ、マージ、イテレーション

  開発者は次の方法を使用して変更を保存することができます：

  • Save Asは、現在のバージョンから新しいバージョンを作成します。
  • マージは、1つのバージョンから別のバージョンに変更を取り込みます。
  • Save/Overwriteは、変更を保存するときに現在のバージョンを置き換えます。

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

• マージコンフリクトの解決

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

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

• 開発およびテスト環境

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

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

• テストツール

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

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

• 承認構造

  アカウント管理者は、アカウントに対して権限レベルとワークフローを構成することができます。これにより、開発者、QAテスター、およびプロダクトマネージャーが役割を遂行するために必要なアクセスと権限を付与し、ユーザーが行うべきでないタスクを防止します。たとえば、開発者はQAテストとプロジェクトマネージャーの承認なしに直接本番環境に公開することはできません。

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

• バージョン追跡マップ

  バージョン追跡マップには、開発、QAテスト、および本番環境のすべてのバージョンが表示されます。ユーザーはバージョンがどのように分岐しているかをすばやく確認し、バージョンをdiffツールで比較し、1つのバージョンから別のバージョンに変更をマージすることができます。

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

公開手順

以下は、Tealium IQプロファイルの更新を管理するための簡略化されたワークフローの手順の要約です：

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

例

アカウントの構成

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

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

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

• 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を参照してください。

したがって、もう1人の開発者がプロファイルのロードルールを整理している場合（バージョンLoad Rule Cleanup For 2023 1Qとします）、その開発者は競合を避けるためにカスタムのDev環境を要求することができます。

変更の開発

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

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

開発のヒント：

• オブジェクトに意味のある記述的な名前とノートを付けることで、バージョンごとの変更を識別し、変更を追跡します。
• タグ、変数、イベント、および拡張機能にラベルを付けて、パブリッシュ環境、地理的位置、またはキャンペーンごとにグループ化します。これにより、変更を整理し、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バージョンを変更することがあります：

• 同時開発の取り組み（もう1人の開発者が最初の開発者の過去のミスを修正する前にLoad Rule Cleanup For 2023 1Qが終了する）。
• Prodバージョンへのクイックなバグ修正（もう1人の開発者が最初の開発者の過去のミスを修正する）。

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

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

以下の図は、2人の開発者が別々のバージョンで作業し、2つのQAブランチがある開発プロセスを表しています：

Prodバージョンの変更を開発中のバージョンにマージするには、次の手順を実行します：

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

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

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

• Merging Versions：古いバージョンから現在の公開バージョンに変更を取り込む方法。
• Version diff tool：ファイルに公開されたバージョンを比較し、配布ファイルを検査するツール。これにより、バージョン間で追加、削除、または変更されなかった構成を特定できます。
• Merging changes between concurrent users：同じプロファイルバージョンの同時ユーザーからの変更を取り込む方法。
• Concurrent Users：同時ユーザーのコミュニケーションツールといくつかの例のコラボレーションワークフローシナリオ。

QAテスト

開発者がテストを終えたら、新しいバージョンをQAに公開し、テストスタッフに通知します。専用のテスト部門がない場合、他の開発者がバージョンをピアレビューして、コーディング規約に従っているか、サイトのパフォーマンスに影響を与えずに正常に機能するかを確認します。

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

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

テストスタッフは、すべての開発バージョンをテスト用の単一のバージョンにまとめることをお勧めします。これにより、テストスタッフは開発者の取り組みの競合を明らかにし、それらをProdに公開する前に提出する前に競合を特定することができます。

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

Prodへの公開の承認

バージョンがProdに公開するためにキューに入れられると、プロダクトマネージャーに公開リクエストの通知が届きます。プロダクトマネージャーは、広告キャンペーンやプロモーションと同時にバージョンを公開することができます。公開が承認されると、バージョンはProdに公開されます。

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

Prodの新しい変更を残りの開発バージョンに更新する方法の詳細については、Merging changes between concurrent usersを参照してください。