CN108334334A - 一种管理依赖包版本的方法和系统 - Google Patents

Abstract

本申请公开了一种管理依赖包版本的方法和系统，其中所述方法包括在获取统一的版本依赖规则，所述版本依赖规则中描述满足最低兼容要求的所有依赖包的版本信息；按照所述版本依赖规则对本地项目执行版本依赖扫描，确定所述本地项目中是否存在不符合所述版本依赖规则的依赖冲突；针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理。

Description

一种管理依赖包版本的方法和系统

技术领域

本申请涉及计算机通信技术领域，具体涉及一种管理依赖包版本的方法和系统。

背景技术

伴随计算机通信技术的发展，软件开发项目和模块越来越多，规模越来越大。一个项目模块会使用到各种开源依赖包或者公司内部其他团队提供的依赖包。当一个软件项目需要用到其他软件项目发布的开发包时，要在这个软件项目中描述对于另外的软件项目的开发包的依赖关系，包括版本信息等，在大规模的软件项目中这种依赖关系可能会非常复杂，伴随开发工作的持续进展，这种依赖关系也可能随时发生变化，因此很容易出现版本依赖冲突的情况。例如，某软件项目A分别依赖了软件项目B的版本为1.0的开发包和软件项目C的版本为3.0的开发包，而软件项目B的版本为1.0的开发包依赖了软件项目D的版本为1.0的开发包，软件项目C的版本为3.0的开发包则依赖了软件项目D的版本为2.0的开发包，此时就出现了软件项目D的开发包依赖冲突，这就是所谓的版本依赖冲突。

每个依赖包都是一个计算机指令的集合，包含了系统对外的接口定义，各种常量变量定义，及各种公共方法的声明，发布依赖包是共享计算机指令代码的一种方式，开发项目中除了会涉及到本地项目中的各模块的相互依赖，还会用到内部合作团队提供的开源二方包和外部开源三方包。所述二方包一般指内部的其他项目团队发布的依赖包，所述三方包是指外部的开源库发布的依赖包。所述二方包和三方包的升级往往会涉及到所有的依赖项目需要升级包版本，尤其是当依赖包的升级涉及系统安全、代码漏洞、算法改进等重要更新时，需要立即导入新版本的依赖包，然而目前的方式都是通过人工排查、邮件通知和邮件跟踪来实现项目的依赖升级。传统的方式效率低且进度不好控制，已无法满足大规模并行开发项目的需要。因此，亟须提供一种能够方便、有效的管理依赖包版本的方法。

发明内容

为了解决现有技术中存在的问题，发明人构思了一种管理依赖包版本的方法、系统、计算设备及计算机可读存储介质，以解决传统方式的弊端，通过便捷、高效的方式实现依赖包版本的管理。

本申请公开了一种管理依赖包版本的方法，该方法包括：

获取统一的版本依赖规则，所述版本依赖规则中描述满足最低兼容要求的所有依赖包的版本信息；

按照所述版本依赖规则对本地项目执行版本依赖扫描，确定所述本地项目中是否存在不符合所述版本依赖规则的依赖冲突；

针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理。

可选地，所述处理包括：

将本地项目中存在依赖冲突的依赖包强制升级到所述依赖规则规定的版本；或

针对本地项目中存在依赖冲突的依赖包发出升级建议。

可选地，所述方法还包括：如果所述版本依赖扫描中发现所述版本依赖规则中未记录的新的依赖包，则发送提示更新的信息，所述提示更新的信息中携带所述未记录的新的依赖包的信息。

可选地，所述依赖冲突包括错误级别依赖冲突和警告级别依赖冲突，若确定发生错误级别依赖冲突则在完成所有冲突依赖规则的扫描后终止构建所述本地项目，否则仅发送警告提示信息。

可选地，所述方法还包括：

在完成所述版本依赖扫描后将扫描记录上传至数据库。

可选地，所述处理包括实时处理和预定时间处理。

可选地，从依赖包仓库下载所述版本依赖规则描述的满足最低兼容要求的依赖包。

一种管理依赖包版本的方法，所述方法包括：

建立统一的版本依赖规则，并将所述版本依赖规则存储于数据库中，所述版本依赖规则中描述满足最低兼容要求的所有依赖包的版本信息；

对所述版本依赖规则进行更新，并在数据库中添加更新后的版本依赖规则。

可选地，所述更新包括：如果接收到提示更新的信息，则根据所述提示更新的信息中携带的新的依赖包的信息在数据库中添加新的版本依赖规则。

