升级私有云Odoo数据库

升级私有云Odoo数据库会十分有挑战性，尤其是当您的数据库包含自定义模块时。本章旨在解释升级包含自定义模块的数据库的技术流程。有关如何升级不包含自定义模块的数据库的指导，请参阅 升级文档 。

自定义模块，是指任何扩展Odoo标准的代码的模块， 它们不使用Odoo Studio来创建。在升级此类模块之前，或在请求升级之前，请查看 服务水平协议（SLA） 以确保了解谁负责它。

在您在进行私有的Odoo，即 自定义升级 数据库中工作时，请务必记住升级的目标：

  1. 持续性运营保障与技术支持

  2. 获取最新功能

  3. 享受性能提升

  4. 减少技术债务

  5. 享受安全改进

随着每个新版本的Odoo的发布，都会引入一些更改。这些更改可能会影响已开发自定义功能的模块。这就是为什么升级包含自定义模块的数据库需要额外步骤来升级源代码的原因。

这些是升级自定义数据库的步骤：

  1. 停止开发并停止配置。

  2. 请求升级数据库。

  3. 使您的模块可安装在空数据库上。

  4. 使您的模块可安装在升级后的数据库上。

  5. 广泛测试并进行演练 。

  6. 升级生产数据库 。

步骤 1：停止开发

开始升级需要承诺和开发资源。如果在同一时间继续进行开发，则每次更改它们时，都需要重新升级和测试这些功能。这就是为什么我们建议在开始升级过程时完全冻结代码库。不用说，修复错误不受此建议的限制。

停止开发后，评估所做的开发并将其与当前版本和目标版本之间引入的功能进行比较是一种良好的做法。尽可能挑战开发并寻找功能变通方法。消除您的开发与Odoo标准版本之间的冗余将简化升级过程并减少技术债务。

Note

您可以在 发行说明 中找到有关版本之间更改的信息。

步骤 2：请求升级数据库

一旦自定义模块的开发停止，并且实施的功能已被挑战以消除冗余和不必要的代码，下一步就是请求升级测试数据库。为此，请按照 获取升级后的测试数据库 中提到的步骤，具体取决于您的数据库的托管类型。

此阶段的目的不是开始在升级后的数据库中使用自定义模块，而是确保标准升级过程顺利进行，并且测试数据库正确交付。如果不是这种情况，并且升级请求失败，请通过选择与测试升级相关的选项，通过 支持页面 请求Odoo官方的协助。

步骤 3：空数据库

在处理升级后的测试数据库之前，我们建议使自定义开发在升级目标版本的空数据库上工作。这确保了自定义与Odoo新版本的兼容性，允许分析其在新功能中的行为和交互，并保证它们在升级数据库时不会引起任何问题。

使自定义模块在空数据库中工作还有助于避免生产数据库中可能存在的更改和错误配置(如Studio自定义、定制的网站页面、电子邮件模板或翻译)。它们与自定义模块本质上无关，并且可能在升级过程的此阶段引发不必要的问题。

要使自定义模块在空数据库上工作，我们建议遵循以下步骤：

  1. 使自定义模块可安装

  2. 测试和修复

  3. 清理代码

  4. 使标准测试成功运行

使自定义模块可安装

第一步是使自定义模块在新的Odoo版本中可安装。这意味着，首先确保在安装过程中没有回溯或警告。为此，在新Odoo版本的空数据库中逐个安装自定义模块，并修复由此产生的回溯和警告。

此过程将有助于检测模块安装期间的问题。例如：

  • 模块依赖关系无效。

  • 语法更改：资产声明、OWL更新、attrs。

  • 对不再存在或已重命名的标准字段、模型、视图的引用。

  • Xpath移动或已从视图中删除。

  • 方法已重命名或已删除。

  • …

测试和修复

一旦安装模块时不再出现回溯，下一步就是测试它们。即使自定义模块可以安装在空数据库上，这也不能保证在执行过程中没有错误。因此，我们鼓励彻底测试所有自定义功能以确保一切按预期工作。

此过程将有助于检测在模块安装过程中未识别的问题，这些问题只能在运行时检测到。例如，对标准Python或OWL函数的弃用调用，对标准字段的不存在的引用等。

我们建议测试所有自定义功能，特别是以下元素：

  • Views

  • 邮件模板

  • 报表

  • 服务器动作和自动化动作

  • 标准工作流程的更改

  • 计算字段

