Multi-warehouse management method, device and equipment under joint development and readable storage medium

Abstract

The invention discloses a multi-warehouse management method, device and equipment under joint development and a readable storage medium, and relates to the field of computers. The method comprises the steps that a source code warehouse and a joint developer Lib warehouse are in a separated state; integrating a target Lib file in the joint developer Lib warehouse to a target source code project of the target project in the source code warehouse according to the target list file through the warehouse management instruction to obtain a new source code project; compiling the new source code project to generate a new version, compiling and packaging source files in the source code warehouse to obtain a target library file, and storing the target library file and a target header file stored with joint developer dependency information into a target Lib folder; and releasing the new version and the target Lib folder to a joint developer system, so that the joint developer system performs function verification on the new version on the basis of not opening the source code warehouse permission and performs development debugging based on the target Lib folder, thereby improving the library file integration efficiency and reducing the labor cost.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular to a multi-warehouse management method, apparatus, device, and readable storage medium under joint development. Background Art

[0002] With the improvement of the performance of in-vehicle chips, the software integration degree of in-vehicle ECUs (Electronic Control Units) has been increasing day by day. Gradually, there has emerged a form in which multiple ECUs are integrated into one system and jointly developed by multiple parties. However, due to information security restrictions on the source codes of each party's functions, they cannot be publicly uploaded to the same warehouse, so they are all integrated in the form of library files. Among them, when managing the code of the MCU (Microcontroller Unit), it is basically implemented in the form of the same code repository, so it is necessary to use the library file method for integration.

[0003] In related technologies, when performing lib (library) integration, it is necessary for the source code repository party to designate internal personnel (hereinafter referred to as integration personnel) to download and integrate the external lib files (i.e., library files) into the specified directory, and then submit the lib files to the corresponding code repository after passing the compilation verification; since this method requires manual implementation of lib file integration, there are not only low efficiency, high labor costs, but also easy to make mistakes. In addition, when the joint development parties are developing and debugging, they need to use a project engineering with complete functions. However, due to information security specification requirements, the permissions of the source code repository cannot be opened to the development personnel of each party, so that each joint development party cannot carry out development and debugging. Summary of the Invention

[0004] This application provides a multi-warehouse management method, apparatus, device, and readable storage medium under joint development, which can enable the joint development parties to achieve development and debugging without opening the permissions of the source code repository, and improve the integration efficiency of library files and reduce labor costs.

[0005] In a first aspect, an embodiment of this application provides a multi-warehouse management method under joint development, including the following steps:

[0006] When there is a version release requirement corresponding to a target project, integrate the target Lib files in the Lib warehouse of the joint development party into the target source code project corresponding to the target project in the source code warehouse through a warehouse management instruction and according to a preset target list file, so as to obtain a new source code project. The target list file is configured with branch information, Lib file information, and project path information to be integrated. The source code warehouse and the Lib warehouse of the joint development party are in a separated state;

[0007] Compile the new source code project to generate a new version, compile and package the source files in the source code repository to obtain the target library file, and store the target library file and the target header file in the target Lib folder, where the target header file stores the dependency information corresponding to the co-developer;

[0008] Release the new version and the target Lib folder to the co-developer system for the co-developer system to perform function verification on the new version and develop and debug based on the target Lib folder.

[0009] Combined with the first aspect, in an implementation, integrating the target Lib file in the co-developer Lib repository into the target source code project corresponding to the target project in the source code repository through the repository management instruction and according to the preset target list file to obtain a new source code project, including:

[0010] Determine the target Lib file from the co-developer Lib repository based on the branch information and the Lib file information;

[0011] Integrate the target Lib file into the target source code project corresponding to the target project in the source code repository through the repository management instruction and based on the project path information to obtain a new source code project.

[0012] Combined with the first aspect, in an implementation, the co-developer system develops and debugs based on the target Lib folder, including:

[0013] The co-developer system generates a first source code project based on the updated local library file and the target library file and the target header file in the target Lib folder;

[0014] The co-developer system develops and debugs the first source code project based on the preset debug project, and the debug project has the same compiler as the source code repository and does not include the source files in the source code repository.

