Backtrace には、さまざまなサーバー、アプリケーション、ゲームで発生したエラー（クラッシュや例外）をトリアージし、優先順位を付け、参照するためのツールが揃っています。多くの組織は、Jira、GitHub の Issues、Phabricator、FogBugz などの対応する問題追跡システムを持っており、それらを使用してエンジニアリングチームの作業内容を追跡して管理しています。Backtrace には、そのようなサードパーティの問題追跡システムに問題を作成してリンクするための手法が揃っており、それらのシステムの既存のワークフローを使用してクラッシュや例外の解決策を管理し、Backtrace と対象の問題解決システム間でデータを同期するタイミングを管理できます。

Backtrace では、主に 2 つの方法でサードパーティの問題追跡システムと統合できます。

自動での問題作成 - Backtrace を使用すると、管理者ユーザーは、エラーが初めて発生したときはいつでも、または特定のプロジェクトでエラーが発生するたびに、対象のシステム（Jira など）に問題を自動で作成するルールを指定できます。これは、Backtrace が受け取るすべてのクラッシュまたは例外に Jira の問題を対応させる必要がある組織によって使用されます（以下の図 1 を参照）。
手動での問題作成 - Backtrace の「トリアージ」ビューで使用できるアクションの 1 つに、1 つの共通のフィンガープリントによって特定されたエラーのグループに対して、Jira、GitHub の Issues、その他リンクされたあらゆる問題追跡システムに問題を作成するアクションがあります。これは、Backtrace に入ってくるエラーを分類して優先順位を付け、重大度や影響度などに応じて問題を関連付ける必要がある組織によって使用されます。つまり、チームが進捗を追跡する必要があるクラッシュに対してのみ問題を作成することができます（以下の図 2 と 3 を参照）。

図 1（以下） - 「プロジェクト設定」ビューで、管理者ユーザーはインテグレーションに対して問題を自動的に作成するタイミングを指定できます。

図 2（以下） - 「トリアージ」ビューで、プロジェクトメンバーはリンクされた問題を表示し、アクションメニューを使用して、1 つの共通のフィンガープリントによって特定されたクラッシュに対して、追加の問題を作成できます。問題追跡インテグレーションの名前を選択し、そのシステムに新しい問題を作成します（以下の例では phabicator か JIRA TEST）。

図 3（以下） - 問題追跡インテグレーション（JIRA TEST など）を選択すると、ユーザーに追加情報（「タイトル」や、その他問題追跡システム内の特定のフィールドの特定の値など）を入力するためのダイアログが表示されます。以下のスクリーンショットは、「タイトル」と「所有者」を示しています。管理者ユーザーは、手順 1 の「インテグレーションを管理する」の「Custom Fields（カスタムフィールド）」を管理することで、ユーザー向けにこのダイアログをさらにカスタマイズできます。

また、Backtrace で 2 つのシステム間でデータが同期されるタイミングを制御することもできます。以下の図 4 を参照してください。

このドキュメントの残りの部分では、管理者ユーザーが自動または手動での問題作成に使用できるように、それらのインテグレーションを作成して管理する方法について説明します。

インテグレーションを管理する

管理者ユーザーは、問題追跡システムに接続する必要があるプロジェクトのインテグレーションを作成する必要があります。このアクションは、「プロジェクト設定」 > 「インテグレーション」で実行されます。

プロジェクトに設定されたすべてのインテグレーションの一覧が表示されます。

管理者ユーザーは、テーブル内のインテグレーションの行を展開することで、特定のインテグレーションの状態を確認できます。

また、異なるターゲットシステム用に新しいインテグレーションを作成したり、既存のインテグレーションを編集したりできます。以下に、新しいインテグレーションフローを開始する方法を示します。

手順 1 - 接続の詳細

Jira とのインテグレーションの接続の詳細を設定するには、次の情報が必要です。

