一种代码自动合并的方法、装置、设备及存储介质

技术领域

本发明属于软件开发技术领域，具体涉及一种代码自动合并的方法、装置、设备及存储介质。

背景技术

系统补丁是系统在使用过程中出现问题而发布的解决问题的小程序，系统出现问题时，通过打补丁方式进行问题修复。为了避免下次上线时补丁衰退，补丁对应的代码需要同步到开发分支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)等，所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

本实施例第五方面提供的前述装置的工作过程、工作细节和技术效果，可以参见第一方面或第二方面中任意一种可能设计所涉及的所述代码自动合并方法，于此不再赘述。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。