可选地，所述版本依赖规则包括错误级别规则和警告级别规则；

所述方法还包括：按照预定的周期将警告级别规则升级为错误级别规则。

可选地，所述方法还包括：

在数据库中为使用者创建账户，在所述账户中存储所述使用者的基本信息和所述使用者完成所述版本依赖扫描的扫描记录；

依据所述使用者的账户中存储的扫描记录和基本信息向使用者发送提醒信息。

可选地，所述方法还包括：

提供依赖包仓库，所述依赖包仓库存储所述版本依赖规则涉及到的所有依赖包。

另一个方面，本申请提供一种管理依赖包版本的系统，包括管理平台、数据库和扫描工具，其中：

所述管理平台，被配置为建立和更新统一的版本依赖规则；

所述数据库被配置为存储所述版本依赖规则；

所述扫描工具被配置为按照所述版本依赖规则对本地项目执行版本依赖扫描，确定本地项目中是否存在不符合所述版本依赖规则的依赖冲突，针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理。

可选地，所述系统还包括将所述版本依赖扫描整合到项目构建工具中的插件。

可选地，所述扫描工具包括下载模块、扫描模块和处理模块，所述下载模块被配置为从数据库中获取统一的版本依赖规则，所述扫描模块被配置为按照所述版本依赖规则对本地项目执行版本依赖扫描，确定所述本地项目中是否存在不符合所述版本依赖规则的依赖冲突，所述处理模块被配置为针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理，所述管理平台包括管理平台用户交互界面(User interface)，所述管理平台UI提供建立和更新所述版本依赖规则的用户交互界面。

可选地，所述扫描工具还包括信息提交模块，如果所述版本依赖扫描中发现所述版本依赖规则中未记录的新的依赖包，则所述信息提交模块向管理平台发送提示信息，所述管理平台还包括管理模块，所述管理模块被配置为接收扫描工具的信息提交模块提交的提示更新的信息，并根据所述提示更新的信息中携带的新的依赖包的信息在数据库中添加新的版本依赖规则。

可选地，所述扫描工具的信息提交模块还被配置为在完成所述版本依赖扫描后将扫描记录上传至数据库，所述管理平台UI还被配置为在数据库中为使用者创建账户，所述账户中存储所述使用者的基本信息和所述使用者完成所述版本依赖扫描的扫描记录，所述管理模块还被配置为依据所述使用者的账户中存储的扫描记录和基本信息向使用者发送提醒信息。

可选地，所述系统还包括依赖包仓库，所述依赖包仓库被配置为存储所述版本依赖规则涉及到的所有依赖包，所述扫描工具被配置为从依赖包仓库中下载依赖包。

另一方面，本申请还提供一种计算设备，包括处理器和存储器，所述存储器上存储有计算机指令，当所述计算机指令被所述处理器执行时，使所述处理器执行如前所述的管理依赖包版本的方法。

另一方面，本申请还提供一种计算机可读存储介质，其上存储有计算机指令，当所述计算机指令被电子设备的处理器执行时，使所述处理器执行如前所述的管理依赖包版本的方法。

根据本申请的管理依赖包版本的方法、系统、计算设备及计算机可读存储介质实现了依赖包版本的统一自动化管理，能够保证多个并行项目之间依赖版本的一致性，此外通过构建检查还能够及时阻止问题依赖上线。根据本申请的方法省略了传统人工排查、邮件通知和邮件跟踪的繁琐工序，大大提高了工作效率，降低了开发项目的运营成本。

附图说明

图1为本申请的一实施例提供的一种管理依赖包版本的系统的结构示意图；

图2为本申请的一实施例提供的一种管理依赖包版本的方法的流程图；

图3为本申请的一实施例提供的一种管理依赖包版本的方法的流程图；

图4为本申请的一实施例提供的一种管理依赖包版本的系统中的扫描工具的结构示意图；

图5为本申请的一实施例提供的一种管理依赖包版本的系统中的管理平台的结构示意图；

图6为本申请的一实施例提供的一种管理依赖包版本的系统中的扫描工具的结构示意图；

图7为本申请的一实施例提供的一种管理依赖包版本的方法中所采用的一种版本依赖规则表的数据模型；

图8为本申请的一实施例提供的一种管理依赖包版本的方法中所采用的一种用户表的数据模型；

图9为本申请的一实施例的一种管理依赖包版本的系统中的Jenkins插件的工作流程图；

图10为本申请的一实施例的计算设备的结构示意图。

具体实施方式

