Project collaborative development method and equipment based on API (Application Program Interface)

Abstract

The invention provides a project collaborative development method and equipment based on an API, and relates to the field of API collaborative development, and the method comprises the steps: constructing an API management working platform which comprises a test end, a design end, a development end and an operation and maintenance end; demand data is obtained, demand collection is conducted on the demand data through the test end and the design end, and an initial API document is obtained; performing document confirmation on the initial API document through the test end, the development end and the operation and maintenance end to obtain a test API document; and S2, performing function test on the test API document through the test end, the development end and the operation and maintenance end, if the test passes, deploying the test API document as a final API document to a formal service, and otherwise, returning to the step S2. According to the method, the test end fully participates in the design process of the final API document, the design end and the development end can completely break the dependency relationship between the front-end development and the rear-end development, and the rear-end development difficulty is greatly reduced due to standardization of the rear-end development; the operation and maintenance end can reduce the maintenance cost and improve the maintenance efficiency.

Description

Technical Field

[0001] The present invention relates to the field of API collaborative development, and particularly to a method and device for project collaborative development based on APIs. Background Art

[0002] API collaborative development generally includes front-end and back-end development stages, API definition stage, and testing stage. However, there are many defects in the existing API collaborative development process, which are specifically as follows:

[0003] Currently, the biggest contradiction in front-end and back-end development is that the back-end does not have complete documentation explanations for APIs, and testing does not have testing and verification for APIs, resulting in very smooth API docking for the front-end. Problems such as missing APIs, missing fields, unclear dependency relationships between APIs, and APIs not working properly occur, resulting in the API docking work being intermittent most of the time, seriously affecting development efficiency.

[0004] Currently, API definitions all rely on back-end developers, and back-end developers are relatively arbitrary. Situations such as not following the RESTful style and inaccurate API descriptions occur from time to time, resulting in strange-shaped API definitions, seriously affecting project handover, transfer, and later maintenance work.

[0005] Currently, testing only has an understanding of the project at the level of requirements and UI functions, and knows very little about the development details of the project. The problems caused thereby are that after receiving a fault report, testing cannot accurately locate and analyze the fault, and it is easy to shift the blame. Moreover, due to the lack of understanding of the development details, it is impossible to effectively evaluate the development workload, and it cannot perform the functions of work scheduling, dispatching, overall planning, and supervision, and can only let the development progress be delayed. At the same time, due to the unclear specific process design of the development program by testing, it is also a common phenomenon that the communication efficiency is not high. Summary of the Invention

[0006] In view of this, an object of the present invention is to provide a method and device for project collaborative development based on APIs, which are used to solve the defects existing in the existing API collaborative development process.

[0007] The present invention provides a method for project collaborative development based on APIs, including the steps of:

[0008] S1: Construct an API management work platform, where the API management work platform includes: a testing end, a design end, a development end, and an operation and maintenance end;

[0009] S2: Obtain requirement data, and collect the requirement data through the testing end and the design end to obtain an initial API document;

[0010] S3: Conduct document confirmation on the initial API document through the test end, development end, and operation and maintenance end to obtain the test API document;

[0011] S4: Conduct functional testing on the test API document through the test end, development end, and operation and maintenance end. If the test passes, deploy the test API document to the formal server as the final API document; otherwise, return to step S2.

[0012] Preferably:

[0013] Use YApi as the API management work platform.

[0014] Preferably, step S2 is specifically as follows:

[0015] S21: Input the requirement data into the test end to obtain a prototype diagram;

[0016] S22: Input the requirement data into the design end to obtain design data;

[0017] S23: Generate the initial API document based on the prototype diagram and design data.

[0018] Preferably, step S3 is specifically as follows:

[0019] Input the initial API document into the development end for content confirmation. If the content is confirmed to be correct, use the initial API document as the test API document; otherwise, return to step S2.

[0020] Preferably, step S4 is specifically as follows:

[0021] S41: Generate the backend Mock, backend code, and Jenkins workflow for the test API document;

[0022] S42: Input the backend Mock into the test end to generate interface test cases;

[0023] S43: Input the Jenkins workflow and backend Mock into the operation and maintenance end to generate a test environment;

[0024] S44: Input the backend code into the development end to generate background code;

[0025] S45: Deploy the background code to the test environment and conduct interface testing according to the interface test cases. If the interface testing fails, return to step S44; otherwise, proceed to step S46;

[0026] S46: Conduct functional testing on the background code. If the functional testing fails, proceed to step S47; otherwise, deploy the background code to the formal server as the final API document;

[0027] S47: Generate the front-end code for the test API document;

[0028] S48: Perform functional testing on the front-end code. If the functional testing fails, return to step S47; otherwise, deploy the front-end code as the final API document to the production server.

[0029] Preferably:

[0030] Generate the back-end Mock, back-end code, and Jenkins workflow of the test API document through the code generation component.

[0031] A storage medium stores instructions and data for implementing the API-based project collaborative development method described above.

[0032] An API-based project collaborative development device includes: a processor and a storage medium; the processor loads and executes the instructions and data in the storage medium for implementing the API-based project collaborative development method described above.

[0033] The present invention has the following beneficial effects:

[0034] After the initial API document is verified and tested by the test side, design side, development side, and operation and maintenance side, the final API document is obtained; enabling the test side to fully participate in the design process of the final API document, the design side and the development side can completely disconnect the dependency between front-end and back-end development, and standardizing back-end development will greatly reduce the difficulty of back-end development; the operation and maintenance side can reduce maintenance costs and improve maintenance efficiency. Brief Description of the Drawings

[0035] Figure 1 It is a flowchart of the method of the embodiment of the present invention;

[0036] Figure 2 It is a structural diagram of the device of the embodiment of the present invention;

[0037] The realization, functional characteristics, and advantages of the object of the present invention will be further described with reference to the embodiments and the accompanying drawings. Detailed Embodiments

[0038] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0039] Referring to Figure 1 , the present invention provides an API-based project collaborative development method, including the steps:

[0040] S1: Build an API management work platform, and the API management work platform includes: a test side, a design side, a development side, and an operation and maintenance side;

[0041] As an embodiment

[0042] Use YApi as the API management work platform.

[0043] Specifically, the development goals that YApi can achieve are as follows:

[0044] 1. Have a complete model definition function, that is, according to the back-end development mode, integrate request parameters and response parameters into model management.

[0045] 2. Have a complete API definition function.

[0046] 3. Have an API publishing function, that is, trigger the Jenkins workflow remotely to perform the code generation process based on the API definition and record it in the "dynamics".

[0047] 4. Upgrade the generated Swagger.json to version 3.0.

[0048] 5. Other functions that are beneficial to the development of testing work.

[0049] S2: Obtain requirement data, collect requirement data through the test side and the design side, and obtain the initial API document;

[0050] As an embodiment, the API document in the process specifically refers to the API definition written in YApi;

[0051] Step S2 is specifically as follows:

[0052] S21: Input the requirement data into the test side to obtain a prototype diagram;

[0053] S22: Input the requirement data into the design side to obtain design data;

[0054] S23: Generate the initial API document through the prototype diagram and the design data.

[0055] S3: Conduct document confirmation on the initial API document through the test side, the development side, and the operation and maintenance side to obtain the test API document; As an embodiment

[0056] Step S3 is specifically as follows:

[0057] Input the initial API document into the development side for content confirmation. If the content is confirmed to be correct, use the initial API document as the test API document; otherwise, return to step S2.

[0058] S4: Conduct functional testing on the test API document through the test side, the development side, and the operation and maintenance side. If the test passes, deploy the test API document as the final API document to the formal server; otherwise, return to step S2.

[0059] As an embodiment

[0060] Step S4 is specifically as follows:

[0061] S41: Generate the backend Mock, backend code, and Jenkins workflow for the test API documentation;

[0062] Specifically, the backend Mock of the API documentation is the API simulation. According to the API definition and the return value definition of special request parameters, YApi provides the simulated API for the front end to dock with the interface and for writing interface test cases during testing;

[0063] The Jenkins workflow is to adopt Jenkins to plan the automated process of the entire development process;

[0064] In the new process, there are more links separated from the code repository, and at the same time, the management requirements for operation and maintenance are more complex. It is no longer suitable to use GitLab CI managed by the software development department for process management. Therefore, we adopt Jenkins as an upgraded automated process management tool.

[0065] Jenkins will take over the following automated processes:

[0066] 1. Generate backend code according to the API definition and create a working branch for the actual project;

[0067] 2. Compile the code and generate an image;

[0068] 3. Deploy the test image to the test environment;

[0069] 4. Conduct interface testing;

[0070] 5. After testing and confirmation, mark the test image as a publishable image;

[0071] 6. Deploy the publishable image to the production environment;

[0072] 7. Data backup and database update (migration);

[0073] This completely liberates the manual operations of operation and maintenance, enabling the operation and maintenance department to focus its main energy on improving the stability and performance of the entire system deployment architecture, further enhancing the overall automation level, and promoting technological evolution.

[0074] S42: Input the backend Mock into the test end to generate interface test cases;

[0075] S43: Input the Jenkins workflow and the backend Mock into the operation and maintenance end to generate a test environment;

[0076] Specifically, the test environment takes the simulated API in the background as the backend and registers it with the middle platform for the front end to dock with the interface;

[0077] S44: Input the backend code into the development end to generate the background code;

[0078] S45: Deploy the background code to the test environment, perform interface testing according to the interface test cases. If the interface testing fails, return to step S44; otherwise, proceed to step S46;

[0079] S46: Conduct functional testing on the background code. If the functional testing fails, proceed to step S47; otherwise, deploy the background code as the final API document to the production server;

[0080] S47: Generate the front-end code for the test API document;

[0081] S48: Conduct functional testing on the front-end code. If the functional testing fails, return to step S47; otherwise, deploy the front-end code as the final API document to the production server.

[0082] As an example

[0083] Generate the backend Mock, backend code, and Jenkins workflow for the test API document through the code generation component.

[0084] Specifically, the code generation component is centered around a template-based code generator developed in.net, packaged into a container for use in the Jenkins workflow. This component accepts several parameters, including the Swagger.json address, release remarks, the code repository address for storing the generated project, the address for storing the actual project, the path of the project based on the generated code in the actual project, and the name of the development branch created with optional parameters. The specific workflow is as follows:

[0085] 1. API changes trigger code generation;

[0086] 2. After code generation, submit it to the Git repository;

[0087] 3. The Git repository, through the cd configuration, locates the corresponding actual development project;

[0088] 4. Pull the actual development project, create a new branch based on the master branch, with the branch name dev_xxxx, and enter the sub-project directory for development based on the generated code;

[0089] 5. Read the generated code reference configuration file in the sub-project directory to obtain the commitId of the generated code project referenced by the actual project;

[0090] 6. Create a temporary directory, pull the generated code project in the temporary directory, and check out the above commitId;

[0091] 7. Overwrite all files in the actual project into the temporary directory and generate a patch using git;

[0092] 8. Discard all changes, checkout the Head, and apply the patch (preserving conflict records);

[0093] 9. Overwrite all files (except.git) in the temporary directory after applying the patch into the sub - project directory, and modify the commitId in the generated code reference configuration file to the Head of the generated code project;

[0094] 10. Commit, and the commit message is wip:xxxx;

[0095] 11. Push.

[0096] After automatically completing code generation, create a development branch for the actual project and change to the project to automatically implement the complete process from API definition modification to work distribution.

