A development management method, platform and storage medium

Abstract

This application discloses a development management method, which includes: if a target development instruction is detected, obtaining a first remote main branch of the object to be developed from a remote platform of the distributed version control system Git; updating the local main branch of the object to be developed based on the first remote main branch to obtain a target main branch; determining the version identifier to be developed of the object to be developed; obtaining a target node corresponding to the version identifier to be developed from the target main branch; determining the target development requirements; and creating a first target development branch corresponding to the version identifier to be developed, implementing the target development requirements, based on the target node and according to a preset development branch naming convention, so as to execute the target development operation through the first target development branch. This application also discloses a development management platform and a storage medium.

Description

Technical Field

[0001] This application relates to the field of World Wide Web (Web) front-end technology, and in particular to a development management method, platform and storage medium. Background Technology

[0002] With the rapid development of computer technology, more and more technologies are being applied in the financial field. The traditional financial industry is gradually transforming into Fintech. However, due to the security and real-time requirements of the financial industry, higher demands are being placed on technology. With the rapid development of internet technology, various applications have been developed and applied. To improve the development efficiency of developers, a variety of development tools are provided. Currently, developers commonly use distributed version control systems (GIT) for development. Git mainly has two workflow modes: one mode treats the master branch as a test branch, and all feature and fix branches are merged into the master branch. Then, at a certain point in time, a release branch is checked out from the master branch and deployed to the production environment. The other mode is that the master branch is the production environment synchronization branch, always keeping the latest modifications. Developers can check out multiple feature or fix branches from the master branch within the same version. After development, these are merged into the corresponding release branch. Testing and deployment are performed on the release branch, and after deployment, the changes are committed back to the master branch.

[0003] Currently, workflow development can be initiated from any branch, leading to unclear purposes for each branch and the potential for overlooking modifications before deployment, thus compromising the success rate of workflow development.

[0004] Application content

[0005] To address the aforementioned technical problems, this application aims to provide a development management method, platform, and storage medium. This solves the problem that developers can use any branch to create requirement development, leading to unclear purposes for multiple branches. It enables the creation of requirement development branches through the main branch, effectively avoiding the situation where modifications are easily overlooked when creating requirement development branches through other branches, and improving the success rate of workflow development.

[0006] The technical solution of this application is implemented as follows:

[0007] Firstly, a development management method, the method comprising:

[0008] If a target development instruction is detected, the first remote master branch of the object to be developed is obtained from the distributed version control system GIT remote platform.

[0009] Based on the first remote main branch, update the local main branch of the object to be developed to obtain the target main branch;

[0010] Determine the development version identifier of the object to be developed;

[0011] Obtain the target node corresponding to the version identifier to be developed from the target main branch;

[0012] Define the target development requirements;

[0013] Based on the target node, and in accordance with the preset development branch naming convention, a first target development branch corresponding to the version identifier to be developed is created to implement the target development requirements, so as to execute the target development operation through the first target development branch.

[0014] Secondly, a development management platform, the development management platform comprising: storage space and at least one development management node; wherein:

[0015] The development management node is used to execute the development management program stored in the storage space to implement the steps of the development management method as described in any of the above.

[0016] Thirdly, a storage medium storing a development management program, which, when executed by a processor, implements the steps of the development management method as described in any of the preceding claims.

[0017] In this embodiment, if a target development instruction is detected, the first remote main branch of the object to be developed is obtained from the distributed version control system GIT remote platform. Based on the first remote main branch, the local main branch of the object to be developed is updated. After obtaining the target main branch, the version identifier of the object to be developed is determined, and the target node corresponding to the version identifier is obtained from the target main branch. After determining the target development requirements, based on the target node, a first target development branch corresponding to the version identifier of the object to be developed, which implements the target development requirements, is created according to the preset development branch naming convention. In this way, when a target development instruction is detected, the local main branch of the object to be developed is updated using the first remote main branch to obtain the target main branch. The first target development branch that implements the target development requirements is then created using the target main branch. This solves the problem that currently, any branch can be used to create requirement development, leading to unclear uses for multiple branches. It realizes the creation of requirement development branches through the main branch, effectively avoiding the situation where modifications are easily missed when creating requirement development branches through other branches, and improving the success rate of workflow development. Attached Figure Description

[0018] Figure 1 A flowchart illustrating a development management method provided in an embodiment of this application;

[0019] Figure 2 A flowchart illustrating another development management method provided in this application embodiment;

[0020] Figure 3 A schematic diagram of a main branch structure provided in an embodiment of this application;

[0021] Figure 4 A schematic diagram illustrating the implementation sequence of a development management method provided in this application embodiment;

[0022] Figure 5 A schematic diagram illustrating the implementation sequence of another development management method provided in this application embodiment;

[0023] Figure 6 A schematic diagram illustrating the implementation sequence of another development management method provided in this application embodiment;

[0024] Figure 7 A flowchart illustrating yet another development management method provided in this application embodiment;

[0025] Figure 8 This is a schematic diagram of the structure of a development management platform provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0027] Embodiments of this application provide a development management method, referring to Figure 1 As shown, the method is applied to the development management node, and the method includes the following steps:

[0028] Step 101: If the target development instruction is detected, obtain the first remote main branch of the object to be developed from the distributed version control system GIT remote platform.

[0029] In this embodiment, the development management node provides a development environment for developers and manages their development operations, such as their code. The development management system includes at least one development management node. For the same development object, such as the same application to be developed, at least one developer can simultaneously perform development operations on the corresponding development management node. The target development instruction is a pre-agreed development statement entered by the developer on the development management node to implement the development. After detecting the target development instruction, the development management node responds by retrieving the first remote master branch of the object to be developed from the Git remote platform.

[0030] Step 102: Based on the first remote master branch, update the local master branch of the object to be developed to obtain the target master branch.

[0031] In this embodiment of the application, after different developers develop the corresponding requirements for the object to be developed, they will save the corresponding modifications in the first remote main branch. Therefore, after the development management node receives the target development instruction, it needs to obtain the first remote main branch from the GIT remote platform to update the local main branch in the development management node and obtain the target main branch, so as to ensure that the developers are currently developing based on the latest main branch.

