CN113867691A - 一种开发管理方法、平台及存储介质 - Google Patents

Abstract

本申请实施例公开了一种开发管理方法，该方法包括：若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支；基于所述第一远程主分支，更新所述待开发对象的本地主分支，得到目标主分支；确定所述待开发对象的待开发版本标识；从所述目标主分支中，获取与所述待开发版本标识对应的目标节点；确定目标开发需求；基于所述目标节点，按照预设开发分支命名规范，创建所述待开发版本标识对应的实现所述目标开发需求的第一目标开发分支，以通过所述第一目标开发分支执行目标开发操作。本申请实施例还公开了一种开发管理平台和存储介质。

Description

一种开发管理方法、平台及存储介质

技术领域

本申请涉及全球广域网(World Wide Web，Web)前端技术领域，尤其涉及一种开发管理方法、平台及存储介质。

背景技术

随着计算机技术的飞速发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性和实时性要求，也对技术提出了更高的要求。随着互联网技术的飞速发展，各种应用程序也逐渐得到了开发与应用，为了提高开发人员的开发效率，为开发人员提供的开发工具也各种各样。目前开发人员常用分布式版本控制系统(GIT)进行开发，GIT主要有两种工作流模式：一种模式是把主(Master)分支当成测试分支，所有的功能(Feature)分支、修复(Fix)分支都合并到Master分支，然后在某一个时间节点从Master分支中检出一个发版(Release)分支发布到生产环境，另一种模式是Master分支为生产环境同步分支，永远保持最新修改的分支，开发者在同个版本下可以从Master分支检出多个Feature分支或者Fix分支，开发完成后都合并到版本对应的Release分支，在Release分支做测试和发布，发布完成后，在提交到合并回Master分支。

目前，在进行工作流开发时，可以由任何分支来创建开发，造成工作流的各个分支用途不明确，容易遗漏某次上线的修改，导致工作流开发过程的成功率无法保证。

申请内容

为解决上述技术问题，本申请实施例期望提供一种开发管理方法、平台及存储介质，解决了目前开发者可以采用任何分支来创建需求开发，导致多分支用途不明确的问题，实现了通过主分支来创建需求开发分支，有效避免了通过其他分支来创建需求开发分支时造成修改容易被遗漏的情况，提高了工作流开发成功率。

本申请的技术方案是这样实现的：

第一方面，一种开发管理方法，所述方法包括：

若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支；

基于所述第一远程主分支，更新所述待开发对象的本地主分支，得到目标主分支；

确定所述待开发对象的待开发版本标识；

从所述目标主分支中，获取与所述待开发版本标识对应的目标节点；

确定目标开发需求；

基于所述目标节点，按照预设开发分支命名规范，创建所述待开发版本标识对应的实现所述目标开发需求的第一目标开发分支，以通过所述第一目标开发分支执行目标开发操作。

第二方面，一种开发管理平台，所述开发管理平台包括：存储空间和至少一个开发管理节点；其中：

所述开发管理节点，用于执行所述存储空间中存储的开发管理程序，以实现如上述任一项所述的开发管理方法的步骤。

第三方面，一种存储介质，所述存储介质上存储有开发管理程序，所述开发管理程序被处理器执行时实现如上述任一项所述的开发管理方法的步骤。

本申请实施例中，若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支，基于第一远程主分支，更新待开发对象的本地主分支，得到目标主分支后，确定待开发对象的待开发版本标识，并从目标主分支中，获取与待开发版本标识对应的目标节点，在确定目标开发需求后，基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支。这样，在检测到目标开发指令时，通过采用待开发对象的第一远程主分支更新待开发对象的本地主分支，得到目标主分支，通过目标主分支来创建实现目标开发需求的第一目标开发分支，解决了目前可以采用任何分支来创建需求开发，导致多分支用途不明确的问题，实现了通过主分支来创建需求开发分支，有效避免了通过其他分支来创建需求开发分支时造成修改容易被遗漏的情况，提高了工作流开发成功率。

附图说明

图1为本申请实施例提供的一种开发管理方法的流程示意图；

图2为本申请实施例提供的另一种开发管理方法的流程示意图；

图3为本申请实施例提供的一种主分支的结构示意图；

图4为本申请实施例提供的一种开发管理方法的实现时序流程示意图；

图5为本申请实施例提供的另一种开发管理方法的实现时序流程示意图；

图6为本申请实施例提供的又一种开发管理方法的实现时序流程示意图；

图7为本申请实施例提供的又一种开发管理方法的流程示意图；

图8为本申请实施例提供的一种开发管理平台的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

本申请的实施例提供一种开发管理方法，参照图1所示，方法应用于开发管理节点，该方法包括以下步骤：

步骤101、若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支。

在本申请实施例中，开发管理节点用于为开发人员提供开发环境，对开发人员的开发操作即开发人员的开发代码等进行管理的节点，开发管理系统包括至少一个开发管理节点，针对同一开发对象例如同一待开发应用程序，可以同时有至少一个开发人员在对应的开发管理节点上进行同时开发操作。目标开发指令为开发人员在开发管理节点上输入的预先约定的用于实现开发的开发语句。开发管理节点检测到目标开发指令后，响应目标开发指令，从GIT远程平台中获取待开发对象的第一远程主(master)分支。

步骤102、基于第一远程主分支，更新待开发对象的本地主分支，得到目标主分支。

在本申请实施例中，不同的开发人员针对待开发对象进行相应的需求开发后，会将对应的修改内容保存于第一远程主分支中，因此，在开发管理节点接收到目标开发指令后，需要从GIT远程平台中获取第一远程主分支，来对开发管理节点中的本地主分支进行更新，得到目标主分支，保证开发人员当前是基于最新的主分支进行开发的。

步骤103、确定待开发对象的待开发版本标识。

在本申请实施例中，待开发对象的待开发版本标识可以是开发人员输入的。