下面结合附图通过实施例来阐述本申请的细节，这样更有利于理解本申请的内容，但本申请能够以多种不同于具体实施例的方式来实施，本领域技术人员可以在不违背本申请内涵的情况下结合现有技术做类似推广，因此本申请不受以下公开的具体实施方式的限制。

在本申请中，“第一”、“第二”、“第三”、“第四”等仅用于彼此的区分，而非表示重要程度及顺序、以及互为存在的前提等。

在本申请中，提供了一种管理依赖包版本的方法、系统、计算设备及计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了本申请一实施例的管理依赖包版本的系统100的结构示意图。所述系统100包括管理平台101、数据库102和扫描工具103，其中所述管理平台101被配置为建立和更新统一的版本依赖规则，所述数据库102被配置为存储所述版本依赖规则，所述扫描工具103按照所述版本依赖规则对本地项目执行版本依赖扫描，确定本地项目中是否存在不符合所述版本依赖规则的依赖冲突，针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理。

所述管理平台101可以执行如图2所示的管理平台侧管理依赖包版本的方法，包括步骤201和202。

步骤201：建立统一的版本依赖规则，并将所述版本依赖规则存储于数据库中，所述版本依赖规则中描述满足最低兼容要求的所有依赖包的版本信息。

步骤202：对所述版本依赖规则进行更新，并在所述数据库中添加更新后的版本依赖规则。

通过管理平台建立了统一使用的版本依赖规则后，伴随开发项目的进展需要随时更新所述版本依赖规则，例如：新增规则、变更规则的属性、删除规则等操作。所述版本依赖规则可以是存储在数据库中的一个或多个规则表，所述规则表中定义有多个规则，每个规则包含多个字段，例如：主键、项目名称、目录结构名称、满足最低要求的版本名称、级别、创建时间等。

在一个实施例中，所述方法中的更新包括：如果接收到提示更新的信息，则根据所述提示更新的信息中携带的新的依赖包的信息在数据库中添加新的版本依赖规则。这一改进能够及时向管理平台反馈本地开发环境中发现的版本依赖的问题，协助管理平台对依赖规则进行更新。

在可选的实施例中，所述版本依赖规则包括错误级别规则和警告级别规则。相应的，所述依赖冲突包括错误级别依赖冲突和警告级别依赖冲突，违反错误级别规则的依赖冲突被定义为错误级别依赖冲突，而违反警告级别规则的依赖冲突被定义为警告级别依赖冲突。若确定发生错误级别依赖冲突则在完成所有冲突依赖规则的扫描后终止构建所述本地项目，否则仅发送警告提示信息。也就是说，整合了插件的项目构建工具如果在构建项目时仅发现警告级别的冲突，并不会终止项目构建，而仅仅向开发人员发送警告信息，所述警告信息例如为存在冲突的依赖包的名称、版本以及冲突处理方法等信息。针对不同情况进行分级处理能够更好的应对复杂情况，避免严重程度并不高的依赖冲突妨碍重要开发项目的进行。

实际应用中，错误级别依赖冲突的危害程度更高，通常涉及系统安全、代码漏洞、关键算法改进等严重错误，开发人员必须立即升级本地的依赖包版本。而警告级别的冲突危害程度较低，通常可暂缓升级。

在另一个实施例中，所述方法还包括：

在数据库中为使用者创建账户，在所述账户中存储所述使用者的基本信息和所述使用者完成所述版本依赖扫描的扫描记录；和

依据所述使用者的账户中存储的扫描记录和基本信息向使用者发送提醒信息。

使用者的账户信息存储在服务器端的一个或多个用户表中，所述用户表中记载使用者的各种信息，这些信息包括但不限于名称、工号、手机号码、邮件地址、用户级别、最近一次完成扫描的时间、本地扫描发现版本依赖包的信息等。通过提取这些信息，就能发现没有及时更新版本依赖规则和升级发现冲突的依赖包的使用者，并向使用者发送提醒信息。即使该用户长期未运行扫描工具，系统也可以通过邮件或短信方式发送提醒信息。灵活便利的方式，有助于提升依赖包管理的实际效果。

在另一个实施例中，所述方法还包括：提供依赖包仓库，所述依赖包仓库存储所述版本依赖规则涉及到的所有依赖包。

在一个具体的实施例中，所述管理依赖包版本系统的扫描工具被配置为与依赖包仓库相连，由此完成所述版本依赖扫描后可直接从依赖包仓库中下载需要升级的依赖包。这样能够节省开发人员寻找依赖包升级版本所耗费的时间和精力，提高工作效率。

