CN113885838A - 功能开关自动生成方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种功能开关自动生成方法、装置、设备及存储介质，属于计算机技术领域。该方法包括：获取用户输入的第一创建指令；根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号；获取用户输入的第二创建指令；根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号；将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。本申请通过自动生成该新增功能对应的功能开关，从而使得对系统中的某一功能进行更新或新增时，无需研发人员手动编写软件代码，以及有效降低开发人员的工作量，提升研发人员的工作效率。

Description

功能开关自动生成方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种功能开关自动生成方法、装置、设备及存储介质。

背景技术

核心系统作为信用卡活动中重要组成部分，需不断的优化已有功能以及扩展新功能来提升客户体验、匹配监控要求、维护银行利益，但需求的快速迭代对系统来说也是一种挑战，需求不明确，设计考虑不周全、测试覆盖度不够、编码的疏忽等等各种原因都可能会对原有功能和系统稳定造成冲击。目前为了减少或规避这种影响，要求开发人员在编码时对新增功能点实现开关控制，开关使用硬编码的方式，关联apollo参数配置平台来实现业务逻辑是使用老代码还是新代码。

虽然这样可以在新版本生产验证阶段如果发现新功能点有问题可以及时关闭开关来降低影响，每个需求每个任务点都需单独的开关，这样一个系统版本中新增功能点都可以单独回退，部分有问题的新增功能点不会整个版本。

但是，这种功能开关硬编码的方式对开发人员及测试人员来说是不友好的，不仅会增加开发人员的工作量还会使得代码可读性变差。

因此，如何解决上述问题是目前亟需解决的问题。

发明内容

本申请提供一种功能开关自动生成方法、装置、设备及存储介质，旨在解决现有技术中存在的功能开关的创建会增加开发人员的工作量还会使得代码可读性变差的技术问题。

第一方面，本申请提供的一种功能开关自动生成方法，所述方法包括：获取用户输入的第一创建指令；根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号；获取用户输入的第二创建指令；根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号；将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码，所述功能开关包括由所述需求编号和所述任务编号所构成的开关编号。

在上述实现过程中，通过采用创建新增功能的需求信息，并基于该需求信息创建任务信息的方式，将该任务绑定到系统对应的工程版本上，从而使得当运行该工程版本(即代码)时自动生成该新增功能对应的功能开关，从而使得对系统中的某一功能进行更新或新增时，无需研发人员手动编写软件代码，以及有效降低开发人员的工作量，提升研发人员的工作效率。

在一可能的实施例中，所述根据所述第一创建指令创建用于描述新增功能的需求信息，包括：所述JIRA平台响应所述第一创建指令，生成需求创建操作界面；基于所述创建操作界面根据所述第一创建指令创建用于描述新增功能的需求信息，其中，用户仅需要在JIRA平台对应的操作界面上输入用于描述新增功能的所述需求信息。

在上述实现过程中，通过在JIRA平台上直接创建新增功能的需求信息，可以使得需求信息的创建更加快捷简单，研发人员只需要根据需求进行输入即可，进一步提高工作效率。

在一可能的实施例中，所述根据所述第二创建指令创建所述需求信息的任务信息，包括：所述JIRA平台响应所述第二创建指令，弹出任务拆分项下拉框；获取用户基于所述任务拆分项下拉框确定的目标拆分选项；基于所述目标拆分选项将所述需求信息拆分至子系统任务，生成任务信息，其中，所述任务信息包括但任务编号、任务类型、任务状态和/或版本信息。

在上述实现过程中，通过直接在JIRA平台中将需求信息拆分到子系统任务，从而直接建立该需求信息对应的任务信息，进一步降低了研发人员的操作难度，提升了工作效率。

在一可能的实施例中，所述将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码，包括：

获取系统对应的工程版本；将所述任务信息关联至GitLab中所管理的所述工程版本，所述GitLab基于关联信息生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。

在一可能的实施例中，所述方法还包括：

获取用于描述所述新增功能完成测试的描述信息；

