支持和维护

当你真正使用ERP，你将从你的投资获取价值。正因为如此，维护和支持是长期成功的关键。

  • 支持着眼于通过回应他们关于使用系统的问题，确保最终用户从OpenERP获得最大的产能。支持可以是技术方面的，也可以是功能方面的。

  • 维护主要关注确保系统能够持续所需的工作。其中包括升级，通过升级可以获得最新的可用功能。

一些合作伙伴提供预防性维护。这确保你系统上的所有定制开发每个都针对新版本进行修订和测试,以保持他们OpenERP基础模块的兼容性。

Tiny themselves have changed their support strategy from time to time. At the time of writing, they propose a maintenance contract supplied either direct to the end user or through partners that guarantees a quick fix to any faults discovered in the covered code. Although you can expect these fixes to become available to all users of the code in time, maintenance guarantees quick attention. And you are likely to get quicker migration support to new upgrades.

If you have not anticipated your needs with a preventive maintenance contract, the costs of migration after a few years can become significant. If special modules that you developed have been allowed to become too old, you may eventually need a new development according to your specifications.

更新与升级

有四种修改OpenERP代码的途径：

  • 补丁提供纠正某微小的BUG错误：验证后，这些补丁应该不会引起任何副作用，

  • 次要升级，在一个软件包里汇集了错误更正，一般以修改版本数字的方式宣布，例如从6.0.0到6.0.1，

  • 升级，在主要版本中包括错误的修正和功能的改进，比如6.0.3 升级到 6.2.0 ，

  • 新功能，一般以新模块的方式发布。

应该与供应商建立OpenERP代码变更的时候的反应流程。

对于简单升级,你的维护团队会对补丁进行评估,以去人它是否对你的OpenERP有用.这些补丁在被应用到你的生产环境之前应该在离线的OpenERP版本进行测试.

维护组需要同时负责日常的软件更新。

补丁和升级只会在你有必要访问OpenERP服务器的时候才会安装。你必须首先安装补丁和升级,然后用命令参数： --update=all重启服务器。

Once Tiny has released a new upgraded version, your response should be a cautious one. If you are perfectly satisfied with the existing system, it would be best to not touch the new version. If you want to have access to the new functionality supplied by an upgraded version, you have a delicate operation to carry out. Most upgrades require your data to be migrated, because the databases before and after the upgrade can be a little different.

版本升级

OpenERP 有一种可以进行半自动化迁移数据的机制。为了能够更新特定的模块或整个数据库，你只要使用 “—update=NAME_OF_MODULE” 或者 “—update=all”参数来启动服务 (这是小模块更改)。

New stable versions of OpenERP sometimes require operations that are not provided in the automated migration. Tiny, the creator and maintainer of OpenERP, has a policy of supporting migration from all official stable releases to the latest. Scripts are provided for each new release of a stable version. These carry out the upgrade from the previous major version to the new major version.

经理负责两个不同版本OpenERP之间的合并，通过在OpenERP服务器doc/migrate 的目录下的文件和必须的脚本实现。

版本4和5之间的变化使得合并过程比过去更加困难,因此比通常花费更多的时间在升级准备和手工工作上。

迁移过程应该像这样执行：

  1. 在旧版OpenERP中完成数据库备份。

  2. 停止运行中的旧版服务

  3. 为你移动的版本之间运行脚本 pre.py 。

  4. 使用选项 --update=all 开启新版本服务器。

  5. 停止运行中的新版本服务器。

  6. 在你移动的版本之间执行叫做 post.py 的脚本。

  7. 使用新版的服务器，并进行测试。

A migration is never an easy process. It may be possible that your system does not function as it did before, or that something requires new developments in the functionality of the modules that have already been installed. So you should only move to a new version if you have a real need, and should engage a competent partner to help if the version that you use differs greatly from the basic version of OpenERP.

Similarly, you should take care that this migration does not incorrectly change any setting that has already been made. The main menu structure might have been modified in place without proper recording of the changes. So you could find that you are making the wrong assumptions about that structure when later loading data that was recorded with the Module Recorder.