CN113190447A - 一种代码自动合并的方法、装置、设备及存储介质 - Google Patents
一种代码自动合并的方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN113190447A CN113190447A CN202110482571.3A CN202110482571A CN113190447A CN 113190447 A CN113190447 A CN 113190447A CN 202110482571 A CN202110482571 A CN 202110482571A CN 113190447 A CN113190447 A CN 113190447A
- Authority
- CN
- China
- Prior art keywords
- repair
- codes
- test case
- code
- branch
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 68
- 238000012360 testing method Methods 0.000 claims abstract description 188
- 230000008439 repair process Effects 0.000 claims abstract description 111
- 238000011161 development Methods 0.000 claims abstract description 33
- 230000004044 response Effects 0.000 claims abstract description 7
- 230000006870 function Effects 0.000 claims description 60
- 230000015654 memory Effects 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 11
- 238000011990 functional testing Methods 0.000 claims description 4
- 238000004891 communication Methods 0.000 claims 1
- 238000012544 monitoring process Methods 0.000 abstract 1
- 230000008569 process Effects 0.000 description 25
- 238000013461 design Methods 0.000 description 11
- 230000001960 triggered effect Effects 0.000 description 4
- 230000007423 decrease Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 229940060321 after-bug Drugs 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 230000007474 system interaction Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3628—Software debugging of optimised code
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种代码自动合并的方法、装置、设备及存储介质,该方法包括:响应于获取项目的修复分支hotfix的修复代码时,触发部署测试任务,以新建测试用例集对所述修复代码对应的漏洞bug进行测试;响应于所述新建测试用例集中自动化测试用例的通过率达到百分百时,将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支deve lop的代码。该方法可自动实现软件补丁的自动测试、测试情况监测和合并操作,避免衔接程序人为操作存在忘记的可能性。
Description
技术领域
本发明属于软件开发技术领域,具体涉及一种代码自动合并的方法、装置、设备及存储介质。
背景技术
系统补丁是系统在使用过程中出现问题而发布的解决问题的小程序,系统出现问题时,通过打补丁方式进行问题修复。为了避免下次上线时补丁衰退,补丁对应的代码需要同步到开发分支develop。
现有补丁对应的代码同步到开发分支的方法为:开发人员先基于代码仓库的上线分支master拉取一个修复分支hotfix,开发人员在修复分支上修复问题后,由测试人员确保测试通过。测试通过后,由测试人员通知开发人员合并修复分支代码到上线分支,准备补丁发布。补丁发布确保系统正常后,测试人员通知开发人员将修复分支hotfix代码合并到开发分支develop,确保下次上线补丁不会衰退。
采用现有方法其存在以下问题:
流程由不同人员完成,不同人员通过约定规范流程或者口口相传,会因为人为因素出现忘记的可能性,流程衔接智能化程度低。
发明内容
本发明为了解决现有软件补丁合并到开发分支各流程衔接需要人为告知的情况,提供一种代码自动合并的方法、装置、设备及存储介质,其可自动实现软件补丁的自动测试和合并操作,避免衔接程序人为操作存在忘记的可能性。
为了实现上述目的,本发明采用以下技术方案:
本发明第一方面提供一种代码自动合并的方法,包括以下步骤:
响应于获取项目的修复分支hotfix的修复代码时,触发部署测试任务,以新建测试用例集对所述修复代码对应的第一产品功能进行测试;
响应于所述新建测试用例集中自动化测试用例的通过率达到百分百时,将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码。
本方案通过设置相应的任务,在提交修复分支的修复代码时触发部署测试任务,实现软件补丁的自动测试,在新建测试用例集中自动化测试用例的通过率达到百分百时触发合并任务,即在确保补丁能有效解决本次提出的漏洞即第一产品功能后自动实现修复代码合并到上线分支master代码中,修复代码合并到开发分支develop代码中,在保证下次上线时补丁不会衰退的情况下,整个流程衔接通过触发相关任务完成,避免衔接程序人为操作存在忘记的可能性,实现软件补丁同步到开发分支的衔接流程的自动化。
在一个可能的设计中,所述方法还包括:
获取第二产品功能对应的已测测试用例集,其中,所述已测测试用例集包括至少一个自动化测试用例,所述第二产品功能为与所述项目对应的产品功能中除所述第一产品功能外的产品功能;
根据所述已测测试用例集中的自动化测试用例,对所述第二产品功能进行测试,并得到所述已测测试用例集中自动化测试用例的通过率。
本发明在新建测试用例集测试的同时,利用已测测试用例集中的自动化测试用例对修复分支的修复代码的进行第二产品功能的测试,该第二产品功能可以的历史的多种功能,避免新BUG在修复的同时引入其他问题,提高补丁测试的全面性和准确性的同时,提高代码开发质量。
在一个可能的设计中,响应于所述新建测试用例集中自动化测试用例的通过率达到百分百时,将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码,包括:
响应于所述新建测试用例集中自动化测试用例的通过率达到百分百,且所述已测测试用例集中自动化测试用例的通过率达到预设阈值,将所述修复代码合并为master的代码,以及将所述修复代码合并为develop的代码。
本方案中新建测试用例集中的自动化测试用例对该修复分支对应的漏洞进行测试,已测测试用例集中的自动化测试用例对修复分支的修复代码进行功能测试,提高代码测试的全面性和准确性,提高软件的性能。
在一个可能的设计中,所述修复代码中包括定位单号,所述定位单号与问题单的单号相同,以便根据所述问题单的单号查找对应的修复代码,所述问题单中包括与所述修复代码对应的至少一个漏洞bug。
本方案通过在修复代码中添加定位单号,以与问题单建立关联,便于根据所述问题单的单号查找对应的修复代码,实现代码可追溯。
在一个可能的设计中,所述方法还包括:
响应于所述新建测试用例集中自动化测试用例的通过率达到百分百的同时,向项目与事务跟踪工具jira服务器发送更新指令,以便所述jira服务器根据所述更新指令,调整所述至少一个bug的状态为已修复。
本方案在测试通过时,通过向项目与事务跟踪工具jira服务器发送更新指令,实现状态自更新,便于测试人员和开发人员对问题单的情况进行跟踪查看。
本发明第二方面提供一种代码自动合并的设备,包括:
一部署测试单元,所述部署测试单元在获取项目的修复分支hotfix的修复代码时,以新建测试用例集对所述修复代码对应的第一产品功能进行测试;
一分支合并单元,所述分支合并单元在所述新建测试用例集中自动化测试用例的通过率达到百分百时,将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码。
在一个可能的设计中,还包括:
一功能测试单元,根据所述已测测试用例集中的自动化测试用例,对所述第二产品功能进行测试,并得到所述已测测试用例集中自动化测试用例的通过率,所述第二产品功能为与所述项目对应的产品功能中除所述第一产品功能外的产品功能。
在一个可能的设计中,还包括:
一状态更新单元,所述状态更新单元在所述新建测试用例集中自动化测试用例的通过率达到百分百时,生成一更新指令,以便所述jira服务器根据所述更新指令,调整所述至少一个bug的状态为已修复。
本发明第三方面提供一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现第一方面及其任一种可能中所述的一种代码自动合并的方法。
本发明第四方面提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现第一方面及其任一种可能中所述的一种代码自动合并的方法。
本发明与现有技术相比,至少具有以下优点和有益效果:
本方案通过设置相应的任务,在提交代码时触发部署测试任务,实现软件补丁的自动测试,在确保补丁能有效解决提出的漏洞后自动实现修复代码合并到上线分支master代码中,修复代码合并到开发分支develop代码中,在保证下次上线时补丁不会衰退的情况下,整个流程衔接通过触发相关任务完成,避免衔接程序人为操作存在忘记的可能性,实现软件补丁同步到开发分支的衔接流程的自动化。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本方案发明代码自动合并方法的一流程图。
图2为本方案代码开发过程的一具体流程图。
图3为本方案代码自动合并装置的原理框图。
图4为本发明一计算机主设备的原理框图。
具体实施方式
下面结合附图及具体实施例来对本发明作进一步阐述。在此需要说明的是,对于这些实施例方式的说明虽然是用于帮助理解本发明,但并不构成对本发明的限定。本文公开的特定结构和功能细节仅用于描述本发明的示例实施例。然而,可用很多备选的形式来体现本发明,并且不应当理解为本发明限制在本文阐述的实施例中。
应当理解,尽管本文可能使用术语第一、第二等等来描述各种单元,但是这些单元不应当受到这些术语的限制。这些术语仅用于区分一个单元和另一个单元。例如可以将第一单元称作第二单元,并且类似地可以将第二单元称作第一单元,同时不脱离本发明的示例实施例的范围。
应当理解,对于本文中可能出现的术语“和/或”,其仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,单独存在B,同时存在A和B三种情况;另外,对于本文中可能出现的字符“/”,一般表示前后关联对象是一种“或”关系。
应当理解,在下面的描述中提供了特定的细节,以便于对示例实施例的完全理解。然而,本领域普通技术人员应当理解可以在没有这些特定细节的情况下实现示例实施例。例如可以在框图中示出系统,以避免用不必要的细节来使得示例不清楚。在其他实例中,可以不以非必要的细节来示出众所周知的过程、结构和技术,以避免使得示例实施例不清楚。
本发明提供的代码自动合的方法适于在仓库管理单元或与仓库管理单元相类似的设备上运行,该仓库管理单元可以是GITLAB,以实现软件补丁同步时各流程的智能化衔接。基于GITLAB的分支模型一般包括上线分支master、开发分支develop和辅助分支,上线分支master与开发分支develop并行且均为主分支,辅助分支包括功能分支feature、发布分支Release和修复分支hotfix。计算机程序的源代码存在于上线分支master上,并且随时都是一个预备生产状态;开发分支develop上的源代码始终体现下个发布版的最新软件变更;功能分支feature通常为即将发布或者未来发布版开发新的功能,最终合并到开发分支中;发布分支Release是为新产品的发布做准备的,最终合并到master和develop上;修复分支hotfix与发布分支很相似,他们都为新的生成环境发布做准备,最终必须合并回master和develop上。
当所属项目有漏洞bug存在时,开发人员手动从该项目的上线分支master上拉取一修复分支hotfix,修复分支创建完成后即可在该修复分支上进行修复代码的开发;针对漏洞的修复代码也可在之前拉取的分支上进行代码开发。测试人员根据漏洞bug创建相应的自动化测试用例构建新建测试用例集,该新建测试用例集中的自动化测试用例可以仅包括一个自动化测试用例,也可包括多个。所述修复代码开发完成提交后,进行软件补丁的自动同步。
基于上述背景,本实施例第一方面提供一种代码自动合并的方法。具体的,如图1所示,该软件补丁自动同步到开发分支的方法,可以但不限于包括如下步骤S101~步骤S102。
步骤S101:响应于获取项目的修复分支hotfix的修复代码时,触发部署测试任务,其中,该部署测试任务用于打包修复分支的代码、部署测试环境后以新建测试用例集对所述修复代码对应的第一产品功能进行测试,该修复分支hotfix的修复代码可以是修复分支hotfix创建后第一次提交的代码,也可以是修复分支修复代码提交测试不通过返回修改后再次提交的代码。
以新建测试用例集对所述修复代码对应的第一产品功能进行测试,以验证该修复代码是否修复此次漏洞。该第一产品功能包括一种或多种产品功能。在对修复代码对应的第一产品功能进行测试时,检测修复代码响应新建测试用例集中自动化测试用例的每条操作步骤后输出的结果与该自动化测试用例期望结果的一致性,若修复代码响应自动化测试用例中所有操作步骤输出的结果均与自动化测试用例期望结果一致,则该条自动化测试用例测试通过。统计参与第一产品功能测试的自动化测试用例和条数和通过测试的自动化测试用例的条数,以计算新建测试用例集中自动化测试用例的通过率。
步骤S102、响应于所述新建测试用例集中自动化测试用例的通过率达到百分百时,触发合并任务,该合并任务用于将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码。该步骤在所述新建测试用例集中自动化测试用例的通过率达到百分百时,触发合并任务,以确保补丁能有效解决本次提出的漏洞。
在本申请实施例中,在步骤S101中计算了新建测试用例集中自动化测试用例的通过率,在通过率为百分百时,说明新建测试用例集中的所有自动化自测用例均通过测试,也就表明与修复代码对应的Bug被修复,此时则可以将修复代码合并为master的代码,并将修复代码合并为develop的代码。
由于在对已发现bug进行修复后,可能会引入其它bug,甚至引入无法修复bug,那避免这种情况出现,在本申请实施例中,步骤S102在具体实现过程中,所述方法还包括如下步骤:
获取第二产品功能对应的已测测试用例集,其中,所述已测测试用例集包括至少一个自动化测试用例,所述第二产品功能为与所述项目对应的产品功能中除所述第一产品功能外的产品功能;
根据所述已测测试用例集中的自动化测试用例,对所述第二产品功能进行测试,并得到所述已测测试用例集中自动化测试用例的通过率。
在该步骤中,还可以同时获取第二产品功能对应的已测测试用例集,以已测测试用例集对第二产品功能进行测试,得到所述已测测试用例集中自动化测试用例的通过率。该第二功能为与所述项目对应的产品功能中除所述第一产品功能外的产品功能,以验证该修复代码是否修复此次漏洞并检验此次修复过程是否引入新的问题。
具体的,功能测试过程中,检测修复代码响应已测测试用例集中自动化测试用例的每条操作步骤后输出的结果与该自动化测试用例期望结果的一致性,若修复代码响应自动化测试用例中所有操作步骤输出的结果均与自动化测试用例期望结果一致,则该条自动化测试用例测试通过。统计参与功能测试的自动化测试用例和条数和通过测试的自动化测试用例的条数,以计算已测测试用例集中自动化测试用例的通过率。
相应的,步骤S102在具体实现过程中,包括:
响应于所述新建测试用例集中自动化测试用例的通过率达到百分百,且所述已测测试用例集中自动化测试用例的通过率达到预设阈值,将所述修复代码合并为master的代码,以及将所述修复代码合并为develop的代码。
此处,可将预设阈值设定为大于等于90%的任何数值,优选的,可设定为95%,以提高修复代码的质量。
通过上述第一方面的方案,在各衔接步骤中,通过条件自动触发部署测试任务和合并任务实现软件补丁合并到开发分支过程中各步骤的自动衔接,整个过程不需要人为参与,避免衔接程序人为操作存在忘记的可能性,实现软件补丁同步到开发分支的衔接流程的自动化。对修复代码进行测试时,通过加入已测测试用例集,提高修复代码的质量,提高修复代码功能的完善性。
进一步,在本申请实施例中,为便于项目与事务跟踪工具jira对bug修复状态的跟踪,在具体实现过程中,所述方法还包括:
响应于所述新建测试用例集中自动化测试用例的通过率达到百分百的同时,向项目与事务跟踪工具jira服务器发送更新指令,以便所述jira服务器根据所述更新指令,调整所述至少一个bug的状态为已修复。
也就是在新建测试用例集中自动化测试用例的通过率达到百分百时,说明与修复代码对应的bug已被修复,那便于jira服务器对该项目的bug进行及时状态更新,则gitlab服务器会给jira服务器发送更新指令,以便jira服务器根据接收到的更新指令,将bug状态调整为已修复状态,从而也能够便于研发人员及时了解bug的处理状态。
当然,在本申请实施例中,也可以是在新建测试用例集中自动化测试用例的通过率达到百分百,以及已测测试用例集中的自动化测试用例的通过率达到预设阈值时,向jira服务器发送更新指令,以便所述jira服务器根据来自gitlab服务器的更新指令,将bug状态调整为已修复状态。
在具体实现过程中,为便于研发人员能够跟踪到修复代码的位置,在本申请实施例中,所述修复代码中包括定位单号,所述定位单号与问题单的单号相同,以便根据所述问题单的单号查找对应的修复代码,所述问题单中包括与所述修复代码对应的至少一个漏洞bug。
那为便于读者更好理解本发明实施例中的技术方案,下面则从系统交互的角度进一步详细阐述本发明实施例中的技术方案。
仓库管理单元仅可实现代码的开发管理,不利于项目的管理。为了便于对项目进行管理,可在项目与事务跟踪工具jira服务器上安装与仓库管理单元相关的插件,实现与仓库管理单元的应用接口连接。如图2所示,当所属项目有漏洞bug存在时,测试人员在项目与事务跟踪工具jira上创建问题单并上传至项目与事务跟踪工具jira服务器,具体的,根据软件运行的实际情况,若现仅存在一个漏洞BUG,则可仅设置一个问题单,若现存在多个BUG,则可设置多个问题单,或者创建的问题单中包括多个漏洞bug。问题单可以以问题单号+程序问题内容的方式。比如,创建一个程序问题内容为“游戏开启闪退”的问题单,其单号为0001。开发人员看到有问题单存在时,根据问题单在该项目的上线分支master上拉取至少一个修复分支hotfix,若漏洞较多,可拉取多个修复分支。开发人员在该至少一个修复分支上进行修复代码开发以使修复代码可以修复问题单中的漏洞,代码开发完成后,在修复代码中添加定位单号,该定位单号与问题单的单号相同。同样,测试人员看到有问题单存在时,根据问题单添加新建测试用例集,新建测试用例集中包括至少一个自动化测试用例,该新建测试用例集中每个自动化测试用例包括至少一条操作步骤和与操作步骤对应的期望结果。修复代码执行自动化测试用例中每条操作步骤后其输出的结果与操作步骤对应的期望结果相同,则代表漏洞修复完成。基于上述背景,本实施例第一方面提供一种代码自动合并的方法。该方法包括步骤201-步骤202。
步骤S201、接收到包含有定位单号的修复分支的修复代码时,按照步骤S101的方法对修复代码进行测试。
步骤S202、按照步骤S102的方法将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码。同时,向项目与事务跟踪工具jira服务器发送更新指令,所述更新指令包括问题单的单号及相应漏洞的状态。项目与事务跟踪工具jira服务器接收到该更新指令后,根据该更新指令,调整问题单中相应漏洞的状态为已修复。此时,即可通过项目与事务跟踪工具jira在漏洞修复完成后通过单号调取查看问题单的状态以及对应问题单的代码,实现代码可追溯。
采用上述方法,在出现线上问题时,不仅确保了修复问题后确保发布的补丁在后续的持续发布过程中不会100%衰退,也实现了软件补丁合并到开发分支过程中各步骤的自动衔接,同时也实现了问题单相关代码及自动化测试用例的可追溯。
本发明第三方面提供一种一种软件补丁自动同步到开发分支的设备,如图3所示,该设备包括依次信号连接的部署测试单元和分支合并单元,
所述部署测试单元在获取项目的修复分支hotfix的修复代码时,以新建测试用例集对所述修复代码对应的第一产品功能进行测试;
所述分支合并单元在所述新建测试用例集中自动化测试用例的通过率达到百分百时,将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码。
在一种可能的设计中,该设备还包括连接在分支合并单元输入端的功能测试单元,所述功能测试单元根据所述已测测试用例集中的自动化测试用例,对所述第二产品功能进行测试,并得到所述已测测试用例集中自动化测试用例的通过率,所述第二产品功能为与所述项目对应的产品功能中除所述第一产品功能外的产品功能。。
在一种可能的设计中,该设备还包括依次与分支合并单信号连接的一状态更新单元、一应用程序接口单元,所述状态更新单元在所述新建测试用例集中自动化测试用例的通过率达到百分百时,生成一更新指令,以便所述jira服务器根据所述更新指令,调整所述至少一个bug的状态为已修复;
一应用程序接口单元,所述应用程序接口单元用于与jira服务器建立信号连接。
本实施例第三方面提供的前述装置的工作过程、工作细节和技术效果,可以参见第一方面、第二方面、第三方面中任意一种可能设计所涉及的所述代码自动合并方法,于此不再赘述。
本发明第四方面提供一种执行第一方面或第二方面中所述代码自动合并的方法的计算机主设备,如图4所示,该计算机主设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,具体举例的,所述存储器可以但不限于包括随机存取存储器(Random Access Memory,RAM)、只读存储器(Read-Only Memory,ROM)、闪存(FlashMemory)、先进先出存储器(First Input First Output,FIFO)和/或先进后出存储器(FreeIn Liner Out,FILO)等等;所述处理器不限于采用型号为STM32F105系列的微处理器、ARM、X86等架构处理器,集成NPU(neural-network processing units)的处理器。所述处理器执行所述计算机程序时实现第一方面至第三方面任一项中所述的一种软件补丁自动同步到开发分支的方法。
本实施例第四方面提供的前述装置的工作过程、工作细节和技术效果,可以参见第一方面或第二方面中任意一种可能设计所涉及的所述代码自动合并方法,于此不再赘述。
本发明第五方面提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序在计算机上运行时,执行如第一方面或第二方面中任一种所述的软件补丁自动同步到开发分支的方法。其中,所述计算机可读存储介质是指存储数据的载体,可以但不限于包括软盘、光盘、硬盘、闪存、优盘和/或记忆棒(Memory Stick)等,所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。
本实施例第五方面提供的前述装置的工作过程、工作细节和技术效果,可以参见第一方面或第二方面中任意一种可能设计所涉及的所述代码自动合并方法,于此不再赘述。
最后应说明的是:以上所述仅为本发明的优选实施例而已,并不用于限制本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种代码自动合并的方法,其特征在于,包括以下步骤:
响应于获取项目的修复分支hotfix的修复代码时,触发部署测试任务,以新建测试用例集对所述修复代码对应的第一产品功能进行测试;
响应于所述新建测试用例集中自动化测试用例的通过率达到百分百时,将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
获取第二产品功能对应的已测测试用例集,其中,所述已测测试用例集包括至少一个自动化测试用例,所述第二产品功能为与所述项目对应的产品功能中除所述第一产品功能外的产品功能;
根据所述已测测试用例集中的自动化测试用例,对所述第二产品功能进行测试,并得到所述已测测试用例集中自动化测试用例的通过率。
3.根据权利要求2所述的方法,其特征在于,响应于所述新建测试用例集中自动化测试用例的通过率达到百分百时,将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码,包括:
响应于所述新建测试用例集中自动化测试用例的通过率达到百分百,且所述已测测试用例集中自动化测试用例的通过率达到预设阈值,将所述修复代码合并为master的代码,以及将所述修复代码合并为develop的代码。
4.根据权利要求1所述的方法,其特征在于,所述修复代码中包括定位单号,所述定位单号与问题单的单号相同,以便根据所述问题单的单号查找对应的修复代码,所述问题单中包括与所述修复代码对应的至少一个漏洞bug。
5.根据权利要求4所述的方法,其特征在于,所述方法还包括:
响应于所述新建测试用例集中自动化测试用例的通过率达到百分百的同时,向项目与事务跟踪工具jira服务器发送更新指令,以便所述jira服务器根据所述更新指令,调整所述至少一个bug的状态为已修复。
6.一种代码自动合并装置,其特征在于,包括依次信号连接的部署测试单元和分支合并单元,
所述部署测试单元在获取项目的修复分支hotfix的修复代码时,以新建测试用例集对所述修复代码对应的第一产品功能进行测试;
所述分支合并单元在所述新建测试用例集中自动化测试用例的通过率达到百分百时,将所述修复代码合并为上线分支master的代码,以及将所述修复代码合并为开发分支develop的代码。
7.根据权利要求6所述的装置,其特征在于,所述装置还包括连接在分支合并单元输入端的一功能测试单元,
所述功能测试单元根据所述已测测试用例集中的自动化测试用例,对所述第二产品功能进行测试,并得到所述已测测试用例集中自动化测试用例的通过率,所述第二产品功能为与所述项目对应的产品功能中除所述第一产品功能外的产品功能。
8.根据权利要求6所述的装置,其特征在于,所述装置还包括与分支合并单信号连接的一状态更新单元,
所述状态更新单元在所述新建测试用例集中自动化测试用例的通过率达到百分百时,生成一更新指令,以便所述jira服务器根据所述更新指令,调整所述至少一个bug的状态为已修复。
9.一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至5任一项中所述的代码自动合并的方法。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至5任一项中所述的代码自动合并的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110482571.3A CN113190447A (zh) | 2021-04-30 | 2021-04-30 | 一种代码自动合并的方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110482571.3A CN113190447A (zh) | 2021-04-30 | 2021-04-30 | 一种代码自动合并的方法、装置、设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN113190447A true CN113190447A (zh) | 2021-07-30 |
Family
ID=76983320
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110482571.3A Pending CN113190447A (zh) | 2021-04-30 | 2021-04-30 | 一种代码自动合并的方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113190447A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113760234A (zh) * | 2021-09-06 | 2021-12-07 | 小叶子(北京)科技有限公司 | 一种软件开发方法和系统 |
WO2024038944A1 (ko) * | 2022-08-19 | 2024-02-22 | 쿠팡 주식회사 | 소스 코드를 업로드하는 방법 및 장치 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101932999A (zh) * | 2007-12-20 | 2010-12-29 | 汇丰技术股份有限公司 | 用于并行开发和部署项目的自动方法和系统 |
CN109766269A (zh) * | 2018-12-18 | 2019-05-17 | 微梦创科网络科技(中国)有限公司 | 持续集成自动化测试方法、装置、设备和介质 |
CN109960643A (zh) * | 2017-12-22 | 2019-07-02 | 网宿科技股份有限公司 | 一种代码测试方法和装置 |
CN110633101A (zh) * | 2019-09-25 | 2019-12-31 | 杭州港盛软件科技有限公司 | 一种程序代码管理方法、装置、设备及可读存储介质 |
CN111352651A (zh) * | 2020-03-31 | 2020-06-30 | 中国建设银行股份有限公司 | 代码分支管理方法及装置 |
CN112379969A (zh) * | 2020-11-13 | 2021-02-19 | 中国人寿保险股份有限公司 | 一种基于容器化应用的持续集成交付方法及相关设备 |
-
2021
- 2021-04-30 CN CN202110482571.3A patent/CN113190447A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101932999A (zh) * | 2007-12-20 | 2010-12-29 | 汇丰技术股份有限公司 | 用于并行开发和部署项目的自动方法和系统 |
CN109960643A (zh) * | 2017-12-22 | 2019-07-02 | 网宿科技股份有限公司 | 一种代码测试方法和装置 |
CN109766269A (zh) * | 2018-12-18 | 2019-05-17 | 微梦创科网络科技(中国)有限公司 | 持续集成自动化测试方法、装置、设备和介质 |
CN110633101A (zh) * | 2019-09-25 | 2019-12-31 | 杭州港盛软件科技有限公司 | 一种程序代码管理方法、装置、设备及可读存储介质 |
CN111352651A (zh) * | 2020-03-31 | 2020-06-30 | 中国建设银行股份有限公司 | 代码分支管理方法及装置 |
CN112379969A (zh) * | 2020-11-13 | 2021-02-19 | 中国人寿保险股份有限公司 | 一种基于容器化应用的持续集成交付方法及相关设备 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113760234A (zh) * | 2021-09-06 | 2021-12-07 | 小叶子(北京)科技有限公司 | 一种软件开发方法和系统 |
CN113760234B (zh) * | 2021-09-06 | 2023-06-27 | 小叶子(北京)科技有限公司 | 一种软件开发方法和系统 |
WO2024038944A1 (ko) * | 2022-08-19 | 2024-02-22 | 쿠팡 주식회사 | 소스 코드를 업로드하는 방법 및 장치 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109960643B (zh) | 一种代码测试方法和装置 | |
CN109683899B (zh) | 一种软件集成方法及装置 | |
US11243516B2 (en) | Edge devices and associated networks utilising microservices | |
CN113190447A (zh) | 一种代码自动合并的方法、装置、设备及存储介质 | |
CN110083369A (zh) | 一种基于容器方案的持续集成和持续交付方法 | |
Rathod et al. | Test orchestration a framework for continuous integration and continuous deployment | |
CN111897566A (zh) | 一种软件开发持续集成方法、装置、设备和介质 | |
CN109753430B (zh) | 一种地面数据处理系统的接口测试方法 | |
CN109840194B (zh) | 一种配置文件的检测方法及系统 | |
CN113111000B (zh) | 持续集成自动化测试系统和方法、电子设备、存储介质 | |
CN114995835A (zh) | 一种应用自动化部署方法、系统、设备和可读存储介质 | |
CN111611157B (zh) | Gms持续集成构建自动化测试方法及系统 | |
CN114880220A (zh) | 车辆自动驾驶软件的开发系统和方法 | |
CN114168213A (zh) | 基于Jenkins的软件发布方法、装置和电子设备 | |
Yuksel et al. | Using continuous integration and automated test techniques for a robust c4isr system | |
Baker et al. | Detect, fix, and verify TensorFlow API misuses | |
CN112596784B (zh) | 一种迭代版本部署方法及装置 | |
Abdul et al. | Implementing Continuous Integration towards rapid application development | |
CN110764785A (zh) | 基于开源组件的电力行业云平台工具链及云平台运维方法 | |
Poornalinga et al. | Continuous integration, deployment and delivery automation in AWS cloud infrastructure | |
CN105868957A (zh) | 一种持续集成方法及装置 | |
CN115309426A (zh) | 系统升级方法、装置、计算机设备及计算机可读存储介质 | |
CN113050926B (zh) | 一种代码同步变更的确认方法、装置和设备 | |
CN115167896A (zh) | 一种更新软件版本的方法、装置、存储介质及电子设备 | |
Pastrana-Pardo et al. | Approach to the Best Practices in Software Development Based on DevOps and SCRUM Used in Very Small Entities |
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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210730 |
|
RJ01 | Rejection of invention patent application after publication |