一种版本更新方法、装置、电子设备及存储介质与流程

1.本技术实施例涉及分布式系统技术领域，尤其涉及一种版本更新方法、装置、电子设备及存储介质。


背景技术：

2.随着分布式系统的复杂性日益增加，该系统也会随之被拆分为多种微服务，一个看似简单的系统，其背后可能有数十个或者上百个微服务在支撑。在对分布式系统进行版本升级时，由于分布式系统的迭代升级往往需要涉及到多个微服务，而每个微服务的版本迭代信息以及运行状态需要相应的开发人员、测试人员以及运维工作人员共同参与确定，由此给企业带来了大量的沟通成本。另外，当前的软件升级所涉及到的持续集成(continuous integration，简称ci)和持续交付(continuous delivery，简称cd)，大多都是基于gitlab或者bit buccket等工具捕捉各个微服务的版本迭代事件，并基于捕捉到的版本迭代事件对各个微服务进行自动化部署和自动化测试，最终产生测试报告，并基于测试报告产生对应的代码合并权限，最终由开发人员确认是否上线生产环境。
3.上述版本升级方式在敏捷开发、软件迅速迭代过程中发挥了很大的作用，但是由于这种方式只能关注单个微服务的版本迭代信息，严重影响整个软件的交付质量和交付效率。


技术实现要素：