基于所述描述信息下线所述功能开关，其中，下线后的所述功能开关控制的底层代码在所述工程版本中被删除。

在上述实现过程中，通过在对新增功能测试完成后，输入完成测试的描述信息，从而可以使得系统自动删除新增功能对应的功能开关，降低工程版本的复杂度，提高代码的可读性。

在一可能的实施例中，所述方法还包括：

基于JIRA平台与阿波罗平台的应用程序编程接口将所述功能开关关联至阿波罗平台，以便于用户基于所述阿波罗平台配置开关信息来控制所述功能开关是否开启。

在上述实现过程中，通过将功能开关关联至阿波罗(Apollo)平台，从而可以使得研发人员可以基于更多的平台来对功能开关进行管理，提升了对功能开关的管理的便捷性。

在一可能的实施例中，所述方法还包括：接收测试信息，所述测试信息用于描述所述新增功能在所述功能开关的控制下的测试结果；解析所述测试信息，得到目标字符；判断所述目标字符是否符合预设条件，所述预设条件包括至少一组字符；若满足预设条件，下线所述功能开关。

在上述实现过程中，通过接收测试信息的方式，然后对测试信息进行解码，得到目标字符，接着将目标字符与预设条件中的至少一组字符进行匹配，如果匹配，则表示目标字符符合预设条件，此时就自动下线功能开关，从而使得无需研发人员手动进行功能开关的下线，使得功能开关在测试完成后即可立即下线，提高工程版本的可读性，另外使得在无人测试的环境下，依然可以实现在测试完成后立即下线功能开关的目的，提高工程版本的运行效率。

第二方面，本申请提供的一种功能开关自动生成装置，所述系统包括：需求创建模块，用于根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号；第二获取模块，用于获取用户输入的第二创建指令；任务创建模块，用于根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号；功能开关生成模块，用于将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码，所述功能开关包括由所述需求编号和所述任务编号所构成的开关编号。

在一可能的实施例中，所述系统还包括：获取模块，用于获取用于描述所述新增功能完成测试的描述信息；下线模块，用于基于所述描述信息下线所述功能开关，其中，下线后的所述功能开关控制的底层代码在所述工程版本中被删除。

第三方面，本申请提供的一种电子设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现如第一方面任一项所述的功能开关自动生成方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理设备运行时执行如第一方面的任一项所述的功能开关自动生成方法的步骤。

有益效果：通过上述功能开关的自动创建方式，使得用户仅仅需要基于新增功能创建需求信息以及对应的任务信息，最后将任务信息绑定到工程版本上即可，以实现了功能开关的自动创建，而无需研发人员编写大量重复代码，有效提高了代码可读性，以及降低了研发人员的工作量，提升了工作效率，以及还降低了测试人员的工作量，使得测试人员无需增加开关开启关闭的情景案例测试。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种电子设备的结构示意图；

图2为本申请实施例提供的一种功能开关自动生成方法的流程图；

图3为图2所示的一种功能开关自动生成方法中的一操作界面示意图；

图4为图2所示的一种功能开关自动生成方法中的一操作界面示意图；

图5为图2所示的一种功能开关自动生成方法中的一操作界面示意图；

图6为图2所示的一种功能开关自动生成方法中的一操作界面示意图；

图7为图2所示的一种功能开关自动生成方法中的一操作界面示意图；

图8为图2所示的一种功能开关自动生成方法中的一操作界面示意图；

图9为本申请实施例提供的另一种功能开关自动生成方法的流程图；

图10为本申请实施例提供的另一种功能开关自动生成方法的流程图；

图11为本申请实施例提供的功能开关自动生成装置的功能模块示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

实施例

图1为本申请实施例提供的一种电子设备的结构示意图，在本申请中可以通过图1所示的示意图来描述用于实现本申请实施例的功能开关自动生成方法、装置、设备及存储介质的示例的电子设备100。

如图1所示的一种电子设备的结构示意图，电子设备100包括一个或多个处理器102、一个或多个存储装置104、输入装置106、输出装置108，这些组件通过总线系统和/或其它形式的连接机构(未示出)互连。应当注意，图1所示的电子设备100的组件和结构只是示例性的，而非限制性的，根据需要，所述电子设备可以具有图1示出的部分组件，也可以具有图1未示出的其他组件和结构。