[0032] Step 103: Determine the version identifier of the object to be developed.

[0033] In this embodiment of the application, the identifier of the version to be developed of the object to be developed can be entered by the developer.

[0034] Step 104: Obtain the target node corresponding to the version identifier to be developed from the target main branch.

[0035] In this embodiment, the target main branch includes a series of nodes containing saved development modifications for different development versions of the object to be developed at different points in time. Therefore, the target node corresponding to the development version identifier of the object to be developed can be determined from the target main branch.

[0036] Step 105: Determine the target development requirements.

[0037] In this embodiment of the application, the target development requirement refers to the functions that need to be developed for the object to be developed. The target development requirement can be input by the developers based on actual development needs, or it can be obtained from the requirement platform.

[0038] Step 106: Based on the target node, create the first target development branch corresponding to the version identifier to be developed, in accordance with the preset development branch naming convention, to achieve the target development requirements.

[0039] Specifically, based on the target node, according to the preset development branch naming convention, a first target development branch corresponding to the version to be developed is created to implement the target development requirements, so as to execute the target development operation through the first target development branch.

[0040] In this embodiment of the application, starting from the target node, a first target development branch corresponding to the version identifier to be developed is created to implement the target development requirements, so that the development operations corresponding to the target development requirements are implemented on the first target development branch.

[0041] In this embodiment, if a target development instruction is detected, the first remote main branch of the object to be developed is obtained from the distributed version control system GIT remote platform. Based on the first remote main branch, the local main branch of the object to be developed is updated. After obtaining the target main branch, the version identifier of the object to be developed is determined, and the target node corresponding to the version identifier is obtained from the target main branch. After determining the target development requirements, based on the target node, a first target development branch corresponding to the version identifier of the object to be developed, which implements the target development requirements, is created according to the preset development branch naming convention. In this way, when a target development instruction is detected, the local main branch of the object to be developed is updated using the first remote main branch to obtain the target main branch. The first target development branch that implements the target development requirements is then created using the target main branch. This solves the problem that developers can currently use any branch to create requirement development, leading to unclear uses for multiple branches. It realizes the creation of requirement development branches through the main branch, effectively avoiding the situation where modifications are easily missed when creating requirement development branches through other branches, and improving the success rate of workflow development.

[0042] Based on the foregoing embodiments, embodiments of this application provide a development management method, referring to... Figure 2 As shown, the method is applied to the development management node, and the method includes the following steps:

[0043] Step 201: If the target development instruction is detected, obtain the first remote main branch of the object to be developed from the distributed version control system GIT remote platform.

[0044] In this embodiment, the target development instruction can be a pre-defined instruction in the development management method used to instruct the development operation. The development management node can run on a device with operational capabilities that can be operated by the user, such as a computer device. Taking the application to be developed as an example, the target development instruction can be represented as "hopma dev". That is, after the developer enters "hopma dev", the development management node responds with "hopma dev" and obtains the first remote master branch of the application to be developed from the Git remote platform.

[0045] Step 202: Based on the first remote master branch, update the local master branch of the object to be developed to obtain the target master branch.

[0046] In this embodiment, the local main branch of the application to be developed in the development management node is updated using the first remote main branch to obtain the target main branch. This updates the content of the local main branch to obtain the latest main branch content, effectively ensuring the real-time nature of development and the synchronization with other development content of the application to be developed.

[0047] Step 203: Determine the version identifier of the object to be developed.

[0048] In this embodiment, the version identifier of the object to be developed can be input into the development management node by the developer through a question-and-answer format. The version identifier is used to identify the version information of the object to be developed. For example, the first development version of the application to be developed can be denoted as V.1. As the application to be developed is used, the developer optimizes the functions and maintains the vulnerabilities of the V.1 version of the application to be developed. Further maintenance of the V.1 application to be developed can result in a second development version, which can be denoted as V.2. In this way, during the development process, the developer can determine the version that needs to be managed and maintained by determining the version identifier in order to optimize the functions.

[0049] In some application scenarios, the process of developers determining the version identifier for an object to be developed can involve the development management node displaying development information for various versions of the object, and the developers selecting from the displayed information and entering the version identifier. However, in other application scenarios, developers can also directly enter the version identifier for the object to be developed based on development requirements.

[0050] Step 204: Obtain the target node corresponding to the version identifier to be developed from the target main branch.

[0051] In this embodiment of the application, the target main branch includes nodes corresponding to multiple different version identifiers. Therefore, the target node corresponding to the version identifier to be developed can be determined from the target main branch. That is, the target node includes various information contents corresponding to the version identifier to be developed.

[0052] Step 205: Determine the target development requirements.

[0053] In this embodiment of the application, the target development requirements are provided by the requirements platform, i.e., a third-party requirements service platform. In this case, the corresponding implementation process can be that the development management node establishes a communication connection with the requirements platform through the communication interface, and then obtains the target development requirements for the object to be developed from the requirements platform.

[0054] Step 206: Based on the target node, create the first target development branch corresponding to the version to be developed, in accordance with the preset development branch naming convention, to achieve the target development requirements.

[0055] Specifically, based on the target node, according to the preset development branch naming convention, a first target development branch corresponding to the version to be developed is created to implement the target development requirements, so as to execute the target development operation through the first target development branch.

[0056] In this embodiment, starting from the target node, a first target development branch corresponding to the version identifier to be developed is created according to a preset development branch naming convention to achieve the target development requirements. For example, the updated target main branch can be as follows: Figure 3 As shown, there are nodes for three versions: V1, V2, and V3. Assuming the version to be developed is identified as V2, then the V2 node can be identified as the target node. Therefore, the first target development branch dev is created starting from the V2 node.

[0057] Step 207: If a target commit instruction is detected that indicates the submission of identification information for target development operations on the first target development branch, a first prompt message is generated to prompt for input of identification information, and the first prompt message is displayed.

[0058] In this embodiment, the target submission instruction is an instruction entered by the developer to the development management node after the developer has completed the target development operation on the first target development branch, i.e., after the developer has finished writing the code for the first target development branch. The identification information is information used to label the content of the target development operation, at least indicating the type of the user's target development operation. After receiving the target submission instruction entered by the user, the development management node can generate a first prompt message requiring the developer to enter the identification information of the type of their target development operation, and display the first prompt message to remind the developer to enter the identification information of their target development operation.