图3示出了本地终端侧管理依赖包版本的方法，所述方法包括步骤301至303。

步骤301：获取统一的版本依赖规则，所述版本依赖规则中描述满足最低兼容要求的所有依赖包的版本信息。

步骤302：按照所述版本依赖规则对本地项目执行版本依赖扫描，确定所述本地项目中是否存在不符合所述版本依赖规则的依赖冲突。

步骤303：针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理。

其中所谓满足最低兼容要求是指本地项目中的依赖包版本不低于所述版本依赖规则所限定版本要求，即在本地项目中就不会出现已知的依赖冲突。当然，针对某些特定情况，满足最低兼容要求的标准可根据具体需要来设定。

在一个实施例中，发现项目中存在不符合依赖规则的依赖冲突时的处理方式包括：

将本地项目中存在依赖冲突的依赖包强制升级到所述依赖规则规定的版本；或

针对本地项目中存在依赖冲突的依赖包发出升级建议。

针对不同情况采用不同的处理方式，能够保证级别高的依赖冲突得到及时解决，同时避免低级别的依赖冲突影响重要项目的顺利进行。

在一个实施例中，所述方法还包括：如果所述版本依赖扫描中发现所述版本依赖规则中未记录的新的依赖包，则发送提示更新的信息，所述提示更新的信息中携带所述未记录的新的依赖包的信息。

通过这种方法，能够及时发现所述版本依赖规则中未记录的依赖规则并进行更新。

本申请的一个实施例中的依赖冲突包括错误级别依赖冲突和警告级别依赖冲突，若确定发生错误级别依赖冲突则在所述版本依赖扫描完成后终止构建所述本地项目，否则仅发送警告提示信息。

提供有区别的处理方式有利于内部各开发组之间的协调管理，以更为恰当的方式处理依赖冲突的问题。

在一个实施例中，所述方法还包括步骤：在完成所述版本依赖扫描后将扫描记录上传至数据库，所述扫描记录的内容能够为管理系统追溯历史结果数据提供依据。

扫描记录里的信息能够反映使用者更新版本依赖规则和升级依赖包版本的情况，针对没有及时更新升级的使用者并按照所述账户中使用者的基本信息，例如：邮箱地址，向其发送提醒信息。

在一个实施例中，针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理包括实时处理和预定时间处理。预定时间处理是指，预定在之后的某个特定时间或经过一段时间后进行处理。这是一种应对实际情况的变通，对于不涉及系统安全、代码漏洞、算法改进等内容的依赖包升级，可暂缓处理。开发人员根据具体情况，选择适当的处理时间。本地工具在预定时间会开发人员发送提醒信息。这一改进能是为了避免开发人员因工作忙碌而遗漏或延误依赖包升级。

在根据本申请的一个实施例中，所述系统100还被配置为将所述版本依赖扫描整合到项目构建工具中的插件104。常见的能够实现开源持续集成的项目构建工具包括但不限于：Jenkins、Buildbot、Travis CI、Strider、Go和Integrity。

图4示出根据本申请的一个实施例提供的管理依赖包版本的系统中的扫描工具400的结构示意图，在本申请的一个实施例中，扫描工具400包括下载模块401、扫描模块402和处理模块403。

所述下载模块401被配置为从数据库中获取统一的版本依赖规则；

所述扫描模块402被配置为按照所述版本依赖规则对本地项目执行版本依赖扫描，确定所述本地项目中是否存在不符合所述版本依赖规则的依赖冲突；

所述处理模块403被配置为针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理。

在一个实施例中，本申请提供的管理依赖包版本的系统中，所述管理平台可以如图5所示，包括管理平台用户界面(UI)501和管理模块502。

所述管理平台UI501被配置为提供建立和更新所述版本依赖规则的用户交互界面。通过所述管理平台UI501能够非常便捷地在数据库中创建和维护统一的版本依赖规则。

所述管理模块502被配置为接收扫描工具的信息提交模块提交的提示更新的信息，并根据所述提示更新的信息中携带的新的依赖包的信息在数据库中添加新的版本依赖规则。