步骤104、从目标主分支中，获取与待开发版本标识对应的目标节点。

在本申请实施例中，目标主分支中包括不同时间点下，针对待开发对象不同开发版本的开发修改保存的内容一系列节点。因此，可以从目标主分支中确定得到待开发对象的待开发版本标识对应的目标节点。

步骤105、确定目标开发需求。

在本申请实施例中，目标开发需求指的是针对待开发对象需要开发的功能。目标开发需求可以是开发人员根据实际开发需求输入的，也可以是从需求平台中获取得到的。

步骤106、基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支。

其中，基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支，以通过第一目标开发分支执行目标开发操作。

在本申请实施例中，从目标节点处，开始创建待开发版本标识对应的用于实现目标开发需求的第一目标开发分支，以便目标开发需求对应的开发操作在第一目标开发分支上实现。

本申请实施例中，若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支，基于第一远程主分支，更新待开发对象的本地主分支，得到目标主分支后，确定待开发对象的待开发版本标识，并从目标主分支中，获取与待开发版本标识对应的目标节点，在确定目标开发需求后，基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支。这样，在检测到目标开发指令时，通过采用待开发对象的第一远程主分支更新待开发对象的本地主分支，得到目标主分支，通过目标主分支来创建实现目标开发需求的第一目标开发分支，解决了目前开发者可以采用任何分支来创建需求开发，导致多分支用途不明确的问题，实现了通过主分支来创建需求开发分支，有效避免了通过其他分支来创建需求开发分支时造成修改容易被遗漏的情况，提高了工作流开发成功率。

基于前述实施例，本申请的实施例提供一种开发管理方法，参照图2所示，方法应用于开发管理节点，该方法包括以下步骤：

步骤201、若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支。

在本申请实施例中，目标开发指令可以是开发管理方法中预先约定好的用于指示进行开发操作的指令。开发管理节点可以运行于具有运行功能，且用户能够操作的设备中，例如可以是计算机设备。以待开发对象为待开发应用程序为例进行说明，目标开发指令可以表示为“hopma dev”，即开发人员输入“hopma dev”后，开发管理节点响应“hopma dev”，从GIT远程平台中，获取待开发应用程序的第一远程master分支。

步骤202、基于第一远程主分支，更新待开发对象的本地主分支，得到目标主分支。

在本申请实施例中，将开发管理节点中待开发应用程序的本地主分支采用第一远程主分支进行更新，得到目标主分支，使本地主分支的内容进行更新得到最新的主分支内容，有效保证了开发的实时性，与待开发应用程序的其他开发内容的同步性。

步骤203、确定待开发对象的待开发版本标识。

在本申请实施例中，待开发对象的待开发版本标识可以是通过问答形式，开发人员输入至开发管理节点中的。待开发版本标识用于标识针对待开发对象的版本信息，例如针对待开发应用程序的第一开发版本，可以记为V.1,随着待开发应用程序的应用过程中，开发人员对V.1版本的待开发应用程序进行功能的优化、漏洞的维护等，对V.1的待开发应用程序进行进一步维护，可以得到第二开发版本，可以记为V.2，如此，在开发人员开发过程中，开发人员可以通过确定待开发版本标识，来确定需要进行管理维护的版本，以进行功能优化。

在一些应用场景中，开发人员在确定待开发对象的待开发版本标识的过程可以是：开发管理节点显示待开发对象对应的各个版本的开发信息，开发人员根据显示的各个版本的开发信息进行选择，输入待开发版本标识。但在一些应用场景下，也可以是开发人员根据开发需求，自己直接输入针对待开发对象的待开发版本标识的。

步骤204、从目标主分支中，获取与待开发版本标识对应的目标节点。

在本申请实施例中，在目标主分支中，包括多个不同版本标识对应的节点，因此，可以从目标主分支中，确定得到与待开发版本标识对应的目标节点，即目标节点中包括有待开发版本标识对应的各种信息内容。

步骤205、确定目标开发需求。

在本申请实施例中，以目标开发需求是由需求平台即第三方需求服务平台提供的进行说明，此时，对应的实现过程可以是开发管理节点通过与需求平台进行通信的通信接口建立通信连接后，从需求平台中获取得到针对待开发对象的目标开发需求。

步骤206、基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支。

其中，基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支，以通过第一目标开发分支执行目标开发操作。

在本申请实施例中，从目标节点为起点，按照预设开发分支命名规范，创建待开发版本标识对应的用于实现目标开发需求的第一目标开发分支。示例性的，更新后得到的目标主分支可以如图3所示，包括针对3个版本的节点，分别为V1节点、V2节点和V3节点，假设待开发版本标识为V2，则可以确定V2节点为目标节点，因此，以V2节点为起点，创建第一目标开发分支dev。

步骤207、若检测到用于指示提交针对第一目标开发分支进行目标开发操作的标识信息的目标提交指令，生成用于提示输入标识信息的第一提示信息，并显示第一提示信息。

在本申请实施例中，目标提交指令为开发人员对第一目标开发分支进行目标开发操作完后，即开发人员对第一目标开发分支的代码编写完以后，输入至开发管理节点的指令信息，标识信息为用于对目标开发操作的内容进行类似标签的信息，至少用于表明用户的目标开发操作的类型。开发管理节点接收到用户输入的目标提交指令后，可以生成需要开发人员输入其目标开发操作的类型的标识信息的第一提示信息，并显示第一提示信息，以提醒开发人员对其目标开发操作输入其目标开发操作的标识信息。

步骤208、若检测到目标标识信息，且目标标识信息与预设标识信息匹配，提交目标标识信息和目标开发操作对应的目标内容至暂存区。