[0059] Step 208: If target identification information is detected and the target identification information matches the preset identification information, submit the target identification information and the target content corresponding to the target development operation to the temporary storage area.

[0060] In this embodiment, the preset identification information is pre-defined based on the types of development operations that developers can perform. Both the target identification information and the preset identification information typically include: a header, a body, and a footer. When entering the target identification information, developers can choose to enter only the header; the body and footer can be selectively filled in based on the developer's needs or habits. The header includes a type and a subject. The type typically includes at least one of the following: new feature type (feat); bug fix type (fix); document modification type (docs); code format modification type (style); adding or modifying test code type (test); code refactoring type (excluding adding features and fixing bugs, refactor); and non-code modification type (chore). The subject is used to identify simple modification descriptions.

[0061] Matching the target identifier information with the preset identifier information means that the content in the target identifier information is consistent with the content in the preset identifier information. In other words, the target identifier information must include a header, and the type in the target identifier information header must match the type in the preset identifier information. The target identifier information header must also include at least subject information. The target identifier information may or may not include body and / or footer information. Because the submitted information has been matched, if the submitted information already meets the requirements, there is no need to execute a question-and-answer process, effectively saving developers' time and simplifying the question-and-answer process during development.

[0062] The development management node includes the Workspace, the Staging Area (Index / Stage), the Repository, and the Remote Repository. The Workspace stores project code; the Index / Stage temporarily stores changes as a single file, containing a list of files to be committed; the Repository, also known as the repository area, securely stores data, including all development versions submitted by developers; and the Remote is a server used to host the code.

[0063] Step 209: If the merge request corresponding to the version to be developed already exists, send the target review instruction to the target management node corresponding to the target user identifier.

[0064] Among them, the target review instruction is used to instruct the review target content.

[0065] In this embodiment, the existence of a merge request corresponding to the version to be developed identifier indicates that the target test branch corresponding to the version to be developed identifier already exists. It should be noted that each version to be developed has only one test branch. The target review instruction is an instruction used to request a reviewer to review the target content corresponding to the version to be developed identifier. That is, after developers develop the target development requirements corresponding to the version to be developed identifier, the corresponding development content, i.e., the target content, needs to be submitted to the reviewer for review to ensure the reliability and accuracy of the developers' development content. The target management node is a development management node in the target management system.

[0066] The reviewer can be a developer's colleague or supervisor, or the person in charge of the object to be developed. The reviewer can be pre-agreed or set during initialization. When setting the reviewer, the reviewer can be identified using unique identifiers within the development content, such as the reviewer's name or employee ID.

[0067] Step 210: If an indication message sent by the target management node indicating that the target content has passed the check is detected, respond to the merge request and merge the first target development branch into the reference test branch corresponding to the merge request to obtain the target test branch.

[0068] In this embodiment, after receiving the target review instruction, the reviewer reviews the target content displayed on the target management node, then performs corresponding operations on the target management node and informs the developers of the review results for the target content. The reference test branch corresponding to the merge request is the unique test branch corresponding to the version identifier to be developed. After detecting the instruction information sent by the target management node, the first target development branch is merged into the reference test branch corresponding to the version identifier to be developed, thereby obtaining the target test branch.

[0069] Step 211: Based on the target test branch, perform test operations targeting the target content.

[0070] In this embodiment, since the target test branch includes a first target development branch, testing the target test branch enables testing of the target content. This ensures that the target content is reviewed and approved by an auditor other than the developers before testing, preventing arbitrary submissions and increasing the credibility of the target content. Furthermore, each version to be tested has only one test branch, ensuring that all development branches are merged into the test branch of the version to be tested, achieving unified release and effectively avoiding test conflicts.

[0071] Based on the foregoing embodiments, in other embodiments of this application, after the development management node executes step 208, it may also choose to execute steps 212 to 215:

[0072] Step 212: If no merge request is found, but a reference test branch corresponding to the version to be developed is found, generate a merge request based on the reference test branch.

[0073] In this embodiment, the existence of a merge request necessarily implies the existence of a reference test branch, but the existence of a reference test branch does not necessarily imply the existence of a merge request. Therefore, when the development management node does not find a merge request (MR) corresponding to the version identifier to be developed, it continues to query whether a reference test branch exists. If a reference test branch is found, a merge request is generated based on the reference test branch.

[0074] Step 213: Send the target review instruction to the target management node.

[0075] Step 214: If an instruction message sent by the target management node is detected, respond to the merge request and merge the first target development branch into the reference test branch to obtain the target test branch.

[0076] Step 215: Based on the target test branch, execute test operations targeting the target content.

[0077] In this embodiment, the system first checks if there is a merge request. If no merge request is found, it then checks if there is a reference test branch corresponding to the version to be developed. This effectively avoids wasting resources by creating a reference test branch and also avoids the situation where the functions already developed on the reference test branch are covered.

[0078] Based on the foregoing embodiments, in other embodiments of this application, after the development management node executes step 208, it may also choose to execute steps 216 to 220:

[0079] Step 216: If no merge request is found, and no reference test branch corresponding to the version ID to be developed is found, create a reference test branch corresponding to the version ID to be developed.

[0080] Step 217: Generate a merge request based on the reference test branch.

[0081] Step 218: Send the target audit instruction to the target management node.

[0082] Step 219: If an indication message is detected, respond to the merge request and merge the first target development branch into the reference test branch to obtain the target test branch.

[0083] Step 220: Based on the target test branch, execute test operations targeting the target content.

[0084] In this embodiment of the application, when neither a merge request nor a reference test branch corresponding to the version identifier to be developed is found, a reference test branch corresponding to the version identifier to be developed needs to be created for subsequent processing, which effectively ensures the uniqueness of the test branch.

[0085] Based on the foregoing embodiments, in other embodiments of this application, after the development management node executes step 211, it is also used to execute steps 221 to 223:

[0086] Step 221: During the execution of test operations targeting the target content, if modifications to the target content are required, receive the modification operation based on the first target development branch.

