一种应用代码包版本管理方法及装置与流程

1.本技术涉及计算机技术领域，更具体地说，是涉及一种应用代码包版本管理方法及装置。


背景技术：

2.近些年，随着devops(development operations)理念的不断推进，各互联网企业都在构建“持续集成、持续发布”的产品服务自动化运维流水线，以保障软件产品和服务的按时交付。然而，随着软件开发效率的提升及开发周期的缩短，伴随着代码的版本管理问题也越发突出。
3.现有软件版本管理中，往往都只关注到了研发过程中的版本管理，能够通过git、svn等平台或工具来对开发过程中的软件进行版本控制。然而，却忽略了对每次上线的应用代码包的管理，经常会出现以下几种情况：1、源代码的研发版本号已经迭代更新了多个版本，而对于应用代码包曾经有过哪些版本、发布过什么环境或部署过什么节点，却缺乏相应的记录；2、当线上应用代码包的版本出现问题，需要回滚到之前的版本时，却难以获知当前环境、当前节点的上一次部署的版本号；3、当需要对服务进行快速扩容时，没有一个可以直接用于部署的应用代码包来应急。以上这些场景，都突显了应用代码包管理在产品交付服务中的重要性。
4.此外，在服务部署、升级、扩容、回滚等操作过程中，应用代码包的传输效率也直接性影响到了服务迭代发布的效率，因此在施工期间如何解决应用代码包在网络中的传输速率问题，也是自动化建设过程中面临的重大问题。


技术实现要素：