在一个实施例中，管理平台的管理模块502还能够按照预定的周期将警告级别规则升级为错误级别规则。该升级周期可作为一个系统常量预设在系统中，所有规则按照统一的周期进行升级。或者把升级周期作为规则定义的一个字段，这样可以为每个规则设定不同的升级周期，且升级周期作为一个可变量，可根据实际情况设定并随时改变。升级周期可结合上述两种方式来设置，例如可设置为：针对规则表中没有专门定义升级周期的规则，系统都会在每个月第一天统一将警告级别规则自动升级为错误级别规则。这种设置能够避免因人为失误而没有及时升规则级别而导致问题依赖上线，同时提高了依赖规则管理的便捷性。

所述管理依赖包版本的系统中的管理平台能够协助管理人员及时发现版本依赖规则中缺少的依赖规则并进行更新。

图6示出根据本申请的另一实施例提供的管理依赖包版本的系统中的扫描工具600，其中下载模块601、扫描模块602、处理模块603均与图4所示包括下载模块401、扫描模块402、处理模块403的扫描工具400相同，此处对其功能不再赘述。

所述扫描工具600与扫描工具400的不同之处在于，所述扫描工具600还包括信息提交模块604，如果所述版本依赖扫描中发现所述版本依赖规则中未记录的新依赖包，则所述信息提交模块604向管理平台发送提示信息，所述提示更新的信息中携带的新的依赖包的信息在数据库中添加新的版本依赖规则。

上述实施例中的管理依赖包版本的设备的扫描工具600能够及时发现所述版本依赖规则中未记录的依赖规则并向管理平台发送提示信息，提醒添加新的版本依赖规则。

所述扫描工具可以是一种可在终端上运行的计算机程序代码，其中内置有版本依赖规则表。

本申请的另一个实施例中，所述扫描工具600的信息提交模块604还被配置为在完成所述版本依赖扫描后将扫描记录上传至数据库。

相应的，所述管理平台UI501还被配置为在数据库中为使用者创建账户，所述账户中存储所述使用者的基本信息和所述使用者完成所述版本依赖扫描的扫描记录，所述管理模块还被配置为依据所述使用者的账户中存储的扫描记录和基本信息向使用者发送提醒信息。

扫描记录里的信息能够反映使用者更新版本依赖规则和升级依赖包版本的情况，针对没有及时更新升级的使用者并按照所述账户中使用者的基本信息，例如：邮箱地址，向其发送提醒信息。

在本申请的一个实施例中，所述系统还包括依赖包仓库，所述依赖包仓库存储所述版本依赖规则涉及到的所有依赖包。

在一个具体的实施例中，所述管理依赖包版本系统的扫描工具被配置为与依赖包仓库相连，由此完成所述版本依赖扫描后可直接从依赖包仓库中下载需要升级的依赖包。这样能够节省开发人员寻找依赖包升级版本所耗费的时间和精力，提高工作效率。

以Java开发项目为例，会产生以下三种依赖关系：对于项目本身模块的依赖，对于内部的封装包的依赖和对于第三方包的依赖。依赖一般分为模块依赖、框架依赖两大类。在Maven坐标系中，可通过artifactId:groupId:version三个坐标信息唯一定位一个模块类依赖包。其中，artifactId对应项目的名称，即项目根目录的名称，是项目的唯一的标识符。groupId对应main目录里Java的目录结构，是项目组织唯一的标识符。Version对应版本信息，所述版本信息的主流构成方式为[Major].[Minor].[Patch]，即通过三个数字来定义版本信息。由此，一个开源依赖包的Maven坐标信息可定义为com.demo.service:common-api:1.0.0，而开发人员使用IDE或Mvn命令根据Maven坐标信息就能从中央仓库或者企业内部私有仓库中定位和下载到该特定依赖包。针对框架依赖，比如Spring框架，当Spring 2，Spring3和Spring4同时并行升级时，就不能仅通过简单限定Spring-core:3.1.3来排除Spring2的依赖包。在这种情况下，需要采用[groupId]:[artifactId]:[Major Version]三个信息来限定包版本的最低要求。

在图7中示出的一种用于定义版本依赖规则的规则表的数据模型，在该规则表中包含能够唯一定义包版本信息的三个字段[groupId]:[artifactId]:[Major Version]，以及其他用于定义规则级别、规则状态和规则有效期等信息的字段。其中[Major Version]用来定义依赖包能够满足最低兼容要求的版本信息。例如某个依赖包在规则表中规定的满足最低兼容性的版本为2.0.0，而本地检查到的依赖包版本定义为信息为1.0.0，则认为存在版本依赖冲突，开发人员应进行相应升级。如果对本地所有依赖包进行扫描后均未发现不满足规则表的情况，则认为不存在版本依赖冲突，反馈信息提示完成扫描。