在本申请实施例中，预设标识信息是预先针对开发人员可以进行的开发操作的类型进行预先约定好的，目标标识信息和预设标识信息通常均包括：标题(header)，正文(body)和底部(footer)；其中，开发人员在输入目标标识信息时，可以只输入header，其中，body和footer可以根据开发人员的需求或习惯，选择性选择是否填写。header包括类型(type)和标题(subject)；类型通常包括以下类型至少之一：新功能类型，可以用feat表示；修复漏洞(BUG)类型，可以用fix表示；文档修改类型，可以用docs表示；代码格式修改类型，可以用style表示；添加或修改测试代码类型，可以用test表示；重构代码类型，不包括新增功能和修改BUG，可以用refactor表示；非代码修改类型，可以用于chore表示。subject用于标识简单的修改描述。

目标标识信息与预设标识信息匹配指的是目标标识信息中的内容与预设标识信息中的内容一致，也就是说，目标标识信息中必须包括header，且目标标识信息header中的类型与预设标识信息中的类型匹配，目标标识信息header中还至少包括subject内容，而目标标识信息中关于body和/或footer可以有，也可以没有。这样，由于对提交的信息进行了匹配处理，在提交的信息已经符合要求的情况下，无需执行选择问答过程，有效节约了开发人员的时间，简化了开发过程中的问答过程。

开发管理节点中包括工作区(Workspace)、暂存区(Index/Stage)、版本库(Repository)和远程仓库(Remote)。其中，Workspace，用于存放项目代码；Index/Stage，用于临时存放改动，为一个文件，保存即将提交到文件列表信息；Repository，还可以称为仓库区，用于安全存放数据，包括开发人员提交的所有开发版本的数据；Remote，用于托管代码的服务器。

步骤209、若查询待开发版本标识对应的合并请求已存在，发送目标审核指令至目标用户标识对应的目标管理节点。

其中，目标审核指令用于指示审核目标内容。

在本申请实施例中，待开发版本标识对应的合并请求已存在，表明待开发版本标识对应的目标测试分支已存在，需说明的是，一个待开发版本只有一个测试分支。目标审核指令为用于请求审核人对待开发版本标识对应的目标内容进行审核的指令，即开发人员在针对待开发版本标识对应的目标开发需求进行开发后，相应的开发内容即目标内容需要提交给审核人进行审核，以保证开发人员的开发内容的可靠性和准确性。目标管理节点是目标管理系统中的一个开发管理节点。

审核人可以是开发人员的同事或领导，或者是该待开发对象的负责人。审核人可以是预先约定好的，也可以是在初始化等过程中设置的，在设置时，可以采用在开发内容用于唯一标识审核人的标识信息来标识即目标用户标识，例如可以是审核人的姓名、工号等。

步骤210、若检测到目标管理节点发送的用于指示目标内容已通过检查的指示信息，响应合并请求，合并第一目标开发分支至与合并请求对应的参考测试分支，得到目标测试分支。

在本申请实施例中，审核人在接收到目标审核指令后，对目标管理节点上显示的目标内容进行审核，然后对目标管理节点进行相应的操作，告知开发人员针对目标内容的审核结果。合并请求对应的参考测试分支为待开发版本标识对应的唯一测试分支，在检测到目标管理节点发送的指示信息后，将第一目标开发分支合并至待开发版本标识对应的参考测试分支，从而得到目标测试分支。

步骤211、基于目标测试分支，执行针对目标内容的测试操作。

在本申请实施例中，由于目标测试分支中包括第一目标开发分支，因此，对目标测试分支进行测试处理，即可实现针对目标内容的测试操作。这样，由于目标内容是由除开发人员外的审核人进行审核通过后才进行测试的，避免了随意提测，增加了目标内容的可信度。并且一个待测试版本只有一个测试分支，使所有开发分支均会合并到待测试版本的测试分支上，以实现统一发布，有效避免了测试冲突。

基于前述实施例，在本申请其他实施例中，开发管理节点执行步骤208之后，还可以选择执行步骤212～215：

步骤212、若未查询到合并请求，且查询到存在待开发版本标识对应的参考测试分支，基于参考测试分支，生成合并请求。

在本申请实施例中，由于存在合并请求，一定存在参考测试分支，而存在参考测试分支，不一定存在合并请求。这样，开发管理节点在未查询到待开发版本标识对应的合并请求(Merge Request，MR)时，继续查询是否存在待开发版本标识对应的参考测试分支，若查询到存在参考测试分支时，基于参考测试分支生成合并请求。

步骤213、发送目标审核指令至目标管理节点。

步骤214、若检测到目标管理节点发送的指示信息，响应合并请求，合并第一目标开发分支至参考测试分支，得到目标测试分支。

步骤215、基于目标测试分支，执行针对目标内容的测试操作。

在本申请实施例中，先查询是否有合并请求，在没有查询到合并请求的情况下，再查询是否存在待开发版本标识对应的参考测试分支，有效避免了创建参考测试分支导致资源浪费的情况，并且避免了参考测试分支已经开发的功能被覆盖的情况。

基于前述实施例，在本申请其他实施例中，开发管理节点执行步骤208之后，还可以选择执行步骤216～220：

步骤216、若未查询到合并请求，且未查询到待开发版本标识对应的参考测试分支，创建与待开发版本标识对应的参考测试分支。

步骤217、基于参考测试分支，生成合并请求。

步骤218、发送目标审核指令至目标管理节点。

步骤219、若检测到指示信息，响应合并请求，合并第一目标开发分支至参考测试分支，得到目标测试分支。

步骤220、基于目标测试分支，执行针对目标内容的测试操作。

在本申请实施例中，在未查询到合并请求，也未查询到待开发版本标识对应的参考测试分支时，需创建待开发版本标识对应的参考测试分支，以进行后续处理，有效保证了测试分支的唯一性。

基于前述实施例，在本申请其他实施例中，开发管理节点执行步骤211之后，还用于执行步骤221～223：

步骤221、在执行针对目标内容的测试操作过程中，若需要对目标内容进行修改，基于第一目标开发分支，接收修改操作。