所述处理器102可以是中央处理单元(CPU)或者具有数据处理能力和/或指令执行能力的其它形式的处理单元，并且可以控制所述电子设备100中的其它组件以执行期望的功能。

应理解，在本申请实施例中的处理器102可以是中央处理单元(centralprocessing unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digitalsignal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储装置104可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质。

应理解，本申请实施例中的存储装置104可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的随机存取存储器(random accessmemory，RAM)可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

其中，在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器102可以运行所述程序指令，以实现下文所述的本申请实施例中(由处理器实现)的客户端功能以及/或者其它期望的功能。在所述计算机可读存储介质中还可以存储各种应用程序和各种数据，例如所述应用程序使用和/或产生的各种数据等。

所述输入装置106可以是用户用来输入指令的装置，并且可以包括键盘、鼠标、麦克风和触摸屏等中的一个或多个。

核心系统作为信用卡活动中重要组成部分，需不断的优化已有功能以及扩展新功能来提升客户体验、匹配监控要求、维护银行利益，但需求的快速迭代对系统来说也是一种挑战，需求不明确，设计考虑不周全、测试覆盖度不够、编码的疏忽等等各种原因都可能会对原有功能和系统稳定造成冲击，目前为了减少或规避这种影响，要求开发人员在编码时对新增功能点实现开关控制，开关使用硬编码的方式；然后关联apollo参数配置平台来实现业务逻辑是使用老代码还是新代码，这样在新版本生产验证阶段如果发现新功能点有问题可以及时关闭开关来降低影响，每个需求每个任务点都需单独的开关，这样一个系统版本中新增功能点都可以单独回退，部分有问题的新增功能点不会整个版本。

但是，这种功能开关硬编码的方式对开发人员及测试人员来说是不友好的，弊端主要有如下列项：

1、徒增大量重复代码，代码可读性变差；

2、开发人员任务量变多，开发人员在考虑新增功能点的同时还要考虑功能开关的覆盖范围；

3、测试人员要增加开关开启关闭的情景案例测试；

4、后期开关去除也需要额外的开发及测试的工作量。因此，如何解决系统新增功能的功能开关的快捷创建是技术人员迫切需要解决的问题。

基于此，本申请希望提供一种能够解决上述技术问题的方案，其可以解决系统新增功能的功能开关快捷创建的问题，其详细内容将在后续实施例中得以阐述。

参照图2，本申请实施例提供的一种功能开关自动生成方法的流程图，方法具体包括如下步骤：

步骤S201，获取用户输入的第一创建指令。

步骤S202，根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号。

可选地，需求信息还可以包括需求提出人、需求价值、需求提出方、来源类型、研发类型、研发人数等信息。

其中，需求编号用于唯一标识一需求。

可选地，研发人员可以同时创建多个需求，每一需求对应一个新增功能或待更新的功能。

作为一种实施方式，步骤S202，包括：JIRA平台响应所述第一创建指令，生成需求创建操作界面；基于所述创建操作界面根据所述第一创建指令创建用于描述新增功能的需求信息，其中，用户仅需要在JIRA平台对应的操作界面上输入用于描述新增功能的所述需求信息。

其中，JIRA平台是Atlassian公司出品的项目与事务跟踪工具。

举例来说，如图3所示，研发人员可以基于该操作界面，在该操作界面上输入相关的需求信息，例如可以输入需求价值，以及部署空间。

也就是说，研发人员在新建功能开关的时候，不需要直接编译代码，只需要先在该JIRA平台上提出具体的需求信息。

当然，在实际使用中，研发人员可以基于当前的具体需求进行填写需求信息。在此，不作具体限定。

应理解，上述仅为示例，而非限定。

继续以上述例子为例，当研发人员在JIRA平台上创建好需求信息后，JIRA平台会生成如图4所示的操作界面，该操作界面上显示有需求信息对应的需求编号，即操作界面上的“CCB01-9986”。

可以理解的是，在本实施例中，为了生成新增功能的功能开关，是无需研发人员去手段编写软件代码的。

步骤S203，获取用户输入的第二创建指令。

步骤S204，根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号。

其中，任务编号用于唯一标识该任务信息，以便于在软件代码运行时识别到对应的功能开关对应的软件代码。

作为一种实施方式，步骤S204，包括：所述JIRA平台响应所述第二创建指令，弹出任务拆分项下拉框；获取用户基于所述任务拆分项下拉框确定的目标拆分选项；基于所述目标拆分选项将所述需求信息拆分至子系统任务，生成任务信息。

其中，任务信息包括但不限于任务编号、任务类型、任务状态、版本信息等。

继续以上述例子为例，当用户创建好任务需求后，基于如图5所示的操作流程，实现对需求信息的拆分，从而创建出任务信息。具体地，当研发人员基于图5所示的操作后，该JIRA平台会弹出如图6所示的操作界面，研发人员基于图6所示的操作界面进行任务的创建，最后生成如图7所示的操作界面，在该操作界面上，生成有任务编号以及其他任务信息。

例如，图7所示的CC252-2368即为任务编号。

可以理解的是，本申请实施例提供的操作示意图仅为示例，而非限定。也就是说，本领域技术人员可以根据实际功能开发进行具体的任务操作。

步骤S205，将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。

其中，所述功能开关包括由所述需求编号和所述任务编号所构成的开关编号。

作为一种实施方式，步骤S205，包括：获取系统对应的工程版本；将所述任务信息关联至GitLab中所管理的所述工程版本，所述GitLab基于关联信息生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。

具体地，在JIRA平台上将所述任务信息关联至GitLab中所管理的所述系统的工程版本，所述GitLab基于关联信息生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。

举例来说，如图8所示，研发人员基于图8所示的操作界面将该任务关联到GitLab中所管理的所述系统的工程版本。在关联之后，通过GitLab可以自动生成新增功能的功能开关以及该功能开关控制的底层代码，此时，会在GitLab系统中记录功能开关与任务点及版本分支的对应关系(即得到一个开关编号，例如[CCB01-9986-CC252-2368-switch])。

其中，工程版本是该系统的正式版本对应的代码。

需要说明的是，当任务点代码分支向版本分支合并时调用GitLab的预设接口，GitLab会将改动的类也记录到之前的功能开关、任务点分支、版本分支的对应关系(即开关编码)中，代码合入后会将改动的原类文件和改动后类文件都加入工程版本中，同时会生成由功能开关控制的底层代码，这段代码控制的是在代码部署执行时由开关控制使用新类还是老类来执行业务逻辑。

也就是说，研发人员基于JIRA平台任务点编辑页面有关联代码工程版本的选项，选中代码版本后会自动从当前任务点拉出基于关联版本的分支。

在上述实现过程中，通过上述功能开关的自动创建方式，使得用户仅仅需要基于新增功能创建需求信息以及对应的任务信息，最后将任务信息绑定到工程版本上即可，以实现了功能开关的自动创建，而无需研发人员编写大量重复代码，有效提高了代码可读性，以及降低了研发人员的工作量，提升了工作效率，以及还降低了测试人员的工作量，使得测试人员无需增加开关开启关闭的情景案例测试。

在一可能的实施例中，所述方法还包括：接收测试信息，所述测试信息用于描述所述新增功能在所述功能开关的控制下的测试结果；解析所述测试信息，得到目标字符；判断所述目标字符是否符合预设条件，所述预设条件包括至少一组字符；若满足预设条件，下线所述功能开关。

其中，测试信息为测试完成后由工程版本自动生成。

可选地，目标字符可以是二进制字符，也可以是十进制字符。在此，不作具体限定。

可以理解的是，上述实现方式通过接收测试信息的方式，然后对测试信息进行解码，得到目标字符，接着将目标字符与预设条件中的至少一组字符进行匹配，如果匹配，则表示目标字符符合预设条件，此时就自动下线功能开关，从而使得无需研发人员手动进行功能开关的下线，使得功能开关在测试完成后即可立即下线，提高工程版本的可读性，另外使得在无人测试的环境下，依然可以实现在测试完成后立即下线功能开关的目的，提高工程版本的运行效率。

需要说明的是，本申请中的新增功能不仅限于在原有功能上的新增，也可以是原有功能的更新。

如图9所示，本申请实施例还提供一种功能开关自动生成方法，该方法包括如下步骤：

步骤S301，获取用户输入的第一创建指令。

步骤S302，根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号。

步骤S303，获取用户输入的第二创建指令。

步骤S304，根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号。

步骤S305，将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。

其中，所述功能开关包括由所述需求编号和所述任务编号所构成的开关编号。

需要说明的是，步骤S301至步骤S305的具体实施方式可以参照上述的描述，在此，不再赘述。

步骤S306，获取用于描述所述新增功能完成测试的描述信息。

其中，该描述信息可以是基于用户在JIRA平台上点击需求或任务验证完成按钮所自动生成的信息。

当然，在实际使用中，该描述信息也可以是研发人员通过文本框进行主动输入得到的，在此，不作具体限定。

步骤S307，基于所述描述信息下线所述功能开关。

其中，下线后的所述功能开关控制的底层代码在所述工程版本中被删除。

也就是说，下线是指将新增功能对应的自动开关给关掉并删除底层中的代码。

换句话说，在测试完成后，新增功能可以发布的情况下，功能开关会失效，工程代码在下个版本会自动删除已过时的相关类文件，达到功能开关自动下线的目的。

可以理解的是，在该实施方式中，通过在对新增功能测试完成后，输入完成测试的描述信息，从而可以使得系统自动删除新增功能对应的功能开关，降低工程版本的复杂度，提高代码的可读性。

如图10所示，本申请实施例还提供一种功能开关自动生成方法，该方法包括如下步骤：

步骤S401，获取用户输入的第一创建指令。

步骤S402，根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号。

步骤S403，获取用户输入的第二创建指令。

步骤S404，根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号。

步骤S405，将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。

其中，所述功能开关包括由所述需求编号和所述任务编号所构成的开关编号。

需要说明的是，步骤S401至步骤S405的具体实施方式可以参照上述的描述，在此，不再赘述。

步骤S406，基于JIRA平台与阿波罗平台的应用程序编程接口将所述功能开关关联至阿波罗平台，以便于用户基于所述阿波罗平台配置开关信息来控制所述功能开关是否开启。

可以理解的是，本申请通过在自动创建功能开关后，再通过将功能开关关联至阿波罗(Apollo)平台，从而可以使得研发人员可以基于更多的平台来对功能开关进行管理，提升了对功能开关的管理的便捷性。

也就是说，通过将功能开关关联到阿波罗平台后，研发人员不仅可以基于GitLab以及JIRA平台对功能开关进行管理，还可以通过阿波罗平台进行管理。

参见图11所示的一种功能开关自动生成装置，该系统500包括：

第一获取模块510，用于获取用户输入的第一创建指令。

需求创建模块520，用于根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号。

具体地，需求创建模块520，用于JIRA平台响应所述第一创建指令，生成需求创建操作界面；

基于所述创建操作界面根据所述第一创建指令创建用于描述新增功能的需求信息，其中，用户仅需要在JIRA平台对应的操作界面上输入用于描述新增功能的所述需求信息。

第二获取模块530，用于获取用户输入的第二创建指令。

任务创建模块540，用于根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号。

具体地，任务创建模块540，用于所述JIRA平台响应所述第二创建指令，弹出任务拆分项下拉框；获取用户基于所述任务拆分项下拉框确定的目标拆分选项；基于所述目标拆分选项将所述需求信息拆分至子系统任务，生成任务信息，其中，所述任务信息包括但任务编号、任务类型、任务状态和/或版本信息。

功能开关生成模块550，用于将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码，所述功能开关包括由所述需求编号和所述任务编号所构成的开关编号。

具体地，功能开关生成模块550，用于将所述任务信息关联至GitLab中所管理的所述系统的工程版本，所述GitLab基于关联信息生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。

在一可能的实施例中，该功能开关自动生成装置500还包括：获取模块，用于获取用于描述所述新增功能完成测试的描述信息；下线模块，用于基于所述描述信息下线所述功能开关，其中，下线后的所述功能开关控制的底层代码在所述工程版本中被删除。

在一可能的实施例中，该功能开关自动生成装置500还包括：关联模块，该关联模块用于基于JIRA平台与阿波罗平台的应用程序编程接口将所述功能开关关联至阿波罗平台，以便于用户基于所述阿波罗平台配置开关信息来控制所述功能开关是否开启。

进一步，本实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理设备运行时执行上述实施例提供的任一项功能开关自动生成方法的步骤。

本申请实施例所提供的一种功能开关自动生成方法、装置、设备及存储介质的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

需要说明的是，上述实施例，可以全部或部分地通过软件、硬件(如电路)、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令或计算机程序。在计算机上加载或执行所述计算机指令或计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质。半导体介质可以是固态硬盘。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A，B可以是单数或者复数。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系，但也可能表示的是一种“和/或”的关系，具体可参考前后文进行理解。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

Claims (10)

1.一种功能开关自动生成方法，其特征在于，所述方法包括：

获取用户输入的第一创建指令；

根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号；

获取用户输入的第二创建指令；

根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号；

将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码，所述功能开关包括由所述需求编号和所述任务编号所构成的开关编号。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一创建指令创建用于描述新增功能的需求信息，包括：

JIRA平台响应所述第一创建指令，生成需求创建操作界面；

基于所述创建操作界面根据所述第一创建指令创建用于描述新增功能的需求信息，其中，用户仅需要在JIRA平台对应的操作界面上输入用于描述新增功能的所述需求信息。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第二创建指令创建所述需求信息的任务信息，包括：

所述JIRA平台响应所述第二创建指令，弹出任务拆分项下拉框；

获取用户基于所述任务拆分项下拉框确定的目标拆分选项；

基于所述目标拆分选项将所述需求信息拆分至子系统任务，生成任务信息，其中，所述任务信息包括但任务编号、任务类型、任务状态和/或版本信息。

4.根据权利要求3所述的方法，其特征在于，所述将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码，包括：

获取系统对应的工程版本；

将所述任务信息关联至GitLab中所管理的所述工程版本，所述GitLab基于关联信息生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取用于描述所述新增功能完成测试的描述信息；

基于所述描述信息下线所述功能开关，其中，下线后的所述功能开关控制的底层代码在所述工程版本中被删除。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

基于JIRA平台与阿波罗平台的应用程序编程接口将所述功能开关关联至阿波罗平台，以便于用户基于所述阿波罗平台配置开关信息来控制所述功能开关是否开启。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收测试信息，所述测试信息用于描述所述新增功能在所述功能开关的控制下的测试结果；

解析所述测试信息，得到目标字符；

判断所述目标字符是否符合预设条件，所述预设条件包括至少一组字符；

若满足预设条件，下线所述功能开关。

8.一种功能开关自动生成装置，其特征在于，所述装置包括：

第一获取模块，用于获取用户输入的第一创建指令；

需求创建模块，用于根据所述第一创建指令创建用于描述新增功能的需求信息，所述需求信息包括需求编号；

第二获取模块，用于获取用户输入的第二创建指令；

任务创建模块，用于根据所述第二创建指令创建所述需求信息的任务信息，所述任务信息包括任务编号；

功能开关生成模块，用于将所述任务信息关联至系统对应的工程版本，生成所述新增功能对应的功能开关以及由所述功能开关控制的底层代码，所述功能开关包括由所述需求编号和所述任务编号所构成的开关编号。

9.一种电子设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现如权利要求1至7任一项所述的功能开关自动生成方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理设备运行时执行如权利要求1-7的任一项所述的功能开关自动生成方法的步骤。

Images