CN112667520A - 一种依赖包的处理方法及系统 - Google Patents
一种依赖包的处理方法及系统 Download PDFInfo
- Publication number
- CN112667520A CN112667520A CN202110063909.1A CN202110063909A CN112667520A CN 112667520 A CN112667520 A CN 112667520A CN 202110063909 A CN202110063909 A CN 202110063909A CN 112667520 A CN112667520 A CN 112667520A
- Authority
- CN
- China
- Prior art keywords
- party package
- library
- tested
- party
- package
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012545 processing Methods 0.000 title claims abstract description 29
- 238000000034 method Methods 0.000 title claims description 40
- 238000012360 testing method Methods 0.000 claims abstract description 172
- 238000011161 development Methods 0.000 claims abstract description 80
- 230000001419 dependent effect Effects 0.000 claims description 15
- 238000004806 packaging method and process Methods 0.000 claims description 10
- 238000003672 processing method Methods 0.000 abstract description 9
- 230000018109 developmental process Effects 0.000 description 68
- 230000006870 function Effects 0.000 description 19
- 230000008569 process Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 9
- XXQCMVYBAALAJK-UHFFFAOYSA-N ethyl n-[4-[benzyl(2-phenylethyl)amino]-2-(2-phenylethyl)-1h-imidazo[4,5-c]pyridin-6-yl]carbamate Chemical compound N=1C=2C(N(CCC=3C=CC=CC=3)CC=3C=CC=CC=3)=NC(NC(=O)OCC)=CC=2NC=1CCC1=CC=CC=C1 XXQCMVYBAALAJK-UHFFFAOYSA-N 0.000 description 7
- 230000008520 organization Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000010276 construction Methods 0.000 description 2
- 238000005034 decoration Methods 0.000 description 2
- 235000008429 bread Nutrition 0.000 description 1
- 239000011248 coating agent Substances 0.000 description 1
- 238000000576 coating method Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012956 testing procedure Methods 0.000 description 1
Images
Abstract
本发明公开了一种依赖包的处理方法及系统，在开发环节中，从开发库获取开发中的二方包所对应的源代码，当源代码对应的功能与预设的代码功能一致时，将源代码进行编译，生成待测试的二方包，将待测试的二方包上传至测试库进行测试，若待测试的二方包通过测试，则将通过测试的二方包上传至发布库，基于发布库中预先存储的三方包，对发布库中通过测试的二方包进行发布。通过上述方案，按照不同环节对二方包和三方包进行单独管理，并采用不同的更新策略来更新不同环节的二方包和三方包，避免在各个环节中使用二方包和三方包时出现冲突，实现提高二方包和三方包的处理效率的目的。
Description
技术领域
本发明涉及软件开发技术领域，更具体地说，涉及一种依赖包的处理方法及系统。
背景技术
在应用软件的开发过程中，无论使用哪种开发语言都会使用到企业内部自行开发的依赖包(二方包)或者由企业外部组织开发的依赖包(三方包)。
二方包和三方包的使用和处理中存在下述一些不同的需求，一是二方包在开发环节变更频繁，引用了二方包的应用程序(Application，APP)在开发新版本时通常也需要使用处于开发环节的最新版本二方包，但不修改已有的代码或配置；二是二方包在测试环节需要保持稳定，应当单独处理，不允许开发人员随意修改覆盖；三是二方包发布后也需要单独处理，禁止让开发和测试环节上传的包覆盖已经发布的包；四是应用的构建过程中可能会同时使用到二方包和三方包，二方包的构建中可能会使用三方包及其他的二方包，需要统一处理三方包及其他的二方包。
现有技术中没有区分研发流程中的各个环节，只是提供了单一的包的处理方案。例如：针对于JAVA的依赖包的处理，通常是搭建一套MAVEN包处理系统，开发环节、测试环节和发布环节都使用该系统。
因此，现有技术方案对二方包和三方包没有单独的处理方式，对二方包和三方包仅使用一个处理方式，使得现有技术方案无法满足上述需求，导致各环节中使用二方包和三方包出现冲突，从而造成在软件开发过程中处理二方包和三方包的效率低下。
发明内容
有鉴于此，本发明公开了一种依赖包的处理方法及系统，避免在各个环节中使用二方包和三方包时出现冲突，实现提高二方包和三方包的处理效率的目的。
为了实现上述目的，其公开的技术方案如下：
本发明第一方面公开了一种依赖包的处理方法，所述方法包括：
在开发环节中，从开发库获取开发中的二方包所对应的源代码；
当所述源代码对应的功能与预设的代码功能一致时，将所述源代码进行编译，生成待测试的二方包；
将所述待测试的二方包上传至测试库进行测试，若所述待测试的二方包通过测试，则将通过测试的二方包上传至发布库；
基于所述发布库中预先存储的三方包，对所述发布库中通过测试的二方包进行发布。
优选的，还包括：
若所述开发中的二方包执行更新操作，则得到更新后的二方包；
将所述更新后的二方包上传至所述开发库；
当更新后的二方包进行联调操作时，将所述开发库中更新后的二方包、所述发布库中已经发布的二方包和所述发布库中的三方包进行打包。
优选的，所述将所述待测试的二方包上传至测试库进行测试，若所述待测试的二方包通过测试，则将通过测试的二方包上传至发布库，包括：
将所述待测试的二方包上传至测试库，使所述测试库基于预先获取到的运行程序对所述待测试的二方包进行编译，生成待测试程序；
通过预设的测试数据对所述待测试程序进行测试，得到测试结果；
若所述测试结果与预设结果一致，则确定所述待测试的二方包通过测试，将通过测试的二方包上传至发布库。
优选的，还包括：
若所述测试结果与所述预设结果不一致，则确定所述待测试的二方包未通过测试。
优选的，还包括：
若所述待测试的二方包未通过测试，将所述编译后的二方包发送至所述开发库。
本发明第二方面公开了一种依赖包的处理系统，所述系统包括：
获取单元，用于在开发环节中，从开发库获取开发中的二方包所对应的源代码；
编译单元，用于当所述源代码对应的功能与预设的代码功能一致时，将所述源代码进行编译，生成待测试的二方包；
测试单元，用于将所述待测试的二方包上传至测试库进行测试，若所述待测试的二方包通过测试，则将通过测试的二方包上传至发布库；
发布单元，用于基于所述发布库中预先存储的三方包，对所述发布库中通过测试的二方包进行发布。
优选的，还包括：
更新单元，用于若所述开发中的二方包执行更新操作，则得到更新后的二方包；
上传单元，用于将所述更新后的二方包上传至所述开发库；
打包单元，用于当更新后的二方包进行联调操作时，将所述开发库中更新后的二方包、所述发布库中已经发布的二方包和所述发布库中的三方包进行打包。
优选的，所述测试单元，包括：
编译模块，用于将所述待测试的二方包上传至测试库，使所述测试库基于预先获取到的运行程序对所述待测试的二方包进行编译，生成待测试程序；
测试模块，用于通过预设的测试数据对所述待测试程序进行测试，得到测试结果；
确定模块，用于若所述测试结果与预设结果一致，则确定所述待测试的二方包通过测试，将通过测试的二方包上传至发布库。
优选的，还包括：
确定单元，用于若所述测试结果与所述预设结果不一致，则确定所述待测试的二方包未通过测试。
优选的，还包括：
发送单元，用于若所述待测试的二方包未通过测试，将所述编译后的二方包发送至所述开发库。
经由上述技术方案可知，在开发环节中，从开发库获取开发中的二方包所对应的源代码，当源代码对应的功能与预设的代码功能一致时，将源代码进行编译，生成待测试的二方包，将待测试的二方包上传至测试库进行测试，若待测试的二方包通过测试，则将通过测试的二方包上传至发布库，基于发布库中预先存储的三方包，对发布库中通过测试的二方包进行发布。通过上述方案，按照不同环节对二方包和三方包进行单独管理，并采用不同的更新策略来更新不同环节的二方包和三方包，避免在各个环节中使用二方包和三方包时出现冲突，实现提高二方包和三方包的处理效率的目的。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本发明实施例公开的一种依赖包的处理系统的架构图；
图2为本发明实施例公开的一种依赖包的处理方法的流程示意图；
图3为本发明实施例公开的在开发环节中APP和二方包进行编译的示意图；
图4为本发明实施例公开的在测试环节中APP和二方包进行测试的示意图；
图5为本发明实施例公开的在发布环节中APP和二方包进行发布的示意图；
图6为本发明实施例公开的将编译后的二方包上传至测试库进行测试，若编译后的二方包通过测试，则将通过测试的二方包上传至发布库的流程示意图；
图7为本发明实施例公开的一种依赖包的处理系统的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
由背景技术可知，有技术方案对二方包和三方包没有单独的处理方式，对二方包和三方包仅使用一个处理方式，导致各环节中使用二方包和三方包出现冲突，从而造成在软件开发过程中处理二方包和三方包的效率低下。
为了解决该问题，本发明实施例公开了一种依赖包的处理方法及系统，按照不同环节对二方包和三方包进行单独管理，并采用不同的更新策略来更新不同环节的二方包和三方包，避免在各个环节中使用二方包和三方包时出现冲突，实现提高二方包和三方包的处理效率的目的。具体实现方式通过下述实施例具体进行说明。
如图1所示，为本发明实施例公开的一种依赖包的处理系统的架构图，该依赖包的处理系统的架构图包括开发库11、测试库12、发布库13和APP。
依赖包的处理过程如下：
依赖包的处理过程包括开发环节、测试环节和发布环节。
在开发环节中，APP从开发库11中获取开发中的二方包，当开发中的二方包所对应的源代码的功能与预设的代码功能一致时，将源代码进行编译，生成待测试的二方包。
开发库11中的二方包允许开发人员上传。上传二方包时需要设置该二方包的版本号，二方包被上传到开发库，允许使用库里已存在的版本号。当APP引用该二方包时，则得到该版本号的最新发布的包。
若开发库11和发布库13中都存在相同版本的二方包，则使用发布库13中的二方包对应的源代码进行编译。
在测试环节中，测试人员将需要测试的二方包上传到测试库12，测试库12只允许测试人员上传二方包。若二方包没有通过测试，需要由开发人员修改该测试没有通过的二方包，再重新提交修改后的二方包测试。开发人员没有权限上传包到测试库12。只有测试人员有权限在测试库12中推送待测试的二方包进行测试。
测试库12支持上传库中已存在版本号的包，在测试库12中进行测试的二方包都是该版本号的最新发布的包。
在发布环节中，发布人员将通过测试的二方包上传到发布库13，基于发布库13中预先存储的三方包，对发布库13中通过测试的二方包进行发布。
发布库13中不允许上传已存在相同版本号的二方包。
本发明实施例中，按照不同环节对二方包和三方包进行单独管理，不同环节由不同的角色上传二方包，避免了二方包的跨环节使用，并且采用不同的更新策略来更新不同环节的二方包和三方包，避免在各个环节中使用二方包和三方包时出现冲突，实现提高二方包和三方包的处理效率的目的。
如图2所示，为本发明实施例公开的一种依赖包的处理方法的流程示意图，该依赖包的处理方法主要包括如下步骤：
步骤S201：在开发环节中，从开发库获取开发中的二方包所对应的源代码。
在步骤S201中，开发库中存储着开发环节中的二方包，若APP需要和开发中的二方包进行编译，则使用开发库中的二方包所对应的源代码进行编译。
二方包是指企业自行开发且可由企业内部自行开发的软件依赖包。由于二方包是由企业自行开发和管理，因此二方包的开发流程需要遵循企业内部的软件开发流程，通常都会分为开发环节、测试环节和发布环节三个主要阶段，企业内部的其他软件在使用二方包时可能会用到上述环节的依赖包。
当开发中的二方包发生了代码更新时，则将发生了代码更新的开发中的二方包上传到开发库中，该开发中的二方包的版本号不变。
可选的，若正在研发的二方包执行更新操作，则得到更新后的二方包，将更新后的二方包上传至开发库，当更新后的二方包进行联调操作时，将开发库中更新后的二方包、发布库中已经发布的二方包和发布库中的三方包进行打包。
发布库中存储着已经发布的二方包和三方包。
三方包是由企业外部组织开发的依赖包。
三方包由于是由外部组织开发和管理，企业能够使用到的三方包是达到了三方包开发组织发布标准的版本。
为了方便理解当开发中的二方包发生了代码更新时，将发生了代码更新的开发中的二方包上传到开发库中，该开发中的二方包的版本号不变的过程，这里举例进行说明：
例如，当开发中的二方包a.lib 1.0.1发生了代码更新，将发生了代码更新的二方包a.lib 1.0.1上传到开发库，该二方包的版本号依旧为a.lib 1.0.1。
如图3所示，为在开发环节中APP和二方包进行编译的示意图。
图3中，开发库中存储着a.lib 1.0.1版本的依赖包。
发布库中存储着a.lib 1.0.0版本的二方包、b.lib 2.0.0版本的二方包和c.lib1.2.0版本的三方包。
APP构建打包时使用最新版本号的依赖包。APP构建打包时使用三种依赖包，即从开发库获取a.lib 1.0.1版本的二方包，从发布库获取已经发布的b.lib2.0.0版本的二方包和c.lib 1.2.0版本的三方包。
步骤S202：当源代码对应的功能与预设的代码功能一致时，将源代码进行编译，生成待测试的二方包。
在步骤S202中，开发库中不同的开发中的二方包的源代码所对应的功能不一样。
预设的代码功能可以是查找功能、循环功能等，具体预设的代码功能的设置根据实际情况由技术人员进行设置，本发明不做具体限定。
可选的，当源代码对应的功能与预设的代码功能不一致时，不对该源代码进行编译操作。
步骤S203：将待测试的二方包上传至测试库进行测试，若待测试的二方包通过测试，则将通过测试的二方包上传至发布库。
在步骤S203中，基于预先获取到的运行程序对待测试的二方包进行编译，生成待测试程序，通过预设的测试数据对待测试程序进行测试，得到测试结果，基于该测试结果确定待测试的二方包是否通过测试。
测试库中存储已经提交测试的编译后的二方包，只有测试人员有权限在测试库中推送编译后的二方包进行测试。
可选的，若待测试的二方包未通过测试，将编译后的二方包发送至开发库。
需要说明的是，若未通过测试，未通过测试的版本的二方包被打回开发环节，当再次将编译后的二方包上传至测试库进行测试时，二方包的版本号不发生变化，但是APP构建打包则使用测试库中二方包的最新版本。
如图4所示，为在测试环节中APP和二方包进行测试的示意图。
图4中，测试库中存储着a.lib 1.0.1版本的二方包,。
发布库中存储着a.lib 1.0.0版本的二方包、b.lib 2.0.0版本的二方包和c.lib1.2.0版本的三方包。
在测试环节中，APP使用三种依赖包，即从测试库获取a.lib 1.0.1版本的二方包，从发布库获取已经发布的b.lib 2.0.0版本的二方包和c.lib 1.2.0版本的三方包。
开发环节和测试环节允许上传相同版本号的二方包。应用在不改变代码和配置的情况下，就可以使用最新的依赖包。这种方式使二方包的更新对应用做到了透明。
步骤S204：基于发布库中预先存储的三方包，对发布库中通过测试的二方包进行发布。
在步骤S204中，在发布环节中，发布人员通过发布库中预先存储的三方包，即通过达到三方包开发组织发布标准的版本对发布库中通过测试的二方包进行发布。
如图5所示，为在发布环节中APP和二方包进行发布的示意图。
图5中，发布库中存储着a.lib 1.0.0版本的二方包、a.lib 1.0.1版本的二方包、b.lib 2.0.0版本的二方包、c.lib 1.2.0版本的三方包、d.lib 3.1.1版本的三方包和e.lib 9.0.1版本的三方包。
APP A使用a.lib 1.0.1版本的二方包、b.lib 2.0.0版本的二方包和c.lib 1.2.0版本的三方包。
APP B使用a.lib 1.0.1版本的二方包和c.lib 1.2.0版本的三方包。
APP C使用d.lib 3.1.1版本的三方包和e.lib 9.0.1版本的三方包。
APP D使用a.lib 1.0.0版本的二方包和b.lib 2.0.0版本的二方包。
需要说明的是，各个APP根据各自不同的需求使用发布库中已经发布的依赖包。
例如，当APP A想使用低版本的a.lib的二方包时，使用a.lib 1.0.0版本的二方包，而不使用新版本的a.lib 1.0.1版本的二方包。
本发明实施例中，按照不同环节对二方包和三方包进行单独管理，不同环节由不同的角色上传二方包，避免了二方包的跨环节使用，并且采用不同的更新策略来更新不同环节的二方包和三方包，避免在各个环节中使用二方包和三方包时出现冲突，实现提高二方包和三方包的处理效率的目的。
上述步骤S203中涉及到将编译后的二方包上传至测试库进行测试，若编译后的二方包通过测试，则将通过测试的二方包上传至发布库的过程，如图6所示。
步骤S601：将待测试的二方包上传至测试库，使测试库基于预先获取到的运行程序对待测试的二方包进行编译，生成待测试程序。
在步骤S601中，将待测试的二方包上传至测试库，测试库基于预先获取到的运行程序对待测试的二方包进行编译，生成待测试程序，从而使待测试的二方包融入至待测试程序中。
步骤S602：通过预设的测试数据对待测试程序进行测试，得到测试结果。
在步骤S602中，对得到的测试结果与期望输出的测试结果进行比较分析。
对待测试程序进行测试的方式可以是动态测试，也可以是静态测试，具体测试的方式的确定根据实际情况由技术人员进行设置，本发明不做具体限定。
步骤S603：判断测试结果是否与预设结果一致，若是，则执行步骤S604，若否，则执行步骤S605。
在步骤S603中，预设结果即为期望输出的测试结果，当测试结果与期望输出的测试结果一致，则确定编译后的二方包通过测试。
步骤S604：确定待测试的二方包通过测试，将通过测试的二方包上传至发布库。
步骤S605：确定待测试的二方包未通过测试。
在步骤S605中，若待测试的二方包未通过测试，测试未通过的版本的二方包被打回开发环节，当再次将待测试的二方包上传至测试库进行测试时，二方包的版本号不发生变化。
本发明实施例中，将待测试的二方包上传至测试库，使测试库基于预先获取到的运行程序对所述待测试的二方包进行编译，生成待测试程序，通过预设的测试数据对待测试程序进行测试，得到测试结果，若测试结果是否与预设结果一致，确定待测试的二方包通过测试，实现将通过测试的二方包上传至发布库进行发布的目的。
基于上述图2中示出了一种依赖包的处理方法，本发明实施例还对应公开了一种依赖包的处理系统，如图7所示，该依赖包的处理系统主要包括：
获取单元701，用于在开发环节中，从开发库中获取开发中的二方包对应的源代码。
编译单元702，用于当源代码对应的功能与预设的代码功能一致时，将源代码进行编译，生成待测试的二方包。
测试单元703，用于将待测试的二方包上传至测试库进行测试，若待测试的二方包通过测试，则将通过测试的二方包上传至发布库。
发布单元704，用于基于发布库中预先存储的三方包，对发布库中通过测试的二方包进行发布。
其中，在发布环节中，发布人员通过发布库中预先存储的三方包，即通过达到三方包开发组织发布标准的版本对发布库中通过测试的二方包进行发布。
可选的，还包括更新单元、上传单元和打包单元。
更新单元，用于若开发中的二方包执行更新操作，则得到更新后的二方包。
上传单元，用于将更新后的二方包上传至所述开发库。
打包单元，用于当更新后的二方包进行联调操作时，将开发库中更新后的二方包、发布库中已经发布的二方包和发布库中的三方包进行打包。
进一步的，测试单元703，包括编译模块、测试模块和确定模块。
编译模块，用于将待测试的二方包上传至测试库，使测试库基于预先获取到的运行程序对待测试的二方包进行编译，生成待测试程序。
测试模块，用于通过预设的测试数据对待测试程序进行测试，得到测试结果。
确定模块，用于若测试结果与预设结果一致，则确定待测试的二方包通过测试，将通过测试的二方包上传至发布库。
可选的，还包括确定单元。
确定单元，用于若测试结果与预设结果不一致，则确定待测试的二方包未通过测试。
其中，若测试未通过，测试未通过的版本的二方包被打回开发环节，当再次将编译后的二方包上传至测试库进行测试时，二方包的版本号不发生变化，但是APP构建打包则使用测试库中二方包的最新版本。
可选的，还包括发送单元。
发送单元，用于若待测试的二方包未通过测试，将编译后的二方包发送至开发库。
本发明实施例中，按照不同环节对二方包和三方包进行单独管理，不同环节由不同的角色上传二方包，避免了二方包的跨环节使用，并且采用不同的更新策略来更新不同环节的二方包和三方包，避免在各个环节中使用二方包和三方包时出现冲突，实现提高二方包和三方包的处理效率的目的。
对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于系统类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本发明各实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
Claims (10)
1.一种依赖包的处理方法，其特征在于，所述方法包括：
在开发环节中，从开发库获取开发中的二方包所对应的源代码；
当所述源代码对应的功能与预设的代码功能一致时，将所述源代码进行编译，生成待测试的二方包；
将所述待测试的二方包上传至测试库进行测试，若所述待测试的二方包通过测试，则将通过测试的二方包上传至发布库；
基于所述发布库中预先存储的三方包，对所述发布库中通过测试的二方包进行发布。
2.根据权利要求1所述的方法，其特征在于，还包括：
若所述开发中的二方包执行更新操作，则得到更新后的二方包；
将所述更新后的二方包上传至所述开发库；
当更新后的二方包进行联调操作时，将所述开发库中更新后的二方包、所述发布库中已经发布的二方包和所述发布库中的三方包进行打包。
3.根据权利要求1所述的方法，其特征在于，所述将所述待测试的二方包上传至测试库进行测试，若所述待测试的二方包通过测试，则将通过测试的二方包上传至发布库，包括：
将所述待测试的二方包上传至测试库，使所述测试库基于预先获取到的运行程序对所述待测试的二方包进行编译，生成待测试程序；
通过预设的测试数据对所述待测试程序进行测试，得到测试结果；
若测试结果与预设结果一致，则确定待测试的二方包通过测试，将通过测试的二方包上传至发布库。
4.根据权利要求3所述的方法，其特征在于，还包括：
若所述测试结果与所述预设结果不一致，则确定所述待测试的二方包未通过测试。
5.根据权利要求1或4所述的方法，其特征在于，还包括：
若所述待测试的二方包未通过测试，将所述编译后的二方包发送至所述开发库。
6.一种依赖包的处理系统，其特征在于，所述系统包括：
获取单元，用于在开发环节中，从开发库获取开发中的二方包所对应的源代码；
编译单元，用于当所述源代码对应的功能与预设的代码功能一致时，将所述源代码进行编译，生成待测试的二方包；
测试单元，用于将所述待测试的二方包上传至测试库进行测试，若所述待测试的二方包通过测试，则将通过测试的二方包上传至发布库；
发布单元，用于基于所述发布库中预先存储的三方包，对所述发布库中通过测试的二方包进行发布。
7.根据权利要求6所述的系统，其特征在于，还包括：
更新单元，用于若所述开发中的二方包执行更新操作，则得到更新后的二方包；
上传单元，用于将所述更新后的二方包上传至所述开发库；
打包单元，用于当更新后的二方包进行联调操作时，将所述开发库中更新后的二方包、所述发布库中已经发布的二方包和所述发布库中的三方包进行打包。
8.根据权利要求6所述的系统，其特征在于，所述测试单元，包括：
编译模块，用于将所述待测试的二方包上传至测试库，使所述测试库基于预先获取到的运行程序对所述待测试的二方包进行编译，生成待测试程序；
测试模块，用于通过预设的测试数据对所述待测试程序进行测试，得到测试结果；
确定模块，用于若所述测试结果与预设结果一致，则确定所述待测试的二方包通过测试，将通过测试的二方包上传至发布库。
9.根据权利要求6所述的系统，其特征在于，还包括：
确定单元，用于若所述测试结果与所述预设结果不一致，则确定所述待测试的二方包未通过测试。
10.根据权利要求6或9所述的系统，其特征在于，还包括：
发送单元，用于若所述待测试的二方包未通过测试，将所述编译后的二方包发送至所述开发库。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110063909.1A CN112667520B (zh) | 2021-01-18 | 一种依赖包的处理方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110063909.1A CN112667520B (zh) | 2021-01-18 | 一种依赖包的处理方法及系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112667520A true CN112667520A (zh) | 2021-04-16 |
| CN112667520B CN112667520B (zh) | 2024-05-14 |
Family
ID=
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104077217A (zh) * | 2013-03-28 | 2014-10-01 | 腾讯科技（深圳）有限公司 | 代码文件的编译发布方法及系统 |
| CN107273281A (zh) * | 2016-04-06 | 2017-10-20 | 阿里巴巴集团控股有限公司 | 基于代码变更的服务化接口测试方法、系统 |
| CN109508203A (zh) * | 2018-11-26 | 2019-03-22 | 中国银行股份有限公司 | 版本一致性确定方法、装置及系统 |
| CN109739523A (zh) * | 2019-01-03 | 2019-05-10 | Oppo广东移动通信有限公司 | 应用程序打包方法、装置、存储介质及终端 |
| US20190392155A1 (en) * | 2018-06-26 | 2019-12-26 | Sri International | Creating software packages for performing secure computations |
| CN111399840A (zh) * | 2020-03-04 | 2020-07-10 | 腾讯音乐娱乐科技（深圳）有限公司 | 一种模块开发方法及装置 |
| CN112083948A (zh) * | 2020-08-28 | 2020-12-15 | 广州九尾信息科技有限公司 | 一种基于数据配置化的自动化构建部署方法及工具 |
| CN112130867A (zh) * | 2020-08-05 | 2020-12-25 | 中国电子科技集团公司第二十八研究所 | 一种研发测试一体化系统 |
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104077217A (zh) * | 2013-03-28 | 2014-10-01 | 腾讯科技（深圳）有限公司 | 代码文件的编译发布方法及系统 |
| CN107273281A (zh) * | 2016-04-06 | 2017-10-20 | 阿里巴巴集团控股有限公司 | 基于代码变更的服务化接口测试方法、系统 |
| US20190392155A1 (en) * | 2018-06-26 | 2019-12-26 | Sri International | Creating software packages for performing secure computations |
| CN109508203A (zh) * | 2018-11-26 | 2019-03-22 | 中国银行股份有限公司 | 版本一致性确定方法、装置及系统 |
| CN109739523A (zh) * | 2019-01-03 | 2019-05-10 | Oppo广东移动通信有限公司 | 应用程序打包方法、装置、存储介质及终端 |
| CN111399840A (zh) * | 2020-03-04 | 2020-07-10 | 腾讯音乐娱乐科技（深圳）有限公司 | 一种模块开发方法及装置 |
| CN112130867A (zh) * | 2020-08-05 | 2020-12-25 | 中国电子科技集团公司第二十八研究所 | 一种研发测试一体化系统 |
| CN112083948A (zh) * | 2020-08-28 | 2020-12-15 | 广州九尾信息科技有限公司 | 一种基于数据配置化的自动化构建部署方法及工具 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109960643B (zh) | 一种代码测试方法和装置 | |
| US9372784B2 (en) | Test system configuration method and system | |
| US8745585B2 (en) | Meta-data for single development test environment | |
| US8533676B2 (en) | Single development test environment | |
| CN108073400A (zh) | 软件自动化构建方法、服务器及存储介质 | |
| US20130174124A1 (en) | Version numbering in single development and test environment | |
| CN111625839A (zh) | 第三方组件漏洞检测方法、装置、设备及计算机存储介质 | |
| CN110795088B (zh) | 前端工程项目构建方法和工具、计算机可读存储介质 | |
| AU2012201749B2 (en) | Single development test environment | |
| CN110262806A (zh) | 一种支持自动化服务编排的DevOps系统 | |
| US7721261B2 (en) | Method and apparatus for generating pairwise combinatorial tests from a graphic representation | |
| CN112965913A (zh) | 一种Java软件依赖冲突问题自动化修复的方法 | |
| Wahler et al. | CAST: Automating software tests for embedded systems | |
| CN109857432A (zh) | 一种游戏应用的热更新方法和装置 | |
| CN110888652A (zh) | 基于jenkins插件的多版本构建方法及终端 | |
| CN105630671A (zh) | 代码覆盖率报告的生成方法及装置 | |
| CN111078265A (zh) | 一种基于jenkins的web项目更新补丁生成方法 | |
| CN112667520A (zh) | 一种依赖包的处理方法及系统 | |
| CN112667520B (zh) | 一种依赖包的处理方法及系统 | |
| CN111240987B (zh) | 移植程序检测方法、装置、电子设备及计算机可读存储介质 | |
| Pautasso | JOpera: An agile environment for web service composition with visual unit testing and refactoring | |
| CN117270864A (zh) | 代码编译方法、装置、设备及存储介质 | |
| EP2503450A2 (en) | Version numbering in single development and test environment | |
| Khazem et al. | Making data-driven porting decisions with Tuscan | |
| EP2503451A2 (en) | Metadata for single development test environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |