DevOps 変更速度管理へのオンボードGitHub —ワークスペース
DevOps 変更ワークスペースプレイブックを使用して GitHub インスタンスに接続し、リポジトリ、計画、パイプラインを検出、構成、およびインポートします。
始める前に
DevOps 変更速度管理 の使用を開始するにはトピックで指定されたタスクを完了します。
必要なロール: sn_devops.admin または sn_devops.tool_owner
手順
-
移動先 ワークスペース > DevOps 変更ワークスペース をクリックし、次のいずれかのオプションを使用してプレイブックを開き、 GitHubをオンボーディングします。
オプション ステップ ホームページ - [ツールを接続] を選択します。
- [ツールに接続] モーダルで、適切なカテゴリ (オーケストレーション、コード、計画、またはソフトウェア品質) からツールを選択します。たとえば、コーディングツールとして GitHub に接続する場合は、[コーディングツール] カテゴリを選択します。
[アプリケーション] モジュール - プライマリナビゲーションから [アプリケーション] (
) を選択します。
- 既存のアプリケーションを選択するか、新規作成します。アプリケーションを作成する場合は、アプリケーションを作成 - ワークスペース を参照します。
- [推奨アクション] ペインから、[ツールを接続] カードを選択します。
- [ツールに接続] モーダルで、適切なカテゴリからツールを選択します。たとえば、コーディングツールとして GitHub に接続する場合は、[コード] カテゴリで [GitHub] を選択します。
[ツール] モジュール - プライマリナビゲーションから [ツール] (
を選択します。
- [機能] リストから適切なカテゴリを選択します。たとえば、コーディングツールとして GitHub に接続する場合は、[コーディング] カテゴリを選択します。
- [ツールを接続] を選択します。
- [ツールに接続] モーダルで、[GitHub] を選択します。
重要:ツールへの接続中にパイプライン、計画、リポジトリなどのツールオブジェクトを検出して追跡する場合は、[アプリケーション] モジュールからツールを接続する必要があります。 -
[ツール名] フィールドに、ツールの名前を入力します。
-
[次へ] を選択します。
オンボーディングタスクを完了するのに役立つ DevOps プレイブックが開きます。
-
プレイブックを使用して接続と構成を完了します。
-
[認証情報タイプ] フィールドで、次のいずれかの認証情報タイプを選択します。
- 基本認証
- 認証コード付き OAuth 2.0
- JSON Web トークン (JWT) を含む OAuth 2.0
-
認証情報を入力します。
基本認証 GitHub インスタンスのユーザー名とパスワード/アクセストークンを入力します。
認証コード付き OAuth 2.0 既存の認証コード付き OAuth 2.0 認証情報レコードを選択するか、認証コード付き OAuth 2.0 認証情報レコードを作成します。詳細については、「GitHubアプリプロバイダーの認証情報レコードの作成 (認証コード)」を参照してください。
JSON Web トークン (JWT) を含む OAuth 2.0 JWT で OAuth 2.0 を使用して接続するには、最初に次を実行する必要があります。前提条件を満たしたら、DevOps 変更速度管理 コネクトプレイブックアクティビティを続行できます。- 既存の JWT 認証情報レコードを使用する場合は、[既存の JWT 認証情報レコードを使用] オプションを選択します。このオプションが選択されていない場合は、新しい JWT 認証情報レコードを作成するフィールドが表示されます。次の手順に進みます。
- [JKS 証明] フィールドで、既存の JKS 証明書を選択します。JWT プロバイダーを一意に識別する名前です。JKS 証明書は、シェルコマンドを使用して作成され、sys_certificate レコードを作成します
詳細については、「GitHub JKS 証明書の JWT 署名キーを作成する」を参照してください。
- [署名キー] フィールドに、JKS 証明書に割り当てる署名キーを入力します。JKS 証明書の生成時に入力したエクスポートパスワードです。
- [GitHub App 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 Apps - JWT を使用して作成されている場合、ツールレコードページで [GitHub App で構成 (Configure with GitHub App)] オプションが利用可能になります。
OAuth2.0 の認証情報の詳細については、「DevOps 変更速度管理 向けの GitHub OAuth 2.0 認証情報の設定」を参照してください。
- オプション:
GitHub アプリを使用して Oauth 2.0 認証情報を作成した場合は、[GitHub アプリのスラッグ名] フィールドに値を入力して、接続する前にツールの権限要件を確認します。
アプリのスラッグ名は、アプリの設定ページで確認できます。
- オプション:
GitHub インスタンスが MID サーバーに添付されている場合は、[MID サーバー] オプションを選択し、その詳細を入力します。
MID サーバーの詳細については、「MID サーバーの選択」を参照してください。
注:OAuth 認証コードと JWT 権限許可タイプは、MID サーバーを使用する GitHub および GitHub Enterprise でサポートされています。 -
[コネクト] を選択します。
-
入力した認証情報に対して権限チェックが実行されます。
必要な権限と利用可能な権限が表示されます。より適切なアクセス許可を持つ認証情報を入力する場合は、[認証情報を再入力] を選択します。必要なすべての権限の詳細については、「DevOps ツールに必要な権限 の GitHub 権限」を参照してください。
GitHubアプリのスラッグ名を入力しない場合、権限要件を確認せずにツールが接続されます。
-
[次へ] を選択します。
-
[認証情報タイプ] フィールドで、次のいずれかの認証情報タイプを選択します。
-
ツールのアクセス権を指定します。
- ツールへのアクセスを制御する場合は、ツールへのアクセス権を付与する必要があるグループを [保守担当者 ] フィールドに追加します。グループ内のこれらのユーザーが実行できるタスクは、割り当てられたロールによって異なります。
- DevOps ツールオーナーロール: ツールを表示および編集できます。
- DevOps アプリオーナーロール: ツールを表示し、ツールのオブジェクト (プラン、リポジトリ、パイプラインなど) の関連付け、検出、履歴データのインポート、パイプラインステップの変更 (該当する場合) を実行できます。
- DevOps 管理者ロール: すべてのツールを編集できます。
- その他の DevOps ロール: ツールを表示できます。
注:グループを選択せずにこの手順をスキップすると、 DevOps ツールオーナーロールを持つすべてのユーザーがツールを編集できます。 - ツールへのアクセスを制御することを選択した場合、 すべてのアプリ所有者がツールオブジェクトを表示してアプリケーションに関連付けることができる オプションが選択可能になります。
このオプションを使用すると、 DevOps アプリオーナーロールを持つすべてのユーザーがツールにアクセスできます。選択すると、ツールのオブジェクトの表示、関連付け、検出、履歴データのインポート、およびパイプラインステップの変更 (該当する場合) が可能になります。
- [アサイン] を選択します。
- ツールへのアクセスを制御する場合は、ツールへのアクセス権を付与する必要があるグループを [保守担当者 ] フィールドに追加します。
-
GitHub インスタンスで Webhook を自動的に構成して、DevOps 変更速度管理 にデータを送信します。
このアクションにより、次の Webhook が構成されます。
- push:リポジトリのコミット、ブランチ、およびタグを収集します
- workflow_job:パイプラインデータを収集します
- issues:問題 (作業アイテム) データを収集するため
注:リアルタイム通知は、特に変更要求を自動化する場合に最新の情報を維持するのに理想的であるため、このタスクの一部として構成を完了することをお勧めします。それ以外の場合は、Enable Polling プロパティを [はい] に設定して、夜間ポーリングを有効にして追跡対象のリポジトリまたはパイプラインのデータシステムをフェッチすることで、後で手動で構成することで Webhook を設定できます。Webhook を構成するリポジトリを選択し、[構成] を選択します。
手動で構成するには、[手動で構成] を選択します。詳細については、「Webhook をGitHub で手動で構成」を参照してください。
重要:- ホームページまたはツールモジュールから接続している場合は、接続が完了し、[サマリー] ページに移動します。
- アプリケーションモジュールから接続している場合は、利用可能なリポジトリとパイプラインが検出されます。それらから履歴データを追跡してインポートできます。
-
追跡する計画を選択します。
更新を追跡し、アプリケーションに関連付けたいプランを選択します。
ツールのオンボーディングが完了すると、これらの選択した計画の作業アイテムのみが自動的にインポートされます。
[次へ] を選択します。
-
追跡するリポジトリを選択します。
- 更新を追跡し、アプリケーションに関連付けたいリポジトリを選択します。
[次へ] を選択します。
リポジトリデータをインポートする場合は、日付範囲を選択して [送信] を選択します。
最大 90 日間のデータをインポートできます。リポジトリに関連付けられているワークフローもインポートされます。
-
追跡するパイプラインを選択します。
更新を追跡し、アプリケーションに関連付けたいパイプラインを選択します。
[次へ] を選択します。
- 選択したパイプラインごとに、最後に成功した実行からすべてのステップまたはステージがインポートされます。[サービスをパイプラインステップにアサイン] アクティビティでは、パイプラインステップごとに以下を選択できます。
パイプラインステップタイプ:サービスをアサインするステップタイプを選択します。
ヒント:パイプライン実行が本番環境への展開として成功したことを識別できるように、Prod deploy本番環境への展開を表すステップDevOpsには少なくともステップタイプを指定してください。サービス:パイプラインステップがマップされる CMDB アプリケーションサービスを選択します。
アプリケーションサービスは、環境にほぼマッピングされます。同じパイプラインステップを使用して異なる環境に展開する場合は、値を空白のままにすることができます。サービス情報により、DevOps でインシデントや機能停止などの運用評価指標を特定してレポートできるようになります。
[次へ] を選択します。
-
[サマリー] ページで [ツールレコードを表示] を選択して、接続された GitHub ツールの詳細を確認します。
GitHub Actionsパイプラインの場合は、シークレットの作成、GitHub でのワークフロー構成の定義など、いくつかの追加手順を実行する必要があります。詳細については、「GitHub Actions構成」を参照してください。
タスクの結果
GitHub ツールが DevOps 変更速度管理 に正常にオンボーディングされました。
次のタスク
GitHub ツールがオンボーディングされた後でも、計画を手動で検出できます。GitHub には計画エンティティがないため、ServiceNow で対応する計画レコードを検出するためにリポジトリが検討されます。
- ツールレコードページから、[検出 (Discover)] を選択して計画を検出します。
- [構成] を選択します。計画が追跡され、作業アイテムのリアルタイム通知を送信する issues と呼ばれる Webhook が作成されます。
- 問題のタイトルの変更
- アサイニーの更新
- 転送の問題注:課題が転送されると、転送元のリポジトリで同じ課題が転送済みとしてマークされ、転送先のリポジトリで開かれます。
- 問題を削除注:GitHub で問題が削除されても、対応する作業アイテムは ServiceNow で削除されませんが、作業アイテムのステータスは削除済みとしてマークされます。
アップグレードするお客様の場合は、定期的に検出するスケジュール済みジョブまたは手動検出を通じて、リポジトリの計画が検出されます。計画が検出されたら、sn_devops.track.github.issues プロパティを有効にして以前に構成したすべてのリポジトリを一度に再構成し、すべての計画が追跡され、作業アイテムの問題 Webhook が作成されるようにすることができます。