在本申请实施例中，在测试操作过程中，需要对目标内容进行修改的情况包括测试时出现测试缺陷，导致需要修改的情况，也有开发人员在测试时发现需要对实现过程进行改进的情况等，此时，开发人员对目标内容进行修改时，是在第一目标开发分支上进行修改操作的。

步骤222、更新目标开发操作为修改操作。

步骤223、重复执行步骤“若检测到用于指示提交针对第一目标开发分支进行目标开发操作的标识信息的目标提交指令，生成用于提示输入标识信息的第一提示信息，并显示第一提示信息”，直至执行至“执行针对目标内容的测试操作”。

在本申请实施例中，将修改操作更新为目标开发操作后，重复执行步骤207～220的操作内容，直至完成测试过程。

需说明的是，步骤221～223也可以是开发管理节点执行步骤215或步骤220之后执行的，即在执行测试过程中，还未执行发布操作前，可以针对目标内容进行相应的修改操作。

这样，在第一目标开发分支上进行修改操作，有效避免了上线修改时容易出现遗漏的情况。

基于前述实施例，在本申请其他实施例中，开发管理节点执行步骤211之后，还用于执行步骤224～227：

步骤224、若待开发版本标识包括的至少两个参考开发需求对应的参考开发分支已通过测试，从至少两个参考开发需求对应的参考开发分支中，确定目标发布需求对应的第二目标开发分支。

其中，目标发布需求属于至少两个参考开发需求。

在本申请实施例中，在一次开发过程中，针对待开发版本标识需要同时对至少两个参考开发需求进行开发，并至少两个参考开发需求已通过测试时，在最终针对该待开发版本标识需要进行发布时最终需要发布的目标发布需求为至少两个参考开发需求中的部分需求时，确定目标发布需求对应的第二目标开发分支。

步骤225、删除待开发版本标识当前对应的当前测试分支。

在本申请实施例中，由于当前测试分支已合并有至少两个参考开发需求对应的参考开发分支，因此，需要删除当前测试分支。

步骤226、创建与待开发版本标识对应的参考测试分支。

在本申请实施例中，基于待开发版本标识设置不与至少两个参考开发需求对应的参考开发分支合并的测试分支。

步骤227、合并第二目标开发分支至参考测试分支，得到目标测试分支。

在本申请实施例中，将目标发布需求对应的第二目标开发分支合并至参考测试分支中，从而得到目标测试分支。这样，在一个应用程序的某个版本有多个需求时，由于本申请实施例中需求是按照开发分支来区分的，因此，只需将目标发布需求对应的第二目标开发分支合并至新创建的测试分支即可实现后续发布过程，明显简化了只需发布部分需求的操作过程，提高了部分开发需求在此次开发过程中不发布的实现过程。

需说明的是，步骤224～227也可以是开发管理节点执行步骤215或步骤220之后执行的，还可以是开发管理节点执行步骤221～223之后执行的，具体执行情况可以根据实际情况来实现，此处不做具体限制。

基于前述实施例，在本申请其他实施例中，开发管理节点执行步骤211之后，开发管理节点可以选择执行步骤228～232：

步骤228、若检测到针对待开发版本标识对应的生产打包指令，从GIT远程平台中，获取第二远程主分支。

其中，第二远程主分支与第一远程主分支具有关联关系。

在本申请实施例中，生产打包指令可以是开发人员输入至开发管理节点的，对应的，生产打包指令可以是特定的人员来输入至开发管理节点的。生产打包指令可以是“hopma deploy”。开发人员输入生产打包指令至开发管理节点，开发管理节点从GIT远程平台中，获取最新版本的第二远程主分支。

步骤229、采用第二远程主分支同步第一发布分支。

步骤230、合并目标测试分支至第一发布分支，得到第二发布分支。

步骤231、推送第二发布分支至远程仓库。

步骤232、若检测到目标发布指令，合并第二发布分支至第二远程主分支。

在本申请实施例中，在发布过程中，从GIT远程平台中获取最新版本的第二远程主分支来进行同步最新发布的功能，避免了由于忘记同步分支，导致遗漏上一版本的功能的问题。

需说明的是，步骤228～232也可以是开发管理节点执行步骤215或步骤220之后执行的，还可以是开发管理节点执行步骤221～223之后执行的，还可以是开发管理节点执行步骤224～227之后执行的，具体执行情况可以根据实际情况来实现，此处不做具体限制。

基于前述实施例，在本申请其他实施例中，开发管理节点执行步骤232之后，还用于执行步骤233～235：

步骤233、若检测到目标日志生成指令，生成针对目标内容的修改日志信息。

在本申请实施例中，目标日志生成指令可以是“hopma changelog”。开发人员输入目标日志生成指令至开发管理节点时，开发管理节点响应目标生成指令，生成针对目标内容的修改日志信息，并存储修改日志信息，以便后续基于生成的修改日志信息进行分析。修改日志信息包括feat、fix类型的提交。

步骤234、创建待开发版本的目标版本标识。

在本申请实施例中，目标版本标识为用于标识针对待开发版本的发布版本内容进行标识的标识信息。

步骤235、推送第二远程主分支和目标版本标识至远程仓库。

这样，在发布时还针对修改内容生成对应的日志信息，以便后续进行分析，提高了开发的可靠性。

基于前述实施例，在本申请其他实施例中，开发管理节点执行步骤235之后，还用于执行步骤236～237:

步骤236、若检测到目标清理指令，显示待清理测试分支标识信息和待清理开发分支标识信息。

在本申请实施例中，目标清理指令可以记为“hopma clear”。

步骤237、若检测到目标清理测试分支标识信息和目标清理开发分支标识信息，删除目标清理测试分支标识信息对应的测试分支和目标清理开发分支标识信息对应的开发分支。

