代码异常处理方法、系统和存储介质与流程

1.本技术实施例涉及软件研发技术领域，尤其涉及一种代码异常处理方法、系统和存储介质。


背景技术：

2.在软件研发过程中，现有技术中在代码完成后，通过相关工具提交到git服务器，进行分支构建与合并，再切换到jenkins服务器，做代码构建，并重复这两个步骤完成软件产品的研发。
3.然而，由于现有技术中，git服务器与jenkins服务器之间相互独立，各自独立进行相关事务的处理，因此，在代码处理过程中，开发人员很难获取到各服务器对代码的处理情况，如提交的代码是否有问题、分支合并是否存在冲突等，往往要等到测试的时候才发现问题。这就使得开发人员不能及时发现问题，进而导致解决问题也比较滞后，从而影响软件研发效率和质量。


技术实现要素：

4.本技术实施例提供一种代码异常处理方法、系统和存储介质，以解决现有技术中存在的软件研发效率和质量不高的问题。
5.第一方面，本技术实施例提供一种代码异常处理方法，包括：
6.当接收到用户提交的代码时，调用git服务器为所述代码创建分支；
7.获取所述代码的分支创建状态；
8.若所述分支创建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
9.可选地，所述方法还包括：
10.若所述分支创建状态为成功，则调用所述git服务器对所述代码进行分支合并；
11.获取所述代码的分支合并状态；
12.若所述分支合并状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
13.可选地，所述方法还包括：
14.若所述分支合并状态为成功，则调用jenkins服务器对进行分支代码构建；
15.获取分支代码构建状态；
16.若所述分支代码构建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
17.可选地，所述方法还包括：
18.若所述分支代码构建状态为成功，则调用所述git服务器对所述代码进行主线合并；
19.获取所述代码的主线合并状态；
20.若所述主线合并状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
21.可选地，所述方法还包括：
22.若所述主线合并状态为成功，则调用所述jenkins服务器进行主线代码构建；
23.获取主线代码构建状态；
24.若所述主线代码构建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
25.可选地，所述方法还包括：
26.若所述主线代码构建状态为成功，则通知第三方对所述代码对应的产品进行验收；
27.若验收通过，则控制告警灯显示第二颜色，以进行验收通过提示。
28.可选地，所述控制告警灯显示第一颜色之后，所述方法还包括：
29.监测所述告警灯显示第一颜色的时长；
30.根据所述时长与预设时长分区，向目标责任人发送异常告警信息。
31.可选地，所述方法还包括：
32.将代码处理状态发送给显示器，以使所述显示器对所述代码处理状态进行可视化展示，所述代码处理状态为分支创建状态、分支合并状态、分支代码构建状态、主线合并状态、主线代码构建状态中的一种。
33.第二方面，本技术实施例提供一种代码异常处理系统，包括：主服务器、git服务器、jenkins服务器、告警灯和显示器；
34.所述主服务器与所述git服务器、所述jenkins服务器、所述告警灯、所述显示器分别连接，用于实现如上述第一方面所述的代码异常处理方法。
35.第三方面，本技术实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的代码异常处理方法。
36.本技术实施例提供的代码异常处理方法、系统和存储介质，通过主服务器调用git服务器和jenkins服务器对代码进行处理，并获取git服务器及jenkins服务器对代码处理的代码处理状态，当根据代码处理状态发现代码存在异常时，及时通过告警灯进行异常告警，以提醒开发人员及时进行异常处理，从而提高了软件的研发效率和质量。
附图说明
37.图1为本技术实施例一提供的代码异常处理系统的结构示意图；
38.图2为本技术实施例二提供的代码异常处理方法的流程示意图；
39.图3为本技术实施例二提供的代码处理的阶段示意图；
40.图4为本技术实施例三提供的代码异常处理装置的结构示意图；
41.图5为本技术实施例四提供的一种主服务器的结构示意图。
具体实施方式
42.下面结合附图和实施例对本技术作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本技术，而非对本技术的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本技术相关的部分而非全部结构。
43.首先，对本技术实施例涉及到的名词进行如下解释：
44.分支创建：为代码创建分支(即代码的临时存放位置)；
45.分支合并：将代码存放到所创建的分支中；
46.分支代码构建：对分支中的代码进行打包、编译等代码构建处理；
47.主线合并：将分支中的代码存放到主线中，主线用于存储特定产品的所有分支代码；
48.主线代码构建：对主线中的所有代码进行打包、编译等代码构建处理。
49.本技术技术方案的主要思路：基于现有技术中存在的技术问题，本技术提供一种代码异常处理方案，通过设置主服务器分别与git服务器及jenkins服务器分别连接，并设置告警灯，及时获取git服务器及jenkins服务器对代码的处理情况，当发现代码存在异常时，及时通过告警灯进行异常告警，以提醒开发人员及时进行异常处理，从而提高了软件的研发效率和质量。
50.实施例一
51.图1为本技术实施例一提供的代码异常处理系统的结构示意图，如图1所示，本实施例中的代码异常处理系统100包括：
52.主服务器110、git服务器120、jenkins服务器130和告警灯140，主服务器110与git服务器120、jenkins服务器130和告警灯140分别连接。
53.其中，主服务器110上存储有预先编写的代码异常处理程序，该代码异常处理程序中包括在代码开发的各个阶段主服务器应用执行的具体操作，从而保证主服务器110在相应阶段通过调用git服务器120或jenkins服务器130对代码进行处理，同时获取代码处理结果，根据代码处理结果控制告警灯140显示的颜色或颜色的显示方式等。
54.git服务器120，实质上是一个git代码仓库，用于对代码进行管理，主要具有为代码创建分支、进行分支合并等功能。
55.jenkins服务器130，实质上是一个代码构建工具，能够根据需要分别进行分支代码构建和主线代码构建等。
56.告警灯140，能够根据预先设置的颜色显示策略，显示不同的颜色(如红色、绿色等)或采用不同的方式进行颜色的显示(如长亮、闪烁等)，从而通过可视化的方式将代码的处理情况及时告知给用户，尤其是当代码处理存在异常时，可以起到及时告警的作用。
57.可选地，本实施例中的告警灯140为熔岩灯，熔岩灯可以设置在研发部门比较显眼的位置，以达到对开发人员进行提醒的目的。
58.可选地，根据实际场地的分布情况及研发项目的个数等，本实施例中可以设置多个告警灯140，如在每个研发区域均设置告警灯一定数量的告警灯，每个告警灯140对应一个研发项目，通过事先设置好告警灯140的接口及配置信息，当某研发项目的代码处理存在异常时，通过主服务器110控制相应区域的相应告警灯告警即可，从而达到对相应开发人员进行提醒的目的。
59.可选地，本实施例中的代码异常处理系统100还包括：显示器150。
60.显示器150与主服务器110连接，主服务器110还可以将各节点的代码处理结果发送给显示器150，以使显示器对处理结果进行可视化展示，从而便于开发人员可以及时查看具体的异常信息，如产生异常的节点、异常类型、责任人等，便于问题的跟踪和解决。
61.可以理解的是，本显示器150的显示内容和格式可根据实际情况进行设定，此处不做限制。显示器150主要用于对代码处理异常进行显示，显示的内容主要可以包括项目名称、需求状态、告警状态、告警类型、告警消息、告警时间、告警人员等。
62.其中，告警状态分为待解决和已解决，告警状态为待解决的，说明需要人为去进行
异常处理，告警状态为已解决的，说明相关异常已经进行了处理。为便于区分，可以待解决告警状态的标记显示为红色，将已解决告警状态的标记显示为绿色。当显示器150显示的告警状态由待解决状态变为已解决状态时，说明代码异常已得到解决，此时，除将告警状态的标记由红色变为绿色外，还可以同时记录解决时间、解决人，以便于后续进行问题追踪和分析。
63.本实施例中，通过设置代码异常处理系统包括主服务器、git服务器、jenkins服务器、告警灯和显示器，主服务器与git服务器、jenkins服务器、告警灯分别连接，通过主服务器实时获取各阶段代码的处理状况，并通过告警灯和显示对异常进行可视化展示，使开发人员可以及时发现各阶段的代码处理异常，并督促开发人员及时解决问题，从而提高了软件的研发效率和质量。
64.实施例二
65.图2为本技术实施例二提供的代码异常处理方法的流程示意图，本实施例的方法可以由本技术实施例一中的主服务器执行。如图2所示，本实施例的代码异常处理方法，包括：
66.s101、当接收到用户提交的代码时，调用git服务器为代码创建分支。
67.本实施例中，开发人员可以在主服务器上进行代码的提交，并进行数据的查看和处理等。相应地，本步骤中，当主服务器接收到用户(即开发人员)提交的代码时，进入代码的分支创建阶段。具体地，由主服务器调用git服务器对当前代码创建分支，记为branch_001。
68.本步骤中，用户提交的代码为用户针对某个任务编写的原始代码。
69.本步骤中，主服务器可以通过向git服务器发送包括用户提交的代码的分支创建消息，以便git服务器根据分支创建消息进行分支创建，从而实现主服务器对git服务器的调用。
70.s102、获取代码的分支创建状态。
71.其中，分支创建状态是一种用于表示分支创建是否成功的状态数据，可以包括成功和失败两种。
72.可选地，本实施例中，可以事先约定相应的标识以对不同的分支创建状态进行表示，示例性地，以一位二进制数表示不同的分支创建状态，如用1表示成功，0表示失败。相反地，也可以用0表示成功，1表示失败。
73.在一种可能的实施方式中，在实施例中，在git服务器完成分支创建后，会向主服务器发送响应消息，响应消息顺携带有分支创建状态。相应地，本步骤中，可以通过对响应消息进行解析，从而提取出代码的分支创建状态。
74.s103、若分支创建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
75.本步骤中，若s102中获取的分支创建状态为失败，则控制告警灯显示第一颜色，以达到异常告警的目的。
76.在一种可能的实施方式中，本步骤中，可以通过向告警灯发送第一消息，通过第一消息控制告警灯显示第一颜色。
77.可选地，本实施例中，第一颜色为红色。
78.s104、若分支创建状态为成功，调用git服务器对代码进行分支合并。
79.本步骤中，若s102中获取的分支创建状态为成功，则主服务器自动触发下一阶段的代码处理流程，进入代码的分支合并阶段。具体地，由主服务器调用git服务器对当前代码进行分支合并，即将当前代码放入到s101所创建的分支中，如将当前代码放入到branch_001中。
80.s105、获取代码的分支合并状态。
81.其中，分支合并状态是一种用于表示分支合并是否成功的状态数据，与分支创建状态类似，本步骤中的，分支合并状态也可以包括成功和失败两种。
82.本步骤中，分支合并状态的表示方式及分支合并状态的获取方式与s102中类似，可以参照s102，此处不再赘述。
83.s106、若分支合并状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
84.本步骤中，若s105中获取的分支合并状态为失败，则控制告警灯显示第一颜色，以达到异常告警的目的。
85.本步骤中，控制告警灯显示第一颜色的具体实施方式与s103中类似，可以参照s103，此处不再赘述。
86.s107、若分支合并状态为成功，则调用jenkins服务器对进行分支代码构建。
87.本步骤中，若s105中的分支合并状态为成功，则主服务器自动触发下一阶段的代码处理流程，进入分支代码构建阶段。具体地，由主服务器调用jenkins服务器对放入分支中的代码进行构建，如对branch_001中的代码进行构建。
88.s108、获取分支代码构建状态。
89.其中，分支代码构建状态是一种用于表示分支代码构建是否成功的状态数据，与分支创建状态、分支合并状态类似，本步骤中，分支代码构建状态也可以包括成功和失败两种。
90.本步骤中，分支代码构建状态的表示方式及分支代码构建状态的获取方式也与s102中类似，可以参照s102，此处不再赘述。
91.s109、若分支代码构建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
92.本步骤中，若s108中获取的分支代码构建状态为失败，则控制告警灯显示第一颜色，以达到异常告警的目的。
93.本步骤中，控制告警灯显示第一颜色的具体实施方式与s103中类似，可以参照s103，此处不再赘述。
94.s110、若分支代码构建状态为成功，则调用git服务器对代码进行主线合并。
95.本步骤中，若s108中获取的分支代码构建状态为成功，则主服务器自动触发下一阶段的代码处理流程，进入代码的主线合并阶段。具体地，由主服务器调用git服务器对放入分支中的代码转移到主线中，如将branch_001中的代码转移到主线中。
96.s111、获取代码的主线合并状态。
97.其中，主线合并状态是一种用于表示主线合并是否成功的状态数据，与分支创建状态、分支合并状态、分支代码构建状态类似，本步骤中，主线合并状态也可以包括成功和失败两种。
98.本步骤中，主线合并状态的表示方式及主线合并状态的获取方式也与s102中类
似，可以参照s102，此处不再赘述。
99.s112、若主线合并状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
100.本步骤中，若s111中获取的主线合并状态为失败，则控制告警灯显示第一颜色，以达到异常告警的目的。
101.本步骤中，控制告警灯显示第一颜色的具体实施方式与s103中类似，可以参照s103，此处不再赘述。
102.s113、若主线合并状态为成功，则调用jenkins服务器进行主线代码构建。
103.本步骤中，若s111中获取的主线合并状态为成功，则主服务器自动触发下一阶段的代码处理流程，进入主线代码构建阶段。具体地，由主服务器调用jenkins服务器对主线中的代码进行构建。
104.可以理解的是，主线中的包括由branch_001转移过来的代码，还包括由同一产品的其他分支转移过来的代码。由产品的一般开发流程可知，为提高产品的开发效率，同一产品，往往会被划分成多个开发任务，由不同的开发人员同时分别进行开发。因此，在同一款产品通常对应一条主线和多个分支，分支的数量与开发任务的数量相等。
105.示例性地，若某产品被划分为5个开发任务，则主服务器可以通过s101为5个开发任务的代码分别创建5个分支branch_001、branch_002、branch_003、branch_004和branch_005，并采用s102
‑
s112对各开发任务对应的代码分别进行处理，当确定各分支代码的主线合并状态均为成功时，则进入主线代码构建阶段，将来源于branch_001、branch_002、branch_003、branch_004和branch_005放在一起进行打包、编译等处理，完成主线代码构建。
106.s114、获取主线代码构建状态。
107.其中，主线代码构建状态是一种用于表示主线代码构建是否成功的状态数据，与分支创建状态、分支合并状态、分支代码构建状态、主线合并状态类似，本步骤中，主线代码构建状态也可以包括成功和失败两种。
108.本步骤中，主线代码构建状态的表示方式及主线代码构建状态的获取方式也与s102中类似，可以参照s102，此处不再赘述。
109.s115、若主线代码构建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
110.本步骤中，若s114中获取的主线代码构建状态为失败，则控制告警灯显示第一颜色，以达到异常告警的目的。
111.本步骤中，控制告警灯显示第一颜色的具体实施方式与s103中类似，可以参照s103，此处不再赘述。
112.s116、若主线代码构建状态为成功，则通知第三方对代码对应的产品进行验收。
113.本步骤中，若s114中获取的主线代码构建状态为成功，则主服务器自动触发下一阶段的代码处理流程，进入产品验收阶段。具体地，通过将相关代码文件打包发送给第三方，并向第三方发送验收消息，以通知第三方对代码对应的产品进行验收。
114.s117、若验收通过，则控制告警灯显示第二颜色，以进行验收通过提示。
115.本步骤中，当第三方对代码对应的产品验证成功时，控制控制告警灯显示第二颜色，以进行验收通过提示，从而达到鼓舞士气的目的。
116.在一种可能的实施方式中，本步骤中，可以通过向告警灯发送第二消息，通过第二消息控制告警灯显示第二颜色。
117.可选地，本实施例中，第二颜色为绿色。
118.可选地，本实施例中，若验收不通过，则控制告警灯显示第一颜色，以进行异常告警。
119.示例性地，图3为本技术实施例二提供的代码处理的阶段示意图，如图3所示，本实施例中，在代码处理的各个阶段，当发现代码处理存在异常时，通过告警灯显示第一颜色的方式提示开发人。可以理解的是，当开发人发现代码处理存在异常时，会主动对查看错误原因，并及时处理，直到异常得到解决。
120.可选地，当代码处理存在异常时，为进一步提高开发人员的异常处理效率，本实施例中，控制告警灯显示第一颜色之后，还包括：
121.监测告警灯显示第一颜色的时长；根据所述时长与预设时长分区，向目标责任人发送异常告警信息。
122.其中，预设时长分区可以预先根据处理相关异常所需的经验值确定，可以理解的是，针对不同的代码处理阶段，预设时长分区可以相同，也可以不同。
123.示例性地，当红灯亮起1小时后，异常没有解决时，会通过相关软件或系统通知造成问题的人，如开发人员；当红灯亮起3小时后，异常还没有解决时，风险升级，通过相关软件或系统通知项目负责人，如项目经理；当红灯亮起8小时后，异常还没得到解决时，风险再次升级，通过相关软件或系统通知造成问题的人上一级主管，如开发人员的领导。
124.可选地，在各代码的各个处理阶段，为便于相关人员进行代码异常的查看和监控，主服务器还用于：
125.将获取到的代码处理状态发送给显示器，以使显示器按照预设样式，如图表等对代码处理状态及相关信息进行可视化展示。
126.其中，代码处理状态为分支创建状态、分支合并状态、分支代码构建状态、主线合并状态、主线代码构建状态中的一种。
127.本实施例中，通过主服务器调用git服务器和jenkins服务器对代码进行处理，并获取git服务器及jenkins服务器对代码处理的代码处理状态，当根据代码处理状态发现代码存在异常时，及时通过告警灯进行异常告警，以提醒开发人员及时进行异常处理，从而提高了软件的研发效率和质量。
128.实施例三
129.图4为本技术实施例三提供的代码异常处理装置的结构示意图，如图4所示，本实施例中代码异常处理装置200包括：
130.处理模块210，用于当接收到用户提交的代码时，调用git服务器为所述代码创建分支；获取所述代码的分支创建状态；
131.控制模块220，用于若所述分支创建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
132.本实施例所提供的代码异常处理装置可执行上述方法实施例所提供的代码异常处理方法，具备执行方法相应的功能模块和有益效果。本实施例的实现原理和技术效果与上述方法实施例类似，此处不再一一赘述。
133.实施例四
134.图5为本技术实施例四提供的一种主服务器的结构示意图，如图5所示，该主服务器110包括存储器111、处理器112及存储在存储器上并可在处理器上运行的计算机程序；主服务器110中处理器112的数量可以是一个或多个，图5中以一个处理器112为例；主服务器110中的处理器112、存储器111可以通过总线或其他方式连接，图5中以通过总线连接为例。
135.存储器111作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本技术实施例中的处理模块210和控制模块220对应的程序指令/模块。处理器112通过运行存储在存储器111中的软件程序、指令以及模块，从而执行主服务器的各种功能应用以及数据处理，即实现上述的代码异常处理方法。
136.存储器111可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器111可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器111可进一步包括相对于处理器112远程设置的存储器，这些远程存储器可以通过网格连接至主服务器。上述网格的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
137.实施例五
138.本技术实施例五还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在由计算机处理器执行时用于执行一种代码异常处理方法，该方法包括：
139.当接收到用户提交的代码时，调用git服务器为所述代码创建分支；
140.获取所述代码的分支创建状态；
141.若所述分支创建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
142.可选地，所述方法还包括：
143.若所述分支创建状态为成功，则调用所述git服务器对所述代码进行分支合并；
144.获取所述代码的分支合并状态；
145.若所述分支合并状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
146.可选地，所述方法还包括：
147.若所述分支合并状态为成功，则调用jenkins服务器对进行分支代码构建；
148.获取分支代码构建状态；
149.若所述分支代码构建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
150.可选地，所述方法还包括：
151.若所述分支代码构建状态为成功，则调用所述git服务器对所述代码进行主线合并；
152.获取所述代码的主线合并状态；
153.若所述主线合并状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
154.可选地，所述方法还包括：
155.若所述主线合并状态为成功，则调用所述jenkins服务器进行主线代码构建；
156.获取主线代码构建状态；
157.若所述主线代码构建状态为失败，则控制告警灯显示第一颜色，以进行异常告警。
158.可选地，所述方法还包括：
159.若所述主线代码构建状态为成功，则通知第三方对所述代码对应的产品进行验收；
160.若验收通过，则控制告警灯显示第二颜色，以进行验收通过提示。
161.可选地，所述控制告警灯显示第一颜色之后，所述方法还包括：
162.监测所述告警灯显示第一颜色的时长；
163.根据所述时长与预设时长分区，向目标责任人发送异常告警信息。
164.可选地，所述方法还包括：
165.将代码处理状态发送给显示器，以使所述显示器对所述代码处理状态进行可视化展示，所述代码处理状态为分支创建状态、分支合并状态、分支代码构建状态、主线合并状态、主线代码构建状态中的一种。
166.当然，本技术实施例所提供的一种包计算机可读存储介质，其计算机程序不限于如上所述的方法操作，还可以执行本技术任意实施例所提供的代码异常处理方法中的相关操作。
167.通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本技术可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read
‑
only memory，rom)、随机存取存储器(random access memory，ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网格设备等)执行本技术各个实施例所述的方法。
168.值得注意的是，上述代码异常处理装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。
169.注意，上述仅为本技术的较佳实施例及所运用技术原理。本领域技术人员会理解，本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由所附的权利要求范围决定。