通过管理平台UI501在数据库中建立如图7所示规则表，在规则表中描述满足最低兼容要求的所有依赖包的版本信息。此外，还通过管理平台UI501在数据库中建立如图8所示的用户表，所述用户表中存储有用户的姓名、邮箱地址和其他信息。

在规则表中，将依赖规则区分为P1和P2两种规则级别，P1代表错误级别(ERROR)，P2：代表警告级别(WARN)。可根据实际需要设定在数据库中定义更多的冲突级别，并设定相应的处理方式和周期。

相应地，冲突的严重程度也分为P1和P2两种。P1级别的冲突危害程度较高，涉及系统安全、代码漏洞、关键算法改进等严重错误，要求开发人员立即升级本地的依赖包版本。P2级别的冲突危害程度较低，虽然向开发人员发送警告信息但可暂缓升级依赖包版本。如果扫描过程中发现了错误级别依赖冲突，则在完成所有规则扫描后，生成结果报告。如果全部扫描完成，只发现了警告级别的冲突，则记录相关信息，将信息写入本地扫描记录中。

使用者本地运行扫描工具，所述扫描工具执行以下步骤：

步骤1：询问开发人员是否更新版本依赖规则，如果选择“是”则从管理平台下载最新的版本依赖规则表并进行本地更新；如果选择“否”则直接跳转至步骤2；

步骤2：对本地项目中的依赖包版本进行扫描，查找是否存在低于版本依赖规则表记载的版本信息的依赖包，如果发现存在冲突，则跳转至步骤3；

步骤3：判断冲突的严重程度，如果判断存在的是P1(ERROR)级别的冲突则记录错误信息，并通知开发人员必须马上对特定依赖包进行版本升级；如果判断存在P2(WARN)级别的冲突则记录该警告信息，则记录该警告信息；如果扫描中发现版本依赖规则中未记录的新的依赖包，则记录所述未记录的新的依赖包的信息，并向管理平台发送提示更新的信息，所述提示更新的信息中携带所述未记录的新的依赖包的信息，返回执行步骤2执行其他依赖冲突规则的检查直至完成本地项目中所有依赖包的检查；

步骤4：结束检查过程并将记录结果反馈给开发人员。

此外所述版本依赖扫描被整合到Jenkins插件中，利用Jenkins本身提供的功能实现自动的持续集成，并执行版本依赖的扫描从而发现项目中存在的依赖冲突。如果项目新增或修改导致签入的源代码破坏了强制性约束，Jenkins能够及时终止项目的构建。Jenkins插件，其能够自动按照预设周期持续地运行自动检查，即CI系统能持续地获取新增或修改后签入的源代码，并确认这些新代码是否破坏了强制性约束，如果出现这样的情况就终止本地项目构建。通过这种方式能够实现对项目地实时监控，及时发现项目中存在依赖冲突。在一具体实施例中，一种根据本申请的管理依赖包版本的系统中的Jenkins插件的工作流程如图9所示：

步骤901：开始；

步骤902：询问是否更新规则，如果是，则跳转步骤903；如果否，则跳转至步骤905；

步骤903：从数据库中下载规则，跳转至步骤904；

步骤904：更新本地规则，跳转步骤905；

步骤905：加载规则集，跳转步骤906；

步骤906：运行Mvn，获取所有依赖信息，跳转步骤907；

步骤907：获取项目所有依赖包清单，进行结果集规则过滤，跳转至步骤908；

步骤908：判断是否发现错误级别的依赖冲突，如果是，则跳转至步骤909；如果否，则跳转至步骤910；

步骤909：记录错误信息，跳转至步骤912；

步骤910：判断是否发现警告级别的依赖冲突，如果是，则跳转至步骤911，如果否，则跳转至步骤912；

步骤911：记录警告信息后跳转至步骤912；

步骤912：判断是否还有要执行的版本冲突规则的扫描，如果是，则跳转至步骤908，如果否，则跳转至步骤912；

步骤913：生成结果报告，跳转至步骤914；

步骤914：结束。

执行完所有版本依赖规则的版本依赖扫描后，Jenkins会终止存在错误级别依赖冲突的项目接下来的源码编译、测试、打包和部署等后续步骤，并向相关人员发送邮件提醒。

此外，Jenkins本身为构建项目提供了很多方便的功能，例如在Jenkins中可根据需求设定构建项目的条件，例如选择“Poll SCM”，然后在日程表里填上cron表达式"H/5****"，表示每5分钟检查一次，发现有代码变更就构建项目，这样就能实现依赖冲突规则的周期性检查。当然我们也可以不选Poll SCM，而是用GitHub插件来实现实时构建。