在本申请实施例中，将不要需要的测试分支以及开发分支进行删除处理，有效节约了开发管理节点的存储资源，提高了开发管理节点的运行效率。

基于前述实施例，在本申请其他实施例中，开关管理节点执行步骤201之前，还用于执行步骤238～240：

步骤238、若检测到目标初始化指令，获取GIT授权码。

在本申请实施例中，目标初始化指令可以记为“hopma init”，对应的GIT授权码可以是开发人员从GIT远程平台中获取到后，输入至开发管理节点的。也可以是开发管理节点直接从GIT远程平台中获取得到的。

步骤239、若与需求平台关联，获取需求平台对应的平台授权码。

在本申请实施例中，开发管理节点与需求平台之间建立通信连接，平台授权码可以是开发人员从需求平台中获取得到的，然后开发人员将获取得到的平台授权码输入至开关管理节点中的，也可以是开发管理节点向需求平台请求得到的。

步骤240、若GIT授权码和平台授权码均有效，将GIT授权码和平台授权码设置为用户配置参数。

其中，GIT授权码用于与GIT远程平台建立通信连接，平台授权码用于与需求平台建立通信连接。

在本申请实施例中，开关管理节点获取到GIT授权码后，将GIT授权码发送至GIT远程平台，以使GIT远程平台对GIT授权码进行有效性验证，若开关管理节点接收到GIR远程平台发送的用于指示GIT授权码有效的信息，开关管理节点确定GIT授权码有效，开发管理节点将平台授权码发送至对应的需求平台，以使需求平台对平台授权码进行有效性验证，若开发管理节点接收到需求平台发送的用于指示平台授权码有效的信息，开发管理节点确定平台授权码有效。

这样，通过初始化操作，使开发管理节点可以关联需求平台和GIT远程平台，丰富了开发管理节点的功能。

基于前述实施例，在本申请其他实施例中，待开发版本标识对应的目标测试分支只包括一个测试分支。

基于前述实施例，在本申请其他实施例中，开发管理节点包括hopma工具和本地GIT工具，在开发人员输入hopma init指令后，hopma工具通过问答交互方式收集到需求平台的平台授权码dpms token及GIT远程平台的GIT授权码git token后，步骤238～240和步骤201～206中对应的步骤的具体实现时序图可以参照图4所示，具体实现过程包括以下步骤：

步骤31、hopma工具发送dpms token至需求平台，进行dpms token的有效性校验；hopma工具发送git token至GIT远程平台，进行git token有效性校验。

其中，hopma工具与需求平台和GIT远程平台使通过对应的应用程序接口(Application Programming Interface)来实现授权码校验的。

步骤32、hopma工具接收需求平台发送的第一校验结果；hopma工具接收GIT远程平台发送的第二校验结果。

步骤33、若第一校验结果表明dpms token有效，第二校验结果表明git token有效，hopma工具将dpms token和git token写入本地GIT工具的用户配置里。

其中，dpms token用于使hopma工具调用需求平台dpms的开放接口，git token用于使hopma工具调用GIT远程平台的开放接口。

步骤34、hopma工具接收hopma dev，hopma工具执行hopma dev，调用本地GIT API切换到master分支，并通过本地GIT工具通过git pull指令从GIT远程平台获取最新master分支。

步骤35、通过本地GIT工具采用获取到的最新master分支对本地master进行同步修改。

步骤36、hopma工具通过与需求平台API调用获取需求和版本接口，通过问答交互方式选中目标开发需求及待开发版本。

步骤37、hopma工具调用GIT API创建待开发版本对应的dev分支，并把目标开发需求写入GIT本地的项目配置里。

基于前述实施例，在本申请其他实施例中，步骤207～223中的部分内容的对应的步骤的具体实现时序图可以参照图5所示，具体实现过程包括以下步骤：

步骤41、hopma工具检测到开发人员输入的git commit指令，执行git commit指令，通过git hook prepare-commit-msg调用hopma commit指令，通过本地GIT工具实现问答交互方式获取提交信息。

其中，提交信息为前述目标标识信息。

在一些应用场景中，开发人员可以直接输入hopma commit指令，使hopma工具执行hopma commit指令，以通过问答交互方式填写提交信息。

步骤42、hopma工具再通过git hook commit-msg调用hopma validate指令，通过本地GIT工具进行提交消息规范校验。

步骤43、hopma工具查询GIT远程平台中是否有MR。

其中，hopma工具是通过执行hopma test指令，调用GIT平台的API的mergerequest查询来实现查询GIT远程平台中是否有MR。

步骤44、若hopma工具未查询到MR，hopma工具创建test分支。

步骤45、通过本地GIT推送(push)test分支至GIT远程平台。

步骤46、如果目标开发需求缺失，hopma工具还会调用需求平台的API，重新获取目标开发需求及待开发版本。

步骤47、hopma工具从GIT远程平台中查询审核review人员列表，并确定目标审核人员。

步骤48、hopma工具创建merge request开放接口，实现MR的创建。

其中，hopma工具根据目标开发需求，结合目标审核人员作为创建MR的提交内容。

基于前述实施例，在本申请其他实施例中，步骤228～237对应的步骤的具体实现时序图可以参照图6所示，具体实现过程包括以下步骤：

步骤51、hopma工具检测到开发人员输入的hopma deploy指令，执行hopma deploy指令，hopma工具将分支切换到release分支。

步骤52、本地GIT工具从GIT远程平台中获取最新master分支并同步release分支。

步骤53、本地GIT工具通过GIT API将test分支合并到release分支。

步骤54、本地GIT工具推送合并之后的release分支到GIT远程平台。

步骤55、等上线发布完成后，hopma工具执行hopma publish，将分支切换到master分支。

步骤56、本地GIT工具从GIT远程平台中获取最新版本的master分支，来同步release分支。

步骤57、hopma工具执行hopma changelog，生成本次需求的修改提交日志。