[0015] Combined with the first aspect, in an implementation, the method further includes:

[0016] After the co-developer system successfully develops and debugs, the co-developer system submits the updated local library file corresponding to the development and debugging to the preset code review tool for verification management of the updated local library file;

[0017] If the result of the verification management is passed, the co-developer system uploads the updated local library file to the co-developer Lib repository;

[0018] If the result of the verification management is not passed, the co-developer system does not upload the updated local library file to the co-developer Lib repository.

[0019] In combination with the first aspect, in one implementation, the co - development party system submits the updated local library file to a preset code review tool for verification management of the updated local library file, including:

[0020] The co - development party system submits the updated local library file to a preset code review tool to generate a target change ID and send it to the compilation server;

[0021] The compilation server downloads a second source code project based on the target change ID and the target manifest file, integrates the updated local library file into the second source code project for compilation, and releases the successfully compiled target version to the co - development party system;

[0022] The co - development party system verifies whether the functions of the target version are normal;

[0023] If the functions are normal, the co - development party system determines that the result of the verification management is passed;

[0024] If the functions are not normal, the co - development party system determines that the result of the verification management is not passed.

[0025] In combination with the first aspect, in one implementation, after the step of integrating the local library file into the second source code project for compilation, it further includes:

[0026] If the compilation fails, the co - development party system is prohibited from uploading the updated local library file to the co - development party Lib repository.

[0027] In a second aspect, an embodiment of the present application provides a multi - repository management device under co - development, including:

[0028] An integration module, which is used when there is a version release requirement corresponding to a target project, to integrate a target Lib file in the co - development party Lib repository into a target source code project corresponding to the target project in the source code repository through a repository management instruction and according to a preset target manifest file to obtain a new source code project, where the target manifest file is configured with branch information, Lib file information, and project path information to be integrated;

[0029] A compilation server, which is used to compile the new source code project to generate a new version, and compile and package the source files in the source code repository to obtain target library files, store the target library files and target header files in the target Lib folder, and the target header files store dependency information corresponding to the co-developers; release the new version and the target Lib folder to the co-developer system for the co-developer system to perform function verification on the new version and develop and debug based on the target Lib folder.

[0030] In combination with the second aspect, in an implementation, the integration module is specifically used for: determining a target Lib file from the co-developer Lib repository based on the branch information and Lib file information; integrating the target Lib file onto the target source code project corresponding to the target project in the source code repository through a repository management instruction and based on the project path information to obtain a new source code project.

[0031] In combination with the second aspect, in an implementation, the co-developer system is specifically used for: generating a first source code project based on the updated local library file and the target library files and target header files in the target Lib folder; performing development and debugging on the first source code project based on a preset debugging project, and the debugging project has the same compiler as the source code repository and does not contain the source files in the source code repository.

[0032] In combination with the second aspect, in an implementation, after the co-developer system successfully develops and debugs, the co-developer system is further used to submit the updated local library file corresponding to the development and debugging to a preset code review tool to perform verification management on the updated local library file; if the result of the verification management is passed, the co-developer system uploads the updated local library file to the co-developer Lib repository; if the result of the verification management is not passed, the co-developer system does not upload the updated local library file to the co-developer Lib repository.

[0033] In combination with the second aspect, in an implementation, the co-developer system submits the updated local library file to a preset code review tool to generate a target change ID and send it to the compilation server; the compilation server downloads a second source code project based on the target change ID and the target manifest file, integrates the updated local library file into the second source code project for compilation, and releases the successfully compiled target version to the co-developer system; the co-developer system verifies whether the function of the target version is normal; if the function is normal, the co-developer system determines that the result of the verification management is passed; if the function is abnormal, the co-developer system determines that the result of the verification management is not passed.

[0034] In combination with the second aspect, in one implementation, the compilation server is further configured to prohibit the co - development party system from uploading the updated local library file to the co - development party's Lib repository if the compilation fails.

[0035] In a third aspect, an embodiment of the present application provides a multi - repository management device under co - development. The multi - repository management device under co - development includes a processor, a memory, and a co - development multi - repository management program stored on the memory and executable by the processor. When the co - development multi - repository management program is executed by the processor, the steps of the multi - repository management method under co - development as described above are implemented.