我们还鼓励编写自动化测试，以节省测试迭代的时间，增加测试覆盖率，并确保引入的更改和修复不会破坏现有流程。如果自定义功能中已经实现了测试，请确保它们已升级到新的Odoo版本并成功运行，修复可能存在的问题。

清理代码

在升级过程的此阶段，我们还建议尽可能清理代码。这包括：

  • 删除多余和不必要的代码。

  • 删除现在是Odoo标准一部分的功能，如 步骤 1：停止开发 中所述。

  • 清理注释代码，如果不再需要。

  • 重构代码（函数、字段、视图、报表等）如果需要。

标准测试

完成前面的步骤后，我们建议确保通过与自定义模块的依赖项相关联的所有标准测试。

如果有标准测试失败，我们建议分析其失败的原因：

  • 自定义功能更改了标准工作流程：适应标准测试以适应您的工作流程。

  • 自定义功能没有考虑特殊流程：调整您的自定义功能以确保其适用于所有标准工作流程。

步骤4：升级数据库

一旦自定义模块可以安装并在空数据库中正常工作，就该使它们在 升级后的数据库 上工作了。

为了确保自定义代码在新版本中完美运行，请遵循以下步骤：

迁移数据

在自定义模块的升级过程中，您可能需要使用 升级脚本 将源代码的更改反映到其对应的数据中。除了升级脚本之外，您还可以使用 Upgrade utils 及其辅助函数。

  • 在自定义代码升级过程中重命名的任何技术数据（模型、字段、外部标识符）都应使用升级脚本重命名，以避免在模块升级过程中丢失数据。另请参见： rename_field() ， rename_model() ， rename_xmlid() 。

  • 在标准升级过程中从较新Odoo版本的源代码和数据库中删除的标准模型的数据，如果仍然存在，可能需要从旧模型表中恢复。

    Example

    从Odoo 15到Odoo 16（当模型合并到 sale.order 时），模型 sale.subscription 的自定义字段不会自动迁移。在这种情况下，可以在升级脚本上执行SQL查询，将数据从一个表移动到另一个表。请考虑到所有列/字段必须已经存在，因此请考虑在 post- 脚本中执行此操作（请参阅 Phases of upgrade scripts ）。

    def migrate(cr, version):
   cr.execute(
      """
      UPDATE sale_order so
         SET custom_field = ss.custom_field
        FROM sale_subscription ss
       WHERE ss.new_sale_order_id = so.id
      """
   )

    有关更多信息，请查看文档： Upgrade scripts 。

升级脚本也可以用于：

  • 简化升级的处理时间。例如，通过使用SQL查询存储具有大量记录的模型上计算的存储字段的值。

  • 重新计算字段，以防其值的计算已更改。另请参见： :meth：recompute_fields 。

  • 卸载不需要的定制模块。另请参见： remove_module() 。

  • 纠正错误数据或错误的配置。

运行和测试升级脚本

由于不允许在Odoo Online数据库上安装包含Python文件的自定义模块，因此无法在此平台上运行升级脚本。

测试自定义模块

为了确保自定义模块在升级后的数据库中与您的数据正常工作，它们也需要进行测试。这有助于确保存储在数据库中的标准和自定义数据是一致的，并且在升级过程中没有丢失任何内容。

注意事项：

  • 视图无法工作：在升级过程中，如果视图由于其内容而引起问题，则会被禁用。您可以在升级报告中找到有关禁用视图的信息。需要再次激活此视图（如果不再有用，则将其删除）。为此，我们建议使用升级脚本。

  • Module data not updated: Custom records that have the noupdate flag are not updated when upgrading the module in the new database. For the custom data that needs to be updated due to changes in the new version, we recommend to use upgrade scripts to do so. See also: update_record_from_xml().

步骤5：测试和预演

当自定义模块在升级后的数据库中正常工作时，进行另一轮测试以评估数据库的可用性并检测在先前的测试中可能被忽视的任何问题是至关重要的的。有关测试升级数据库的更多信息，请查看 测试新版数据库 。

正如 升级生产数据库 中提到的那样，标准升级脚本和您的数据库都在不断发展。因此，强烈建议您经常请求新的升级测试数据库，并确保升级过程仍然成功。

除此之外，在升级生产数据库的前一天进行完整的升级预演，以避免在升级过程中出现不良行为，并检测迁移数据可能发生的任何问题。

步骤 6：生产系统升级

一旦您有信心升级生产数据库，请按照 升级生产数据库 中描述的过程，具体取决于您的数据库的托管类型。