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

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間：11分

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    始める前に

    必要なロール：admin

    このタスクについて

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

    手順

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

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

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

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

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

    始める前に

    必要なロール：admin

    このタスクについて

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

    手順

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

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

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