[0087] In this embodiment of the application, the situations in which the target content needs to be modified during the testing process include situations where test defects occur during testing, resulting in the need for modification, and situations where developers discover during testing that the implementation process needs to be improved. In these cases, when developers modify the target content, they perform the modification operation on the first target development branch.

[0088] Step 222: Update the target development operation to a modification operation.

[0089] Step 223: Repeat the step "If a target submission instruction is detected that indicates the submission of identification information for target development operations on the first target development branch, generate a first prompt message to prompt for input of identification information and display the first prompt message" until the execution reaches "Execute test operations for target content".

[0090] In this embodiment of the application, after the modification operation is updated to the target development operation, the operation content of steps 207 to 220 is repeated until the testing process is completed.

[0091] It should be noted that steps 221 to 223 can also be executed after the development management node executes step 215 or step 220. That is, during the test process, before the release operation is performed, the target content can be modified accordingly.

[0092] This approach, by making modifications on the primary development branch, effectively avoids the possibility of omissions during deployment.

[0093] Based on the foregoing embodiments, in other embodiments of this application, after the development management node executes step 211, it is also used to execute steps 224 to 227:

[0094] Step 224: If the reference development branches corresponding to at least two reference development requirements included in the version to be developed have passed the test, determine the second target development branch corresponding to the target release requirement from the reference development branches corresponding to the at least two reference development requirements.

[0095] Among them, the target release requirement belongs to at least two reference development requirements.

[0096] In this application embodiment, during a development process, if at least two reference development requirements need to be developed simultaneously for the version identifier to be developed, and at least two reference development requirements have passed testing, and when the final target release requirement to be released for the version identifier to be developed is a part of the requirements of the at least two reference development requirements, then the second target development branch corresponding to the target release requirement is determined.

[0097] Step 225: Delete the current test branch corresponding to the version to be developed.

[0098] In this embodiment of the application, since the current test branch has been merged with at least two reference development branches corresponding to reference development requirements, it is necessary to delete the current test branch.

[0099] Step 226: Create a reference test branch corresponding to the version identifier to be developed.

[0100] In this embodiment of the application, a test branch is set based on the identifier of the version to be developed, which is not merged with the reference development branch corresponding to at least two reference development requirements.

[0101] Step 227: Merge the second target development branch into the reference test branch to obtain the target test branch.

[0102] In this embodiment, the second target development branch corresponding to the target release requirement is merged into the reference test branch to obtain the target test branch. Thus, when a version of an application has multiple requirements, since the requirements are differentiated according to development branches in this embodiment, the subsequent release process can be achieved simply by merging the second target development branch corresponding to the target release requirement into the newly created test branch. This significantly simplifies the process for releasing only some requirements and improves the implementation process for some development requirements that are not released during this development process.

[0103] It should be noted that steps 224 to 227 can also be executed after the development management node executes steps 215 or 220, or after the development management node executes steps 221 to 223. The specific execution can be implemented according to the actual situation, and no specific restrictions are made here.

[0104] Based on the foregoing embodiments, in other embodiments of this application, after the development management node executes step 211, the development management node may choose to execute steps 228 to 232:

[0105] Step 228: If a production packaging instruction corresponding to the version identifier to be developed is detected, obtain the second remote main branch from the GIT remote platform.

[0106] The second remote main branch is related to the first remote main branch.

[0107] In this embodiment, the production packaging command can be entered by a developer into the development management node. Correspondingly, the production packaging command can be entered by a specific person into the development management node. The production packaging command can be "hopma deploy". The developer enters the production packaging command into the development management node, and the development management node obtains the latest version of the second remote main branch from the Git remote platform.

[0108] Step 229: Synchronize the first release branch using the second remote master branch.

[0109] Step 230: Merge the target test branch into the first release branch to obtain the second release branch.

[0110] Step 231: Push the second release branch to the remote repository.

[0111] Step 232: If a target release command is detected, merge the second release branch into the second remote master branch.

[0112] In this embodiment of the application, during the release process, the latest version of the second remote master branch is obtained from the Git remote platform to synchronize the latest released functions, thus avoiding the problem of missing the functions of the previous version due to forgetting to synchronize the branch.

[0113] It should be noted that steps 228 to 232 can also be executed after the development management node executes steps 215 or 220, or after the development management node executes steps 221 to 223, or after the development management node executes steps 224 to 227. The specific execution can be implemented according to the actual situation, and no specific restrictions are made here.

[0114] Based on the foregoing embodiments, in other embodiments of this application, after the development management node executes step 232, it is also used to execute steps 233 to 235:

[0115] Step 233: If a target log generation command is detected, generate modification log information for the target content.

[0116] In this embodiment, the target log generation command can be "hopma changelog". When a developer inputs the target log generation command into the development management node, the development management node responds to the command, generates modification log information for the target content, and stores the modification log information for subsequent analysis. The modification log information includes commits of type feat and fix.

[0117] Step 234: Create a target version identifier for the version to be developed.

[0118] In this embodiment of the application, the target version identifier is an identifier used to identify the content of the release version of the version to be developed.

[0119] Step 235: Push the second remote master branch and target version identifier to the remote repository.

[0120] In this way, corresponding log information is generated for the modified content during release, so as to facilitate subsequent analysis and improve the reliability of development.

[0121] Based on the foregoing embodiments, in other embodiments of this application, after the development management node executes step 235, it is also used to execute steps 236 to 237:

[0122] Step 236: If a target cleanup command is detected, display the identifier information of the test branch to be cleaned and the identifier information of the development branch to be cleaned.

[0123] In this embodiment of the application, the target cleanup command can be denoted as "hopma clear".

[0124] Step 237: If target cleanup test branch identifier information and target cleanup development branch identifier information are detected, delete the test branch corresponding to the target cleanup test branch identifier information and the development branch corresponding to the target cleanup development branch identifier information.

[0125] In this embodiment, unnecessary test branches and development branches are deleted, which effectively saves storage resources of the development management node and improves the operating efficiency of the development management node.

[0126] Based on the foregoing embodiments, in other embodiments of this application, before the switch management node executes step 201, it is further configured to execute steps 238 to 240:

[0127] Step 238: If a target initialization instruction is detected, obtain the GIT authorization code.

