deployment-workflow

デプロイワークフロー

概要

このスキルでは、インスタンス間（Dev → Test → Prod）でServiceNowの構成をデプロイするための包括的なフレームワークを提供します。デプロイのライフサイクル全体を網羅しています。

• デプロイ前の検証と準備
• 更新セットのエクスポートおよびインポートのプロセス
• プレビューと競合解決の戦略
• デプロイ後の検証
• デプロイ失敗時のロールバック手順

使用する場面： SDLCパイプラインを通じて構成変更を昇格させる場合や、ServiceNowインスタンス間でカスタマイズを移行する場合です。

対象ユーザー： ServiceNowのデプロイを担当する管理者、DevOpsエンジニア、開発者です。

前提条件

• ロール： ソースインスタンスとターゲットインスタンスの両方でadminまたはupdate_set_admin
• アクセス権： sys_update_set、sys_update_xml、sys_remote_update_setテーブルへのアクセス
• 環境： 適切に構成されたインスタンス接続（自動取得の場合）
• 関連スキル： 先にadmin/update-set-managementを完了してください

デプロイパイプラインの概要

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│     DEV     │────►│    TEST     │────►│    PROD     │
│  (develop)  │     │  (validate) │     │  (release)  │
└─────────────┘     └─────────────┘     └─────────────┘
      │                   │                   │
      ▼                   ▼                   ▼
   Create             Preview              Preview
   Update Set         & Test               & Commit
   Complete           Commit               Validate
   Export             Validate

手順

フェーズ1：デプロイ前の検証

ステップ1.1：更新セットの内容を確認する

デプロイ前に、デプロイ対象の内容を十分に確認します。

MCPを使用する場合：

Tool: SN-Inspect-Update-Set
Parameters:
  update_set_sys_id: [your_update_set_sys_id]
  instance: dev

詳細な内容のクエリ：

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_xml
  query: update_set=[update_set_sys_id]
  fields: name,type,target_name,action,sys_created_on,sys_created_by
  limit: 500
  instance: dev

想定される内容の分類：

種類	件数	説明
sys_script	5	ビジネスルール
sys_ui_policy	3	UIポリシー
sys_script_include	2	スクリプトインクルード
sys_ui_action	1	UIアクション

ステップ1.2：構成の品質を検証する

よくあるデプロイ上の問題がないか確認します。

スクリプトの検証：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var updateSetId = '[update_set_sys_id]';
    var issues = [];

    // Check for hardcoded sys_ids (potential issue)
    var gr = new GlideRecord('sys_update_xml');
    gr.addQuery('update_set', updateSetId);
    gr.addQuery('payload', 'CONTAINS', 'sys_id');
    gr.query();

    while (gr.next()) {
      if (gr.payload.indexOf("'32") > -1 || gr.payload.indexOf('"32') > -1) {
        issues.push('Potential hardcoded sys_id in: ' + gr.name);
      }
    }

    // Check for instance-specific URLs
    var gr2 = new GlideRecord('sys_update_xml');
    gr2.addQuery('update_set', updateSetId);
    gr2.addQuery('payload', 'CONTAINS', '.service-now.com');
    gr2.query();

    if (gr2.getRowCount() > 0) {
      issues.push('WARNING: ' + gr2.getRowCount() + ' records contain instance-specific URLs');
    }

    gs.info('Validation Issues: ' + JSON.stringify(issues));
  description: Pre-deployment validation check
  instance: dev

ステップ1.3：依存関係を文書化する

更新セットの依存関係を特定し、文書化します。

関連する更新セットを確認する：

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_set
  query: parent=[update_set_sys_id]^ORbase_update_set=[update_set_sys_id]
  fields: name,sys_id,state,description
  instance: dev

依存関係の文書化テンプレート：

UPDATE SET: PROJ123-FEAT-CustomerPortal-v1
DEPENDS ON:
  1. PROJ123-BASE-TableSchema-v1 (must be deployed first)
  2. PROJ123-DATA-ReferenceData-v1 (required reference data)
CONFLICTS WITH:
  - None identified
NOTES:
  - Requires system property: com.glide.custom.portal.enabled=true

フェーズ2：更新セットのエクスポート

ステップ2.1：更新セットを完了する

