Hybris升级的总结

前两天闲来无事给一个项目做了Hybris版本的升级，版本跨度比较大，从6.0版本升级到6.7。 当中当然会存在不少问题，在完成之后写出来标记下。

 

升级一个已经成熟的系统存在风险，基本要遵循下面的思路打底：

首先，对于已有项目的升级，我尽量遵循竟可能的不去修改已有逻辑，实在逼不得已那就顺着升级版本去修改已有逻辑。

其次，在时间允许的情况下先通过代码搞清楚原有逻辑与需求，有条件的情况下能看到原始需求最好。

最后，在此基础上我们需要翻阅大量的hybris wiki来确保升级后的版本到底都做了哪些修改。

 

来看看具体的升级步骤：

1. 首先肯定需要去Hybris官网上下载一个Hybris v6.7的资源包。

2. 在解压完成之后

• • setantenv.bat (set ant 环境)
  • 然后再ant clean all (选择 [develop] 环境在本地)
  • 之后用命令行直接运行ant initialize (这样做有一个好处： 我们可以不用初始化原有的数据库，复用数据库的数据。）当然这个前提是你用了第三方的数据库而不是自带的HSQL。

3. 将项目中自定义的configure文件，自定义extension，自定义addon移入新的6.7版本中。

• • 复制local.properties，localextension.xml文件到新的项目目录中。（因为6.7版本已经彻底移除了HMC，所以要删除所有HMC相关的extension。）
  • 复制原项目自定义的extension和add-on到新项目目录中。
  • 将第三方数据库驱动jar包放到hybris/bin/platform/lib/dbdriver路径下。
  • 注释掉所有storefront中的add-on重新用命令安装或者先卸载后安装也是可以的，因为有些addon有一些变化。直接build有可能出错，重新安装之后解决。（ant addoninstall -Daddonnames="XXXXaddon" -DaddonStorefront.yb2bacceleratorstorefront=" XXXXstorefront "）

4. 尝试Build系统，这样build会以build error帮你检查出一些升级的不同。当出现build error的时候，心情是很激动的。build error出现的越多，前期发现的错误越多，提前修改的问题也多。因为后面的问题都是比较难发现和定位的了，这个是后话。

• • Fix all build issue for new version project.
  • Fix start server issue. (这个主要是解决Spring 配置文件的问题，在版本升级或修改了build问题之后可能会漏掉一些Spring配置文件的修改。)
  • Fix common issue after start server, 一般情况以下问题值得我们关注下：
    • Solr index 问题，因为高版本的solr server 的配置有修改，因此我们需要重新在impex文件中配置solr server。
    • CSRF问题，高版本对POST请求做了过滤，因此需要在Spring Security文件中修改配置，或者通过properties文件配置CSRF的例外。
    • 对于promotion的修改，高版本promotion的Action实现发生的变化。因此需要按照新的实现方式去修干原来自定义的promotion。

Hybris v6.0 implement: https://help.hybris.com/6.0.0/hcd/235755743eaf4da2aec5ac1352f93674.html#loio235755743eaf4da2aec5ac1352f93674

Hybris v6.7 implement:https://help.hybris.com/6.7.0/hcd/235755743eaf4da2aec5ac1352f93674.html#loio235755743eaf4da2aec5ac1352f93674

• • • 对于已经存在的doorls rule不能使用的问题，hybris也提供了修改方案。在DroolsRuleModel的脚本中加入@modelName("XXXXXXX")

5. 基于上面几个步骤，基本上我们已经完成了一大半的升级任务，但注意，也只是升级任务。我们还需要对整个系统做一个简单的升级的regression test。因此下面的例子可能比较特殊化，所以我们只是看方向，不看具体修改。

• 首先在测试过程中发现后台时不时会报一个extension name 找不到的错误。

按道理来说extension name都是hybris自己生成extension就定好统一管理的啊。在查看了代码之后发现：原来是在高版本中storefront中的一个UiExperienceViewResolver 对URL的解析改变了，由于storefront是自定义的，旧版本生成这个的时候这个类并不是这样的。因此原因找到了，那么直接修改这个类就可以了。因为如果拿新版本生成storefront的话这个类一定是最新版本的，所以这种解决方案没有问题。

• 当到某个search页面的时候发现所有的排序全都不能使用了。

在研究之后发现我们的项目中为了实现某个功能将commerceSearchQueryPageableConverter的配置修改了，而高版本的代码也将sort抽离出来单独covert了因此也在Spring文件中修改了这个bean的依赖。所以问题找到了，把缺失的sort转换依赖加进来问题就解决了。

• 也是查询的问题，因为是自定义功能不方便描述细节，因此只说新版本最终的变化。

hyrbis solr之前都是通过解析query来拼装实际传入solr 服务的查询语句的，但是新版本会先将query解析到keywords中，最终去解析的是keywords.这之多一造成问题的原因在于，之前自定义需求的实现回去处理query，然后将query按照定好的规则，一部分放入q中作为关键字查询，另一部分作为fq在查询出的结果上过滤第二个关键字。因此基于这种实现，高版本的改动就需要我们重新修改业务逻辑，根据keywords去拆分和解析查询语句。这样问题也解决了。

 

总的来说，升级不能急，要洞察那些高版本中微小的改动。（一般大的改动都能在build中或hybris官方文档中找到原由与实现方案）然后耐心的测试最可能出错的核心功能，再到边边脚脚的小功能测试。基本这样的升级就可以有信息交给客户了。但是值得注意的是，在这之后当然还是需要专业测试团队进行专业regression test的，针对整个系统功能而非升级可能出现的问题。这样才能保证系统在升级之后可以正常上线。