[0128] In this embodiment, the target initialization command can be denoted as "hopma init". The corresponding Git license code can be obtained by the developer from the Git remote platform and then entered into the development management node. Alternatively, it can be obtained directly by the development management node from the Git remote platform.

[0129] Step 239: If associated with the demand platform, obtain the platform authorization code corresponding to the demand platform.

[0130] In this embodiment of the application, a communication connection is established between the development management node and the demand platform. The platform authorization code can be obtained by the developer from the demand platform and then input into the switch management node by the developer, or it can be obtained by the development management node from the demand platform.

[0131] Step 240: If both the GIT license key and the platform license key are valid, set the GIT license key and the platform license key as user configuration parameters.

[0132] Among them, the GIT authorization code is used to establish a communication connection with the GIT remote platform, and the platform authorization code is used to establish a communication connection with the demand platform.

[0133] In this embodiment, after the switch management node obtains the GIT authorization code, it sends the GIT authorization code to the GIT remote platform so that the GIT remote platform can verify the validity of the GIT authorization code. If the switch management node receives information from the GIT remote platform indicating that the GIT authorization code is valid, the switch management node determines that the GIT authorization code is valid. The development management node then sends the platform authorization code to the corresponding demand platform so that the demand platform can verify the validity of the platform authorization code. If the development management node receives information from the demand platform indicating that the platform authorization code is valid, the development management node determines that the platform authorization code is valid.

[0134] In this way, the initialization operation enables the development management node to be associated with the requirements platform and the Git remote platform, thus enriching the functionality of the development management node.

[0135] Based on the foregoing embodiments, in other embodiments of this application, the target test branch corresponding to the version to be developed identifier includes only one test branch.

[0136] Based on the foregoing embodiments, in other embodiments of this application, the development management node includes the hopma tool and a local Git tool. After the developer inputs the hopma init command, the hopma tool collects the platform authorization code (dpms token) of the demand platform and the Git authorization code (git token) of the remote Git platform through a question-and-answer interaction. The specific implementation sequence diagrams of the corresponding steps in steps 238-240 and 201-206 can be referred to... Figure 4 As shown, the specific implementation process includes the following steps:

[0137] Step 31: The hopma tool sends the dpms token to the requesting platform to verify its validity; the hopma tool also sends the git token to the Git remote platform to verify its validity.

[0138] Among them, the hopma tool, the demand platform, and the Git remote platform use corresponding application programming interfaces (APIs) to verify the authorization code.

[0139] Step 32: The hopma tool receives the first verification result sent by the requesting platform; the hopma tool receives the second verification result sent by the GIT remote platform.

[0140] Step 33: If the first verification result shows that the dpms token is valid and the second verification result shows that the git token is valid, the hopma tool will write the dpms token and git token into the user configuration of the local Git tool.

[0141] The dpms token is used to enable the hopma tool to call the open interface of the demand platform dpms, and the git token is used to enable the hopma tool to call the open interface of the Git remote platform.

[0142] Step 34: The hopma tool receives hopma dev, executes hopma dev, calls the local GIT API to switch to the master branch, and uses the local GIT tool to obtain the latest master branch from the remote GIT platform via the git pull command.

[0143] Step 35: Use the latest master branch obtained from the local Git tool to synchronize and modify the local master branch.

[0144] Step 36: The hopma tool obtains the requirements and version interfaces by calling the requirements platform API, and selects the target development requirements and the version to be developed through a question-and-answer interaction.

[0145] Step 37: The hopma tool calls the GIT API to create the dev branch corresponding to the version to be developed, and writes the target development requirements into the local GIT project configuration.

[0146] Based on the foregoing embodiments, in other embodiments of this application, the specific implementation timing diagrams of some of the steps in steps 207 to 223 can be referred to. Figure 5 As shown, the specific implementation process includes the following steps:

[0147] Step 41: The hopma tool detects the git commit command entered by the developer, executes the git commit command, calls the hopma commit command through git hook prepare-commit-msg, and obtains the commit information through a question-and-answer interactive method using a local Git tool.

[0148] The information submitted is the aforementioned target identification information.

[0149] In some application scenarios, developers can directly input the hopma commit command to have the hopma tool execute the hopma commit command, so as to fill in the submission information through a question-and-answer interactive method.

[0150] Step 42: The hopma tool then calls the hopma validate command via git hook commit-msg to perform commit message specification validation using a local Git tool.

[0151] Step 43: Use the hopma tool to check if there is an MR in the Git remote platform.

[0152] The hopma tool checks for MapReduce (MR) on the Git remote platform by executing the hopma test command and calling the mergeequest query of the Git platform's API.

[0153] Step 44: If the hopma tool does not find the MapReduce, the hopma tool will create a test branch.

[0154] Step 45: Push the test branch to the remote Git platform via local Git.

[0155] Step 46: If the target development requirements are missing, the hopma tool will also call the API of the platform in question to retrieve the target development requirements and the version to be developed.

[0156] Step 47: The hopma tool queries the list of reviewers from the Git remote platform and identifies the target reviewer.

[0157] Step 48: Use the hopma tool to create a merge request open interface to realize the creation of MR.

[0158] Among them, the hopma tool uses the target development needs and the target reviewers as the submission content for creating a MapReduce.

[0159] Based on the foregoing embodiments, in other embodiments of this application, the specific implementation timing diagrams of steps 228-237 can be referred to. Figure 6 As shown, the specific implementation process includes the following steps:

[0160] Step 51: The hopma tool detects the hopma deploy command entered by the developer, executes the hopma deploy command, and switches the branch to the release branch.

[0161] Step 52: The local Git tool retrieves the latest master branch from the Git remote platform and synchronizes the release branch.

[0162] Step 53: The local Git tool merges the test branch into the release branch via the Git API.

[0163] Step 54: Push the merged release branch to the remote Git platform using the local Git tool.

[0164] Step 55: After the deployment is complete, use the hopma tool to execute hopma publish and switch the branch to the master branch.

[0165] Step 56: The local Git tool retrieves the latest version of the master branch from the remote Git platform to synchronize the release branch.

[0166] Step 57: The hopma tool executes hopma changelog to generate the modification and commit log for this requirement.