[0036] In a fourth aspect, an embodiment of the present application provides a computer - readable storage medium. A co - development multi - repository management program is stored on the computer - readable storage medium. When the co - development multi - repository management program is executed by a processor, the steps of the multi - repository management method under co - development as described above are implemented.

[0037] The beneficial effects brought by the technical solutions provided in the embodiments of the present application include:

[0038] By controlling the source code repository and the co - development party's Lib repository to be in a separated state, each party only needs to open the read - write permissions of its corresponding Lib repository, providing an environmental basis for development and debugging without the need to open the source code repository permissions. When there is a version release requirement corresponding to the target project, through the repository management instruction and according to the target list file, the target Lib files in each co - development party's Lib repository are automatically integrated onto the target source code project of the target project in the source code repository to obtain a new source code project, without the need for manual integration of Lib files, effectively improving the integration efficiency of library files and reducing labor costs. Then, after compiling the new source code project to generate a new version, during version compilation, the source files in the source code repository are compiled and packaged into target library files, and the target library files and target header files storing co - development party dependency information are stored in the specified target Lib folder. Finally, the new version and the target Lib folder are released to the co - development party system, enabling the co - development party system to directly perform function verification on the new version and conduct development and debugging based on the target Lib folder without obtaining the source code repository permissions. It can be seen that the present application enables co - development parties to achieve development and debugging without opening the source code repository permissions, and improves the integration efficiency of library files and reduces labor costs. Description of the Drawings

[0039] Figure 1 It is a flowchart of an embodiment of the multi - repository management method under co - development of the present application;

[0040] Figure 2 It is a schematic diagram of code repository management in the prior art;

[0041] Figure 3 Schematic diagram of code repository management involved in the solution of the embodiment of the present application;

[0042] Figure 4 Schematic diagram of Lib file integration involved in the solution of the embodiment of the present application;

[0043] Figure 5 Schematic diagram of the specific process of multi-repository management under joint development involved in the solution of the embodiment of the present application;

[0044] Figure 6 Schematic diagram of the hardware structure of the multi-repository management device under joint development involved in the solution of the embodiment of the present application. Detailed implementation manners

[0045] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0046] To make the purpose, technical solution and advantages of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the accompanying drawings.

[0047] In a first aspect, an embodiment of the present application provides a multi-repository management method under joint development.

[0048] In one embodiment, referring to Figure 1 , Figure 1 is a schematic flowchart of an embodiment of the multi-repository management method under joint development of the present application. As Figure 1 shown, the multi-repository management method under joint development includes:

[0049] Step S10: When there is a version release requirement corresponding to a target project, integrate the target Lib files in the Lib repository of the joint development party into the target source code project corresponding to the target project in the source code repository through a repository management instruction and according to a preset target list file, so as to obtain a new source code project. The target list file is configured with branch information, Lib file information and project path information to be integrated, and the source code repository and the Lib repository of the joint development party are in a separated state.

[0050] Exemplarily, referring to Figure 2As shown, when managing the MCU code, it is basically implemented in the form of the same code repository, that is, all the Lib files of the joint developers will be integrated into the source code repository of the corresponding XX project. However, due to the requirements of information security regulations, the permissions of the source code repository cannot be opened to the developers of all parties, resulting in the inability of the joint developers to carry out development and debugging. In this embodiment, to solve the problem that the permissions of the source code repository cannot be opened to all parties, the source code repository and the Lib repository of the joint developers are separated, that is, see Figure 3 As shown, the source code repository of the XX project and the lib repositories of each joint developer are built separately, so that the source code repository and the Lib repositories of each joint developer are in a separated state; based on this, each party only needs to open the read and write permissions of the corresponding repository, thereby providing an environmental basis for realizing development and debugging without opening the permissions of the source code repository; it should be noted that in order to cope with the delivery of each stage of the project, the branch management of each joint developer's Lib repository should be the same as that of the source code repository.