エクスポート前に、更新セットが完了としてマークされていることを確認します。

MCPを使用する場合：

Tool: SN-Update-Record
Parameters:
  table_name: sys_update_set
  sys_id: [update_set_sys_id]
  data:
    state: complete
  instance: dev

ステップ2.2：バックアップ用に複製する（推奨）

デプロイ前にバックアップ用の複製を作成します。

MCPを使用する場合：

Tool: SN-Clone-Update-Set
Parameters:
  source_update_set_sys_id: [update_set_sys_id]
  new_name: "PROJ123-FEAT-CustomerPortal-v1-BACKUP-20260206"
  instance: dev

ステップ2.3：エクスポート方法

方法A：XMLエクスポート（手動）

1. System Update Sets → Local Update Setsに移動します
2. 更新セットを開きます
3. Related Links → Export to XMLを選択します
4. XMLファイルを保存します

方法B：リモートインスタンスからの自動取得 インスタンスが接続されている場合：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var source = new GlideRecord('sys_update_set_source');
    source.get('name', 'Development Instance');

    var updateSet = '[update_set_name]';
    // Trigger retrieval via update set source
    gs.info('Retrieval must be initiated from target instance UI');
  description: Check update set source configuration
  instance: test

フェーズ3：ターゲットインスタンスへのインポート

ステップ3.1：更新セットをインポートする

方法A：XMLインポート（手動）

1. ターゲットインスタンスで、System Update Sets → Retrieved Update Setsに移動します
2. Import Update Set from XMLを選択します
3. エクスポートしたXMLファイルを選択します
4. Uploadをクリックします

方法B：リモート取得（接続済みインスタンス）

1. ターゲットインスタンスで、System Update Sets → Update Sourcesに移動します
2. ソースインスタンスを選択します
3. Retrieve Update Setsをクリックします
4. 取得する更新セットを選択します

ステップ3.2：インポートの成功を確認する

取得した更新セットを確認する：

Tool: SN-Query-Table
Parameters:
  table_name: sys_remote_update_set
  query: name=[update_set_name]
  fields: name,state,remote_sys_id,description,collision_count
  instance: test

状態：

状態	意味
Loaded	プレビューの準備完了
Previewing	プレビューを実行中
Previewed	コミットの準備完了
Committing	コミットを実行中
Committed	正常に適用済み
Error	失敗 — ログを確認してください

フェーズ4：プレビューと競合解決

ステップ4.1：更新セットをプレビューする

プレビューにより、コミット前に潜在的な競合を特定できます。

プレビューを開始する（手動）：

1. 取得した更新セットを開きます
2. 「Preview Update Set」をクリックします
3. プレビューが完了するまで待ちます

プレビューの状態を確認する：

Tool: SN-Query-Table
Parameters:
  table_name: sys_remote_update_set
  query: name=[update_set_name]
  fields: name,state,collision_count,error_count
  instance: test

ステップ4.2：競合を分析する

プレビューの問題をクエリする：

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_preview_problem
  query: remote_update_set=[remote_update_set_sys_id]
  fields: description,type,status,disposition
  limit: 100
  instance: test

競合の種類と解決方法：

種類	説明	解決方法
衝突	ターゲットで同じレコードが変更されています	どちらのバージョンを保持するか選択します
参照先が見つからない	参照先のレコードが存在しません	依存関係を作成するか、スキップします
検証エラー	スクリプトまたは構成の検証に失敗しました	ソースを修正して再エクスポートします
権限の問題	変更に必要な権限が不足しています	必要な権限を付与します

ステップ 4.3：競合を解決する

競合の場合 — リモートを採用（ソースを優先）：

Tool: SN-Update-Record
Parameters:
  table_name: sys_update_preview_problem
  sys_id: [problem_sys_id]
  data:
    disposition: Accept remote update
  instance: test

競合の場合 — スキップ（ターゲットを優先）：

Tool: SN-Update-Record
Parameters:
  table_name: sys_update_preview_problem
  sys_id: [problem_sys_id]
  data:
    disposition: Skip remote update
  instance: test

