DevOps ツールの履歴データをインポート

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間：11分

    • サービスカタログを使用して、新しいアプリをオンボーディングし、そのアプリの DevOps 履歴データをインポートします。ポーリングを有効にして、関連する計画、リポジトリ、およびパイプラインにマッピングされているデータをスケジュールされた頻度でインポートします。

    既存のツールの DevOps 履歴データをインポート

    アプリのオンボーディングカタログフォームを使用して、アプリのオンボーディング要求を作成し、 既にオンボーディングしている DevOps ツールの履歴データをインポートできます。現在、現在の日付から過去 90 日間の履歴データをインポートし、次のツールに対してスケジュールされた頻度でポーリングを有効にできます。
    • Jira (計画)
    • GitHub および GitHub Enterprise (コーディング)
    • Jenkins (オーケストレーション)
    注:
    • 対象データをインポートするツールが 作成され、接続され、検出されていることを確認確認します。
    • 計画ツール (Jira) のインポート要求が最初に処理され、その後にリポジトリとパイプラインのインポート要求が処理されます。

    ワークフローと再試行をインポート

    セルフサービスカタログからカタログ要求が正常に送信されると、設定した指定の承認者フローに従って、要求が承認のために送信されます。要求が承認されると、アプリのオンボーディング要求の受信イベントが作成されます。受信イベントレコードの [処理の詳細] フィールドには、インポート要求 ID とステータスが表示されます。単一のインポート要求で、関連リストに表示される複数の子インポート要求ページが作成されます。インポート要求ページは、サポートされているツールの次のロジックに基づいて作成されます。
    • Jira：ページは 15 日間の範囲で作成されます。
    • GitHub：100 コミットごとにページが作成されます。
    • Jenkins：ページは Build ごとに作成されます。
    。インポート要求の処理が完了すると、関連する作業アイテム、コミット、分岐、タグ、パイプライン実行、マッピングしたテストサマリーが作成され、システムに保持されます。
    インポートが成功すると、インポートされたすべてのコミットを次の場所に表示できます DevOps > 開発:
    • 分岐
    • コミット
    • コミット担当者
    • タグ
    • リポジトリ
    • 作業アイテム
    指定した日付範囲のインポートが成功したことを確認するための詳細。

    インポート要求の処理中にページエラーが発生した場合、組み込みの再試行メカニズムが、設定された回数だけページの処理を試行します。すべての自動再試行の後、ページがまだエラー状況の場合は、インポート要求の後続または残りのページが処理されます。インポート要求の全体的な状況はエラーのままです。

    たとえば、計画インポート要求が (すべての再試行後に) 失敗した場合、リポジトリとパイプラインのインポートの処理に進みます。次からインポート要求の再試行を構成できます DevOps > アドミニストレーション > プロパティ > インポート時のページあたりの最大再試行回数.
    • [インポート時のページあたりの最大再試行回数] フィールドで、インポート要求ページが失敗した場合に自動試行する再試行回数を指定します。すべての自動再試行後にページが成功しなかった場合、インポート要求は残りのページを処理します。インポート要求の全体的な状況はエラーのままです。
    • 失敗したインポート要求ページで [インポートを再試行] ボタンをクリックすると、失敗したインポートの試行を手動で再試行できます。

    ポーリングのスケジュールと構成

    ポーリングを有効にして、履歴データをインポートし、関連する計画、リポジトリ、およびパイプラインにマッピングされているアプリに、スケジュールされた頻度で DevOps データをインポートします。

    アプリをオンボーディングし、関連する DevOps データをインポートした後、追跡され、アプリに関連付けられている計画、リポジトリ、およびパイプラインのインポート要求を作成するためのベースシステムスケジュールを有効にすることができます。インポート要求の処理が完了すると、関連付けられたデータが保持され、アプリに対して表示されます。ベースシステムの DevOpsImportPolling スケジュールジョブはデフォルトで有効になっていますが、スケジュール済みジョブを実行するには、 DevOps プロパティからのポーリングを有効にする必要があります。

    ポーリングを有効にするには、 DevOps > アドミニストレーション > プロパティ > インポートポーリングを有効にする をクリックし、チェックボックスをオンにします。

    このプロパティフラグをオンにすると、ベースシステムの DevOpsImportPolling スケジュールジョブが有効になります。ポーリングのスケジュール済みジョブでは、アクティブでパイプラインが追跡されているすべてのアプリについて、最後に成功したインポートまたは 30 日後のいずれか遅い方を「開始日」として、当日の日付をデータインポートの「終了日」と見なします。このジョブは、前回成功したインポート時刻を検索し、それに応じて後続のインポート要求を作成します。このロジックにより、スケジュール設定済みポーリングジョブは、そのアプリに関連する DevOps データのデルタを、最後に成功したインポートから現在まで、最大 30 日間インポートします。
    注:
    ポーリング頻度を 1 日または 24 時間未満に設定しないでください。
    ジョブのデフォルトの頻度は、システムタイムゾーンを使用して毎日真夜中に実行されるように設定されています。スケジュール済みジョブの頻度を変更するには、 ServiceNow ServiceNow AI Platform アドミニストレーター (admin) ロールが必要です。
    移動先 システム定義 > スケジュール済みジョブ > DevOpsインポートポーリング をクリックし、必要に応じて [実行 頻度]、[ タイムゾーン]、および [時間 ] フィールドの値を変更します。スケジュール済みジョブの詳細については、「ジョブをスケジュール」を参照してください。
    注:
    • スケジュール済みジョブは、アクティブなアプリにのみ適用されます。ポーリングを構成しているアプリがアクティブ状態であり、関連するパイプラインの [追跡 ] フィールドが有効になっていることを確認します。
    • スケジュール頻度を変更する場合は、次の点を考慮してください。
      • JIRA の場合、デフォルトのタイムゾーンは JIRA サーバーの場所のタイムゾーンに基づいています。
      • Jenkinsの場合、デフォルトのタイムゾーンは UTC です。詳細については、「Jenkins システムタイムゾーンのドキュメント」を参照してください。
    DevOpsデータをインポートするためにポーリングするスケジュール済みジョブは、インポートおよびインポート要求に関連する次のDevOpsプロパティのデフォルト値に従います。
    • インポート時のページあたりの最大再試行回数
    • インポート要求で一度に処理する最大ページ数
    • インポート要求ページレコードの添付ファイルとしてペイロードを保存するには、[値] フィールドを true に設定します。それ以外はすべて false と見なされます。

    既存の Azure DevOps パイプライン、リポジトリ、および計画をインポートする

    Azure DevOps を DevOps と統合した後は、最大 90 日間の既存のパイプライン、リポジトリ、および計画データをインポートAzure DevOpsできます。その後、 DevOps ダッシュボードを使用して Azure DevOps データを表示および管理できます。

    始める前に

    必要なロール：admin

    このタスクについて

    • 事前定義されたカタログアイテムとしてサービスカタログからデータを要求します。
    • インポートされたテストサマリ、アーティファクト、およびパッケージは、ステップ実行ではなくパイプライン実行にリンクされます。
    • SonarQube スキャン結果はインポートされません。
    • Azure DevOps には次の制限が課せられます。
      • 最大 20,000 個の作業アイテムを 15 日ごとにインポートできます。
      • 最大 200 件の実行コミットを任意のパイプライン実行にマップできます。
      • 7 日を超えるパイプライン実行のテスト結果は返されません。
    注:
    非常に大きなデータセットの場合、インポートプロセスに数時間かかることがあります。

    手順

    1. 移動先 すべて > サービスカタログ > カタログ定義 > 自分のカタログ を選択し、[ DevOps Onboarding] を選択します。
    2. [カタログアイテム] 関連リストで、[DevOps アプリのオンボーディング] を選択します。
    3. [カタログアイテム] フォームで、[試行] を選択してデータを要求します。
      結果の DevOps アプリオンボーディングフォームでは、注文するカタログアイテムを指定できます。この場合、注文する「アプリ」は Azure DevOps インスタンスです。

      オンボーディングフォームでインスタンスを指定する

    4. [アプリ] フィールドで [リストで選択 (Select in list)] アイコン ( [アプリケーション] アイコン) を選択し、Azure DevOps のインスタンスを選択します。
      インスタンスを指定したので、インポートする日付範囲とデータソースを指定します。
    5. インポートする各パイプライン、リポジトリ、および計画について、次の手順を繰り返します。
      1. 適切な [オンボーディング] フィールドで [リストで選択 (Select in list)] アイコン ( [アプリケーション] アイコン) を選択して、インポートするアイテムを選択します。
        複数のアイテムを選択できます。
      2. [インポート元] フィールドと [インポート先] フィールドで、データの日付範囲を指定します。
    6. [今すぐ注文] を選択します。
      要求が [注文ステータス] ページに表示されます。
    7. 要求番号を選択して、自分または admin ロールを持つ別のユーザーが要求を承認できるようにします。
      承認できるように要求を選択します
    8. 要求を承認する: [要求] フォームで、[承認 (Approval)] と [要求状況] を [承認済み (Approved)] に設定します。
      インポートプロセスは承認後すぐに開始されます。

    既存の GitLab パイプラインとリポジトリのインポート

    GitLab を DevOps と統合した後、最大 90 日間の既存のGitLabパイプラインとリポジトリデータをインポートできます。その後、 DevOps ダッシュボードを使用して GitLab データを表示および管理できます。

    始める前に

    必要なロール：admin

    このタスクについて

    • 事前定義されたカタログアイテムとしてサービスカタログからデータを要求します。
    • インポートされたテストサマリーは、ステップ実行ではなくパイプライン実行にリンクされます。
    • artifacts キーワードを使用して公開されたアーティファクトのみがインポートされます。
    • 有効期限が切れたアーティファクトのテスト結果は表示されません。アーティファクトの有効期限を設定するには、パイプラインで expire_in プロパティを構成します。アーティファクトの有効期限ポリシーの詳細については、「アーティファクトとジョブのメタデータの有効期限」を参照してください。
    • SonarQube スキャン結果はインポートされません。
    • 1 回のインポートでインポートできるのは、ブランチあたり 6400 コミットのみです。
    • GitLab には次の制限があります: 実行コミットをパイプライン実行に関連付けている間、一部のシナリオでは GitLab はコミットの詳細の開始部分を提供しません。SHA の前の部分のみを「0000000000000000」として提供します。このようなシナリオでは、最新のコミットが実行コミットとして関連付けられます。たとえば、新しい分岐が作成されたときや、パイプラインが手動で実行されたときなどです。
      注:
      非常に大きなデータセットの場合、インポートプロセスに数時間かかることがあります。

    手順

    1. 移動先 すべて > サービスカタログ > カタログ定義 > 自分のカタログ を選択し、[ DevOps Onboarding] を選択します。
    2. [カタログアイテム] 関連リストで、[DevOps アプリのオンボーディング] を選択します。
    3. [カタログアイテム] フォームで、[試行] を選択してデータを要求します。
      結果の DevOps アプリオンボーディングフォームでは、注文するカタログアイテムを指定できます。この場合、注文する「アプリ」は GitLab インスタンスです。

      オンボーディングフォームでインスタンスを指定する

    4. [アプリ] フィールドで [リストで選択 (Select in list)] アイコン ( [アプリケーション] アイコン) を選択し、GitLab のインスタンスを選択します。
      インスタンスを指定したので、インポートする日付範囲とデータソースを指定します。
    5. インポートする各リポジトリについて、次の手順を繰り返します。
      1. [オンボーディングリポジトリ] フィールドで [リストで選択] アイコン ([アプリケーション] アイコン) を選択し、インポートするアイテムを選択します。
        複数のアイテムを選択できます。
      2. [インポート元] フィールドと [インポート先] フィールドで、データの日付範囲を指定します。
      注:
      [オンボーディングリポジトリ] フィールドでリポジトリを選択すると、リポジトリにマッピングされたパイプラインが自動的に選択されます。パイプラインを個別に選択する必要はありません。
    6. [今すぐ注文] を選択します。
      要求が [注文ステータス] ページに表示されます。
    7. 要求番号を選択して、自分または admin ロールを持つ別のユーザーが要求を承認できるようにします。
      承認できるように要求を選択します
    8. 要求を承認する：[要求] フォームで、[承認 (Approval)] と [要求状況] を [承認済み (Approved)] に設定します。
      インポートプロセスは、承認後すぐに開始されます。