[0051] In this embodiment, Repo (a tool for managing multiple Git repositories) will be used to automatically manage multiple repositories of all the already separated repositories, so as to improve the efficiency and accuracy of repository management, and specify the branches, files, project paths, etc. that need to be integrated through the xml file of the manifest file. It should be understood that the target project refers to the project that needs to release a new version; when the target project needs to release a new version, the branch information, Lib file information, and project path information to be integrated will be configured to generate a target manifest file, for example, see Figure 4 As shown, the target manifest file may include "source code repository path", "path of the joint developer's Lib1 repository, which needs to be integrated under the xx / xx path of the source code repository", etc.; see Figure 4 and Figure 5 As shown, during the integrated compilation, the multi-repository integrated download is performed through the repository management instruction Repo, that is, the Lib files are automatically integrated into the specified directory according to the configuration in the target manifest file, that is, the target Lib files in the joint developer's Lib repository are automatically integrated into the target source code project corresponding to the target project in the source code repository, so as to realize the automatic generation of a new source code project, and finally perform the build (the build refers to the software manager initiating the compilation of the code project and generating binary products and upgrade files, etc.) compilation.

[0052] Furthermore, in one embodiment, integrating the target Lib files in the joint developer's Lib repository into the target source code project corresponding to the target project in the source code repository through the repository management instruction and according to the preset target manifest file to obtain a new source code project includes:

[0053] Determine the target Lib file from the joint developer's Lib repository based on the branch information and Lib file information;

[0054] Integrate the target Lib file into the target source code project corresponding to the target project in the source code repository based on the project path information through the repository management instruction to obtain a new source code project.

[0055] Exemplarily, in this embodiment, first determine the target Lib file to be integrated from the corresponding joint developer's Lib repository through the branch information and Lib file information in the target manifest file; then automatically integrate the target Lib file into the corresponding specified directory through the Repo instruction according to the project path information in the target manifest file, and the target Lib file can be integrated into the target source code project in the source code repository corresponding to the target project, thereby obtaining a new source code project, without manual integration of the Lib file, effectively improving the integration efficiency of the library file and reducing the labor cost, and reducing the possibility of errors.

[0056] Step S20: Compile the new source code project to generate a new version, and compile and package the source files in the source code repository to obtain a target library file, and store the target library file and the target header file in the target Lib folder, and the target header file stores the dependency information corresponding to the joint developer.

[0057] Exemplarily, refer to Figure 5 As shown, after obtaining the new source code project, it will be compiled to generate a new binary file (i.e., the new version); it should be noted that during the version compilation, all source files in the source code repository will also be compiled to generate.o files (i.e., object files) and packaged into a target library file, and the target library file will be stored in the specified folder (i.e., the target Lib folder); at the same time, during each version compilation, the target header file containing the dependency information such as the driver interface or parameter type required for the joint developer's development will be automatically copied to the target Lib folder.

[0058] Step S30: Release the new version and the target Lib folder to the joint developer's system for the joint developer's system to perform functional verification on the new version and develop and debug based on the target Lib folder.

[0059] Exemplarily, it should be understood that when the compilation is completed, when uploading the compilation product, the generated target Lib folder will be uploaded to the version server at the same time, that is, the newly generated version and the target Lib files will be uploaded to the version server to be released to the co-development party's system, so that the co-development party's system can directly perform function verification on the new version and develop and debug based on the target Lib folder without obtaining the source code repository permission. It can be seen that this embodiment can not only enable the co-development party to develop and debug using the complete project on the basis of not opening the source code repository permission, but also improve the integration efficiency of library files and reduce labor costs.

[0060] Further, in one embodiment, the co-development party's system developing and debugging based on the target Lib folder includes:

[0061] The co-development party's system generates a first source code project based on the updated local library files, the target library files and the target header files in the target Lib folder;

[0062] The co-development party's system develops and debugs the first source code project based on a preset debugging project, and the debugging project has the same compiler as the source code repository and does not include the source files in the source code repository.

[0063] Exemplarily, it should be understood that the project usually iterates in real time and the source code is constantly updated, that is, the local library files of the co-development party will be continuously updated and iterated, thus generating updated local library files; therefore, as shown in Figure 5 When the co-development party is developing and debugging, the co-development party can obtain the target library files and the target header files from the version server, so that the co-development party's system generates a first source code project according to the updated local library files, the target library files and the target header files, and develops and debugs the first source code project based on a preset debugging project. It should be noted that to ensure the consistency of the development environment, this embodiment will provide the co-development party with a debugging project with the same compilation environment (hereinafter referred to as the minimum system), and this minimum system needs to meet the following conditions: (1) The minimum system needs to use the same compiler and compilation script as the source code repository; (2) The minimum system project does not contain any c code files (i.e., source files) of the source code repository; (3) The minimum system supports the modification of the manifest file, such as adding or deleting source files and header files, Lib integration, and Lib encapsulation, etc.

[0064] Further, in one embodiment, the method further includes:

[0065] After the co-development party's system successfully develops and debugs, the co-development party's system submits the updated local library files corresponding to the development and debugging to a preset code review tool to verify and manage the updated local library files;

[0066] If the result of verification management is passed, the co - development party system uploads the updated local library file to the co - development party's Lib repository;

[0067] If the result of verification management is not passed, the co - development party system does not upload the updated local library file to the co - development party's Lib repository.

[0068] Exemplarily, it should be understood that when integrating library files in traditional solutions, due to various reasons such as limited environment, the integrators cannot fully verify the integrated library files, resulting in risks such as anomalies in the integrated system. Therefore, when each co - development party's Lib repository needs to submit a new version of the library file (i.e., the updated local library file), to ensure normal version delivery, as shown in Figure 5 In this embodiment, Verify management (i.e., verification management) is performed on each repository, that is, each co - development party system fully verifies the updated local library file that has been successfully developed and debugged; specifically, the updated local library file can be submitted to a code review tool (such as the gerrit tool) for Verify management to determine whether to upload the updated local library file to the corresponding co - development party's Lib repository according to the verification management result; among them, if the result of verification management is passed, the co - development party system is allowed to upload its updated local library file to the corresponding co - development party's Lib repository, and if the result of verification management is not passed, the co - development party system is prohibited from uploading its updated local library file to the corresponding co - development party's Lib repository to reduce the risk of anomalies in the integrated system.

[0069] Further, in one embodiment, the co - development party system submits the updated local library file to a preset code review tool for verification management, including:

[0070] The co - development party system submits the updated local library file to a preset code review tool to generate a target change ID and send it to the compilation server;

[0071] The compilation server downloads a second source code project based on the target change ID and the target manifest file, integrates the updated local library file into the second source code project for compilation, and releases the successfully compiled target version to the co - development party system;

[0072] The co - development party system verifies whether the target version is functional properly;

[0073] If the function is normal, the co - development party system determines that the result of verification management is passed;

[0074] If the function is abnormal, the co - development party system determines that the result of verification management fails.

[0075] Exemplarily, in this embodiment, the co - development party system first needs to submit the updated local library file to the gerrit tool. At this time, the updated local library file is in a state waiting to be stored in the repository. The gerrit tool generates a changID (i.e., the target change ID) for the updated local library file waiting to be stored in the repository, and at the same time includes the changed file name and the directory where the file is located. Among them, when initiating the Verify function (i.e., during verification management), it is specified which modification is to be included in this verification (i.e., filling in the changID), and the compilation server that executes the Verify function (such as the Jekins server, GHS compiler, etc.) will first download the latest source code project (i.e., the second source code project) according to the manifest file. After the download is completed, the compilation server inserts the updated local library file to be verified into the second source code project for compilation. If the compilation is successful, it triggers the verify + 1 action and uploads the successfully compiled target version to the version server for release to the co - development party system.

[0076] The co - development party system then obtains the target version from the version server and verifies whether the function is normal. If the function is normal and it is determined that the result of verification management passes, it allows the updated local library file waiting to be stored in the repository to be stored in the repository. If the function is abnormal and it is determined that the result of verification management fails, it prohibits the updated local library file waiting to be stored in the repository from being stored in the repository.

[0077] It can be seen that in this embodiment, when triggering the version release, it will automatically integrate each co - development party's Lib repository through multi - repository management, and generate the library file of the source code repository during integrated compilation and upload it to the version server. Each co - development party uses the minimum system of the source code project for development and debugging, encapsulates its own source code as a library file in the compilation environment of the minimum system, and then uploads it to its own Lib repository to form a closed - loop.