4.本技术提供一种版本更新方法、装置、电子设备及存储介质，可以针对分布式系统自动地实现版本更新，大大地提高版本管理的灵活性和透明性，从而可以节省大量的人力成本，提高交付质量和交付效率。
5.第一方面，本技术实施例提供了一种版本更新方法，所述方法包括：
6.当检测到目标服务组件的代码入库消息时，将所述目标服务组件合并至与所述目标服务组件关联的目标业务中；
7.获取所述目标业务当前的升级状态，根据所述目标业务的升级状态和所述目标业务的合并结果更新所述目标业务的第一版本信息，所述升级状态包括待测试状态和已升级状态，所述第一版本信息用于指示所述目标业务的升级次数和测试次数；
8.针对所述目标业务合并的目标服务组件进行部署测试，并反馈测试结果；
9.在接收到针对所述测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将所述目标业务的升级状态从所述待测试状态更新为所述已升级状态；
10.在接收到针对所述测试结果的反馈是确认不交付的情况或者未收到针对所述测试结果的反馈的情况下，等待并检测是否有与所述目标业务关联的其他服务组件的代码入库消息。
11.第二方面，本技术实施例还提供了一种版本更新装置，所述装置包括：组件合并模块、版本更新模块和部署测试模块；其中，
12.所述组件合并模块，用于当检测到目标服务组件的代码入库消息时，将所述目标服务组件合并至与所述目标服务组件关联的目标业务中；
13.所述版本更新模块，用于获取所述目标业务当前的升级状态，根据所述目标业务的升级状态和所述目标业务的合并结果更新所述目标业务的第一版本信息，所述升级状态包括待测试状态和已升级状态，所述第一版本信息用于指示所述目标业务的升级次数和测试次数；
14.所述部署测试模块，用于针对所述目标业务合并的目标服务组件进行部署测试，并反馈测试结果；
15.所述版本更新模块，还用于在接收到针对所述测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将所述目标业务的升级状态从所述待测试状态更新为所述已升级状态；在接收到针对所述测试结果的反馈是确认不交付的情况或者未收到针对所述测试结果的反馈的情况下，等待并检测是否有与所述目标业务关联的其他服务组件的代码入库消息。
16.第三方面，本技术实施例提供了一种电子设备，包括：
17.一个或多个处理器；
18.存储器，用于存储一个或多个程序，
19.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本技术任意实施例所述的版本更新方法。
20.第四方面，本技术实施例提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现本技术任意实施例所述的版本更新方法。
21.本技术实施例提出了一种版本更新方法、装置、电子设备及存储介质，当检测到目标服务组件的代码入库消息时，先将目标服务组件合并至与目标服务组件关联的目标业务中；然后获取目标业务当前的升级状态，根据目标业务的升级状态和目标业务的合并结果更新目标业务的第一版本信息；再针对目标业务合并的目标服务组件进行部署测试，并反馈测试结果；在接收到针对测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将目标业务的升级状态从待测试状态更新为已升级状态；在接收到针对测试结果的反馈是确认不交付的情况或者未收到针对测试结果的反馈的情况下，等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。也就是说，在本技术的技术方案中，可以基于目标业务的一个统一的版本信息对目标业务进行版本更新，而不是基于目标业务的各个服务组件的版本信息对目标业务进行版本更新，这样版本升级人员只需要关注目标业务的一个统一的版本信息即可，而无需关注各个服务组件的版本信息。而在现有的版本更新方法中，只能关注到单个服务组件的版本信息，不能满足需要同时关注多个服务组件的版本信息的业务的需求，也不能针对目标业务进行状态追踪，以便运维人员能够及时地捕捉到目标业务的升级状态。因此，和现有技术相比，本技术实施例提出的版本更新方法、装置、电子设备及存储介质，可以针对目标业务自动地实现版本更新，大大地提高版本管理的灵活性和透明性，从而可以节省大量的人力成本，提高交付质量和交付效率；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
附图说明
22.图1是本技术实施例提供的版本更新方法的第一流程示意图；
23.图2是本技术实施例提供的版本更新方法的第二流程示意图；
24.图3是本技术实施例提供的版本更新方法的第三流程示意图；
25.图4是本技术实施例提供的版本文件的结构示意图；
26.图5是本技术实施例提供的第一版本信息更新方法的流程示意图；
27.图6是本技术实施例提供的软件更新系统的架构示意图；
28.图7是本技术实施例提供的版本更新装置的结构示意图；
29.图8是本技术实施例提供的电子设备的结构示意图。
具体实施方式
30.下面结合附图和实施例对本技术作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本技术，而非对本技术的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本技术相关的部分而非全部结构。
31.实施例一
32.图1是本技术实施例提供的版本更新方法的第一流程示意图，该方法可以由版本更新装置或者电子设备来执行，该装置或者电子设备可以由软件和/或硬件的方式实现，该装置或者电子设备可以集成在任何具有网络通信功能的智能设备中。如图1所示，版本更新方法可以包括以下步骤：
33.s101、当检测到目标服务组件的代码入库消息时，将目标服务组件合并至与目标服务组件关联的目标业务中。
34.在本步骤中，当检测到目标服务组件的代码入库消息时，电子设备可以将目标服务组件合并至与目标服务组件关联的目标业务中。具体地，本技术实施例可以预先将目标服务组件与目标业务进行关联，同一个目标业务可以与不同的目标服务进行关联。本技术实施例可以使用第一版本信息表示目标业务的版本信息；使用第二版本表示目标服务组件的版本信息。可选地，代码入库消息可以包括目标服务组件的第二版本信息。例如，假设对于某一个目标服务组件，其第二版本信息可以是以下其中任意一个：第一版本号、第二版本号、
…
、第n版本号；其中，n为大于1的自然数。在不同的开发阶段，该目标服务组件可以有不同的版本号。在版本号级别较低的情况下，该版本号表示服务组件的开发阶段(或者服务阶段)处于较为初级的阶段；在版本号级别较高的情况下，该版本号表示服务组件的开发阶段(或者服务阶段)处于较为高级的阶段。
35.本技术实施例中的服务组件包括但不限于以下至少其中之一：应用程序的代码、测试脚本、配置文件和非关系型数据库变更脚本；服务组件的信息至少包括：服务组件的名称、服务组件的版本号、服务组件所依赖的数据库的版本、服务组件对应的第二版本信息；其中，服务组件对应的第二版本信息包括但不限于以下至少其中之一：新增的接口的名称、修改的功能名称、修复的接口的名称。
36.s102、获取目标业务当前的升级状态，根据目标业务的升级状态和目标业务的合并结果更新目标业务的第一版本信息，升级状态包括待测试状态和已升级状态，第一版本信息用于指示目标业务的升级次数和测试次数。
37.在本步骤中，电子设备可以获取目标业务当前的升级状态，根据目标业务的升级状态和目标业务的合并结果更新目标业务的第一版本信息，升级状态包括待测试状态和已升级状态，第一版本信息用于指示目标业务的升级次数和测试次数。具体地，若目标业务的升级状态为待测试状态，则电子设备可以对目标业务的测试次数进行更新；若目标业务的升级状态为已升级状态，则电子设备可以对目标业务的升级次数和测试次数进行更新。需要说明的是，本技术实施例对目标业务的第一版本信息进行更新时，可以先在代码仓库中确定出目标业务关联的服务组件；然后基于目标业务关联的服务组件对目标业务的第一版本信息进行更新。例如，假设代码仓库中包括四个服务组件，分别为：服务组件a、服务组件b、服务组件c和服务组件d；针对某一个目标业务，假设其所涉及到的服务组件仅包括：服务组件a和服务组件b，那么此时电子设备可以仅基于服务附件a和服务组件b对该目标业务的第一版本信息进行更新。再例如，针对另外一个目标业务，假设其所涉及到的服务仅包括：服务组件c和服务组件d，那么此时电子设备可以仅基于服务组件c和服务组件d对该另外一个目标业务的第一版本信息进行更新。
38.s103、针对目标业务合并的目标服务组件进行部署测试，并反馈测试结果。
39.在本步骤中，电子设备可以针对目标业务合并的目标服务组件进行部署测试，并反馈测试结果。具体地，电子设备在接收到目标服务组件后的预设时间段内，在检测到至少一个与目标业务关联的其他服务组件的合并操作的情况，针对目标服务组件和该至少一个其他服务组件进行部署测试，并反馈测试结果。举例说明，假设目标业务关联的服务组件包括以下三个服务组件，分别为：服务组件a、服务组件b和服务组件c。首次建立该目标业务对应的代码集合时，生成一个该目标业务的第一版本信息v1.0.0.0，该目标业务的升级状态为待测试状态；对服务组件a、服务组件b和服务组件c进行ci/cd部署测试，若测试结果显示不通过，则确定需要修复的服务组件，比如需要修复的是服务组件b和服务组件c；若接收到服务组件b的代码入库消息，则将服务组件b合并至该目标业务中，更新目标业务的第一版本信息为v1.0.0.1，并针对最新版本的服务组件b进行部署与测试，若测试结果显示不通过，则确定需要修复的服务组件，比如需要修复的是服务组件a和服务组件b；若接收到服务组件b的代码入库消息，也接收到服务组件a的代码入库消息，则将服务组件b和服务组件a合并至该目标业务中，更新目标业务的第一版本信息为v1.0.0.2；并针对最新版本的服务组件a和服务组件b进行部署与测试，若测试结果显示不通过，则等待服务组件c的代码入库消息。若接收到服务组件c的代码入库消息，则将服务组件c合并至该目标业务中，更新目标业务的第一版本信息为v1.0.0.3；并针对最新版本的服务组件c进行部署和测试，若吃的是结果显示通过，则确定目标业务的第一版本信息可交付，将v1.0.0.3进行交付，并更新目标业务的升级状态为已升级状态。
40.s104、判断接收到针对测试结果的反馈是确认交付的情况或者确认不交付的情况或者未收到针对测试结果的反馈的情况。
41.s105、在接收到针对测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将目标业务的升级状态从待测试状态更新为已升级状态。
42.s106、在接收到针对测试结果的反馈是确认不交付的情况或者未收到针对测试结果的反馈的情况下，等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。
43.在本技术的具体实施例中，若电子设备接收到针对测试结果的反馈，则可以判断
针对测试结果的反馈是确认交付或者确认不交付；如果针对测试结果的反馈是确认交付，则电子设备可以以当前第一版本信息进行发布升级，并将目标业务的升级状态从待测试状态更新为已升级状态；如果针对测试结果的反馈是确认不交付，则电子设备可以等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。此外，若电子设备未接收到针对测试结果的反馈，则电子设备也可以等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。
44.本技术实施例提出的版本更新方法，当检测到目标服务组件的代码入库消息时，先将目标服务组件合并至与目标服务组件关联的目标业务中；然后获取目标业务当前的升级状态，根据目标业务的升级状态和目标业务的合并结果更新目标业务的第一版本信息；再针对目标业务合并的目标服务组件进行部署测试，并反馈测试结果；在接收到针对测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将目标业务的升级状态从待测试状态更新为已升级状态；在接收到针对测试结果的反馈是确认不交付的情况或者未收到针对测试结果的反馈的情况下，等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。也就是说，在本技术的技术方案中，可以基于目标业务的一个统一的版本信息对目标业务进行版本更新，而不是基于目标业务的各个服务组件的版本信息对目标业务进行版本更新，这样版本升级人员只需要关注目标业务的一个统一的版本信息即可，而无需关注各个服务组件的版本信息。而在现有的版本更新方法中，只能关注到单个服务组件的版本信息，不能满足需要同时关注多个服务组件的版本信息的业务的需求，也不能针对目标业务进行状态追踪，以便运维人员能够及时地捕捉到目标业务的升级状态。因此，和现有技术相比，本技术实施例提出的版本更新方法，可以针对目标业务自动地实现版本更新，大大地提高版本管理的灵活性和透明性，从而可以节省大量的人力成本，提高交付质量和交付效率；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
45.实施例二
46.图2是本技术实施例提供的版本更新方法的第二流程示意图。基于上述技术方案进一步优化与扩展，并可以与上述各个可选实施方式进行结合。如图2所示，版本更新方法可以包括以下步骤：
47.s201、当检测到目标服务组件的代码入库消息时，将目标服务组件合并至与目标服务组件关联的目标业务中。
48.s202、获取目标业务当前的升级状态，若目标业务的升级状态为待测试状态，则对目标业务的测试次数进行更新；若目标业务的升级状态为已升级状态，则对目标业务的升级次数和测试次数进行更新；升级状态包括待测试状态和已升级状态，第一版本信息用于指示目标业务的升级次数和测试次数。
49.在本步骤中，电子设备可以获取目标业务当前的升级状态，若目标业务的升级状态为待测试状态，则电子设备可以对目标业务的测试次数进行更新；若目标业务的升级状态为已升级状态，则电子设备可以对目标业务的升级次数和测试次数进行更新；升级状态包括待测试状态和已升级状态，第一版本信息用于指示目标业务的升级次数和测试次数。在本技术的具体实施例中，目标业务的第一版本信息可以为va.b.c.d；其中，a、b、c、d可以分别表示一个数组；每一个数组可以只包含一个数值，也可以包含多个数值。在上述第一版本信息的格式中，第一位a可以表示目标业务不兼容特性升级；第二位b可以表示目标业务
的特大功能升级，例如，新增支持某个业务线等；第三位c可以表示目标业务的普通升级，即目标业务每升级一次，c位上的一个数值加1；第四位d可以表示目标业务的子交付过程，即已上线部分服务组件，但尚未完全交付完成；目标业务每增加一个子交付过程，d位上的一个数值加1。
50.s203、针对目标业务合并的目标服务组件进行部署测试，并反馈测试结果。
51.在本步骤中，电子设备可以针对目标业务合并的目标服务组件进行部署测试，并反馈测试结果。具体地，电子设备在接收到目标服务组件后的预设时间段内，在检测到至少一个与目标业务关联的其他服务组件的合并操作的情况，针对目标服务组件和该至少一个其他服务组件进行部署测试，并反馈测试结果。具体地，电子设备在针对目标业务合并的目标服务组件进行部署测试时，可以触发目标服务组件的持续集成流程，根据其持续集成流程的执行结果得到目标服务组件的测试结果。例如，若目标服务组件的持续集成流程的执行结果为表示持续集成完成或者成功的结果，则电子设备可以确定目标服务组件的测试结果为测试通过；若服务组件的持续集成流程的执行结果为表示持续集成未完成或者未成功的结果，则电子设备可以确定服务组件的测试结果为测试不通过。
52.s204、判断接收到针对测试结果的反馈是确认交付的情况或者确认不交付的情况或者未收到针对测试结果的反馈的情况。
53.s205、在接收到针对测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将目标业务的升级状态从待测试状态更新为已升级状态。
54.s206、在接收到针对测试结果的反馈是确认不交付的情况或者未收到针对测试结果的反馈的情况下，等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。
55.本技术实施例提出的版本更新方法，当检测到目标服务组件的代码入库消息时，先将目标服务组件合并至与目标服务组件关联的目标业务中；然后获取目标业务当前的升级状态，根据目标业务的升级状态和目标业务的合并结果更新目标业务的第一版本信息；再针对目标业务合并的目标服务组件进行部署测试，并反馈测试结果；在接收到针对测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将目标业务的升级状态从待测试状态更新为已升级状态；在接收到针对测试结果的反馈是确认不交付的情况或者未收到针对测试结果的反馈的情况下，等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。也就是说，在本技术的技术方案中，可以基于目标业务的一个统一的版本信息对目标业务进行版本更新，而不是基于目标业务的各个服务组件的版本信息对目标业务进行版本更新，这样版本升级人员只需要关注目标业务的一个统一的版本信息即可，而无需关注各个服务组件的版本信息。而在现有的版本更新方法中，只能关注到单个服务组件的版本信息，不能满足需要同时关注多个服务组件的版本信息的业务的需求，也不能针对目标业务进行状态追踪，以便运维人员能够及时地捕捉到目标业务的升级状态。因此，和现有技术相比，本技术实施例提出的版本更新方法，可以针对目标业务自动地实现版本更新，大大地提高版本管理的灵活性和透明性，从而可以节省大量的人力成本，提高交付质量和交付效率；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
56.实施例三
57.图3是本技术实施例提供的版本更新方法的第三流程示意图。基于上述技术方案进一步优化与扩展，并可以与上述各个可选实施方式进行结合。如图3所示，版本更新方法
可以包括以下步骤：
58.s301、当检测到目标服务组件的代码入库消息时，将目标服务组件合并至与目标服务组件关联的目标业务中。
59.s302、获取目标业务当前的升级状态，若目标业务的升级状态为待测试状态，则对目标业务的测试次数进行更新；若目标业务的升级状态为已升级状态，则对目标业务的升级次数和测试次数进行更新；升级状态包括待测试状态和已升级状态，第一版本信息用于指示目标业务的升级次数和测试次数。
60.s303、在接收到目标服务组件后的预设时间段内，在检测到至少一个与目标业务关联的其他服务组件的合并操作的情况，针对目标服务组件和该至少一个其他服务组件进行部署测试，并反馈测试结果。
61.在本步骤中，电子设备在接收到目标服务组件后的预设时间段内，在检测到至少一个与目标业务关联的其他服务组件的合并操作的情况，电子设备可以针对目标服务组件和该至少一个其他服务组件进行部署测试，并反馈测试结果。例如，假设目标业务关联的服务组件包括：服务组件a和服务组件b。电子设备在接收到服务组件a之后的预设时间段内，在检测到服务组件b的合并操作的情况，电子设备可以针对服务组件a和服务组件b进行部署测试，并反馈测试结果。
62.具体地，本技术实施例中的服务组件包括但不限于以下至少其中之一：应用程序的代码、测试脚本、配置文件和非关系型数据库变更脚本；组件信息至少包括：服务组件的名称、服务组件的版本号、服务组件所依赖的数据库的版本、服务组件对应的第二版本信息；其中，服务组件对应的第二版本信息包括但不限于以下至少其中之一：新增的接口的名称、修改的功能名称、修复的接口的名称。
63.较佳地，在本技术的具体实施例中，电子设备在检测到目标服务组件的代码入库消息时，将目标服务组件合并至与目标服务组件关联的目标业务中之前，还可以接收用户上传的各个服务组件的组件信息，并对各个服务组件分别标记业务类型；然后将标记有目标业务类型的服务组件合并创建为目标业务，并更新目标业务的升级状态为待测试状态。在接收用户上传的各个服务组件之后，电子设备还可以确定各个服务组件对应的组件类型，然后根据组件类型将各个服务组件分别保存至与组件类型对应的代码群组中。例如，在代码仓库中，应用程序的代码可以被存储至应用程序的代码的组件类型对应的群组(app group)；测试脚本可以被存储至测试脚本的组件类型对应的群组(test script group)；配置文件可以被存储至配置文件的组件类型对应的群组(config template group)；非关系型数据库变更脚本可以被存储至非关系型数据库变更脚本的组件类型对应的群组(schemal group)。本技术实施例中群组的作用是将不同组件类型的服务组件存储至同一个存储空间中，方便用户查询和管理。需要说明的是，本技术实施例中不同的应用程序的代码可以匹配于同一个配置文件，也可以匹配于不同的配置文件；此外，不同的测试脚本可以匹配于同一个配置文件，也可以匹配于不同的配置文件。同样地，本技术实施例中不同的应用程序的代码可以匹配于同一个非关系型数据库变更脚本，也可以匹配于不同的非关系型数据库变更脚本；此外，不同的测试脚本可以匹配于同一个非关系型数据库变更脚本，也可以匹配于不同的非关系型数据库变更脚本。
64.进一步地，本技术实施例中的标签至少可以包括：第一子标签和第二子标签；其
中，第一子标签用于表示目标业务；第二子标签用于表示服务组件的组件类型。示例性地，app1对应的标签可以为project id s1；app2对应的标签可以为project id s2；test script1的标签可以为project id t1；test script2的标签可以为project id t2；config file的标签可以为project id c1；sql script的标签可以为project id d1。
65.图4是本技术实施例提供的版本文件的结构示意图。如图4所示，假设本技术实施例中的代码仓库可以包括：应用程序的代码、测试脚本、配置文件和非关系型数据库变更脚本；其中，应用程序的代码可以包括：app1、app2、
…
、app n；测试脚本可以包括：test script1、test script2、
…
、test script n；n为大于等于1的自然数。此外，配置文件可以为：config file；非关系型数据库变更脚本可以为：sql script。在本技术的优选实施例中，针对每一个服务组件，电子设备都可以预先在其根目录下保存一个版本文件。例如，针对app2，电子设备可以预先在其根目录下保存一个app2的版本文件，该版本文件至少可以包括两个子文件；假设该版本文件的第一个子文件为新增接口对应的子文件；第二个字文件为修复接口对应的子文件；其中，第一个子文件可以包括：app2的名称(service＝app2)、app2的版本号(service.version＝v1.0.0.0)、app2所依赖的数据库的版本(db.version＝v0.0.0.0)、app2对应的新增的接口的名称(新增的接口的名称)。此外，第二个子文件可以包括：app2的名称(service＝app2)、app2的版本号(service.version＝v1.0.0.0)、app2所依赖的数据库的版本(db.version＝v0.0.0.0)、app2对应的修复的接口的名称(修复的接口的名称)。
66.s304、判断接收到针对测试结果的反馈是确认交付的情况或者确认不交付的情况或者未收到针对测试结果的反馈的情况。
67.s305、在接收到针对测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将目标业务的升级状态从待测试状态更新为已升级状态。
68.s306、在接收到针对测试结果的反馈是确认不交付的情况或者未收到针对测试结果的反馈的情况下，等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。
69.图5是本技术实施例提供的第一版本信息更新方法的流程示意图。如图5所示，在第一次交付时，针对目标业务的第一版本信息为v1.0.0.0，此次交付内容只涉及到了部分服务组件，假设此次交付内容只涉及到了app a、app b；其中，app a的第二版本信息为v1.0.0.0；app b的第二版本信息为v1.0.0.0；并假设此次升级还应涉及app c的升级，但是由于app c的变动较大，难度较高，不能与appa和app b一起进行升级并同时完成交付，如果此时基于第一次交付的服务组件a和服务组件b的第二版本信息v1.0.0.0，用户已经可以针对app a和app b相关的接口进行测试，那么此时用户可以分别触发app a和app b的第一次持续集成或者持续交付流程，输出app a和app b的升级错误信息，以便开展针对第一次升级交付进行修复的工作。接下来，在第二次交付时，将目标业务当前的第一版本信息的最后一位加1，得到目标业务更新后的第一版本信息，假设目标业务更新后的第一版本信息为v1.0.0.1，这个第一版本信息将涵盖app c以及其他服务组件的修复版本，例如project_app_a：v1.0.0.1。由于此时已更新目标业务的第一版本信息，则可以开始触发app a、app b和app c的持续集成或者持续交付流程，输出测试报告，并完成此次分布式系统的版本升级工作。假设第二次交付已经能够完成这次版本升级的交付，则该第一版本信息(v1.0.0.1)也完成了它的一次生命周期，此时该目标业务的升级状态可以由待测试状态变更为已升级
状态，即针对此第一版本信息则不再捕捉相关联的代码入库请求事件。
70.图6是本技术实施例提供的软件更新系统的架构示意图。如图6所示，在每一个服务组件完成版本开发后，可以由用户推送到代码仓库，版本管理系统会捕捉该推送事件，并发送通知给版本升级负责人，让该版本升级负责人判断本次推送的服务组件是否可以进行持续集成或者持续交付流程，如果该服务组件可以进行持续集成或者持续交付流程，则版本升级负责人执行一次版本发布操作，由发布系统将目标业务所关联的所有服务组件发送至构建服务器，由构建服务器对目标业务所关联的所有服务组件进行构建和打包，并将构建后的代码包发布到对应的云服务器以及测试用例服务器上，由云服务器和测试服务器配合执行自动化测试流程，最终输出测试结果。本技术实施例中的云服务器可以为混合云，该混合云可以同时包括本地云和远程云；也可以只包括本地云或者只包括远程云。例如，远程云可以为：亚马逊云、阿里云等。
71.进一步地，如果测试结果满足目标业务的交付条件，则版本管理系统会自动地对代码仓库的相关的服务组件发送标记正式版本号的指令，基于标记为正式版本号的相关的服务组件对目标业务的第一版本信息进行更新，得到目标业务更新后的第一版本信息。如果测试结果不满足目标业务的交付条件，则继续执行上述捕捉代码入库消息的操作；直到完成目标业务的软件升级。示例性地，各个微服务的标记的格式可以为：project_app_a：v1.0.0.0，其中project_app_a为服务组件的名称，v1.0.0.0为服务组件的第二版本信息。此外，判断目标业务是否满足交付的条件可以为：目标业务所关联的测试用例组下的测试用例是否都能正常部署并没有任何错误。
72.本技术实施例提出的版本更新方法，当检测到目标服务组件的代码入库消息时，先将目标服务组件合并至与目标服务组件关联的目标业务中；然后获取目标业务当前的升级状态，根据目标业务的升级状态和目标业务的合并结果更新目标业务的第一版本信息；再针对目标业务合并的目标服务组件进行部署测试，并反馈测试结果；在接收到针对测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将目标业务的升级状态从待测试状态更新为已升级状态；在接收到针对测试结果的反馈是确认不交付的情况或者未收到针对测试结果的反馈的情况下，等待并检测是否有与目标业务关联的其他服务组件的代码入库消息。也就是说，在本技术的技术方案中，可以基于目标业务的一个统一的版本信息对目标业务进行版本更新，而不是基于目标业务的各个服务组件的版本信息对目标业务进行版本更新，这样版本升级人员只需要关注目标业务的一个统一的版本信息即可，而无需关注各个服务组件的版本信息。而在现有的版本更新方法中，只能关注到单个服务组件的版本信息，不能满足需要同时关注多个服务组件的版本信息的业务的需求，也不能针对目标业务进行状态追踪，以便运维人员能够及时地捕捉到目标业务的升级状态。因此，和现有技术相比，本技术实施例提出的版本更新方法，可以针对目标业务自动地实现版本更新，大大地提高版本管理的灵活性和透明性，从而可以节省大量的人力成本，提高交付质量和交付效率；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
73.实施例四
74.图7为本技术实施例提供的版本更新装置的结构示意图。如图7所示，所述版本更新装置包括：组件合并模块701、版本更新模块702和部署测试模块703；其中，
75.所述组件合并模块701，用于当检测到目标服务组件的代码入库消息时，将所述目
标服务组件合并至与所述目标服务组件关联的目标业务中；
76.所述版本更新模块702，用于获取所述目标业务当前的升级状态，根据所述目标业务的升级状态和所述目标业务的合并结果更新所述目标业务的第一版本信息，所述升级状态包括待测试状态和已升级状态，所述第一版本信息用于指示所述目标业务的升级次数和测试次数；
77.所述部署测试模块703，用于针对所述目标业务合并的目标服务组件进行部署测试，并反馈测试结果；
78.所述版本更新模块702，还用于在接收到针对所述测试结果的反馈是确认交付的情况下，以当前第一版本信息进行发布升级，并将所述目标业务的升级状态从所述待测试状态更新为所述已升级状态；在接收到针对所述测试结果的反馈是确认不交付的情况或者未收到针对所述测试结果的反馈的情况下，等待并检测是否有与所述目标业务关联的其他服务组件的代码入库消息。
79.进一步的，所述版本更新模块702，具体用于若所述目标业务的升级状态为所述待测试状态，则对所述目标业务的测试次数进行更新；若所述目标业务的升级状态为所述已升级状态，则对所述目标业务的升级次数和测试次数进行更新。
80.上述版本更新装置可执行本技术任意实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本技术任意实施例提供的版本更新方法。
81.实施例五
82.图8是本技术实施例提供的电子设备的结构示意图。图8示出了适于用来实现本技术实施方式的示例性电子设备的框图。图8显示的电子设备12仅仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
83.如图8所示，电子设备12以通用计算设备的形式表现。电子设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
84.总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。
85.电子设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
86.系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)30和/或高速缓存存储器32。电子设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图8未显示，通常称为“硬盘驱动器”)。尽管图8中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd
‑
rom，dvd
‑
rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本技术各
实施例的功能。
87.具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如存储器28中，这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本技术所描述的实施例中的功能和/或方法。
88.电子设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该电子设备12交互的设备通信，和/或与使得该电子设备12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口22进行。并且，电子设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器20通过总线18与电子设备12的其它模块通信。应当明白，尽管图8中未示出，可以结合电子设备12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
89.处理单元16通过运行存储在系统存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现本技术实施例所提供的版本更新方法。
90.实施例六
91.本技术实施例六提供了一种计算机存储介质。
92.本技术实施例的计算机可读存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
93.计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
94.计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于无线、电线、光缆、rf等等，或者上述的任意合适的组合。
95.可以以一种或多种程序设计语言或其组合来编写用于执行本技术操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c ，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在
涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
96.注意，上述仅为本技术的较佳实施例及所运用技术原理。本领域技术人员会理解，本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由所附的权利要求范围决定。