步骤58、hopma工具创建本次的版本tag。

步骤59、hopma工具推送合并release分支的master分支和tag到GIT远程平台。

步骤510、hopma工具执行hopma clear指令，选择要删除的test分支和dev分支，调用GIT API删除选中的test分支和dev分支。

其中，前述包括的指令至少包括以下规范指令：

hopma init:初始化配置指令，用于git hooks初始化、需求平台token及git远程仓库token收集验证。

hopma dev:开始开发指令，用于按照需求版本和自定义版本创建dev分支。

hopma test:提交测试指令，用于创建版本test分支、dev分支到test分支的MR请求，并指定目标审核人。

hopma deploy:生产打包指令，用于将待开发版本的test分支合并到release分支，并同步Master分支。

hopma publish:发布指令，用于在master分支与release分支合并后，创建版本tag和changelog归档。

hopma changelog:日志生成指令，用于生成修改后日志changelog。

hopma clear:清理指令，用于清理选中版本的dev分支和test分支。

hopma commit:提交指令，实现husky prepare-commit-msg钩子回调，用于提交修改前修改提交信息。

hopma validate:实现husky commit-msg hooks钩子回调，用于提交修改校验提交信息。在执行hopma commit时，自动执行。

hopma push:实现husky pre-push hooks钩子回调，用于推送分支，提示执行提测。

其中，开发dev分支的规范包括：用途为用于功能需求开发和bug修复，命名规范可以为：dev_${name}_v${version}，作用域，所有开发人员均可执行push和merge操作。测试test分支的规范为：用途：用于代码审核和测试，命名规范为：test_v{version},作用域：通常为管理员可push和merge操作。发布release分支的规范为：用于预发布和正式发布，命名规范：release，作用域：通常为管理员可push和merge操作。主master分支规范：用于同步归档，命名规范：master，作用域：通常为管理员可push和merge操作。

对应的，开发管理方法可以分为开发阶段、测试阶段、发布归档阶段。完整流程如图7所示：

步骤61、开始。步骤62、开发人员输入hopma init。步骤63、开发人员填写gittoken。步骤64、开发管理节点判断是否关联需求平台，若关联，执行步骤65，否则，执行步骤66。步骤65、开发人员设置需求平台token。步骤66、开发管理节点执行初始化。步骤67、开发人员输入hopma dev。步骤68、开发管理节点同步master分支。步骤69、开发管理节点判断是否支持需求平台，若支持，执行步骤610，否则执行611。步骤610、开发管理节点获取需求版本号。步骤611、开发人员输入自定义版本号。步骤612、开发管理节点创建并切换到dev分支。步骤613、开发人员输入hopma commit。步骤614、开发人员填写提交信息。步骤615、开发管理节点自动运行hopma validate。步骤616、开发管理节点判断提交信息是否符合规范，若不符合规范，执行步骤613，否则执行步骤617。步骤617、开发人员输入hopma test。步骤618、开发管理节点判断提交的提交信息是否提交成功，若提交失败，执行步骤613，否则执行步骤619。步骤619、开发管理节点判断是否已创建有MR，若未创建有MR，执行步骤620，若已创建有MR，执行步骤623。步骤620、开发管理节点判断是否已有test分支，若有test分支，执行步骤621，否则，执行步骤622。步骤621、开发管理节点创建MR。步骤622、开发管理节点创建test分支。步骤623、开发管理节点生成提示审核的提示信息。步骤624、开发管理节点判断目标内容是否已审核，若已审核，执行步骤625，否则执行步骤623。步骤625、开发管理节点判断测试分支是否已通过测试，若已通过测试，执行步骤626，否则执行步骤613。步骤626、开发人员输入hopma deploy。步骤627、开发管理节点同步master分支。步骤628、开发管理节点合并master分支至release分支。步骤629、开发管理节点推送合并后的release分支。步骤630、开发人员输入hopma publish。步骤631、开发管理节点将合并后的release分支合并至master分支。步骤632、开发管理节点生成changelog。步骤633、开发管理节点创建tag。步骤634、开发管理节点判断是否清理分支，若清理，执行步骤635，否则执行步骤636。步骤635、清理分支。步骤636、结束。

这样，从开发、测试、发布规范都有具体的规范，hopma dev指令能按照规范创建规范的开发分支名，不用人为的去按照规范创建分支，并且创建的开发分支可以关联需求平台及版本，开发分支、测试分支以及主分支各个分支的功能明确，有利于分支管理。hopmatest指令在提测前要求进行审核，可以创建MR请求，并指定审核人进行设备，只有审核通过并且同意MR请求之后，才会提交测试。最后hopam deploy、hopma publish会归档每次的修改，做好分支之间的同步，解决多人协作中产生的各种问题，为开发流程提高了工作效率。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

本申请实施例中，若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支，基于第一远程主分支，更新待开发对象的本地主分支，得到目标主分支后，确定待开发对象的待开发版本标识，并从目标主分支中，获取与待开发版本标识对应的目标节点，在确定目标开发需求后，基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支。这样，在检测到目标开发指令时，通过采用待开发对象的第一远程主分支更新待开发对象的本地主分支，得到目标主分支，通过目标主分支来创建实现目标开发需求的第一目标开发分支，解决了目前开发者可以采用任何分支来创建需求开发，导致多分支用途不明确的问题，实现了通过主分支来创建需求开发分支，有效避免了通过其他分支来创建需求开发分支时造成修改容易被遗漏的情况，提高了工作流开发成功率。

基于前述实施例，本申请的实施例提供一种开发管理平台，参照图8所示，该开发管理平台7可以包括：存储空间71和至少一个开发管理节点72；其中：

开发管理节点72，用于执行存储空间71中存储的开发管理程序，以实现以下步骤：

若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支；

基于第一远程主分支，更新待开发对象的本地主分支，得到目标主分支；

确定待开发对象的待开发版本标识；

