---
sourceDocument: Xanadu IT Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/it-service-management

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

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

# DevOpsツールの履歴データのインポート {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：10分

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

## 既存のツールの履歴 DevOps データをインポート {#import-historical-data-devops-catalog__section_rnt_wyr_jsb}

アプリのオンボーディングカタログフォームを使用して、アプリのオンボーディング要求を作成し、 既にオンボーディングしている DevOps ツールの履歴データをインポートできます。現在、現在の日付から過去 90 日間の履歴データをインポートし、次のツールに対してスケジュールされた頻度でポーリングを有効にできます。

* Jira (計画)
* GitHub および GitHub Enterprise (コーディング)
* Jenkins (オーケストレーション)

{#import-historical-data-devops-catalog__ul_mbb_lsl_jsb}  
注:  
* データのインポート対象のツールを作成、接続、および検出していることを確認します。
* 計画ツール (Jira) のインポート要求が最初に処理され、その後にリポジトリとパイプラインのインポート要求が処理されます。
{#import-historical-data-devops-catalog__ul_h33_zxr_jsb}

## ワークフローと再試行のインポート {#import-historical-data-devops-catalog__section_nn3_czr_jsb}

セルフサービスカタログからカタログ要求が正常に送信されると、設定した指定の承認者フローに従って、要求が承認のために送信されます。要求が承認されると、アプリのオンボーディング要求の受信イベントが作成されます。受信イベントレコードの \[処理の詳細 \] フィールドには、インポート要求 ID とステータスが表示されます。単一のインポート要求で、関連リストに表示される複数の子インポート要求ページが作成されます。インポート要求ページは、サポートされているツールの次のロジックに基づいて作成されます。

* Jira:ページは 15 日間の範囲で作成されます。
* GitHub :100 コミットごとにページが作成されます。
* Jenkins:ページはビルドごとに作成されます。
{#import-historical-data-devops-catalog__ul_xzm_tjt_4sb} . インポート要求の処理が完了すると、マッピングした関連する作業アイテム、コミット、分岐、タグ、パイプライン実行、テストサマリが作成され、システムに保持されます。  
インポートが成功すると、インポートされたすべてのコミットを DevOps開発:

* 分岐
* コミット
* コミット担当者
* タグ
* リポジトリ
* 作業アイテム
{#import-historical-data-devops-catalog__ul_pc3_334_ksb} 指定した日付範囲のインポートが成功したことを確認するための詳細。

インポート要求の処理中にページエラーが発生した場合、組み込みの再試行メカニズムが設定された回数だけページの処理を試行します。すべての自動再試行の後、ページがまだエラー状態の場合は、インポート要求の後続または残りのページが処理されます。インポート要求の全体的なステータスはエラーのままです。  
たとえば、計画インポート要求が (すべての再試行後に) 失敗した場合、リポジトリとパイプラインのインポートの処理に進みます。からのインポート要求の再試行を構成できます DevOps管理プロパティインポート時のページあたりの最大再試行回数.

* \[ インポート中のページあたりの最大再試行 回数\] フィールドで、インポート要求ページが失敗した場合に自動試行する再試行回数を指定します。すべての自動再試行後にページが成功しなかった場合、インポート要求は残りのページを処理します。インポート要求の全体的なステータスはエラーとして反映されます。
* 失敗したインポート要求ページで \[ インポートの再試行 \] ボタンをクリックすると、失敗したインポートの試行を手動で再試行できます。
{#import-historical-data-devops-catalog__ul_vlg_syr_jsb}

## ポーリングのスケジュールと構成 {#ariaid-title2}

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

ポーリングを有効にするには、 DevOps管理プロパティインポートポーリングを有効化 をクリックし、チェックボックスをオンにします。  
このプロパティフラグをオンにすると、ベースシステムの <var class="keyword varname">DevOpsImportPolling</var> スケジュールジョブが有効になります。ポーリングのスケジュール済みジョブでは、アクティブでパイプラインが追跡されているすべてのアプリについて、最後に成功したインポートまたは 30 日後のいずれか遅い方を「開始日」として、当日の日付をデータインポートの「終了日」と見なします。このジョブは、前回成功したインポート時刻を検索し、それに応じて後続のインポート要求を作成します。このロジックにより、スケジュール設定済みポーリングジョブは、そのアプリに関連する DevOps データのデルタを、最後に成功したインポートから現在まで、最大 30 日間インポートします。  
注:  
ポーリング頻度を 1 日または 24 時間未満に設定しないでください。
ジョブのデフォルトの頻度は、システムタイムゾーンを使用して毎日真夜中に実行されるように設定されています。スケジュール済みジョブの頻度を変更するには、 ServiceNow Now Platform アドミニストレーター (admin) ロールが必要です。  
移動先 システム定義スケジュール済みジョブDevOpsImportPolling をクリックし、必要に応じて \[ 実行 頻度\]、\[ タイムゾーン\]、および \[時間 \] フィールドの値を変更します。詳細については、「[ジョブのスケジュール」](https://www.servicenow.com/docs/access?context=c_ScheduledJobs&version=xanadu&pubname=xanadu-platform-administration&ft:locale=en-US)を参照してください  
注:  
* スケジュール済みジョブは、アクティブなアプリにのみ適用されます。ポーリングを構成しているアプリがアクティブ状態であり、関連するパイプラインの \[追跡 \] フィールドが有効になっていることを確認します。
* スケジュール頻度を変更する場合は、次の点を考慮してください。
  * JIRA の場合、デフォルトのタイムゾーンは JIRA サーバーの場所のタイムゾーンに基づいています。
  * Jenkinsの場合、デフォルトのタイムゾーンは UTC です。詳細については、 Jenkins [システムタイムゾーンのドキュメント](https://www.jenkins.io/doc/book/managing/change-system-timezone/)を参照してください。
  {#polling-import-schedule-devops-data__ul_jk1_wt4_ksb}
{#polling-import-schedule-devops-data__ul_wt1_qt4_ksb}  
DevOpsデータをインポートするためにポーリングするスケジュール済みジョブは、インポートおよびインポート要求に関連する次のDevOpsプロパティのデフォルト値に従います。

* インポート時のページあたりの最大再試行回数
* インポート要求で一度に処理する最大ページ数
* インポート要求ページレコードの添付ファイルとしてペイロードを保存するには、\[値\] フィールドを \[true\] に設定します。それ以外はすべて false と見なされます。
{#polling-import-schedule-devops-data__ul_njp_525_jsb}

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

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

### 始める前に

必要なロール：admin

### このタスクについて

* 事前定義されたカタログアイテムとしてサービスカタログからデータを要求します。
* インポートされたテストサマリ、アーティファクト、およびパッケージは、ステップ実行ではなくパイプライン実行にリンクされます。
* SonarQube スキャン結果はインポートされません。
* Azure DevOps には次の制限が課せられます。
  * 最大 20,000 個の作業アイテムを 15 日ごとにインポートできます。
  * 最大 200 件の実行コミットを任意のパイプライン実行にマップできます。
  * 7 日を超えるパイプライン実行のテスト結果は返されません。
  {#devops-import-existing-ado-data__ul_etn_zrv_ctb}

{#devops-import-existing-ado-data__ul_l54_rdl_2tb}  
注:  
非常に大きなデータセットの場合、インポートプロセスに数時間かかることがあります。

### 手順

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

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

## 既存の GitLab パイプラインとリポジトリをインポート {#ariaid-title4}

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

### 始める前に

必要なロール：admin

### このタスクについて

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

### 手順

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

4. \[アプリ\] フィールドで \[リストで選択\] アイコン ( ![\[アプリケーション\] アイコン]()) を選択し、GitLab のインスタンスを選択します。  
   インスタンスを指定したので、インポートする日付範囲とデータソースを指定します。
5. インポートするリポジトリごとに次の手順を繰り返します。
   1. \[オンボーディングリポジトリ\] フィールドで \[リストで選択\] アイコン ( ![\[アプリケーション\] アイコン]()) を選択し、インポートするアイテムを選択します。  
      複数のアイテムを選択できます。
   2. \[ インポート元\] フィールドと \[ インポート先 \] フィールドで、データの日付範囲を指定します。

   {#import-existing-gitlab-pipelines-and-repositories__substeps_efn_vn4_ctb}  
   注:  
   \[ オンボーディングリポジトリ \] フィールドでリポジトリを選択すると、リポジトリにマップされたパイプラインが自動的に選択されます。パイプラインを個別に選択する必要はありません。
6. \[Order Now (今すぐ注文)\] を選択します。  
   要求が \[注文ステータス\] ページに表示されます。
7. 要求番号を選択して、自分または admin ロールを持つ別のユーザーが要求を承認できるようにします。  
8. 要求を承認する: \[要求\] フォームで、\[ 承認 \] と \[要求の状態 \] を \[ 承認済み\] に設定します。  
   インポートプロセスは承認後すぐに開始されます。
{#import-existing-gitlab-pipelines-and-repositories__steps_dk4_pcr_x5b}