[0078] Further, in one embodiment, after the step of integrating the local library file into the second source code project for compilation, it further includes:

[0079] If the compilation fails, the co - development party system is prohibited from uploading the updated local library file to the co - development party's Lib repository.

[0080] Exemplarily, in this embodiment, after the updated local library file that needs to be verified is inserted into the second source code project for compilation, if the compilation server finds that the compilation fails, the verify-1 action is triggered, and the result of the verification management is determined to be failed. At this time, the updated local library file to be stored will be prohibited from being stored in the library to ensure that it does not affect the normal version delivery.

[0081] It can be seen that this embodiment is based on the cooperation between compilation servers, Repo, gerrit and other tools to achieve separate management of the warehouses of each party in a joint development scenario, that is, the library files of each party are uploaded separately, submitted for verification separately, automatically integrated when the version is released, and the Lib files of each party are automatically shared. An automated integration and release solution, that is, a set of iterative, cross-platform, and efficient MCU multi-warehouse management is realized, and a solution that can automatically integrate, automatically release versions, and synchronize development projects is realized. It is not only highly scalable, but also has efficient and accurate integration, and the development methods of all parties are flexible. It also solves the bugs or exceptions caused by the asynchronous debugging versions of both parties that may be caused by the rapid iteration of the current version.

[0082] In summary, this embodiment can save the man-hour cost of manual integration through automated integration, and the integration is stable and error-prone; and on the basis of fully complying with information security specifications, the development environment of all parties is completely consistent, and version iteration is convenient and fast; in addition, before the parties integrate a new version, the parties can obtain the version produced by the compilation server in advance for sufficient verification before submitting it, thereby ensuring system stability.

[0083] In a second aspect, the embodiments of the present application also provide a multi-warehouse management device under joint development.

[0084] In one embodiment, the multi-warehouse management device under joint development includes:

[0085] An integration module is used to integrate the target Lib files in the Lib warehouse of the joint developer into the target source code project corresponding to the target project in the source code warehouse through warehouse management instructions and in accordance with a preset target manifest file when there is a version release requirement corresponding to the target project, so as to obtain a new source code project. The target manifest file is configured with branch information to be integrated, Lib file information and project path information;

[0086] A compilation server is used to compile the new source code project to generate a new version, and compile and package the source files in the source code repository to obtain a target library file, store the target library file and the target header file in a target Lib folder, and the target header file stores dependency information corresponding to the joint developer; release the new version and the target Lib folder to the joint developer system, so that the joint developer system can perform functional verification on the new version and perform development and debugging based on the target Lib folder.

[0087] Further, in one embodiment, the integration module is specifically configured to: determine a target Lib file from the Lib repository of the joint developer based on the branch information and the Lib file information; and integrate the target Lib file onto the target source code project corresponding to the target project in the source code repository through a repository management instruction based on the project path information to obtain a new source code project.

[0088] Further, in one embodiment, the joint developer system is specifically configured to: generate a first source code project based on the updated local library file and the target library files and target header files in the target Lib folder; and perform development and debugging on the first source code project based on a preset debugging project, where the debugging project has the same compiler as the source code repository and does not include the source files in the source code repository.

[0089] Further, in one embodiment, after the joint developer system successfully develops and debugs, the joint developer system is further configured to submit the updated local library file corresponding to the development and debugging to a preset code review tool to perform verification management on the updated local library file; if the result of the verification management is passed, the joint developer system uploads the updated local library file to the joint developer Lib repository; if the result of the verification management is not passed, the joint developer system does not upload the updated local library file to the joint developer Lib repository.

[0090] Further, in one embodiment, the joint developer system submits the updated local library file to a preset code review tool to generate a target change ID and send it to the compilation server; the compilation server downloads a second source code project based on the target change ID and the target manifest file, integrates the updated local library file into the second source code project for compilation, and releases the successfully compiled target version to the joint developer system; the joint developer system verifies whether the function of the target version is normal; if the function is normal, the joint developer system determines that the result of the verification management is passed; if the function is abnormal, the joint developer system determines that the result of the verification management is not passed.