一括解決スクリプト：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var remoteSetId = '[remote_update_set_sys_id]';

    // Accept all remote updates (source wins for all)
    var gr = new GlideRecord('sys_update_preview_problem');
    gr.addQuery('remote_update_set', remoteSetId);
    gr.addQuery('disposition', '');  // Unresolved only
    gr.query();

    var count = 0;
    while (gr.next()) {
      gr.disposition = 'Accept remote update';
      gr.update();
      count++;
    }
    gs.info('Resolved ' + count + ' conflicts by accepting remote updates');
  description: Bulk resolve conflicts - accept remote
  instance: test

フェーズ 5：更新セットをコミットする

ステップ 5.1：最終検証

コミットする前に、すべての競合が解決されていることを確認してください。

未解決の問題を確認する：

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_preview_problem
  query: remote_update_set=[remote_update_set_sys_id]^dispositionISEMPTY
  fields: description,type
  instance: test

件数が 0 より大きい場合は、先にすべての問題を解決してください。

ステップ 5.2：更新セットをコミットする

コミット（手動）：

1. 取得した更新セットを開きます
2. 状態が「Previewed」で、未解決の競合がないことを確認します
3. 「Commit Update Set」をクリックします
4. 進行状況を監視します

コミットの成功を確認する：

Tool: SN-Query-Table
Parameters:
  table_name: sys_remote_update_set
  query: name=[update_set_name]
  fields: name,state,committed_on,committed_by
  instance: test

想定される状態：「Committed」

フェーズ 6：デプロイ後の検証

ステップ 6.1：デプロイされたレコードを確認する

コミットされた変更を確認する：

Tool: SN-Query-Table
Parameters:
  table_name: sys_update_version
  query: source_update_set=[remote_update_set_sys_id]
  fields: name,type,state,action
  limit: 100
  instance: test

ステップ 6.2：機能テスト

テストチェックリストを作成する：

Tool: SN-Create-Record
Parameters:
  table_name: sys_user_task
  data:
    short_description: "Post-Deployment Testing: [update_set_name]"
    description: |
      Deployment Validation Checklist:

      [ ] Business Rules execute correctly
      [ ] UI Policies display/hide fields correctly
      [ ] ACLs enforce proper access
      [ ] Forms render without errors
      [ ] Scripts run without errors
      [ ] Integration points functional
      [ ] No console errors in browser
    assigned_to: [tester_sys_id]
    priority: 2
  instance: test

ステップ 6.3：システムログを監視する

デプロイ後にエラーがないか確認する：

Tool: SN-Query-Table
Parameters:
  table_name: syslog
  query: level=2^sys_created_on>javascript:gs.hoursAgo(1)
  fields: message,source,sys_created_on
  limit: 50
  instance: test

フェーズ 7：ロールバック手順

ステップ 7.1：ロールバックするタイミング

ロールバックの判断基準：

• 重要な機能が動作しない
• システムのパフォーマンスが低下した
• ログに予期しないエラーがある
• ビジネスプロセスに障害が発生した

ステップ 7.2：即時ロールバックの選択肢

オプション A：個別のレコードを取り消す

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var remoteSetId = '[remote_update_set_sys_id]';

    // Get all versions from this update set
    var gr = new GlideRecord('sys_update_version');
    gr.addQuery('source_update_set', remoteSetId);
    gr.query();

    gs.info('Found ' + gr.getRowCount() + ' records to potentially back out');

    // List records for review
    while (gr.next()) {
      gs.info('Record: ' + gr.name + ' | Type: ' + gr.type + ' | Action: ' + gr.action);
    }
  description: List records from committed update set for rollback planning
  instance: test

オプション B：以前のバージョンに戻す

個別のレコードについては、sys_update_version を使用して復元します：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var recordSysId = '[record_to_revert_sys_id]';
    var tableName = '[table_name]';

    // Find previous version
    var version = new GlideRecord('sys_update_version');
    version.addQuery('name', tableName + '_' + recordSysId);
    version.orderByDesc('sys_recorded_at');
    version.setLimit(2);  // Current and previous
    version.query();

    version.next();  // Skip current
    if (version.next()) {
      gs.info('Previous version found from: ' + version.sys_recorded_at);
      // Restore would require loading the payload
    } else {
      gs.info('No previous version found');
    }
  description: Find previous version for rollback
  instance: test