「名前」（必須）：このインテグレーションを識別するための名前。これは、インテグレーションのリストと、実行する手動のアクションのリストで使用されます。
「メール」（必須）：Jira インスタンスに関連付けられているメール。ユーザーによっては、Jira インスタンスのユーザー名が使用される場合があります。
「API トークン」（必須）：こちらから取得した Jira API トークン。一部の Jira インスタンスでは API トークンの代わりにパスワードもサポートされていますが、その機能は非推奨であり、削除される予定です。
「Project Key（プロジェクトキー）」（必須）：Jira のプロジェクトキー
「Issue Type（問題の種類）」：Jira の問題の種類。存在しない場合、デフォルトは「Bug（バグ）」です。
「Field for Main Body Text（本文テキストのフィールド）」：エラーに関する説明情報を追加するフィールドの名前。通常、その名前は「Description（説明）」です。
「Custom Fields（カスタムフィールド）」： Backtrace では、JIRA の問題に入力する追加のフィールドや値を指定できます。先頭に $ を付けることで、テキスト内で属性の値を使用できます（例：$version）。配列タイプのフィールドの場合は、値をカンマで区切ります。あるエラーグループ内に指定された属性の値が複数ある場合は、最も個数が多い値が使用されます。
「Subject（件名）」：Jira の問題の件名。その問題の適切な件名行が動的に入力されるように、多数のマクロに対応しています。

手順 2 - ペイロードの詳細

接続の詳細を設定した後は、そのインテグレーションのペイロードを定義します。これには次の情報が含まれます。

一方向同期の設定：Backtrace の状態（「未解決」、「解決済み」、「ミュート済み」）と担当者をサードパーティのシステムと同期する場合は、この設定をオンにします。オンにすると、Backtrace でこれらのフィールドが変更されると、サードパーティのシステム内のリンクされた問題にその変更が反映されます。Backtrace では、問題の状態からサードパーティのシステムへのマッピングを自動的に判定することを試行します。Backtrace の問題の状態（「未解決」、「解決済み」など）のサードパーティへのマッピングを、ユーザーが指定できるようにする計画があります。
表示設定：「Description（説明）」フィールドに含める情報を選択します。これには、Backtrace の一般的な情報のほか、表示する必要がある特定の属性値が含まれます。

手順 3 - 問題作成とデータ同期動作

エラーが発生したときに Jira に新しい問題を自動で作成するよう、システムを設定できるようになりました。問題はルールエンジンが一通り実行された後に作成されます。ルールは手順 4 で定義します。

データ同期 - フィンガープリントの担当者と状態情報の変更を Backtrace から Jira へ、同様にその情報を Jira から Backtrace 同期するかどうかを指定できます。
自動アクション - 問題を自動的に作成するかどうか？発生したエラーに対して問題を自動で作成するようさらにシステムを設定する場合は、「はい」を選択します。
作成をトリガーするタイミングを選択する：発生したすべてのエラーに対して問題を作成するか、新しいエラーに対してのみ問題を作成するかを指定します。

手順 4 - 自動作成動作のルール

最後に、エラーとともに送信される属性の値に応じて、問題作成を送信または除外するルールエンジンを設定できます。

たとえば、「buildType」属性が「stable」である場合にのみ、問題を自動で作成する必要があるとします。次のアクションをこの順序で設定します。

いずれかの属性が正規表現 .* と一致する場合は「フィルター」
buildType 属性が正規表現 stable と一致する場合は「送信」

buildType が stable の場合、最後の一致が「送信」であるため、通知は送信されます。それ以外の場合は、「フィルター」が有効になります。

一致させる対象の属性は、必ず「プロジェクト設定」の「属性」セクションで定義します。詳細については、「属性」を参照してください。

1 つ以上の送信/フィルターアクションを指定すると、システムでは上から順番に正規表現に対してユーザーが指定した属性がチェックされます。最後の一致が「送信」の場合、システムは最終的に通知を送信します。最後の一致が「フィルター」の場合は、送信されません。

追加のルール

「属性」：アクションが実行されるかどうかを判別するために、このカスタム属性に対してテストを実行します。
「正規表現」：この正規表現に対して属性をテストします。
「ターゲット」：メンションの場合、基準が満たされたときにメンションするユーザーまたはチャンネルを指定します。
「アクション」：特定の基準が満たされた場合にイベントを送信または除外するか、特定のユーザーへのメンションをトリガーするかを指定します（例：サービスの @username）。1 つ以上の送信/フィルターアクションが指定されている場合は、（上から順番にチェックされ）リストで最後に一致したものが有効になります。