5.有鉴于此，本技术提供了一种应用代码包版本管理方法及装置，以提升应用代码包的传输效率。
6.为实现上述目的，本技术第一方面提供了应用代码包版本管理方法，包括：
7.对待存储的应用代码包进行规范性检测，得到检测结果，所述检测结果包括所述应用代码包是否检测通过；
8.对于检测通过的应用代码包，根据所述应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息；
9.根据所述应用信息，从预设的配置管理数据库中获取需要部署所述应用代码包的各节点的节点信息；
10.根据所述各节点的节点信息，确定至少一个目标代码仓库，并将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库。
11.优选地，根据所述各节点的节点信息，确定至少一个目标代码仓库的过程，包括：
12.针对所述各节点中的每个节点：
13.根据所述节点的节点信息，获取候选代码仓库列表，所述候选代码仓库列表包括
至少一个候选代码仓库；
14.获取各候选代码仓库的网络类型、有效带宽、存储空间大小、所述节点到各候选代码仓库的路由跳数；
15.根据所述网络类型、有效带宽、存储空间大小以及所述节点到各候选代码仓库的路由跳数，确定所述节点的目标代码仓库。
16.优选地，根据所述网络类型、有效带宽、存储空间大小以及所述节点到各候选代码仓库的路由跳数，确定所述节点的目标代码仓库的过程，包括：
17.针对每个代码仓库，采用下述公式计算得到所述代码仓库的优先级：
18.p＝100
×
n-j
×
r 50
×
m/1000 (d-500)/1000
19.其中，n为由所述网络类型确定的网络环境系数，j为所述节点到所述候选代码仓库的路由跳数，r为由所述网络类型确定的路由衰减系数，m为所述有效带宽，d为存储空间大小；
20.将优先级最高的候选代码仓库确定为所述目标代码仓库。
21.优选地，对待存储的应用代码包进行规范性检测的过程，包括：
22.检测所述应用代码包的文件格式是否与所述应用代码包所承载的服务的类型相匹配；
23.检测所述应用代码包的命名方式是否符合预设的命名规范；
24.检测所述应用代码包的目录结构是否符合预设的目录结构规范；
25.检测所述应用代码包是否不为锁定状态。
26.优选地，将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库的过程，包括：
27.通知所述目标代码仓库所在的节点的节点代理，由所述节点代理拉取携带有所述指纹信息的所述应用代码包，并由所述节点代理将携带有所述指纹信息的所述应用代码包推送至所述目标代码仓库。
28.优选地，在所述生成指纹信息之后，还包括：
29.将携带有所述指纹信息的所述应用代码包发送至备份仓库，所述备份仓库用于以备份的形式存储所有检测通过的应用代码包。
30.优选地，还包括：
31.当接收到应用代码包的部署请求时，根据部署请求的参数，获取需要部署的节点的信息、应用代码包的目标指纹信息；
32.根据所述需要部署的节点的信息，确定目标代码仓库；
33.判断所述目标代码仓库是否存储有携带有所述目标指纹信息的应用代码包；
34.若是，将所述目标代码仓库的携带有所述目标指纹信息的应用代码包发送至所述需要部署的节点；
35.若否，将备份仓库的携带有所述目标指纹信息的应用代码包发送至所述需要部署的节点。
36.优选地，将所述目标代码仓库的携带有所述目标指纹信息的应用代码包发送至所述需要部署的节点的过程，包括：
37.通知所述需要部署的节点的节点代理，由所述节点代理从所述目标代码仓库拉取
携带有所述目标指纹信息的应用代码包，并由所述节点代理将携带有所述目标指纹信息的应用代码包推送至所述需要部署的节点的主机集群。
38.优选地，还包括：
39.当携带有所述目标指纹信息的应用代码包成功部署到所述需要部署的节点后，根据携带有所述目标指纹信息的应用代码包的测试报告生成所述应用代码包的标签。
40.本技术第二方面提供了一种应用代码包版本管理装置，包括：
41.规范性检测单元，用于对待存储的应用代码包进行规范性检测，得到检测结果，所述检测结果包括所述应用代码包是否检测通过；
42.指纹生成单元，用于对于检测通过的应用代码包，根据所述应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息；
43.信息获取单元，用于根据所述应用信息，从预设的配置管理数据库中获取需要部署所述应用代码包的各节点的节点信息；
44.目标确定单元，用于根据所述各节点的节点信息，确定至少一个目标代码仓库，并将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库。
45.经由上述的技术方案可知，本技术对待存储的应用代码包进行规范性检测，得到检测结果，所述检测结果包括所述应用代码包是否检测通过。对于检测通过的应用代码包，首先，根据所述应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息，其中，所述指纹信息对于每一份应用代码包都是唯一的，能够根据所述指纹信息关联到唯一对应的应用代码包，且可以根据所述指纹信息，验证所述应用代码包文件是否完整无损。然后，根据所述应用信息，从预设的配置管理数据库中获取需要部署所述应用代码包的各节点的节点信息。最后，根据所述各节点的节点信息，确定至少一个目标代码仓库，并将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库。其中，所述目标代码仓库为相对于各节点最为合适的代码仓库。通过将检测通过的应用代码包预先存储至需要部署所述应用代码包的各节点的目标代码仓库，使得所述各节点可以对应用代码包进行就近调度，提升了应用代码包的部署效率，缩短了应用代码包的升级发布时间。
附图说明
46.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
47.图1为本技术实施例公开的应用代码包版本方法在存储部分的示意图；
48.图2为本技术实施例公开的应用代码包版本方法在存储部分的另一示意图；
49.图3为本技术实施例公开的应用代码包版本方法在存储流程的示意图；
50.图4为本技术实施例公开的应用代码包版本方法在部署部分的示意图；
51.图5为本技术实施例公开的应用代码包版本方法在部署流程的示意图；
52.图6为本技术实施例公开的应用代码包版本管理装置中的存储部分的示意图；
53.图7为本技术实施例公开的应用代码包版本管理装置中的存储部分的另一示意图；
54.图8为本技术实施例公开的应用代码包版本管理装置中的部署部分的示意图；
55.图9为本技术实施例公开的应用代码包版本管理装置中的部署部分的另一示意图；
56.图10为本技术实施例公开的应用代码包版本管理设备的示意图。
具体实施方式
57.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
58.项目部署的集中式管理，仅适合规模小、业务架构单一的微小服务，一旦面临复杂架构、跨机房多点部署的服务时，依靠公网从数据中心传输项目的应用代码包，难以满足高效传输需要。
59.对于服务节点分布较广较分散的场景，如果高效地实现项目的快速部署是一件具有挑战性的任务。例如，某ddns服务运行在全国各个十多个省份的云资源池里(如贵州、湖南、河北、江苏、山西等资源池，各个资源池之间网独立通)，每次服务部署升级需要对所有资源池同时进行升级。如果是集中式的包管理，就需要升级时把包通过公网传到各个资源池，然后再逐一升级。这样不仅网络开销大，升级效率也低。
60.而绝对的边缘化，将应用代码包文件分散存储在各个节点上，虽然可以最大程度上减少网络干扰因素、提升传输效率，但也容易造成成本过高、资源分配不合理的问题。
61.本技术的发明人发现，如果在应用代码包上传时就实行分布式存储，则可以依据每个部署节点，把应用代码包存储到对应的一个或多个代码仓库里。如此一来，在应用代码包升级的时候，就能让各个资源池从最近的代码仓库去拉取代码包，降低网络开销并提升整个服务的升级效率。
62.基于此，本技术拟采用适当边缘化的形式，结合网络环境、网络带宽、存储空间等资源属性，制定出应用代码包的版本管理方案，以解决自动化运维建设过程中应用服务版本管理和升级发布传输效率的双重问题。
63.下面介绍本技术实施例提供的应用代码包版本管理方法。请参阅图1，本技术实施例提供的应用代码包版本管理方法可以包括如下步骤：
64.步骤s101，对待存储的应用代码包进行规范性检测。
65.其中，规范性检测后可以得到检测结果，该检测结果包括应用代码包是否检测通过。
66.规范性检测中检测点可以包括：应用代码包的命名规范、文件目录结构的规范、安全性规范等。通过规范性检测可以将不符合规范的应用代码包过滤掉，不作存储处理。
67.步骤s102，对于检测通过的应用代码包，根据该应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息。
68.其中，应用代码包中的应用信息可以包括产品名称、应用类型(如java、python、go、html、node.js等)、服务名称(如服务平台对应英文简称等)。指纹信息对于每一份应用代码包是唯一的，可以用来标识应用代码包。
69.步骤s103，根据该应用信息，从预设的配置管理数据库中获取需要部署该应用代码包的各节点的节点信息。
70.其中，配置管理数据库(configuration management database，cmdb)包含有项目部署的所有相关信息，例如，哪些节点需要部署哪些项目，这些项目依赖于哪些应用代码包，等等。
71.通过查询该预设的配置管理数据库，可以获取需要部署指定应用代码包的各节点的节点信息。其中，对于某应用代码包，可能有多个分散的节点需要对其进行部署，也可能只有一个节点需要对其进行部署。
72.该节点信息可以包括节点附近的代码仓库的网络信息及容量信息等。
73.步骤s104，根据各节点的节点信息，确定至少一个目标代码仓库，并将携带有指纹信息的应用代码包发送至该目标代码仓库。
74.其中，每一个节点必然对应于一个目标代码仓库，同时，可能存在多个节点公用一个目标代码仓库的情况。目标代码仓库为节点附近的代码仓库中，根据预设的算法计算得到的，最适合于存储应用代码包的代码仓库。
75.本技术对待存储的应用代码包进行规范性检测，得到检测结果，所述检测结果包括所述应用代码包是否检测通过。对于检测通过的应用代码包，首先，根据所述应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息，其中，所述指纹信息对于每一份应用代码包都是唯一的，能够根据所述指纹信息关联到唯一对应的应用代码包，且可以根据所述指纹信息，验证所述应用代码包文件是否完整无损。然后，根据所述应用信息，从预设的配置管理数据库中获取需要部署所述应用代码包的各节点的节点信息。最后，根据所述各节点的节点信息，确定至少一个目标代码仓库，并将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库。其中，所述目标代码仓库为相对于各节点最为合适的代码仓库。通过将检测通过的应用代码包预先存储至需要部署所述应用代码包的各节点的目标代码仓库，使得所述各节点可以对应用代码包进行就近调度，提升了应用代码包的部署效率，缩短了应用代码包的升级发布时间。
76.请参阅图2，在本技术的一些实施例中，在上述步骤s102之后，还可以包括：
77.步骤s105，将携带有指纹信息的应用代码包发送至备份仓库。
78.其中，该备份仓库用于以备份的形式存储所有检测通过的应用代码包。
79.容易理解的是，代码仓库和备份仓库都是用来存放应用代码包的仓库。其中，代码仓库是分布式的资源池，各个代码仓库里应用代码包的数量都是有差异的。示例如，某服务只有一个部署节点，那么，该服务的应用代码包就只会存储在距离这个节点最近的代码仓库里。当服务需要升级发布的时候，各节点从最近的或最优的代码仓库去获取应用代码包。备份仓库是一个全量的应用代码包仓库，其存储有所有服务的应用代码包，当代码仓库里的应用代码包丢失时，可以采用备份仓库里的应用代码包。
80.在本技术的一些实施例中，上述步骤s104根据所述各节点的节点信息，确定至少一个目标代码仓库的过程，可以包括：
81.针对各节点中的每个节点：
82.s1，根据该节点的节点信息，获取候选代码仓库列表。
83.其中，该候选代码仓库列表包括至少一个候选代码仓库。
84.s2，获取各候选代码仓库的网络类型、有效带宽、存储空间大小、该节点到各候选代码仓库的路由跳数。
85.其中，网络类型可以包括内网、专线、公网；有效带宽可以由候选代码仓库所接入的网络的带宽大小以及接入系数所确定，接入系数由接入形式决定，接入形式包括独立带宽和共享带宽。
86.示例性地，假设网络的带宽大小表示为w，接入系数表示为k，则有效带宽m可以表示为m＝w
·
k。
87.s3，根据网络类型、有效带宽、存储空间大小以及该节点到各候选代码仓库的路由跳数，确定该节点的目标代码仓库。
88.由于在确定目标代码仓库的过程中考虑了网络因素及存储空间因素，可以为每个节点选取网络上距离较近、且存储空间足够的代码仓库作为目标代码仓库。
89.在本技术的一些实施例中，上述s3根据所述网络类型、有效带宽、存储空间大小以及所述节点到各候选代码仓库的路由跳数，确定所述节点的目标代码仓库的过程，可以包括：
90.s31，针对每个候选代码仓库，采用下述公式计算得到该候选代码仓库的优先级：
91.p＝100
×
n-j
×
r 50
×
m/1000 (d-500)/1000
92.其中，n为由网络类型确定的网络环境系数，j为该节点到该候选代码仓库的路由跳数，r为由网络类型确定的路由衰减系数，m为有效带宽，d为存储空间大小。
93.示例性地，对于上述的网络环境系数，可以设置为：若网络类型为内网，n＝1.0，若网络类型为专线，n＝0.75，若网络类型为公网，n＝0.5；
94.对于上述的路由衰减系数，可以设置为：若网络类型为内网，r＝0.3，若网络类型为专线，r＝0.2，若网络类型为公网，r＝0.1；
95.对于上述的有效带宽，可以设置为：若接入形式为独立带宽，k＝1，有效带宽等于网络的宽带大小，即m＝w；若接入形式为共享带宽，k＝0.5，有效带宽等于网络的宽带大小的一半，即m＝0.5w。
96.s32，将优先级最高的代码仓库确定为所述目标代码仓库。
97.上述实施例在确定目标代码仓库的过程中，在网络参数方面，考虑到了网络类型(内网、专线及公网)，还考虑到了接入形式(独立带宽、共享带宽)，所采用的公式能够比较充分地体现网络的实际传输能力，便于为节点确定在网络距离上更近的代码仓库，有利于应用代码包的传送。
98.在本技术的一些实施例中，上述步骤s101对待存储的应用代码包进行规范性检测的过程，可以包括：
99.s1，检测该应用代码包的文件格式是否与该应用代码包所承载的服务的类型相匹配。
100.具体地，不同类型的服务会被要求打包成不同文件格式的包，这些文件格式可以包括.war格式、.zip文件格式、.tar..gz文件格式等等。
101.s2，检测该应用代码包的命名方式是否符合预设的命名规范。
102.示例如，该预设的命名规范可以为：项目名-版本号.后缀形式，其中，项目名要和版本管理平台中相应的项目的名称一致，版本号要以x.x.x的格式来表述，其中，x表示数
字，且版本号最少3位数字。
103.s3，检测该应用代码包的目录结构是否符合预设的目录结构规范。
104.示例如，预设的目录结构规范可以为：应用代码包的一级目录下必须包含bin文件及服务的启动停止管理脚本，配置文件都存放在config目录下。
105.s4，检测该应用代码包是否未锁定状态。
106.具体地，应用代码包的部署大致可分为部署自测、部署提测、部署灰度、部署线上4个过程。在部署自测阶段，研发可能需要不断修改bug重复上传同版本代码，所以这个阶段的应用代码包是未锁定状态。从部署提测开始，由软件测试部门介入这个应用代码包的操作，不允许软件研发部门对应用代码包进行覆盖。此时，为避免应用代码包在操作中被改动，应用代码包被设置为锁定状态。如果应用代码包测试不通过，则会将其进行解锁；如果应用代码包测试通过，则一直为锁定状态，直到应用代码包被发布上线。
107.对于上述四项检测项目，任何一项不通过，则应用代码包的检测结果为检测未通过；只有当所有项目都检测通过，应用代码包的检测结果才为检测通过。
108.请参阅图3，在本技术的一些实施例中，上述步骤s104将携带有指纹信息的应用代码包发送至该目标代码仓库的过程，可以包括：
109.a1，通知该目标代码仓库所在的节点的节点代理，由该节点代理拉取携带有该指纹信息的应用代码包，并由该节点代理将携带有该指纹信息的应用代码包推送至该目标代码仓库。
110.上面介绍了应用代码包的存储管理过程，下面对应用代码包的部署管理过程进行介绍。请参阅图4，在本技术的一些实施例提供的应用代码包版本管理方法，还可以包括：
111.步骤s201，当接收到应用代码包的部署请求时，根据部署请求的参数，获取需要部署的节点的信息、应用代码包的目标指纹信息。
112.通常地，部署请求的参数可以包括需要部署的项目名、应用代码包的版本号、部署的环境、以及部署的方式，其中部署的方式可以包括全量部署、分批部署、比例部署、是否逐台重启服务、重启间隔等。
113.此外，一种特殊的部署为版本回滚。由于应用代码包在部署时，会将各个版本的目录文件按文件名 版本号进行管理，而正在运行的文件是没有版本号的，并且通常是由带有版本号的文件软链出来的。基于此，版本回滚可以包括两种情况，一是通过参数传递上个版本的应用代码包，以使用上个版本的应用代码包进行重新部署，二是修改该带有版本号的文件的软链，通过软链直接链接到上个版本的文件。
114.步骤s202，根据需要部署的节点的信息，确定目标代码仓库。
115.本步骤确定目标代码仓库的过程与上述步骤s104中确定目标代码仓库的原理一样，此处不再赘述。
116.步骤s203，判断目标代码仓库是否存储有携带有该目标指纹信息的应用代码包。
117.示例如，首先，依据目标指纹信息获取应用代码包的应用信息、版本号、md5值等信息；然后根据该应用信息、版本号判断目标代码仓库中是否存储有指定的应用代码包；最后，对该应用代码包进行哈希计算，确定该应用代码包的md5值是否与指纹信息中的md5值一致。其中，对md5值进行比对可以检验出传输过程中出现文件受损或应用代码包文件被篡改的情况。
118.若目标代码仓库存储有携带有该目标指纹信息的应用代码包，转去执行步骤s204；否则，转去执行步骤s205。
119.步骤s204，将目标代码仓库的携带有该目标指纹信息的应用代码包发送至需要部署的节点。
120.步骤s205，将备份仓库的携带有目标指纹信息的应用代码包发送至需要部署的节点。
121.可以理解的是，由于目标代码仓库为待部署节点的最优选择，从目标代码仓库中获取应用代码包在传输效率上是最优的。当目标代码仓库中不存在指定的应用代码包，或该应用代码包受损，才从备份仓库中获取该应用代码包。
122.请参阅图5，在本技术的一些实施例中，上述步骤s204将目标代码仓库的携带有该目标指纹信息的应用代码包发送至需要部署的节点的过程，可以包括：
123.b1，通知所述需要部署的节点的节点代理，由该节点代理从目标代码仓库中拉取携带有该目标指纹信息的应用代码包，并由该节点代理将携带有该目标指纹信息的应用代码包推送至需要部署的节点的主机集群。
124.具体地，在每个节点都会设置一个节点代理，节点代理负责应用代码包的传输，以及对待部署的主机或主机集群进行控制。
125.然而，上述a1中的代理节点与b1的代理节点可能并非同一个节点。原因是，在应用代码包的存储流程中，是通过代码仓库所在节点的节点代理进行调用控制的；而在部署流程中，所调用的节点代理是当前待部署节点的节点代理。
126.请参阅图5，代码仓库1对应于节点1，那整个存储流程都是调用节点1的节点代理。假如部署时，需要部署节点1和节点2，而节点2没有独立的代码仓库，节点2和节点1复用代码仓库1。那么在部署的时候，版本管理平台会同时通知节点1的代理节点和节点2的代理节点同时去代码仓库1拉取代码。
127.在本技术的一些实施例提供的应用代码包版本管理方法，还可以包括：
128.当携带有该目标指纹信息的应用代码包成功部署到需要部署的节点后，根据该携带有目标指纹信息的应用代码包的测试报告生成该应用代码包的标签。
129.具体地，该标签可以包括：测试通过、测试不通过、灰度通过、灰度回滚、生产xxx节点通过、生产xxx节点回滚等。其中，应用代码包可同时包括多个标签，示例如，某个应用代码包会同时存在测试通过、灰度通过、生产xxx节点通过这几个标签。
130.通常地，在测试部署结束后，会依据测试报告生成对应的通过或失败标签；而灰度和生产部署完成后，会默认标注通过标签，当发生回滚操作时会自动变更为对应回滚的标签。其中，标签信息是在版本管理平台中的代码包信息管理处进行管理的，具体形式为对某个服务的某个版本号添加或删除标签信息。
131.通过多样化的标签管理，一方面，约束应用代码包必须依次经过研发环境-测试环境-灰度环境-生产环境，大大提升了应用代码包的上线的质量；另一方面，通过节点部署标签，解决不同节点差异版本的管理问题。此外，通过版本管理 标签管理，能够快速提供所有历史上线过的应用代码包进行回滚或部署，解决某些隐患问题需跨版本回滚的需求。
132.下面对本技术实施例提供的应用代码包版本管理装置进行描述，下文描述的应用代码包版本管理装置与上文描述的应用代码包版本管理方法可相互对应参照。
133.请参见图6，本技术实施例提供的应用代码包版本管理装置，可以包括：
134.规范性检测单元21，用于对待存储的应用代码包进行规范性检测，得到检测结果，所述检测结果包括所述应用代码包是否检测通过；
135.指纹生成单元22，用于对于检测通过的应用代码包，根据所述应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息；
136.信息获取单元23，用于根据所述应用信息，从预设的配置管理数据库中获取需要部署所述应用代码包的各节点的节点信息；
137.目标确定单元24，用于根据所述各节点的节点信息，确定至少一个目标代码仓库，并将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库。
138.在本技术的一些实施例中，目标确定单元24根据所述各节点的节点信息，确定至少一个目标代码仓库的过程，可以包括：
139.针对所述各节点中的每个节点：
140.根据所述节点的节点信息，获取候选代码仓库列表，所述候选代码仓库列表包括至少一个候选代码仓库；
141.获取各候选代码仓库的网络类型、有效带宽、存储空间大小、所述节点到各候选代码仓库的路由跳数；
142.根据所述网络类型、有效带宽、存储空间大小以及所述节点到各候选代码仓库的路由跳数，确定所述节点的目标代码仓库。
143.在本技术的一些实施例中，目标确定单元24根据所述网络类型、有效带宽、存储空间大小以及所述节点到各候选代码仓库的路由跳数，确定所述节点的目标代码仓库的过程，可以包括：
144.针对每个代码仓库，采用下述公式计算得到所述代码仓库的优先级：
145.p＝100
×
n-j
×
r 50
×
m/1000 (d-500)/1000
146.其中，n为由所述网络类型确定的网络环境系数，j为所述节点到所述候选代码仓库的路由跳数，r为由所述网络类型确定的路由衰减系数，m为所述有效带宽，d为存储空间大小；
147.将优先级最高的候选代码仓库确定为所述目标代码仓库。
148.在本技术的一些实施例中，规范性检测单元21对待存储的应用代码包进行规范性检测的过程，可以包括：
149.检测所述应用代码包的文件格式是否与所述应用代码包所承载的服务的类型相匹配；
150.检测所述应用代码包的命名方式是否符合预设的命名规范；
151.检测所述应用代码包的目录结构是否符合预设的目录结构规范；
152.检测所述应用代码包是否不为锁定状态。
153.在本技术的一些实施例中，目标确定单元24将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库的过程，可以包括：
154.通知所述目标代码仓库所在的节点的节点代理，由所述节点代理拉取携带有所述指纹信息的所述应用代码包，并由所述节点代理将携带有所述指纹信息的所述应用代码包推送至所述目标代码仓库。
155.请参见图7，在本技术的一些实施例中，该应用代码包版本管理装置，还可以包括：
156.备份单元25，用于将携带有所述指纹信息的所述应用代码包发送至备份仓库，所述备份仓库用于以备份的形式存储所有检测通过的应用代码包。
157.请参见图8，在本技术的一些实施例中，该应用代码包版本管理装置，还可以包括：
158.部署信息接收单元51，用于当接收到应用代码包的部署请求时，根据部署请求的参数，获取需要部署的节点的信息、应用代码包的目标指纹信息；
159.代码仓库确定单元52，用于根据所述需要部署的节点的信息，确定目标代码仓库；
160.目标代码鉴定单元53，用于判断所述目标代码仓库是否存储有携带有所述目标指纹信息的应用代码包；
161.目标代码获取单元54，用于：
162.若目标代码鉴定单元53判断出所述目标代码仓库存储有携带有所述目标指纹信息的应用代码包，将所述目标代码仓库的携带有所述目标指纹信息的应用代码包发送至所述需要部署的节点；
163.若目标代码鉴定单元53判断出所述目标代码仓库并不存储有携带有所述目标指纹信息的应用代码包，将备份仓库的携带有所述目标指纹信息的应用代码包发送至所述需要部署的节点。
164.在本技术的一些实施例中，目标代码获取单元54将所述目标代码仓库的携带有所述目标指纹信息的应用代码包发送至所述需要部署的节点的过程，可以包括：
165.通知所述需要部署的节点的节点代理，由所述节点代理从所述目标代码仓库拉取携带有所述目标指纹信息的应用代码包，并由所述节点代理将携带有所述目标指纹信息的应用代码包推送至所述需要部署的节点的主机集群。
166.请参见图9，在本技术的一些实施例中，该应用代码包版本管理装置，还可以包括：
167.标签生成单元55，用于当携带有所述目标指纹信息的应用代码包成功部署到所述需要部署的节点后，根据携带有所述目标指纹信息的应用代码包的测试报告生成所述应用代码包的标签。
168.本技术实施例提供的应用代码包版本管理装置可应用于应用代码包版本管理设备，如计算机等。可选的，图10示出了应用代码包版本管理设备的硬件结构框图，参照图10，应用代码包版本管理设备的硬件结构可以包括：至少一个处理器31，至少一个通信接口32，至少一个存储器33和至少一个通信总线34。
169.在本技术实施例中，处理器31、通信接口32、存储器33、通信总线34的数量为至少一个，且处理器31、通信接口32、存储器33通过通信总线34完成相互间的通信；
170.处理器31可能是一个中央处理器cpu，或者是特定集成电路asic(application specific integrated circuit)，或者是被配置成实施本技术实施例的一个或多个集成电路等；
171.存储器32可能包含高速ram存储器，也可能还包括非易失性存储器(non-volatile memory)等，例如至少一个磁盘存储器；
172.其中，存储器33存储有程序，处理器31可调用存储器33存储的程序，所述程序用于：
173.对待存储的应用代码包进行规范性检测，得到检测结果，所述检测结果包括所述
应用代码包是否检测通过；
174.对于检测通过的应用代码包，根据所述应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息；
175.根据所述应用信息，从预设的配置管理数据库中获取需要部署所述应用代码包的各节点的节点信息；
176.根据所述各节点的节点信息，确定至少一个目标代码仓库，并将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库。
177.可选的，所述程序的细化功能和扩展功能可参照上文描述。
178.本技术实施例还提供一种存储介质，该存储介质可存储有适于处理器执行的程序，所述程序用于：
179.对待存储的应用代码包进行规范性检测，得到检测结果，所述检测结果包括所述应用代码包是否检测通过；
180.对于检测通过的应用代码包，根据所述应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息；
181.根据所述应用信息，从预设的配置管理数据库中获取需要部署所述应用代码包的各节点的节点信息；
182.根据所述各节点的节点信息，确定至少一个目标代码仓库，并将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库。
183.可选的，所述程序的细化功能和扩展功能可参照上文描述。
184.综上所述：
185.本技术对待存储的应用代码包进行规范性检测，得到检测结果，所述检测结果包括所述应用代码包是否检测通过。对于检测通过的应用代码包，首先，根据所述应用代码包中的应用信息、版本号、上传时间和文件大小，生成指纹信息，其中，所述指纹信息对于每一份应用代码包都是唯一的，能够根据所述指纹信息关联到唯一对应的应用代码包，且可以根据所述指纹信息，验证所述应用代码包文件是否完整无损。然后，根据所述应用信息，从预设的配置管理数据库中获取需要部署所述应用代码包的各节点的节点信息。最后，根据所述各节点的节点信息，确定至少一个目标代码仓库，并将携带有所述指纹信息的所述应用代码包发送至所述目标代码仓库。其中，所述目标代码仓库为相对于各节点最为合适的代码仓库。通过将检测通过的应用代码包预先存储至需要部署所述应用代码包的各节点的目标代码仓库，使得所述各节点可以对应用代码包进行就近调度，提升了应用代码包的部署效率，缩短了应用代码包的升级发布时间。
186.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
187.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他
实施例的不同之处，各个实施例之间可以根据需要进行组合，且相同相似部分互相参见即可。
188.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。