[0167] Step 58: Use the hopma tool to create the current version tag.

[0168] Step 59: Use the hopma tool to push the merged release branch's master branch and tag to the Git remote platform.

[0169] Step 510: The hopma tool executes the hopma clear command, selects the test and dev branches to be deleted, and calls the GIT API to delete the selected test and dev branches.

[0170] The aforementioned instructions include at least the following specification instructions:

[0171] `hopma init`: Initialization configuration command, used for initializing git hooks, collecting and verifying platform tokens and git remote repository tokens.

[0172] hopma dev: Start development command, used to create dev branches according to required versions and custom versions.

[0173] hopma test: Submits a test command to create a MapReduce request from the dev branch to the test branch and specify the target reviewer.

[0174] `hopma deploy`: This production packaging command is used to merge the test branch of the version to be developed into the release branch and synchronize the Master branch.

[0175] The `hopma publish` command is used to create version tags and changelog archives after the master and release branches are merged.

[0176] hopma changelog: A log generation command used to generate a changelog of modified log entries.

[0177] `hopma clear`: This command is used to clear the `dev` and `test` branches of the selected version.

[0178] hopma commit: The commit command that implements the husky prepare-commit-msg hook callback, used to modify the commit message before committing changes.

[0179] `hopma validate`: Implements the `husky commit-msg` hook callback, used to validate commit messages when submitting changes. It is executed automatically when `hopma commit` is executed.

[0180] hopma push: Implements Husky pre-push hooks callbacks for pushing branches and prompting for test submission.

[0181] The specifications for the `dev` branch are as follows: Its purpose is for feature development and bug fixing; the naming convention is `dev_${name}_v${version}`; its scope is open to all developers for push and merge operations. The specifications for the `test` branch are: its purpose is for code review and testing; the naming convention is `test_v{version}`; its scope is typically open to administrators for push and merge operations. The specifications for the `release` branch are: its purpose is for pre-release and official release; the naming convention is `release`; its scope is typically open to administrators for push and merge operations. The specifications for the `master` branch are: its purpose is for synchronized archiving; the naming convention is `master`; its scope is typically open to administrators for push and merge operations.

[0182] Correspondingly, development management methods can be divided into development phase, testing phase, and release / archiving phase. The complete process is as follows: Figure 7 As shown:

[0183] Step 61: Start. Step 62: Developer enters `hopma init`. Step 63: Developer enters `git token`. Step 64: The development management node checks if the platform is associated. If associated, proceed to step 65; otherwise, proceed to step 66. Step 65: Developer sets the platform token. Step 66: The development management node performs initialization. Step 67: Developer enters `hopma dev`. Step 68: The development management node synchronizes the master branch. Step 69: The development management node checks if the platform is supported. If supported, proceed to step 610; otherwise, proceed to step 611. Step 610: The development management node retrieves the platform version number. Step 611: Developer enters a custom version number. Step 612: The development management node creates and switches to the `dev` branch. Step 613: Developer enters `hopma commit`. Step 614: Developer enters the commit message. Step 615: The development management node automatically runs `hopma validate`. Step 616: The development management node checks if the commit message conforms to the specifications. If not, proceed to step 613; otherwise, proceed to step 617. Step 617: The developer enters `hopma test`. Step 618: The development management node checks if the commit message was successfully submitted. If the commit fails, proceed to step 613; otherwise, proceed to step 619. Step 619: The development management node checks if a MapReduce (MR) has been created. If not, proceed to step 620; if an MR has been created, proceed to step 623. Step 620: The development management node checks if a `test` branch already exists. If a `test` branch exists, proceed to step 621; otherwise, proceed to step 622. Step 621: The development management node creates the MR. Step 622: The development management node creates the `test` branch. Step 623: The development management node generates a prompt message for review. Step 624: The development management node checks if the target content has been reviewed. If reviewed, proceed to step 625; otherwise, proceed to step 623. Step 625: The development management node checks if the test branch has passed testing. If it has passed testing, proceed to step 626; otherwise, proceed to step 613. Step 626: The developer enters `hopma deploy`. Step 627: The development management node synchronizes the master branch. Step 628: The development management node merges the master branch into the release branch. Step 629: The development management node pushes the merged release branch. Step 630: The developer enters "hopma publish". Step 631: The development management node merges the merged release branch into the master branch. Step 632: The development management node generates a changelog. Step 633: The development management node creates a tag.Step 634: The development management node determines whether to clean up the branch. If so, proceed to step 635; otherwise, proceed to step 636. Step 635: Clean up the branch. Step 636: End.

[0184] In this way, there are specific specifications for development, testing, and release. The `hopma dev` command can create development branches according to these specifications, eliminating the need for manual branch creation. Furthermore, the created development branches can be associated with the required platform and version. The functions of development branches, testing branches, and the main branch are clearly defined, facilitating branch management. The `hopmatest` command requires review before submission for testing. It can create MapReduce (MR) requests and specify the reviewer to conduct testing. Only after the review is approved and the MR request is approved will it be submitted for testing. Finally, `hopam deploy` and `hopma publish` archive each modification, ensuring synchronization between branches, resolving various issues arising in multi-person collaboration, and improving the efficiency of the development process.

[0185] It should be noted that the descriptions of the same steps and contents as in other embodiments in this embodiment can be found in the descriptions in other embodiments, and will not be repeated here.

[0186] In this embodiment, if a target development instruction is detected, the first remote main branch of the object to be developed is obtained from the distributed version control system GIT remote platform. Based on the first remote main branch, the local main branch of the object to be developed is updated. After obtaining the target main branch, the version identifier of the object to be developed is determined, and the target node corresponding to the version identifier is obtained from the target main branch. After determining the target development requirements, based on the target node, a first target development branch corresponding to the version identifier of the object to be developed, which implements the target development requirements, is created according to the preset development branch naming convention. In this way, when a target development instruction is detected, the local main branch of the object to be developed is updated using the first remote main branch to obtain the target main branch. The first target development branch that implements the target development requirements is then created using the target main branch. This solves the problem that developers can currently use any branch to create requirement development, leading to unclear uses for multiple branches. It realizes the creation of requirement development branches through the main branch, effectively avoiding the situation where modifications are easily missed when creating requirement development branches through other branches, and improving the success rate of workflow development.