[0091] Further, in one embodiment, the compilation server is further configured to prohibit the joint developer system from uploading the updated local library file to the joint developer Lib repository if the compilation fails.

[0092] Wherein, the function implementation of each module in the above multi-repository management device under joint development corresponds to each step in the above multi-repository management method embodiment under joint development, and its function and implementation process will not be elaborated here one by one.

[0093] In a third aspect, an embodiment of the present application provides a multi-warehouse management device under joint development. The multi-warehouse management device under joint development may be a device with data processing functions such as a personal computer (PC), a laptop computer, a server, etc.

[0094] Referring to Figure 6 , Figure 6 FIG. is a schematic diagram of the hardware structure of the multi-warehouse management device under joint development involved in the solution of the embodiment of the present application. In the embodiment of the present application, the multi-warehouse management device under joint development may include a processor, a memory, a communication interface, and a communication bus.

[0095] Among them, the communication bus can be of any type and is used to interconnect the processor, the memory, and the communication interface.

[0096] The communication interface includes interfaces such as input / output (I / O) interfaces, physical interfaces, and logical interfaces for implementing the interconnection of components inside the multi-warehouse management device under joint development, as well as interfaces for implementing the interconnection between the multi-warehouse management device under joint development and other devices (such as other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.; the user device can be a display screen (Display), a keyboard (Keyboard), etc.

[0097] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical memory, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0098] The processor can be a general-purpose processor. The general-purpose processor can call the multi-warehouse management program stored in the memory and execute the multi-warehouse management method provided by the embodiment of the present application. For example, the general-purpose processor can be a central processing unit (CPU). Among them, the method executed when the multi-warehouse management program is called can refer to the various embodiments of the multi-warehouse management method of the present application and will not be elaborated here.

[0099] Those skilled in the art can understand, Figure 6The hardware structure shown does not constitute a limitation on this application, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0100] Fourthly, an embodiment of this application also provides a computer-readable storage medium.

[0101] A multi-warehouse management program under joint development is stored on the readable storage medium of this application. When the multi-warehouse management program under joint development is executed by a processor, the steps of the multi-warehouse management method under joint development as described above are implemented.

[0102] Among them, the method implemented when the multi-warehouse management program under joint development is executed can refer to the various embodiments of the multi-warehouse management method under joint development of this application, which will not be elaborated here.

[0103] It should be noted that the serial numbers of the above embodiments of this application are only for description and do not represent the superiority or inferiority of the embodiments.

[0104] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices. The descriptions of terms such as "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit that "first", "second" and "third" are different types.

[0105] In the description of the embodiments of this application, "exemplary", "for example" or "for instance" etc. are used to indicate examples, illustrations or explanations. Any embodiment or design solution described as "exemplary", "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Exactly speaking, the use of words such as "exemplary", "for example" or "for instance" is intended to present relevant concepts in a specific manner.

[0106] In the description of the embodiments of this application, unless otherwise specified, " / " means "or". For example, A / B may mean A or B; "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "a plurality of" means two or more than two.

[0107] In some of the processes described in the embodiments of the present application, multiple operations or steps appear in a specific order. However, it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or may be executed in parallel. The serial numbers of the operations are only used to distinguish different operations, and the serial numbers themselves do not represent any order of execution. Additionally, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.

[0108] Through the description of the above embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases, the former is a better implementation. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium as described above (such as ROM / RAM, magnetic disk, optical disc) and includes several instructions for causing a terminal device to execute the methods described in the various embodiments of the present application.

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

Claims

1. A method for managing multiple warehouses under joint development, characterized in that: The following steps are involved: When there is a version release requirement corresponding to the target project, the target Lib file in the joint developer's Lib warehouse is integrated into the target source code project corresponding to the target project in the source code warehouse through the warehouse management instruction and in accordance with the preset target list file, so as to obtain a new source code project. The target list file is configured with the branch information to be integrated, the Lib file information and the project path information. The source code warehouse and the joint developer's Lib warehouse are in a separated state; Compile the new source code project to generate a new version, compile and package the source files in the source code repository to obtain a target library file, store the target library file and the target header file in the target Lib folder, and the target header file stores the dependency information corresponding to the joint development party; The new version and the target Lib folder are released to the joint development party system, so that the joint development party system can perform functional verification on the new version and perform development and debugging based on the target Lib folder.

