一种基于ReactNative的灰度热部署系统技术方案

本发明专利技术公开了一种基于React Native的灰度热部署系统，包括gitlabrunner模块、web端模块、服务端模块和客户端模块；本发明专利技术提供基于ReactNative应用热部署方案，实现自动发布、灰度可控、增量下发的一种基于ReactNative的灰度热部署系统。度热部署系统。度热部署系统。

【技术实现步骤摘要】
一种基于React Native的灰度热部署系统


[0001]本专利技术涉及软件热部署领域，更具体的说，它涉及一种基于React Native 的灰度热部署系统。

技术介绍

[0002]在大型的Saas软件内都需要构建强大的营销中台，以支持商户在线上、线下一体化营销中需要的灵活多变场景。软件应允许商户针对不同场景建立自定义规则，制定不同营销优惠策略。此类系统存在很多的问题如难以进行灰度热部署进行系统的升级管理、系统在事务处理中难以实现分布式处理、缺少强有力的表达方式的系统搭建，营销类系统对于打印统计也要求极高，目前难以实现快速的移动端打印等。其中，如何进行灰度热部署进行系统的升级管理成为重要问题之一。
[0003]React Native是FaceBook开源的跨平台移动开发框架,能够利用 JavaScript编写移动应用，当移动应用上架到各大应用市场后，在不需要重新提交审核的情况下，下发打包的JavaScript代码即可更新应用，这种快速触达用户，高效的开发方式，受到越来越多的开发者青睐。
[0004]目前现有的热部署方案主要有：
[0005]1)集成微软开源的code push服务。该方案优点是集成简单，企业节约开发成本，但缺点也很明显，code push服务在国外，热部署时效性低，会出现更新失败的问题，打包需要在终端执行打包命令，繁琐且易出错，打包后的文件是全量下载，浪费用户流量。
[0006]2)自己搭建服务存储打包后的JavaScript文件，客户端集成SDK下载。该方案优点是服务比较稳定可控，缺点也很明显，打包文件全量下载，浪费客户流量，同样需要终端执行打包命令。
[0007]3)基于Jenkins+自己搭建服务+客户端集成SDK下载。该方案利用Jenkins 线性工作机制，配置好打包脚本，发布时在Jenkins工作台点击下即可打包发布，方便快速，但这种方式很难做到灰度可控，同样存在全量下载浪费客户流量的问题。

技术实现思路