[0187] Based on the foregoing embodiments, embodiments of this application provide a development management platform, referring to... Figure 8 As shown, the development management platform 7 may include: storage space 71 and at least one development management node 72; wherein:

[0188] The development management node 72 is used to execute the development management program stored in storage space 71 to achieve the following steps:

[0189] If a target development instruction is detected, the first remote master branch of the object to be developed is obtained from the distributed version control system GIT remote platform.

[0190] Based on the first remote master branch, update the local master branch of the object to be developed to obtain the target master branch;

[0191] Determine the version identifier of the object to be developed;

[0192] From the target main branch, obtain the target node corresponding to the version identifier to be developed;

[0193] Define the target development requirements;

[0194] Based on the target node, according to the preset development branch naming convention, a first target development branch corresponding to the version to be developed is created to implement the target development requirements, so as to execute the target development operation through the first target development branch.

[0195] In other embodiments of this application, the development management node is also used to perform the following steps:

[0196] If a target commit instruction is detected that indicates the submission of identification information for target development operations on the first target development branch, a first prompt message is generated to prompt for input of the identification information, and the first prompt message is displayed.

[0197] If target identification information is detected and matches the preset identification information, submit the target identification information and the target content corresponding to the target development operation to the temporary storage area;

[0198] If the merge request corresponding to the version to be developed already exists, send the target review instruction to the target management node corresponding to the target user identifier; the target review instruction is used to indicate the target content to be reviewed.

[0199] If an indication message sent by the target management node indicating that the target content has passed the check is detected, respond to the merge request and merge the first target development branch into the reference test branch corresponding to the merge request to obtain the target test branch;

[0200] Based on the target test branch, execute test operations targeting the target content.

[0201] In other embodiments of this application, the development management node is also used to perform the following steps:

[0202] If no merge request is found, but a reference test branch corresponding to the version to be developed is found, a merge request is generated based on the reference test branch.

[0203] Send the target review instruction to the target management node;

[0204] If an instruction message sent by the target management node is detected, respond to the merge request and merge the first target development branch into the reference test branch to obtain the target test branch;

[0205] Based on the target test branch, execute test operations targeting the target content.

[0206] In other embodiments of this application, the development management node is also used to perform the following steps:

[0207] If no merge request is found, and no reference test branch corresponding to the version ID to be developed is found, create a reference test branch corresponding to the version ID to be developed.

[0208] Generate a merge request based on the reference test branch;

[0209] Send the target review instruction to the target management node;

[0210] If an indication message is detected, respond to the merge request and merge the first target development branch into the reference test branch to obtain the target test branch;

[0211] Based on the target test branch, execute test operations targeting the target content.

[0212] In other embodiments of this application, the development management node is also used to perform the following steps:

[0213] During the execution of test operations targeting the target content, if modifications to the target content are required, the modification operation is received based on the first target development branch;

[0214] The target development operation has been changed to a modification operation;

[0215] Repeat the step "If a target commit instruction is detected that indicates the submission of identification information for target development operations on the first target development branch, generate a first prompt message to prompt for input of identification information, and display the first prompt message" until the execution reaches "Execute test operations for target content".

[0216] In other embodiments of this application, the development management node is also used to perform the following steps:

[0217] If the reference development branches corresponding to at least two reference development requirements included in the version to be developed have passed testing, determine the second target development branch corresponding to the target release requirement from the reference development branches corresponding to the at least two reference development requirements; wherein, the target release requirement belongs to at least two reference development requirements;

[0218] Delete the current test branch corresponding to the pending development version identifier;

[0219] Create a reference test branch corresponding to the version identifier to be developed;

[0220] Merge the second target development branch into the reference test branch to obtain the target test branch.

[0221] In other embodiments of this application, the development management node is also used to perform the following steps:

[0222] If a production packaging instruction corresponding to the identifier of the version to be developed is detected, the second remote main branch is obtained from the Git remote platform; wherein the second remote main branch is related to the first remote main branch;

[0223] The first release branch is synchronized using the second remote master branch;

[0224] Merge the target test branch into the first release branch to obtain the second release branch;

[0225] Push the second release branch to the remote repository;

[0226] If a target release command is detected, merge the second release branch into the second remote master branch.

[0227] In other embodiments of this application, if the development management node detects a target release instruction and merges the second release branch into the second remote master branch, it is further configured to perform the following steps:

[0228] If a target log generation instruction is detected, a target version identifier for the version to be developed is created;

[0229] Push the second remote master branch and target version identifier to the remote repository.

[0230] In other embodiments of this application, after the development management node is used to push the second remote main branch and target version identifier to the remote repository, it is also used to perform the following steps:

[0231] If a target cleanup command is detected, the identifiers of the test branch to be cleaned and the development branch to be cleaned will be displayed.

[0232] If target cleanup test branch identifier information and target cleanup development branch identifier information are detected, delete the test branch corresponding to the target cleanup test branch identifier information and the development branch corresponding to the target cleanup development branch identifier information.

[0233] In other embodiments of this application, before the development management node executes the step of obtaining the first remote main branch of the object to be developed from the distributed version control system GIT remote platform if a target development instruction is detected, it is also used to execute:

[0234] If a target initialization command is detected, obtain the Git license code;

[0235] If associated with a demand platform, obtain the platform authorization code corresponding to that platform;

[0236] If both the Git license code and the platform license code are valid, set them as user configuration parameters; the Git license code is used to establish a communication connection with the Git remote platform, and the platform license code is used to establish a communication connection with the required platform.

[0237] In other embodiments of this application, the target test branch corresponding to the version to be developed identifier includes only one test branch.

[0238] It should be noted that the explanation of the steps in the embodiments of this application where one or more programs can be processed by one or more processors can be found in the following references. Figures 1-2 The implementation process of the methods provided in other embodiments will not be described in detail here.