[0097] Please refer to Figure 2 , Figure 2 which is the schematic diagram of the hardware device working in the embodiment of the present invention. The hardware device specifically includes: a project collaborative development device 401 based on API, a processor 402, and a storage medium 403.

[0098] A project collaborative development device 401 based on API: The project collaborative development device 401 based on API implements the project collaborative development method based on API.

[0099] Processor 402: The processor 402 loads and executes the instructions and data in the storage medium 403 to implement the project collaborative development method based on API.

[0100] Storage medium 403: The storage medium 403 stores instructions and data; the storage medium 403 is used to implement the project collaborative development method based on API.

[0101] It should be noted that in this article, the terms "include", "comprise" or any other variant thereof are intended to cover non - exclusive inclusion, so that a process, method, article or system including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or also includes elements inherent to this process, method, article or system. Without further limitations, an element defined by the statement "including one..." does not exclude the existence of another identical element in the process, method, article or system including that element.

[0102] The serial numbers of the embodiments of the present invention above are only for description and do not represent the superiority or inferiority of the embodiments. Among the several unit claims of the devices, several of these devices may be embodied by the same hardware item. The use of the terms "first", "second", and "third", etc. does not indicate any order, and these terms may be interpreted as identifiers.

[0103] The above are only the preferred embodiments of the present invention, and do not limit the patent scope of the present invention accordingly. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied to other related technical fields, shall be equally included in the patent protection scope of the present invention.

Claims

1. A project collaborative development method based on API, characterized in that Including the steps: S1: Build an API management work platform, which includes a testing end, a design end, a development end, and an operation and maintenance end; S2: Obtain requirement data, collect requirements for the requirement data through the testing end and the design end to obtain an initial API document; S3: Conduct document confirmation on the initial API document through the testing end, the development end, and the operation and maintenance end to obtain a test API document; S4: Conduct functional testing on the test API document through the testing end, the development end, and the operation and maintenance end. If the test passes, deploy the test API document to the formal server as the final API document; otherwise, return to step S2.

2. The API-based project collaborative development method according to claim 1, characterized in that: Use YApi as the API management work platform.

3. The API-based project collaborative development method according to claim 1, wherein Step S2 is specifically: S21: Input the requirement data into the testing end to obtain a prototype diagram; S22: Input the requirement data into the design end to obtain design data; S23: Generate an initial API document based on the prototype diagram and the design data.

4. The API-based project collaborative development method according to claim 1, wherein Step S3 is specifically: Input the initial API document into the development end for content confirmation. If the content is confirmed to be correct, use the initial API document as the test API document; otherwise, return to step S2.

5. The API-based project collaborative development method according to claim 1, wherein Step S4 is specifically: S41: Generate the backend Mock, backend code, and Jenkins workflow for the test API document; S42: Input the backend Mock into the testing end to generate interface test cases; S43: Input the Jenkins workflow and the backend Mock into the operation and maintenance end to generate a test environment; S44: Input the backend code into the development end to generate backend code; S45: Deploy the backend code to the test environment and conduct interface testing according to the interface test cases. If the interface testing fails, return to step S44; otherwise, proceed to step S46; S46: Conduct functional testing on the backend code. If the functional testing fails, proceed to step S47; otherwise, deploy the backend code to the formal server as the final API document; S47: Generate the front-end code for the test API document; S48: Conduct functional testing on the front-end code. If the functional testing fails, return to step S47; otherwise, deploy the front-end code to the formal server as the final API document.

6. The API-based project collaborative development method according to claim 5, characterized in that: Generate the backend Mock, backend code, and Jenkins workflow for the test API document through a code generation component.

7. A storage medium, characterized in that: The storage medium stores instructions and data for implementing the API-based project collaborative development method according to any one of claims 1 to 6.

8. An API-based project collaborative development device, characterized in that: Including: A processor and a storage medium; the processor loads and executes the instructions and data in the storage medium for implementing the API-based project collaborative development method according to any one of claims 1 to 6.

Images