1. 课程导入与全景认知

ThingWorx 作为工业物联网应用平台，其升级迁移并不是一次简单的“安装包替换”。在真实项目中，升级往往同时牵动平台内核、扩展包、自定义服务、数据库结构、设备连接、身份认证与前端 Mashup 等多个层面。版本治理则是在升级前后持续保证“可追溯、可回退、可复现”的工程能力。本课程的目标，是让学员建立一套从版本盘点、兼容性评估、迁移实施到回退验证的完整方法论，而不是记住某一条命令。

一、学习目标与核心概念

完成本课程后，学员应能独立完成以下任务：识别当前 ThingWorx 版本与目标版本之间的差异；梳理平台内所有扩展、自定义实体与外部依赖；制定升级顺序与停机窗口；执行数据库与配置的备份；在测试环境完成迁移演练；对升级结果进行功能与性能验证；并在出现异常时按预案回退。核心概念包括：平台版本号语义、扩展包（Extension）兼容矩阵、实体导入导出、数据库 Schema 变更、集群节点滚动升级、以及版本基线（Baseline）。

需要特别区分三个容易混淆的概念：升级（Upgrade）指在同一大版本内提升小版本或补丁；迁移（Migration）指跨大版本或跨部署形态（如单机到集群、本地到容器）的转移；版本治理（Version Governance）则是贯穿始终的管理机制，包括版本命名、变更记录、依赖锁定与发布审批。三者关系可以用下面的全景图来理解。

二、整体框架：三条主线并行

从上面的全景图可以看到，整个工作可以拆成三条并行主线。第一条是治理线，负责版本基线、依赖锁定、审批与追溯，它像一条“约束带”贯穿始终；第二条是实施线，即从现状盘点到回退固化的七个环节，是实际动手的部分；第三条是风险线，把扩展兼容、Schema 变更、自定义服务、停机窗口、回退一致性等典型挑战显式暴露出来，提醒我们在每个环节提前设防。

很多团队失败的原因，是把注意力全部放在“实施线”上，而忽略了治理线和风险线。例如，升级前没有登记当前扩展包的确切版本，升级后某个驱动无法加载，却无法判断是升级导致还是原本就有问题；又如，没有在测试环境演练数据库迁移脚本，生产升级时 Schema 变更失败，只能被迫回退，而此时已有新数据写入，回退后数据不一致。因此，本课程会反复强调：治理先行、风险前置、演练充分。

三、典型挑战与应对思路

下面用一张对照表梳理常见挑战及其应对方向，便于在实际项目中快速定位。

四、一个可参考的版本基线登记示例

版本治理的起点是“知道自己现在有什么”。下面给出一个版本基线登记表的示例，字段可根据实际项目增减。示例中的版本号与日期均为教学假设，不代表真实环境。

【ThingWorx 版本基线登记表 · 示例】
登记日期：2025-03-10        登记人：平台运维组
当前平台版本：9.4.0          目标版本：9.6.2
数据库：PostgreSQL 13.4      部署形态：3 节点集群

扩展包清单：
  - IndustrialConnection 9.4.1   → 目标 9.6.0（需确认兼容）
  - KepwareServer 9.4.0          → 目标 9.6.0
  - CustomAuth 1.2.0（自研）     → 需重新编译，依赖 SDK 9.6

自定义实体：
  - Thing 模板 42 个
  - Thing 实例 1860 个
  - 服务 315 个（其中脚本服务 88 个）
  - Mashup 76 个

外部依赖：
  - LDAP 目录服务
  - MQTT Broker（EMQX 5.x）
  - 历史数据库（PostgreSQL 只读账号）

风险备注：
  - CustomAuth 扩展使用已弃用 API，升级后需替换
  - 脚本服务中有 6 个调用了旧版日期函数，需回归测试

这份登记表的价值在于：它把“升级”从一次模糊的操作，变成了一次有清单、有对比、有风险标注的工程活动。升级前，团队可以据此逐项确认；升级后，可以据此逐项验证。没有这份基线，后续的兼容性评估和回退预案都无从谈起。