[0239] In this embodiment, if a target development instruction is detected, the first remote main branch of the object to be developed is obtained from the distributed version control system GIT remote platform. Based on the first remote main branch, the local main branch of the object to be developed is updated. After obtaining the target main branch, the version identifier of the object to be developed is determined, and the target node corresponding to the version identifier is obtained from the target main branch. After determining the target development requirements, based on the target node, a first target development branch corresponding to the version identifier of the object to be developed, which implements the target development requirements, is created according to the preset development branch naming convention. In this way, when a target development instruction is detected, the local main branch of the object to be developed is updated using the first remote main branch to obtain the target main branch. The first target development branch that implements the target development requirements is then created using the target main branch. This solves the problem that developers can currently use any branch to create requirement development, leading to unclear uses for multiple branches. It realizes the creation of requirement development branches through the main branch, effectively avoiding the situation where modifications are easily missed when creating requirement development branches through other branches, and improving the success rate of workflow development.

[0240] Based on the foregoing embodiments, embodiments of this application provide a computer-readable storage medium, simply referred to as a storage medium, which stores one or more programs that can be executed by one or more processors to achieve, as follows: Figures 1-2 The implementation process of the development and management methods provided in other embodiments will not be described in detail here.

[0241] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0242] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0243] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0244] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0245] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A development management method, characterized in that, The method includes: If a target development instruction is detected, the first remote master branch of the object to be developed is obtained from the distributed version control system GIT remote platform. Based on the first remote main branch, update the local main branch of the object to be developed to obtain the target main branch; Determine the development version identifier of the object to be developed; Obtain the target node corresponding to the version identifier to be developed from the target main branch; Define the target development requirements; Based on the target node, according to the preset development branch naming convention, a first target development branch corresponding to the version identifier to be developed is created to implement the target development requirements, so as to execute the target development operation through the first target development branch; If a target commit instruction is detected that indicates the submission of identification information for target development operations on the first target development branch, a first prompt message is generated to prompt for input of the identification information, and the first prompt message is displayed. If target identification information is detected and the target identification information matches preset identification information, the target identification information and the target content corresponding to the target development operation are submitted to the temporary storage area. If the merge request corresponding to the version to be developed identifier already exists, a target review instruction is sent to the target management node corresponding to the target user identifier; wherein, the target review instruction is used to instruct the review of the target content; If an indication message sent by the target management node indicating that the target content has passed the check is detected, the merge request is responded to, and the first target development branch is merged into the reference test branch corresponding to the merge request to obtain the target test branch; wherein, the target test branch corresponding to the version to be developed identifier includes only one test branch; Based on the target test branch, perform test operations targeting the target content.

2. The method according to claim 1, characterized in that, The method further includes: If the merge request is not found, but a reference test branch corresponding to the version to be developed is found, the merge request is generated based on the reference test branch; Send the target review instruction to the target management node; If the indication information sent by the target management node is detected, respond to the merge request and merge the first target development branch into the reference test branch to obtain the target test branch; Based on the target test branch, perform test operations targeting the target content.

3. The method according to claim 1, characterized in that, The method further includes: If the merge request is not found, and the reference test branch corresponding to the version identifier to be developed is not found, create the reference test branch corresponding to the version identifier to be developed; The merge request is generated based on the reference test branch; Send the target review instruction to the target management node; If the indication information is detected, respond to the merge request and merge the first target development branch into the reference test branch to obtain the target test branch; Based on the target test branch, perform test operations targeting the target content.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: During the execution of test operations targeting the target content, if it is necessary to modify the target content, the modification operation is received based on the first target development branch; The target development operation is updated to the modification operation; Repeat the step "If a target submission instruction is detected that indicates the submission of identification information for target development operations on the first target development branch, generate a first prompt message to prompt for input of identification information, and display the first prompt message" until the execution reaches "Execute test operations for the target content".

5. The method according to claim 1, characterized in that, The method further includes: If the reference development branches corresponding to at least two reference development requirements included in the version to be developed have passed testing, a second target development branch corresponding to the target release requirement is determined from the reference development branches corresponding to the at least two reference development requirements; wherein, the target release requirement belongs to at least two reference development requirements; Delete the current test branch corresponding to the version to be developed; Create a reference test branch corresponding to the identifier of the version to be developed; The second target development branch is merged into the reference test branch to obtain the target test branch.

6. The method according to any one of claims 1 to 3 and 5, characterized in that, The method further includes: If a production packaging instruction corresponding to the identifier of the version to be developed is detected, a second remote main branch is obtained from the Git remote platform; wherein the second remote main branch is associated with the first remote main branch; The first release branch is synchronized using the second remote master branch; Merge the target test branch into the first release branch to obtain the second release branch; Push the second release branch to the remote repository; If a target release instruction is detected, merge the second release branch into the second remote master branch.

7. The method according to claim 6, characterized in that, If a target release instruction is detected, after merging the second release branch into the second remote master branch, the method further includes: If a target log generation instruction is detected, modification log information for the target content is generated; Create a target version identifier for the version to be developed; Push the second remote main branch and the target version identifier to the remote repository.

8. The method according to claim 7, characterized in that, After pushing the second remote main branch and the target version identifier to the remote repository, the method further includes: If a target cleanup command is detected, the identifiers of the test branch to be cleaned and the development branch to be cleaned will be displayed. If target cleanup test branch identifier information and target cleanup development branch identifier information are detected, delete the test branch corresponding to the target cleanup test branch identifier information and the development branch corresponding to the target cleanup development branch identifier information.

9. The method according to claim 1, characterized in that, Before obtaining the first remote master branch of the object to be developed from the distributed version control system GIT remote platform if a target development instruction is detected, the method further includes: If a target initialization command is detected, obtain the Git license code; If associated with a demand platform, obtain the platform authorization code corresponding to that demand platform; If both the GIT authorization code and the platform authorization code are valid, set the GIT authorization code and the platform authorization code as user configuration parameters; wherein, the GIT authorization code is used to establish a communication connection with the GIT remote platform, and the platform authorization code is used to establish a communication connection with the demand platform.

10. A development management platform, characterized in that, The development management platform includes: storage space and at least one development management node; wherein: The development management node is used to execute the development management program stored in the storage space to implement the steps of the development management method as described in any one of claims 1 to 9.

11. A storage medium, characterized in that, The storage medium stores a development management program, which, when executed by a processor, implements the steps of the development management method as described in any one of claims 1 to 9.

Images