[0008]本专利技术克服了现有技术的不足，提供基于React Native应用热部署方案，实现自动发布、灰度可控、增量下发的一种基于React Native的灰度热部署系统。
[0009]本专利技术的技术方案如下：
[0010]一种基于React Native的灰度热部署系统，包括gitlab runner模块、web 端模块、服务端模块和客户端模块；
[0011]gitlab runner模块用于执行打包任务，通过开源代码托管平台，部署基于该平台的运行服务，该运行服务通过相应执行任务文件进行运作，任务文件实现执行的任务，其包括依赖下载、打包；任务文件通过开源代码托管平台相应的对外接口进行触发；
[0012]web端模块用于灰度发布，触发gitlab runner模块的打包功能，打包结束后会将
包上传到服务器,完成一次打包任务；服务器收到打包文件后，会将这次发布的版本及灰度方式存储到数据库中，完成一次应用发布；
[0013]服务端模块用于存储、下发打包的执行任务文件；服务端模块包括数据库表packages和packages_diff，其中packages表记录每次版本的发布，信息包括包下载链接、版本号、灰度方式、是否存在diff包、是否可下载；packages_diff表记录每次发布的diff后的文件信息；当服务端收到gitlab runner模块上传的包后，检查packages表是否已存在同版本的包，如果不存在，记录该次发布的相应信息到表packages；如果存在，则利用文本差异方法生成差异化后的内容，将差异后的内容保存到旧包进行替换，同时记录到packages_diff表，完成一次差异化过程；
[0014]当客户端模块的请求到达时，服务端模块根据请求携带的版本号检查 packages表，如果不存在对应的版本号，则返回无更新包；如果存在对应的版本号，检查是否满足灰度条件，不满足灰度条件时返回无更新包，满足灰度条件时，检查是否存在差异包，不存在，下发完整的包下载链接，存在，从表packages_diff中获取下载链接返回；
[0015]当从web端模块暂停某次灰度发布时，服务端模块会将packages表对应的那条发布记录是否可下载字段标记为否，此时当客户端模块请求触达时返回无更新包；
[0016]客户端模块，每次客户端模块启动时，请求接口检查更新，服务器模块根据接口参数，返回相关结果，客户端模块拿到返回结果后；如果无更新包，则结束流程；如果有更新包，下载该包；下载完成后，判断是否为差异包，如果不是差异包，保存该包到本地，同时将该包标记为current_package，将正在运行的包标记为previous_package；如果是差异包，则利用文本差异方法合并差异包内容到现有包，并保存到本地，同时将保存的包标记为current_package，将正在运行的包标记为previous_package；
[0017]下次启动获取标记为current_package的包运行，如果首次运行current_package包崩溃，则删除current_package标记的包，同时将标记为previous_package的包更改为current_package，供下次启动运行。
[0018]进一步的，当客户端模块的请求包括版本号、系统版本、网络条件、地区信息。
[0019]进一步的，灰度条件的方式为android系统版本大于8，当请求携带的信息android系统版本为7时则不满足灰度条件，android系统版本为9时则满足灰度条件。
[0020]进一步的，差异包为下载的包信息里面携带了是否为差异包信息。
[0021]进一步的，文本差异方法采用处理步骤少，且处理上删除后新增，比新增后删除多；其中，通过图的最短路径搜索问题来进行最优选择；具体的，把文件头部相同的最长子串剔除；对于尾部，以较短的字符串为依据求最长子串，后剔除最长子串，文件剩下的部分再做diff包处理。
[0022]本专利技术相比现有技术优点在于：
[0023]本专利技术通过gitlab runner模块、web端模块、服务端模块和客户端模块，形成React Native应用热部署的有效闭环；提供基于React Native应用热部署方案，实现自动发布、灰度可控、增量下发。
[0024]本专利技术在具体软件灰度发布过程中，由于热部署打包的js代码字符串，前后两次热部署很大程度上，大部分代码都是一样的，仅有少部分的改动，因此会先做一个掐头去尾操作，把头部相同的最长子串剔除；对于尾部，以较短的字符串为依据求最长子串，后剔除
最长子串，剩下的再做diff包过程，这样还能加速diff包过程。
附图说明
[0025]图1为本专利技术的灰度热部署自动化打包流程示意图；
[0026]图2为本专利技术的灰度热部署检查更新流程示意图；
[0027]图3为本专利技术的灰度热部署最优路径实例示意图；...

【技术保护点】

【技术特征摘要】
1.一种基于React Native的灰度热部署系统，其特征在于：包括gitlab runner模块、web端模块、服务端模块和客户端模块；gitlab runner模块用于执行打包任务，通过开源代码托管平台，部署基于该平台的运行服务，该运行服务通过相应执行任务文件进行运作，任务文件实现执行的任务，其包括依赖下载、打包；任务文件通过开源代码托管平台相应的对外接口进行触发；web端模块用于灰度发布，触发gitlab runner模块的打包功能，打包结束后会将包上传到服务器,完成一次打包任务；服务器收到打包文件后，会将这次发布的版本及灰度方式存储到数据库中，完成一次应用发布；服务端模块用于存储、下发打包的执行任务文件；服务端模块包括数据库表packages和packages_diff，其中packages表记录每次版本的发布，信息包括包下载链接、版本号、灰度方式、是否存在diff包、是否可下载；packages_diff表记录每次发布的diff后的文件信息；当服务端收到gitlab runner模块上传的包后，检查packages表是否已存在同版本的包，如果不存在，记录该次发布的相应信息到表packages；如果存在，则利用文本差异方法生成差异化后的内容，将差异后的内容保存到旧包进行替换，同时记录到packages_diff表，完成一次差异化过程；当客户端模块的请求到达时，服务端模块根据请求携带的版本号检查packages表，如果不存在对应的版本号，则返回无更新包；如果存在对应的版本号，检查是否满足灰度条件，不满足灰度条件时返回无更新包，满足灰度条件时，检查是否存在差异包，不存在，下发完整的包下载链接，存在，从表packages_diff中获取下载链接返回；当从web端模块暂停某次灰度发布时，服务端模块会将packages表对应的那条发布记录是否可下载字段标记为否，此时当客户端模块请求触达时返回无更新包；客...

【专利技术属性】
技术研发人员：赵存，高宇健，欧平均，
申请(专利权)人：广州衣科明夷信息技术有限公司，
类型：发明
国别省市：