在的实施例中，整合到Jenkins构建中的插件能够实现如下功能：

未发现依赖冲突和版本依赖规则中未记录的新的依赖包的情况下，则完成构建并认为构建是稳定的，在构建成功后即可将计算机程序代码部署上去；

如果未发现依赖冲突，但发现版本依赖规则中未记录的新的依赖包的情况下，则完成构建，但被认为不稳定可延迟部署并反馈给相关开发人员；

未发现错误级别依赖冲突，构建失败后，要发送通知邮件将构建失败的情况和原因反馈给开发人员。

在该系统中，除了能够通过管理平台UI手动升级依赖规则的级别，还可以实现按预定周期自动升级，例如：周期为1个月，这样每个月系统都会自动将当前P2级别规则升级至P1级别。

随着项目开发的进行，必然会需要修改规则表中的已有规则或添加新增规则。可以通过管理平台UI手工完成这个升级更新的步骤。但为了提高操作的简便性和避免人为错误，还可以提供一种系统自动设置规则状态的功能，通过设置规则状态设定当前生效的版本依赖规则。系统中默认版本号较高规则会使版本号较低规则自动失效。例如，如果从管理平台UI录入依赖包A的新规则A：2.2，则系统中旧的版本号较低规则A：2.1就会失效。但如果新录入规则的版本号低于原有规则，则发送警告信息，并根据操作人员的级别决定是否接受其新录入的较低规则。上述功能通过在规则表中增加一个限定规则状态的字段来实现。具体的，规则表中分别定义两种规则状态：“激活”和“失效”。这样，在系统中录入高版本的规则A：2.2时，低版本的规则A：2.1就会自动失效。在系统中同一时间针对同一依赖包仅有一个激活状态规则。此外增加规则状态字段也可用于版本依赖规则的自动升级，例如，针对依赖包A的当前规则为A：2.1，可以设定三周后自动将其升级为A：2.2，升级前规则A：2.1的状态为激活，规则A：2.2的状态为失效，三周后到达预定时间点，系统将A：2.1的状态变为失效，规则A：2.2的状态变为激活，就实现了规则定时升级的功能。

此外，用户表中除了记录使用者的基本信息以外，还可以记录使用者本地扫描记录中的信息，包括最后完成本地扫描的时间、本地发生依赖冲突的情况、依赖包升级的情况等，通过管理平台UI能够随时从数据库中读取到这些信息，根据这些信息可以监督开发人员进行依赖包版本的升级，并根据用户表中记录的使用者的联系方式提醒那些没有按要求运行扫描工具或没有及时升级依赖包版本的开发人员。

在这个实施例中，系统提供了内部的依赖包仓库，所述依赖包仓库存储所述版本依赖规则涉及到的所有依赖包。开发人员可以随时通过扫描工具从依赖包仓库中下载需要的依赖包。

本申请的另一实施例还提供一种计算机可读存储介质，其上存储有计算机指令，该指令处理器执行时，使所述处理器执行上述的管理依赖包版本的方法。

所述包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与前述的管理依赖包版本的方法属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述管理依赖包版本的方法的技术方案的描述。

本申请的另一实施例提供一种计算设备1000，如图10所示，包括存储器1001和处理器1002，所述存储器1001上存储有计算机指令，当所述计算机指令被所述处理器1002执行时，使所述处理器1002执行上文所述的管理依赖包版本的方法。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该申请仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (20)

1.一种管理依赖包版本的方法，其特征在于，所述方法包括：

获取统一的版本依赖规则，所述版本依赖规则中描述满足最低兼容要求的所有依赖包的版本信息；

按照所述版本依赖规则对本地项目执行版本依赖扫描，确定所述本地项目中是否存在不符合所述版本依赖规则的依赖冲突；

针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理。

2.根据权利要求1所述的方法，其特征在于，所述处理包括：

将所述本地项目中存在依赖冲突的依赖包强制升级到所述依赖规则规定的版本；或

针对所述本地项目中存在依赖冲突的依赖包发出升级建议。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

如果所述版本依赖扫描中发现新的依赖包未被记录在所述版本依赖规则中，则发送提示更新的信息，所述提示更新的信息中携带所述未记录的新的依赖包的信息。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述依赖冲突包括错误级别依赖冲突和警告级别依赖冲突，若确定发生错误级别依赖冲突，则在完成所有冲突依赖规则的扫描后终止构建所述本地项目，否则仅发送警告提示信息。