2. The method for managing multiple warehouses under joint development as claimed in claim 1, characterized in that: The target Lib file in the Lib warehouse of the joint developer is integrated into the target source code project corresponding to the target project in the source code warehouse through the warehouse management instruction and according to the preset target list file to obtain a new source code project, including: Determine the target Lib file from the Lib warehouse of the joint developer based on the branch information and the Lib file information; The target Lib file is integrated into the target source code project corresponding to the target project in the source code warehouse through the warehouse management instruction and based on the project path information to obtain a new source code project.

3. The multi-warehouse management method under joint development as claimed in claim 1, characterized in that: The joint development system performs development and debugging based on the target Lib folder, including: The joint development system generates a first source code project based on the updated local library file and the target library file and target header file in the target Lib folder; The joint development system develops and debugs the first source code project based on a preset debugging project, where the debugging project has the same compiler as the source code repository and does not include source files in the source code repository.

4. The multi-warehouse management method under joint development according to claim 1 or 3, characterized in that: The method further comprises: After the joint developer system has successfully developed and debugged, the joint developer system will submit the updated local library file corresponding to the development and debugging to a preset code review tool to verify and manage the updated local library file; If the result of the verification management is passed, the joint developer system uploads the updated local library file to the joint developer Lib warehouse; If the result of the verification management is failure, the joint developer system will not upload the updated local library file to the joint developer Lib warehouse.

5. The method for managing multiple warehouses under joint development as claimed in claim 4, characterized in that: The joint development system submits the updated local library file to a preset code review tool to perform verification management on the updated local library file, including: The joint development system submits the updated local library file to a preset code review tool to generate a target change ID and send it to the compilation server; The compiling server downloads the second source code project based on the target change ID and the target manifest file, integrates the updated local library file into the second source code project for compilation, and releases the successfully compiled target version to the joint development party system; The joint development party system verifies whether the target version functions normally; If the function is normal, the joint development party system determines that the result of the verification management is passed; If the function is not normal, the joint development party system determines that the result of the verification management is failed.

6. The method for managing multiple warehouses under joint development as claimed in claim 5, characterized in that: After the step of integrating the local library file into the second source code project for compilation, the method further includes: If the compilation fails, the joint developer system is prohibited from uploading the updated local library file to the joint developer Lib warehouse.

7. A multi-warehouse management device under joint development, characterized in that: include: An integration module is used to integrate the target Lib files in the Lib warehouse of the joint developer into the target source code project corresponding to the target project in the source code warehouse through warehouse management instructions and in accordance with a preset target manifest file when there is a version release requirement corresponding to the target project, so as to obtain a new source code project. The target manifest file is configured with branch information to be integrated, Lib file information and project path information; A compilation server is used to compile the new source code project to generate a new version, and compile and package the source files in the source code repository to obtain a target library file, store the target library file and the target header file in a target Lib folder, and the target header file stores dependency information corresponding to the joint developer; release the new version and the target Lib folder to the joint developer system, so that the joint developer system can perform functional verification on the new version and perform development and debugging based on the target Lib folder.

8. The multi-warehouse management device under joint development as claimed in claim 7, characterized in that: The integrated module is specifically used for: Determine the target Lib file from the Lib warehouse of the joint developer based on the branch information and the Lib file information; The target Lib file is integrated into the target source code project corresponding to the target project in the source code warehouse through the warehouse management instruction and based on the project path information to obtain a new source code project.

9. A jointly developed multi-warehouse management device, characterized in that: The multi-warehouse management device under joint development includes a processor, a memory, and a multi-warehouse management program under joint development stored in the memory and executable by the processor, wherein when the multi-warehouse management program under joint development is executed by the processor, the steps of the multi-warehouse management method under joint development as described in any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a multi-warehouse management program under joint development, wherein when the multi-warehouse management program under joint development is executed by a processor, the steps of the multi-warehouse management method under joint development as described in any one of claims 1 to 6 are implemented.

Images