从目标主分支中，获取与待开发版本标识对应的目标节点；

确定目标开发需求；

基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支，以通过第一目标开发分支执行目标开发操作。

在本申请其他实施例中，开发管理节点还用于执行以下步骤：

若检测到用于指示提交针对第一目标开发分支进行目标开发操作的标识信息的目标提交指令，生成用于提示输入标识信息的第一提示信息，并显示第一提示信息；

若检测到目标标识信息，且目标标识信息与预设标识信息匹配，提交目标标识信息和目标开发操作对应的目标内容至暂存区；

若查询待开发版本标识对应的合并请求已存在，发送目标审核指令至目标用户标识对应的目标管理节点；其中，目标审核指令用于指示审核目标内容；

若检测到目标管理节点发送的用于指示目标内容已通过检查的指示信息，响应合并请求，合并第一目标开发分支至与合并请求对应的参考测试分支，得到目标测试分支；

基于目标测试分支，执行针对目标内容的测试操作。

在本申请其他实施例中，开发管理节点还用于执行以下步骤：

若未查询到合并请求，且查询到存在待开发版本标识对应的参考测试分支，基于参考测试分支，生成合并请求；

发送目标审核指令至目标管理节点；

若检测到目标管理节点发送的指示信息，响应合并请求，合并第一目标开发分支至参考测试分支，得到目标测试分支；

基于目标测试分支，执行针对目标内容的测试操作。

在本申请其他实施例中，开发管理节点还用于执行以下步骤：

若未查询到合并请求，且未查询到待开发版本标识对应的参考测试分支，创建与待开发版本标识对应的参考测试分支；

基于参考测试分支，生成合并请求；

发送目标审核指令至目标管理节点；

若检测到指示信息，响应合并请求，合并第一目标开发分支至参考测试分支，得到目标测试分支；

基于目标测试分支，执行针对目标内容的测试操作。

在本申请其他实施例中，开发管理节点还用于执行以下步骤：

在执行针对目标内容的测试操作过程中，若需要对目标内容进行修改，基于第一目标开发分支，接收修改操作；

更新目标开发操作为修改操作；

重复执行步骤“若检测到用于指示提交针对第一目标开发分支进行目标开发操作的标识信息的目标提交指令，生成用于提示输入标识信息的第一提示信息，并显示第一提示信息”，直至执行至“执行针对目标内容的测试操作”。

在本申请其他实施例中，开发管理节点还用于执行以下步骤：

若待开发版本标识包括的至少两个参考开发需求对应的参考开发分支已通过测试，从至少两个参考开发需求对应的参考开发分支中，确定目标发布需求对应的第二目标开发分支；其中，目标发布需求属于至少两个参考开发需求；

删除待开发版本标识当前对应的当前测试分支；

创建与待开发版本标识对应的参考测试分支；

合并第二目标开发分支至参考测试分支，得到目标测试分支。

在本申请其他实施例中，开发管理节点还用于执行以下步骤：

若检测到针对待开发版本标识对应的生产打包指令，从GIT远程平台中，获取第二远程主分支；其中，第二远程主分支与第一远程主分支具有关联关系；

采用第二远程主分支同步第一发布分支；

合并目标测试分支至第一发布分支，得到第二发布分支；

推送第二发布分支至远程仓库；

若检测到目标发布指令，合并第二发布分支至第二远程主分支。

在本申请其他实施例中，开发管理节点执行步骤若检测到目标发布指令，合并第二发布分支至第二远程主分支之后，还用于执行以下步骤：

若检测到目标日志生成指令，创建待开发版本的目标版本标识；

推送第二远程主分支和目标版本标识至远程仓库。

在本申请其他实施例中，开发管理节点用于执行步骤推送第二远程主分支和目标版本标识至远程仓库之后，还用于执行以下步骤：

若检测到目标清理指令，显示待清理测试分支标识信息和待清理开发分支标识信息；

若检测到目标清理测试分支标识信息和目标清理开发分支标识信息，删除目标清理测试分支标识信息对应的测试分支和目标清理开发分支标识信息对应的开发分支。

在本申请其他实施例中，开发管理节点用于执行步骤若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支之前，还用于执行：

若检测到目标初始化指令，获取GIT授权码；

若与需求平台关联，获取需求平台对应的平台授权码；

若GIT授权码和平台授权码均有效，将GIT授权码和平台授权码设置为用户配置参数；其中，GIT授权码用于与GIT远程平台建立通信连接，平台授权码用于与需求平台建立通信连接。

在本申请其他实施例中，待开发版本标识对应的目标测试分支只包括一个测试分支。

需要说明的是，本申请实施例中个或者多个程序可被一个或者多个处理器的步骤的解释说明，可以参照图1～2以及其他实施例提供的方法实现过程，此处不再赘述。

本申请实施例中，若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支，基于第一远程主分支，更新待开发对象的本地主分支，得到目标主分支后，确定待开发对象的待开发版本标识，并从目标主分支中，获取与待开发版本标识对应的目标节点，在确定目标开发需求后，基于目标节点，按照预设开发分支命名规范，创建待开发版本标识对应的实现目标开发需求的第一目标开发分支。这样，在检测到目标开发指令时，通过采用待开发对象的第一远程主分支更新待开发对象的本地主分支，得到目标主分支，通过目标主分支来创建实现目标开发需求的第一目标开发分支，解决了目前开发者可以采用任何分支来创建需求开发，导致多分支用途不明确的问题，实现了通过主分支来创建需求开发分支，有效避免了通过其他分支来创建需求开发分支时造成修改容易被遗漏的情况，提高了工作流开发成功率。

基于前述实施例，本申请的实施例提供一种计算机可读存储介质，简称为存储介质，该计算机可读存储介质存储有一个或者多个程序，该一个或者多个程序可被一个或者多个处理器执行，以实现如图1～2以及其他实施例提供的开发管理方法实现过程，此处不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

