DevOps 変更速度へのオンボードGitHub —ワークスペース

リリースバージョン: Zurich

更新日 2025年07月31日

所要時間：12分

DevOps 変更ワークスペースプレイブックを使用して GitHub インスタンスに接続し、リポジトリ、計画、パイプラインを検出、構成、およびインポートします。

始める前に

DevOps 変更速度の開始トピックで指定されたタスクを完了します。

必要なロール:sn_devops.admin または sn_devops.tool_owner

手順

移動先ワークスペース > DevOps 変更ワークスペースをクリックし、次のいずれかのオプションを使用してプレイブックを開き、 GitHubオンボーディングします。

オプション	ステップ
ホームページ	[ツールを接続] を選択します。 [ツールに接続] モーダルで、適切なカテゴリ (オーケストレーション、コード、プラン、またはソフトウェア品質) からツールを選択します。たとえば、コーディングツールとして GitHub に接続する場合は、[ コーディングツール ] カテゴリを選択します。
アプリケーションモジュール	プライマリナビゲーションから [アプリケーション ] を選択します。既存のアプリケーションを選択するか、新しいアプリケーションを作成します。アプリケーションを作成するには、「アプリケーションの作成 - ワークスペース」を参照してください。 [推奨アクション] ペインで、[ ツールを接続 ] カードを選択します。 [ツールに接続] モーダルで、適切なカテゴリからツールを選択します。たとえば、コーディングツールとして GitHub に接続する場合は、[コード] カテゴリで [GitHub] を選択します。
ツールモジュール	プライマリナビゲーションから [ツール ] ( を選択します。 [機能] リストから適切なカテゴリを選択します。たとえば、コーディングツールとして GitHub に接続する場合は、[ コーディング ] カテゴリを選択します。 [ツールを接続] を選択します。 [ツールに接続] モーダルで、[ GitHub] を選択します。

重要:

ツールへの接続中にパイプライン、プラン、リポジトリなどのツールオブジェクトを検出して追跡する場合は、アプリケーションモジュールからツールを接続する必要があります。

[ツール名] フィールドに、ツールの名前を入力します。
[Next (次へ)] をクリックします。

オンボーディングタスクを完了するのに役立つ DevOps プレイブックが開きます。

プレイブックを使用して接続と構成を完了します。

[ 認証情報タイプ ] フィールドで、次のいずれかの認証情報タイプを選択します。
- 基本認証
- 認証コード付き OAuth 2.0
- JSON Web トークン (JWT) を含む OAuth 2.0

認証情報を入力します。


基本認証	GitHubインスタンスのユーザー名とパスワード/アクセストークンを入力します。
認証コード付き OAuth 2.0	認証コード付きの既存の OAuth 2.0 認証情報レコードを選択するか、認証コード付きの OAuth 2.0 認証情報レコードを作成します。詳細については、「GitHub アプリプロバイダーの認証情報レコードの作成 (認証コード)」を参照してください。注: GitHub アプリを使用して接続していて、権限チェックで問題が発生した場合は、GitHub アプリのクライアント ID プレフィックスが DevOps プロパティ ( GitHub アプリのクライアント ID 指定子) で使用できることを確認してください。詳細については、「クライアント ID を DevOps プロパティに追加」を参照してください。
JSON Web トークン (JWT) を含む OAuth 2.0	JWT で OAuth 2.0 を使用して接続するには、最初に次の手順を実行する必要があります。 GitHub アプリの作成と構成の Java KeyStore 証明書の生成 GitHub GitHub Java KeyStore 証明書をインスタンスに添付します前提条件を満たした後、 DevOps 変更速度コネクトプレイブックアクティビティを続行できます。既存の JWT 認証情報レコードを使用する場合は、[既存の JWT 認証情報レコードを使用 ] オプションを選択します。このオプションが選択されていない場合、新しい JWT 認証情報レコードを作成するためのフィールドが表示されます。次のステップに進みます。 [JKS 証明書] フィールドで、既存の JKS 証明書を選択します。これは、JWT プロバイダーを一意に識別するために入力した名前です。JKS 証明書は、シェルコマンドを使用して sys_certificate レコードを作成します。詳細については、「GitHub JKS 証明書の JWT 署名キーを作成する」を参照してください。 [署名キー] フィールドに、JKS 証明書にアサインする署名キーを入力します。これは、JKS 証明書の生成中に入力されたエクスポートパスワードです。 [GitHub アプリ ID] フィールドで、GitHub アプリのアプリ ID を選択します (GitHub の GitHub アプリ構成の [関連情報] セクションで利用可能)。次の図は、GitHub アプリ ID、クライアント ID、クライアントシークレットにアクセスできる GitHub アプリ構成の [バージョン情報] セクションの例を示しています。 [クライアント ID] フィールドで、GitHub アプリのクライアント ID を選択します (GitHub の GitHub アプリ構成の [バージョン情報] セクションで利用可能)。 [クライアントシークレット] フィールドで、GitHub アプリのクライアントシークレット (GitHub の GitHub アプリ構成の [バージョン情報] セクションで利用可能) を選択します。 [ トークン URL ] フィールドで、インスタンスがトークンを取得および更新するために使用するトークンエンドポイントの場所を選択します。クラウドバージョンの場合は、「 `https://api.github.com/app/installations/<installation_id>/access_tokens`」と入力します。エンタープライズバージョンの場合は、「 `https://<HOST_URL>/api/v3/app/installations/<installation_id>/access_tokens`」と入力します。インストール ID については、GitHub の GitHub アプリ構成の [アプリのインストール] セクションに移動し、歯車アイコンを選択してアプリを構成します。インストールIDはWebページのURLにあります。例:https://github.com/settings/installations/<installation_id>。 OAuth 認証情報が GitHub アプリ - JWT を使用して作成されている場合、ツールレコードページで [GitHub アプリと構成 ] オプションが使用可能になります。注: GitHub アプリを使用して接続していて、権限チェックで問題が発生した場合は、GitHub アプリのクライアント ID プレフィックスが DevOps プロパティ ( GitHub アプリのクライアント ID 指定子) で使用できることを確認してください。詳細については、「クライアント ID を DevOps プロパティに追加」を参照してください。

OAuth2.0 認証情報の詳細については、「の GitHub OAuth 2.0 認証情報の設定 DevOps 変更速度」を参照してください。

オプション: GitHub アプリを使用して Oauth 2.0 認証情報を作成した場合は、接続する前に GitHub アプリのスラッグ名フィールドに値を入力して、ツールの権限要件を確認してください。
アプリのスラッグ名は、アプリの設定ページで確認できます。
オプション: GitHub インスタンスがMID サーバーに添付されている場合は、[MID サーバー] オプションを選択し、その詳細を入力します。

MID サーバーの詳細については、「 MID サーバーの選択」を参照してください。

注:
OAuth 認証コードと JWT 権限許可タイプは、GitHub および GitHub Enterprise と MID サーバーでサポートされています。
[Connect (接続)] を選択します。
入力した認証情報に対して権限チェックが実行されます。

必要な権限と利用可能な権限が表示されます。より適切な権限を持つ認証情報を入力する場合は、[ 認証情報の再入力] を選択します。必要なすべての権限の詳細については、「DevOpsツールに必要な権限のGitHub権限」を参照してください。

OAuth 2.0 では、 GitHub アプリのスラッグ名を入力していない場合、権限要件を確認せずにツールが接続されます。
[Next (次へ)] をクリックします。

ツールのアクセス権を指定します。
1. ツールへのアクセスを制御する場合は、ツールへのアクセス権を付与する必要があるグループを [ 管理担当者 ] フィールドに追加します。
  グループ内のこれらのユーザーが実行できるタスクは、アサインされたロールによって異なります。
  - DevOps ツールオーナーロール:ツールを表示および編集できます。
  - DevOps アプリオーナーロール:ツールを表示し、ツールのオブジェクト (プラン、リポジトリ、パイプラインなど) のパイプラインステップ (該当する場合) を関連付け、検出、インポートし、パイプラインステップを変更できます。
  - DevOps アドミニストレーターロール:すべてのツールを編集できます。
  - その他の DevOps ロール:ツールを表示できます。
  注:
  グループを選択せずにこの手順をスキップすると、 DevOps ツールオーナーロールを持つすべてのユーザーがツールを編集できます。
2. ツールへのアクセスを制御することを選択した場合、すべてのアプリ所有者がツールオブジェクトを表示してアプリケーションに関連付けることができるオプションが選択可能になります。
  このオプションを使用すると、 DevOps アプリオーナーロールを持つすべてのユーザーがツールにアクセスできます。選択すると、ツールのオブジェクトの表示、関連付け、検出、履歴データのインポート、およびパイプラインステップの変更 (該当する場合) を行うことができます。
3. [アサイン] を選択します。
GitHub インスタンスで Webhook を自動的に構成して、DevOps 変更速度にデータを送信します。
このアクションでは、次の Webhook を構成します。
- push:リポジトリのコミット、ブランチ、およびタグを収集するには
- workflow_job:パイプラインデータを収集します
- issues:問題 (作業アイテム) データを収集します
注:
リアルタイム通知は、特に変更要求を自動化する場合に現在の情報を維持するのに理想的であるため、このタスクの一部として構成を完了することをお勧めします。それ以外の場合は、 Enable Polling プロパティを Yes に設定して、夜間のポーリングを有効にして追跡されたリポジトリまたはパイプラインのデータシステムをフェッチすることで、後で手動で構成することで Webhook を設定できます。

Webhook を構成するリポジトリを選択し、[ 構成] を選択します。

手動で構成するには、[ 手動で構成] を選択します。詳細については、「手動で GitHub で Webhook を構成する」を参照してください。
重要:
ホームページまたはツールモジュールから接続している場合は、接続が完了し、[概要] ページが表示されます。

アプリケーションモジュールから接続している場合は、利用可能なリポジトリとパイプラインが検出されます。それらから履歴データを追跡してインポートできます。
追跡する計画を選択します。
1. 更新を追跡してアプリケーションに関連付ける計画を選択します。
  
  ツールのオンボーディングが完了すると、これらの選択した計画の作業アイテムのみが自動的にインポートされます。
2. [Next (次へ)] をクリックします。
追跡するリポジトリを選択します。
1. 更新を追跡してアプリケーションに関連付けるリポジトリを選択します。
2. [Next (次へ)] をクリックします。
3. リポジトリデータをインポートする場合は、日付範囲を選択して [送信] を選択します。
  
  最大 90 日間のデータをインポートできます。リポジトリに関連付けられたワークフローもインポートされます。
追跡するパイプラインを選択します。
1. 更新を追跡してアプリケーションに関連付けるパイプラインを選択します。
2. [Next (次へ)] をクリックします。
3. 選択したパイプラインごとに、最後に成功した実行のすべてのステップまたはステージがインポートされます。[サービスをパイプラインステップにアサイン] アクティビティでは、パイプラインステップごとに以下を選択できます。
  1. パイプラインステップタイプ:サービスをアサインするステップタイプを選択します。
    
    ヒント:
    本番展開を表すステップに少なくとも Prod deploy ステップタイプを指定して、 DevOps 成功したパイプライン実行を本番展開として識別できるようにします。
  2. サービス:パイプラインステップがマップされる CMDB アプリケーションサービスを選択します。
    
    アプリケーションサービスは環境に近似的にマッピングされます。同じパイプラインステップを使用して異なる環境に展開する場合は、フィールドを空のままにします。サービス情報により、 DevOps インシデントや機能停止などの運用評価指標を識別してレポートすることができます。
4. [Next (次へ)] をクリックします。
[概要] ページで [ツールレコードの表示] を選択して、接続されたGitHubツールの詳細を確認します。

GitHub Actionsパイプラインでは、シークレットの作成、GitHub でのワークフロー構成の定義などの追加の手順を実行する必要があります。詳細については、「GitHub Actions構成」を参照してください。

タスクの結果

GitHub ツールが DevOps 変更速度に正常にオンボーディングされました。

次のタスク

GitHub ツールがオンボードされた後でも、プランを手動で検出できます。GitHub には計画エンティティがないため、ServiceNow で対応する計画レコードを検出するためにリポジトリが考慮されます。

ツールレコードページで、[ 検出 ] を選択して計画を検出します。
[Configure] を選択します。計画が追跡され、作業アイテムのリアルタイム通知を送信する issues という Webhook が作成されます。

対応する問題が GitHub で更新されると、ServiceNow の作業アイテムについて次の情報が更新されます。

問題のタイトルの変更
アサイニーの更新
転送の問題
注:
課題が転送されると、その課題は転送元のリポジトリで転送済みとしてマークされ、転送先のリポジトリで開かれます。
問題を削除
注:
GitHub で問題が削除された場合、対応する作業アイテムは ServiceNow で削除されませんが、作業アイテムのステータスは削除済みとしてマークされます。

アップグレードのお客様は、定期的に検出するスケジュール済みジョブまたは手動検出によって、リポジトリの計画が検出されます。計画が検出されたら、 sn_devops.track.github.issues プロパティを有効にして、以前に構成したすべてのリポジトリを一度に再構成し、すべての計画が追跡され、作業項目の問題 Webhook が作成されるようにできます。

注:

計画の履歴インポートはサポートされていません。

を使用した GitHub のオンボーディングワークスペース

チューリッヒ IT サービス管理

DevOps 変更速度へのオンボードGitHub —ワークスペース

始める前に

手順

タスクの結果

次のタスク