deployment-workflow

部署工作流

概述

此技能提供了在 ServiceNow 实例之间部署配置（Dev → Test → Prod）的完整框架，涵盖部署的整个生命周期：

• 部署前验证与准备
• 更新集导出与导入流程
• 预览与冲突解决策略
• 部署后验证
• 部署失败时的回滚流程

适用场景： 在 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. 从 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

冲突类型及解决方法：

类型	描述	解决方法
Collision	目标实例中的同一记录已被修改	选择要保留的版本
Missing Reference	引用的记录不存在	创建依赖项或跳过
Validation Error	脚本/配置验证失败	修复源配置并重新导出
Permission Issue	权限不足，无法进行修改	授予所需权限

步骤 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 更新集
• 已检索的更新集
• 预览并提交