Claims (13)

1.一种开发管理方法，其特征在于，所述方法包括：

若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支；

基于所述第一远程主分支，更新所述待开发对象的本地主分支，得到目标主分支；

确定所述待开发对象的待开发版本标识；

从所述目标主分支中，获取与所述待开发版本标识对应的目标节点；

确定目标开发需求；

基于所述目标节点，按照预设开发分支命名规范，创建所述待开发版本标识对应的实现所述目标开发需求的第一目标开发分支，以通过所述第一目标开发分支执行目标开发操作。

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

若检测到用于指示提交针对所述第一目标开发分支进行目标开发操作的标识信息的目标提交指令，生成用于提示输入标识信息的第一提示信息，并显示所述第一提示信息；

若检测到目标标识信息，且所述目标标识信息与预设标识信息匹配，提交所述目标标识信息和所述目标开发操作对应的目标内容至暂存区；

若查询所述待开发版本标识对应的合并请求已存在，发送目标审核指令至目标用户标识对应的目标管理节点；其中，所述目标审核指令用于指示审核所述目标内容；

若检测到所述目标管理节点发送的用于指示所述目标内容已通过检查的指示信息，响应所述合并请求，合并所述第一目标开发分支至与所述合并请求对应的参考测试分支，得到目标测试分支；

基于所述目标测试分支，执行针对所述目标内容的测试操作。

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

若未查询到所述合并请求，且查询到存在所述待开发版本标识对应的所述参考测试分支，基于所述参考测试分支，生成所述合并请求；

发送所述目标审核指令至所述目标管理节点；

若检测到所述目标管理节点发送的所述指示信息，响应所述合并请求，合并所述第一目标开发分支至所述参考测试分支，得到目标测试分支；

基于所述目标测试分支，执行针对所述目标内容的测试操作。

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

若未查询到所述合并请求，且未查询到所述待开发版本标识对应的所述参考测试分支，创建与所述待开发版本标识对应的所述参考测试分支；

基于所述参考测试分支，生成所述合并请求；

发送所述目标审核指令至所述目标管理节点；

若检测到所述指示信息，响应所述合并请求，合并所述第一目标开发分支至所述参考测试分支，得到目标测试分支；

基于所述目标测试分支，执行针对所述目标内容的测试操作。

5.根据权利要求2至4任一项所述的方法，其特征在于，所述方法还包括：

在执行针对所述目标内容的测试操作过程中，若需要对所述目标内容进行修改，基于所述第一目标开发分支，接收修改操作；

更新所述目标开发操作为所述修改操作；

重复执行步骤“若检测到用于指示提交针对所述第一目标开发分支进行目标开发操作的标识信息的目标提交指令，生成用于提示输入标识信息的第一提示信息，并显示所述第一提示信息”，直至执行至“执行针对所述目标内容的测试操作”。

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

若所述待开发版本标识包括的至少两个参考开发需求对应的参考开发分支已通过测试，从所述至少两个参考开发需求对应的参考开发分支中，确定目标发布需求对应的第二目标开发分支；其中，所述目标发布需求属于至少两个参考开发需求；

删除所述待开发版本标识当前对应的当前测试分支；

创建与所述待开发版本标识对应的参考测试分支；

合并所述第二目标开发分支至所述参考测试分支，得到目标测试分支。

7.根据权利要求2至4、6任一项所述的方法，其特征在于，所述方法还包括：

若检测到针对所述待开发版本标识对应的生产打包指令，从所述GIT远程平台中，获取第二远程主分支；其中，所述第二远程主分支与所述第一远程主分支具有关联关系；

采用所述第二远程主分支同步第一发布分支；

合并所述目标测试分支至所述第一发布分支，得到第二发布分支；

推送所述第二发布分支至远程仓库；

若检测到目标发布指令，合并所述第二发布分支至所述第二远程主分支。

8.根据权利要求7所述的方法，其特征在于，所述若检测到目标发布指令，合并所述第二发布分支至所述第二远程主分支之后，所述方法还包括：

若检测到目标日志生成指令，生成针对所述目标内容的修改日志信息；

创建所述待开发版本的目标版本标识；

推送所述第二远程主分支和所述目标版本标识至远程仓库。

9.根据权利要求8所述的方法，其特征在于，所述推送所述第二远程主分支和所述目标版本标识至远程仓库之后，所述方法还包括：

若检测到目标清理指令，显示待清理测试分支标识信息和待清理开发分支标识信息；

若检测到目标清理测试分支标识信息和目标清理开发分支标识信息，删除所述目标清理测试分支标识信息对应的测试分支和所述目标清理开发分支标识信息对应的开发分支。

10.根据权利要求1所述的方法，其特征在于，所述若检测到目标开发指令，从分布式版本控制系统GIT远程平台中，获取待开发对象的第一远程主分支之前，所述方法还包括：

若检测到目标初始化指令，获取GIT授权码；

若与需求平台关联，获取所述需求平台对应的平台授权码；

若所述GIT授权码和所述平台授权码均有效，将所述GIT授权码和所述平台授权码设置为用户配置参数；其中，所述GIT授权码用于与GIT远程平台建立通信连接，所述平台授权码用于与所述需求平台建立通信连接。

11.根据权利要求2至4任一项所述的方法，其特征在于，所述待开发版本标识对应的目标测试分支只包括一个测试分支。

12.一种开发管理平台，其特征在于，所述开发管理平台包括：存储空间和至少一个开发管理节点；其中：

所述开发管理节点，用于执行所述存储空间中存储的开发管理程序，以实现如权利要求1至11中任一项所述的开发管理方法的步骤。

13.一种存储介质，其特征在于，所述存储介质上存储有开发管理程序，所述开发管理程序被处理器执行时实现如权利要求1至11中任一项所述的开发管理方法的步骤。

Images