5.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：

在完成所述版本依赖扫描后将扫描记录上传至数据库。

6.根据权利要求1所述的方法，其特征在于，所述处理包括实时处理和预定时间处理。

7.根据权利要求1至3中任一项所述的方法，其特征在于，从依赖包仓库下载所述版本依赖规则描述的满足最低兼容要求的依赖包。

8.一种管理依赖包版本的方法，其特征在于，所述方法包括：

建立统一的版本依赖规则，并将所述版本依赖规则存储于数据库中，所述版本依赖规则中描述满足最低兼容要求的所有依赖包的版本信息；

对所述版本依赖规则进行更新，并在所述数据库中添加更新后的版本依赖规则。

9.根据权利要求8所述的方法，其特征在于，所述更新包括：如果接收到提示更新的信息，则根据所述提示更新的信息中携带的新的依赖包的信息，在数据库中添加新的版本依赖规则。

10.根据权利要求8或9所述的方法，其特征在于，所述版本依赖规则包括错误级别规则和警告级别规则；

所述方法还包括：按照预定的周期将所述警告级别规则升级为错误级别规则。

11.根据权利要求8或9所述的方法，其特征在于，所述方法还包括：

在数据库中为使用者创建账户，在所述账户中存储所述使用者的基本信息和所述使用者完成所述版本依赖扫描的扫描记录；

依据所述使用者的账户中存储的扫描记录和基本信息向使用者发送提醒信息。

12.根据权利要求8或9所述的方法，其特征在于，所述方法还包括：

提供依赖包仓库，所述依赖包仓库存储所述版本依赖规则涉及到的所有依赖包。

13.一种管理依赖包版本的系统，其特征在于，包括管理平台、数据库和扫描工具，其中：

所述管理平台，被配置为建立和更新统一的版本依赖规则；

所述数据库，被配置为存储所述版本依赖规则；

所述扫描工具，被配置为按照所述版本依赖规则对本地项目执行版本依赖扫描，确定本地项目中是否存在不符合所述版本依赖规则的依赖冲突，针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理。

14.根据权利要求13所述的系统，其特征在于，所述系统还包括将所述版本依赖扫描整合到项目构建工具中的插件。

15.根据权利要求13或14所述的系统，其特征在于，所述扫描工具包括下载模块、扫描模块和处理模块，所述下载模块被配置为从数据库中获取统一的版本依赖规则，所述扫描模块被配置为按照所述版本依赖规则对本地项目执行版本依赖扫描，确定所述本地项目中是否存在不符合所述版本依赖规则的依赖冲突，所述处理模块被配置为针对存在依赖冲突的依赖包按照版本依赖规则规定的方式进行处理，所述管理平台包括管理平台用户交互界面(User interface)，所述管理平台UI提供建立和更新所述版本依赖规则的用户交互界面。

16.根据权利要求15所述的系统，其特征在于，

所述扫描工具还包括信息提交模块，如果所述版本依赖扫描中发现所述版本依赖规则中未记录的新的依赖包，则所述信息提交模块向管理平台发送提示信息；所述管理平台还包括管理模块，所述管理模块被配置为接收扫描工具的信息提交模块提交的提示更新的信息，并根据所述提示更新的信息中携带的新的依赖包的信息在数据库中添加新的版本依赖规则。

17.根据权利要求15所述的系统，其特征在于，

所述扫描工具的信息提交模块还被配置为在完成所述版本依赖扫描后将扫描记录上传至数据库；所述管理平台UI还被配置为在数据库中为使用者创建账户，所述账户中存储所述使用者的基本信息和所述使用者完成所述版本依赖扫描的扫描记录；所述管理模块还被配置为依据所述使用者的账户中存储的扫描记录和基本信息向使用者发送提醒信息。

18.根据权利要求13或14所述的系统，其特征在于，

所述系统还包括依赖包仓库，所述依赖包仓库被配置为存储所述版本依赖规则涉及到的所有依赖包，所述扫描工具被配置为从依赖包仓库中下载依赖包。

19.一种计算设备，包括处理器和存储器，所述存储器上存储有计算机指令，其特征在于，当所述计算机指令被所述处理器执行时，使所述处理器执行根据权利要求1至7或8至12中任一项所述的管理依赖包版本的方法。

20.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，当所述计算机指令被电子设备的处理器执行时，使所述处理器执行根据权利要求1至7或8至12中任一项所述的管理依赖包版本的方法。