规划升级{ #planning-upgrades }¶

负责 DHIS2 系统的实体（如卫生部的 HMIS 部门）应制定明确的系统升级政策，以及描述*如何*进 行升级的书面 SOP（见SOP 部分）。其中一部分工作应是定义一个总的升级日程表，描述关键活动通常应在何时进行（见下文升级日程表部分）。

对于每个升级周期，都应根据当前情况和升级的特殊性制定详细的计划和时间表。一次升级可能需要与集成或定制应用程序相关的开发工作，这需要在计划中加以考虑。另一次升级可能涉及面向用户的更改，需要一定程度的培训，或许必须与其他活动协调进行（例如，许多用户已在同一地点的季度审查会议）。

在高层次上，升级计划应包括这些活动：

1. 评估更改
2. 预算和日历
3. [元数据清理]（#upgrade-metadata_cleaning）（重要，可选）
4. [测试]（#升级测试）
5. [进行修改]（#升级进行必要的修改）
6. 交流与培训
7. 将升级应用于生产

美人鱼 流程图 TD A[启动升级周期] → B[评估变化］ B→D[预算和日历］ D → C[元数据清理]:::可选 D→E[测试］ C → E E→F[进行必要的修改］ F→G[交流与培训］ G→H[实施：升级执行］ H→I[升级后支持和审查］ I→J[结束］

子图 测试详情
  E1[应用程序测试］
  E2[用户角色测试］
  E3[集成］
  E4[性能］
  E-->E1
  E-->E2
  E-->E3
  E --> E4
结束

Beta[Beta 测试]::可选
Beta -.-> E

子图修改
  F1[元数据修改］
  F2[应用程序和集成］
  F --> F1
  F --> F2
结束

classDef 可选 stroke-dasharray：5 5;

```

评估变化{ #upgrade-evaluating_changes }¶

在发布新版本时，必须仔细阅读与该版本相关的文档。访问这些文档最直接的方式是通过 dhis2.org/downloads，每个支持的版本都有相关文档的链接： * 发布说明**概述了发布版本中的所有变更，并提供了指向特定 jira 票据和文档部分的相关链接。每个主要版本、补丁和热修复版本都有单独的发布说明文档。 * **升级说明**为发布和升级过程提供了详细的技术信息和要求，例如强调了支持 java 或 postgresql 版本的变化、数据库表或 API 端点的重命名可能会影响自定义脚本和集成等。这对于在服务器上计划和执行实际升级的人员至关重要，但对于 DHIS2 核心团队的其他成员也很重要。 * **功能概述**是一个永久链接，可链接到随主要版本（如 v40 或 v41）发布的发行说明，其中列出了该主要版本的新功能（包括发行说明，对于补丁和热修补版本，发行说明仅列出已解决的小改动和错误）。 * (待定） **废弃功能 列出了主要版本中已废弃的特定功能、特性和 API 端点。 每次升级，特别是升级到新的主要版本时，这些文件都需要由支持升级过程的核心团队进行审核。如果要升级多个版本（如从 2.39 升级到 v41），则必须审核每个版本的文件。并非所有的变更都与每次实施相关，但那些可能与特定系统相关的变更都应记录在案。在此基础上，可以制定如何管理变更的计划。 可以将变化分为三大类，并以不同的方式加以解决： 1. 直接影响最终用户的变化 这类变更包括影响最终用户与系统交互方式的变更。这包括必须使用全新的应用程序进行核心活动（即从 Pivot Table 到 Data Visualizer 或从 Tracker Capture 到 Capture），也包括对用户界面的较小改动。 在此，考虑受影响的用户类型非常重要。绝大多数用户通常只使用几个应用程序进行数据录入和/或分析，在许多方面影响到这些用户的变化会产生最大的影响和后果。其他应用程序的用户数量相对较少，通常仅限于核心国家工作人员（如卫生部），为这部分用户提供指导甚至额外培训要便宜得多，也容易得多。 负责升级的核心团队必须考虑到这一类的相关变化，考虑到潜在的后果，以及应计划什么样的活动，以确保最终用户可以继续使用系统，并将中断时间减少到最低限度。好的做法是在升级前向所有用户发出通知，告知他们何时升级、升级后会有哪些变化，并提醒他们遇到问题时如何获得支持。对于较小的变化，这可能足以解决最终用户可见的变化。 当出现较大变化时，可能需要进行更全面的沟通和培训。这方面的例子包括 * 制作简短的手册或工作辅助工具，解释这些变化 * 组织网络研讨会和/或提供视频演示 * 面对面培训或指导，可能与其他活动相衔接 核心小组必须根据变化和当地情况确定其中哪些是相关的。 2. ** 应用程序或数据库模式更改** * 更改应用程序接口或 * 任何可能受影响的集成或自定义应用程序/工具 这些变化要求对受影响的应用程序和/或工具进行计划验证和可能的修订。 3. 配置更改 配置更改是在升级过程中引入的更改，需要核心管理员团队对 DHIS2 元数据配置进行更改，以确保系统继续按预期运行。因此，终端用户不会直接看到这些变更，除非这些变更没有得到解决，系统停止运行。这类更改并不常见，因为大多数情况下都是在升级过程中自动处理的，但偶尔也会发生。

元数据清理{ #upgrade-metadata_cleaning }¶

随着时间的推移，随着配置的修改和修正，DHIS2 元数据中可能会出现完整性问题。这些完整性问题并不总是立即可见，但可能会在升级过程中造成问题。例如，它们可能导致自动数据库迁移失败，或使应用程序中元数据的获取和呈现失败。因此，作为任何重大版本升级的第一步，审查并修复元数据完整性问题是一个很好的做法。元数据完整性]() 部分介绍了如何执行此操作。尤其是元数据完整性检查强调为*关键*或*严重*的问题，应在升级前解决；标注为*警告*的完整性检查通常不会对升级造成问题。

测试{ #upgrade-testing }¶

测试通常是最耗时也是最重要的步骤，将在单独的测试部分中详细阐述，该部分涵盖了这两个步骤。

进行必要的修改{ #upgrade-making_necessary_modifications }¶

这包括对评估阶段确定的所需修改采取行动。修改通常分为两大类： * 元数据修改：可能需要更改 DHIS2 配置本身，以确保与新版本兼容。如前所述，在升级过程中不自动应用必要更改的情况非常罕见。升级说明以及测试活动的结果是例外情况的主要来源。 * 应用程序和集成：任何自定义应用程序、脚本或与其他系统的集成都可能需要更新： * 审查和更新应用程序接口调用，以使用最新的端点 * 测试和更新定制应用程序以确保兼容性 * 修改集成脚本，以处理数据结构的任何变化 * 如果安全要求发生变化，更新验证方法 如果需要从第三方采购，提前规划这些修改阶段尤为重要。

交流与培训{ #upgrade-communication_and_training }¶

有效的沟通和培训是重大升级成功的关键；当推出重大变革时。这涉及几个关键方面： 传播战略：
* 制定明确的沟通计划，使所有利益相关者都能参与其中 * 向卫生部和其他主要机构发出正式通知 * 提前向所有系统用户通报计划停机时间 * 创建变更时间表并与受影响的用户共享 * 在升级过程中和升级后建立明确的支持和反馈渠道 用户通知应包括：
* 计划升级的日期和时间 * 预计系统停机时间 * 用户将经历的主要变化列表 * 他们可以期待的新功能或改进 * 如果遇到问题，到哪里寻求帮助 * 支持联系信息 培训考虑因素：
在对当前版本与升级过程中引入的版本之间的变化进行评估的基础上，需要对不同用户群的潜在培训要求做出决定。 培训方法的例子包括 * 现场研讨会/培训 * 小更新在线网络研讨会 * 自定进度的学习材料 * 快速参考指南或工作辅助工具 一般来说，面对面培训比任何虚拟/在线培训的成本都要高得多，尽管任何这些方法都 至少需要投入一些工作人员的时间。不过，有时也有机会利用现有活动来降低成本，这些都应加以考虑。例如，如果有将相关用户召集在一起的例行数据审查会议，就有可能在即将进行的升级中增加一 次会议，审查已发生变化的功能。同样，如果有定期复习培训的机制，也可以介绍即将发生的变化。 一般来说，在规划培训时，您需要考虑以下方面的预算影响： * 培训地点和后勤 * 培训者和参与者的差旅费 * 编写培训材料 * 工作人员的准备和交付时间 文件和培训资源
包括面向用户的更改在内的升级可能需要开发专门的培训资源，但也意味着要更新现有的培训资源和文档。这包括 * 更新用户手册 * 为新功能开发快速参考指南 * 录制常见任务的视频教程 * 为实践学习准备实际练习 * 考虑为可持续能力建设制定培训员培训计划

主要考虑因素{ #key-considerations }¶

成本和时间是上述所有问题的两个重要方面。这两个方面都需要仔细考虑。

预算编制{ #budgeting }¶

在计划升级时，需要考虑几个成本组成部分并编制预算： 培训和文件费用： * 编制培训材料和用户指南 * 印刷和分发文件 * 任何面对面培训课程的地点和后勤安排 * 教员和学员的每日津贴和差旅费 * 工作人员准备和开展培训的时间 技术更新： * 开发人员更新定制应用程序和工具的时间 * 修改现有集成 * 更新脚本和自动流程 * 必要的技术援助费用 测试资源： * 工作人员用于综合测试的时间 * 测试阶段的额外服务器资源 * 测试所需的工具或软件 * 测试计划协调时间 基础设施： * 测试服务器的设置和维护 * 测试环境的额外存储空间 * 备份系统和存储 * 如果新版本需要，可能进行硬件升级 支助和应急： * 过渡期间的服务台或支持人员 * 意外技术问题的缓冲 * 应急小组的可用性 * 必要时进行回滚准备

制作升级日历{ #making_an_upgrade_calendar }¶

结构合理的升级日历有助于组织升级流程，确保所有利益相关者保持一致。下面介绍如何操作： 年度规划： 升级通常不是一次性的，而是需要定期进行。特别是，您可能希望 * 将重大升级安排在活动较少的时段进行 * 与财政年度/报告年度要求保持一致 * 考虑国定假日和重大健康活动 * 计划全年定期更新补丁 时间表组成部分： 主要版本升级和补丁升级的时间表和活动强度有很大不同。以下是典型阶段和持续时间的比较： | 相 | 活动 | 主要版本 | 补丁版本 | |-------|------------|---------------|---------------| | 规划 | - 初步评估
- 利益攸关方磋商
- 资源分配
- 元数据清理 | 1-2 个月
要求 | 1-2 周
常规 | | 发展 | - 技术准备
- 更新定制解决方案
- 文档更新 | 1-3 个月
要求 | 1-2 周
如有需要 | | 测验 | - 系统测试
- 用户验收测试
- Beta 测试计划 | 1-2 个月
要求 | 1-2 周
建议 | | 训练 | - 材料准备
- 培训课程
- 用户指导 | 1-2 个月
要求 | 通常不需要 | | 实施情况 | - 最终备份
- 升级执行
- 初始监控 | 1-2 周
要求 | 1-2 天
要求 | | 升级后 | - 加强支持期
- 性能监测
- 问题解决 | 1 个月
要求 | 1 周
建议 | 美人鱼

config： theme: default gantt： titleTopMargin: 15 fontSize: 20 sectionFontSize: 24 条形图高度： 40 leftPadding：250 numberSectionStyles: 2 gridLineStartPadding：50

甘特图 标题 升级时间线比较（周） 日期格式 w axisFormat %W tickInterval 4weeks 节 主要版本 规划 :maj1，2024-01-01，2M 开发 :maj2, after maj1, 3M 测试 :maj3, 2024-05-01, 2M 培训 :maj4, 2024-06-01, 1M 实施 :crit, maj5, after maj4, 2w 升级后 :maj6, after maj5, 1M 部分 补丁版本 规划 :pat1, 2024-01-01, 1w 开发 :pat2, 在 pat1 之后, 1w 测试 :pat3, 在 pat1 之后, 2w 实施 :pat4, pat3 之后, 2d 升级后 :pat5, 之后 pat4, 1w 部分 热修复 测试 :hot1, 2024-01-01, 1d 执行 :crit, hot4, after hot1, 1d ```

注

主要版本升级涉及重大变更，需要彻底执行所有阶段的工作 补丁升级主要集中在错误修复和安全更新上，需要的准备和测试工作较少。如果跳转多个补丁版本，风险和持续时间会增加，而如果保持最新的补丁版本，风险和持续时间会减少。 热修补程序通常可以快速应用，风险极小；但应根据具体情况进行评估。 实际持续时间可能因系统复杂性、定制化和可用资源而异

成功秘诀：

• 为突发问题预留缓冲时间
• 考虑不同阶段之间的依赖关系
• 说明审批程序和行政要求
• 包括定期检查点和进度审查
• 在每个重要里程碑制定交流计划