オプション C：バックアップクローンを使用して全体をロールバックする

バックアップクローンを作成している場合：

1. バックアップの更新セットをデプロイします
2. 競合によって以前のバージョンに復元されます

ステップ 7.3：ロールバックを記録する

Tool: SN-Create-Record
Parameters:
  table_name: sys_update_set
  data:
    name: "ROLLBACK-PROJ123-FEAT-CustomerPortal-v1-20260206"
    description: |
      ROLLBACK RECORD

      Original Update Set: PROJ123-FEAT-CustomerPortal-v1
      Deployed: 2026-02-06 14:00 UTC
      Rolled Back: 2026-02-06 16:30 UTC

      Reason: [Document the failure reason]

      Records Affected:
      - [List affected records]

      Resolution:
      - [Document fix approach]
    state: complete
  instance: test

デプロイチェックリスト

デプロイ前

• 更新セットをレビューし、内容を検証した
• ハードコードされた sys_ids やインスタンス URL がない
• 依存関係を特定し、記録した
• バックアップクローンを作成した
• 変更リクエストの承認を得た（必要な場合）

デプロイ中

• 更新セットを正常にインポートした
• エラーなしでプレビューが完了した
• すべての競合をレビューし、解決した
• コミットが正常に完了した

デプロイ後

• コミットされたすべてのレコードを確認した
• 機能テストが完了した
• システムログに新たなエラーがない
• 関係者にデプロイを通知した
• ドキュメントを更新した

ツールの使用概要

操作	MCP ツール	目的
調査	SN-Inspect-Update-Set	更新セットの内容を確認する
クローン	SN-Clone-Update-Set	デプロイ前にバックアップを作成する
レコードの移動	SN-Move-Records-To-Update-Set	誤ったセットにあるレコードを修正する
クエリ	SN-Query-Table	状態と競合を確認する
更新	SN-Update-Record	競合を解決し、状態を更新する
スクリプト	SN-Execute-Background-Script	複雑な検証とロールバックを行う

ベストプラクティス

• 必ず最初にプレビューする： プレビューせずにコミットしないでください
• バックアップを作成する： 大規模なデプロイの前に更新セットをクローンしてください
• すべてを記録する： すべての判断と競合の解決内容を記録してください
• 十分にテストする： 各環境で機能テストを完了してください
• 順序どおりにデプロイする： DEV → TEST → PROD のパイプラインに厳密に従ってください
• 適切なタイミングを選ぶ： 利用の少ない時間帯にデプロイしてください
• ロールバック計画を用意する： デプロイ前に元に戻す方法を把握してください
• 関係者に通知する： デプロイの時間帯と状況を伝えてください

トラブルシューティング

プレビューが停止する、またはタイムアウトする

原因： 更新セットが大きい、または依存関係が複雑 解決策：

1. 更新セットを小さな単位に分割します
2. システムジョブのタイムアウトを延長します
3. 業務時間外にプレビューをスケジュールします

エラーによりコミットに失敗する

原因： スクリプトの検証エラー、または依存関係の不足 解決策：

1. ログのエラーメッセージを確認します
2. ソースインスタンスで問題を修正します
3. 更新セットを再エクスポートし、再インポートします

コミット後に参照先が見つからない

原因： 参照先のレコードが更新セットに含まれていない 解決策：

1. 不足しているレコードを別の更新セットでエクスポートします
2. データレコードには Data Preservers を使用します
3. 依存関係を含む更新セットを先にデプロイします

デプロイ後のパフォーマンス低下

原因： デプロイしたコード内の非効率なスクリプトやクエリ 解決策：

1. ビジネスルールとスクリプトインクルードを確認します
2. ループ内に不要なクエリがないか確認します
3. 新しいフィールドに適切なインデックスを追加します
4. 重大な場合はロールバックを検討します

関連スキル

• admin/update-set-management - 更新セットの作成と管理
• admin/batch-operations - デプロイ時のレコード一括操作
• admin/script-execution - 検証のためのバックグラウンドスクリプト実行
• itsm/change-management - 本番環境へのデプロイにおける変更プロセス

参考資料

• ServiceNow 更新セット
• 取得した更新セット
• プレビューとコミット