Construction management system, method and equipment of multi-module software architecture and medium

Abstract

The embodiment of the invention relates to the technical field of software development, and discloses a construction management system, method and equipment of a multi-module software architecture and a medium. According to the embodiment of the invention, each module under the multi-module software architecture can be independently managed to meet the requirement of independently issuing each module; codes of all the modules can be stored through a remote warehouse, and version information, change records, review records, storage links and other related information of the modules are managed on a unified platform; the construction project of the whole code can be deployed on a server, and the server can obtain related information of each module from a unified platform according to development requirements and complete code pulling, compiling construction, change statistics and software release processes according to established rules. According to the construction management system provided by the embodiment of the invention, the construction efficiency of the multi-module architecture software can be improved, the traceability of the software is ensured, and the quality and reliability of the software are improved.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a construction management system, method, device and medium for a multi-module software architecture. Background Technology

[0002] With the development of automotive technology, automotive software is becoming increasingly important for the realization of vehicle power, comfort, and safety; correspondingly, the amount of code in automotive software is also growing rapidly. To adapt to this change, the automotive electronic and electrical architecture based on domain controllers has gradually become the mainstream due to its advantages such as high software integration and fewer hardware components.

[0003] Compared to traditional automotive controllers, domain controllers can integrate more functions onto a single controller. Their software architecture includes multiple functional modules that work together to achieve the overall domain control functionality. However, this multi-module architecture introduces problems such as version inconsistencies when each module is developed independently, cumbersome and inefficient software compilation, and difficulties in troubleshooting and tracing the root cause of problems. These issues significantly reduce the efficiency of automotive R&D and introduce unreliable factors into the automotive development process. Summary of the Invention

[0004] The purpose of this invention is to provide a construction management system, method, device, and medium for multi-module software architecture, which can at least improve the construction efficiency of multi-module software architecture, ensure software traceability, and improve software quality and reliability.

[0005] To address the aforementioned technical problems, in a first aspect, the present invention provides a multi-module software architecture build management system, which includes at least a development subsystem, a review subsystem, a build subsystem, a release subsystem, and a remote warehouse management subsystem;

[0006] The development subsystem establishes connections with both the remote repository subsystem and the review subsystem, and is at least used to perform module development of the software architecture according to project documents and project development needs, and update the version number in the module code; and, after the development of any module is completed, submits the corresponding module commit information to the remote repository subsystem, so that after the remote repository subsystem verifies and approves the module commit information, at least the corresponding module code is uploaded to the remote repository subsystem; and, after the module code is uploaded to the remote repository subsystem, records the module information to the review subsystem to trigger a review request;

[0007] The review subsystem is connected to the build subsystem and is used at least to respond to the review request by verifying the change status of the corresponding module based on the module commit information in each module information; and, after the change status verification of the corresponding module is passed, to perform at least requirement review verification, development review verification, and test review verification on the corresponding module; and, after all the review verifications are passed, to trigger a code merge request and modify the module commit information of the corresponding module to be compileable.

[0008] The build subsystem establishes a connection with the release subsystem and is at least used to respond to the project development needs by pulling the remote repository code of the corresponding module according to the build file and checking the version and module information of each module; and after all the modules required for architecture construction have passed the check, triggering the compilation script to execute the architecture module compilation; and after the architecture module compilation is completed, analyzing the log file generated by the compilation to verify whether the compilation was successful, and if the compilation was successful, modifying the change status of each of the modules required for architecture construction.

[0009] The release subsystem is at least used to upload the compilation process files of the architecture module to a predetermined directory for storage after the architecture module is successfully compiled; and to synchronize the architecture module compilation information to the architecture project members.

[0010] Optionally, the review subsystem is specifically used for at least:

[0011] In response to the review request, the module change status associated with each module commit information is determined; if the module change status is a first preset status, the value of the status tag is set to the first preset value; if the module change status is not in the first preset status, the value of the status tag remains unchanged, and a comment is added to the submission to remind the developer to modify the status, and the module change status determination process is retried until the value of the status tag is set to the first preset value.

[0012] After the value of the status label is the first preset value, requests are simultaneously sent to the requirements end, development end, and testing end of the project to perform review and verification on the code content, code writing format, and unit test results respectively; after all the review and verification are passed, the requirements verification label is set to the second preset value through the requirements end, the development verification label is set to the third preset value through the development end, and the test verification label is set to the fourth preset value through the testing end.

[0013] Once the total score of the review verification tag corresponding to any review request reaches the fifth preset value, the merging permission for this code submission is activated, and the developer is notified to merge the code. After the code is merged, the associated module change status is modified to the second preset status, so that the development manager or project manager can check which changes have been submitted and perform code tracking management by filtering changes in the second preset status.

[0014] Optionally, the construction subsystem is specifically used for at least:

[0015] In response to the project development needs, source code compilation can be triggered manually or on a scheduled basis;

[0016] The system retrieves the remote repository code of the corresponding module based on the module code storage location provided in the build file input by the project, and checks whether the version information recorded in the code is consistent with the module version number recorded in the build file. If the versions are inconsistent, the source code file is non-compliant, and the build fails at the end of the current build. If the versions are consistent, the system calls the compilation script to compile the architecture module.

[0017] If the source code fails to compile, extract the error message from the compilation log, lock the module that caused the error, and notify the person in charge of the relevant module.

[0018] If the source code compiles successfully, then based on the build file, the change records of each module required for the architecture are uniformly organized into a software change record file; at the same time, the version numbers recorded in the code of all modules are analyzed, all module versions are recorded and associated with the software version to be released, forming the build list for this build; and, based on the module commit information, the change status of each module required for the architecture is changed to integrated, and the name of the executable file generated this time is written back to the change information for traceability.

[0019] Optionally, the first preset value, the second preset value, the third preset value, and the fourth preset value can be configured to at least 1; the fifth preset value can be configured to at least 4.

[0020] Optionally, the first preset state refers at least to the Inprogress state, and the second preset state refers at least to the Reslove state.

[0021] Optionally, the requirements side is at least subject to the requests of the requirements engineer to review and verify the code content, code writing format, and unit test results respectively;

[0022] The development team is at least subject to the architect's request to review and verify the code content, code writing format, and unit test results.

[0023] The testing side is subject to review and verification of the code content, code format, and unit test results at least upon request from the test engineer.

[0024] Optionally, the project development needs to include at least the need for requirement changes and the need for defect changes.

[0025] Based on the same concept, in a second aspect, the present invention also provides a method for building and managing a multi-module software architecture, wherein the method is executed using the multi-module software architecture building and management system described in any one of the first aspects, the method comprising:

[0026] The development subsystem executes the software architecture module development according to the project files and project development needs, and updates the version number in the module code.

[0027] After any module is developed, the corresponding module commit information is submitted to the remote warehouse management subsystem through the development subsystem. After the remote warehouse management subsystem verifies and approves the module commit information, at least the corresponding module code is uploaded to the remote warehouse management subsystem.

[0028] After the module code is uploaded to the remote warehouse management subsystem, the module information is recorded by the development subsystem to the review subsystem to trigger a review request;

[0029] In response to the review request, the review subsystem verifies the change status of the corresponding module based on the module commit information in each module information.

[0030] After the change status verification of the corresponding module is passed, the review subsystem shall perform at least the requirement review verification, development review verification and test review verification on the corresponding module.

[0031] After all the review and verification are passed, the code merging request is triggered through the review subsystem, and the module commit information of the corresponding module is modified to be compilable.

[0032] In response to the project development needs, the build subsystem pulls the remote repository code of the corresponding module according to the build file and checks the version and module information of each module.

[0033] After all the modules required for architecture construction have passed the checks, the compilation script is triggered by the construction subsystem to compile the architecture modules.

[0034] After the architecture modules are compiled, the build subsystem analyzes the generated log files to verify whether the compilation was successful. If the compilation is successful, the change status of each module required for the architecture construction is modified.

[0035] After the architecture module is successfully compiled, the compilation process files of the architecture module are uploaded to a predetermined directory for storage through the release subsystem, and the compilation information of the architecture module is synchronized to the architecture project members.

[0036] Based on the same concept, in a third aspect, the present invention also provides an electronic device, including a memory and a processor, the memory storing a computer program executable on the processor, wherein the processor, when executing the program, implements the steps of the construction management method for the multi-module software architecture of any one of the second aspects.

[0037] Based on the same concept, in a fourth aspect, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the construction management method for the multi-module software architecture described in any of the second aspects.

[0038] The technical solution provided in this invention, when implementing the construction management of a multi-module software architecture, firstly, executes the development of software architecture modules according to project files and project development needs through a development subsystem, and updates the version number in the module code; further, after the development of any module is completed, the development subsystem submits the corresponding module commit information to the remote warehouse management subsystem, so that after the remote warehouse management subsystem verifies and approves the module commit information, at least the corresponding module code is uploaded to the remote warehouse management subsystem; further, after the module code is uploaded to the remote warehouse management subsystem, the development subsystem records the module information to the review subsystem to trigger a review request; further, in response to the review request, the review subsystem verifies the change status of the corresponding module according to the module commit information in each module information; further, after the change status of the corresponding module is verified, the review subsystem at least executes the corresponding module... The process involves requirement review and verification, development review and verification, and test review and verification. Further, after all reviews and verifications pass, the review subsystem triggers a code merging request and modifies the corresponding module's commit information to compileable. Further, in response to project development needs, the build subsystem pulls the remote repository code for the corresponding module based on the build files and checks the version and module information of each module. Further, after all modules required for architecture construction have passed checks, the build subsystem triggers a compilation script to compile the architecture modules. Further, after the architecture modules are compiled, the build subsystem analyzes the generated log files to verify successful compilation; if successful, the change status of each module required for architecture construction is modified. Finally, after successful architecture module compilation, the release subsystem uploads the architecture module compilation process files to a predetermined directory for storage and synchronizes the architecture module compilation information with architecture project members.

[0039] Therefore, this invention can independently manage each module in a multi-module software architecture, meeting the needs of independent development for each module. The code for each module can be stored in a remote repository (i.e., a remote repository management subsystem), and the module's version information, change records, review records, storage links, and other related information are managed on a unified platform (i.e., a collective term for the development subsystem and the review subsystem). The entire code build process can be deployed on a server, which can retrieve relevant information for each module from the unified platform according to development requirements and complete the code retrieval, compilation, change statistics, and software release processes according to predetermined rules. The build management system provided by this invention can meet the needs of distributed project development and improve development efficiency. Simultaneously, the system can utilize platform tools to make pre-compilation review and checks a necessary pre-compilation process, effectively avoiding invalid compilation and improving compilation efficiency. Furthermore, the system can introduce various script files, which helps improve the automation level of the entire process. In addition, the system supports richer build result outputs, providing more supporting files for subsequent testing, facilitating the troubleshooting and identification of test problems.

[0040] In summary, the build management system provided by the embodiments of the present invention can improve the build efficiency of multi-module architecture software, ensure software traceability, and improve software quality and reliability. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the structure of a multi-module software architecture construction management system provided in an embodiment of the present invention;

[0042] Figure 2 This is an interactive flowchart of a development subsystem and a review subsystem provided in an embodiment of the present invention;

[0043] Figure 3 This is an interactive flowchart of a development subsystem, a review subsystem, and a construction subsystem provided in an embodiment of the present invention;

[0044] Figure 4 This is an interactive flowchart of a development subsystem, a construction subsystem, and a release subsystem provided in an embodiment of the present invention;

[0045] Figure 5 This is a flowchart of a publishing subsystem provided in an embodiment of the present invention;

[0046] Figure 6 This is a flowchart of a construction and management method for a multi-module software architecture provided in an embodiment of the present invention;

[0047] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0050] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0051] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0052] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0053] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0054] It should be noted that any symbols and / or numbers present in the specification that are not marked in the accompanying drawings are not reference numerals.

[0055] Figure 1 This is a schematic diagram of a multi-module software architecture build management system provided by an embodiment of the present invention. This embodiment is at least applicable to build management scenarios for devices and components (such as domain controllers) with multi-module software architectures in various types of vehicles. This multi-module software architecture build management system can be implemented using software and / or hardware. Figure 1 As shown, the multi-module software architecture build management system includes at least a development subsystem 110, a review subsystem 120, a build subsystem 130, a release subsystem 140, and a remote warehouse management subsystem 150.

[0056] The development subsystem 110 establishes connections with the remote warehouse management subsystem 150 and the review subsystem 120, respectively. It is used at least to perform module development of the software architecture according to project documents and project development needs, and to update the version number in the module code. After any module is developed, it submits the corresponding module commit information to the remote warehouse management subsystem 150. After the remote warehouse management subsystem 150 verifies the module commit information, it uploads the corresponding module code to the remote warehouse management subsystem 150. After the module code is uploaded to the remote warehouse management subsystem 150, it records the module information to the review subsystem 120 to trigger a review request.

[0057] The review subsystem 120 is connected to the build subsystem 130. It is used at least to respond to review requests, verify the change status of the corresponding module based on the module commit information in each module information; and, after the change status verification of the corresponding module is passed, to perform requirement review verification, development review verification and test review verification on the corresponding module; and, after all review verifications are passed, to trigger a code merge request and modify the module commit information of the corresponding module to be compileable.

[0058] The build subsystem 130 establishes a connection with the release subsystem 140, at least to respond to project development needs, pull the remote repository code of the corresponding module according to the build file, and check the version and module information of each module; and, after all the modules required for architecture building have passed the check, trigger the compilation script to execute the architecture module compilation; and, after the architecture module compilation is completed, analyze the log file generated by the compilation to verify whether the compilation was successful. If the compilation is successful, modify the change status of each module required for architecture building.

[0059] The release subsystem 140 is used at least to upload the compilation process files of the architecture module to a predetermined directory for storage after the architecture module is successfully compiled; and to synchronize the architecture module compilation information to the architecture project members.

[0060] Taking vehicle domain controllers as an example, their multi-module architecture software often involves independent development by different engineers or even different teams. After development, the software code for these modules needs to be compiled and built on a unified server to obtain the final executable file. Traditional methods of collecting development code via instant messaging tools and email suffer from problems such as untimely submissions, easy omissions, and difficulties in review and management. These problems can lead to errors in the build process or inaccurate build results, rendering the executable file unusable and requiring repeated builds, thus reducing development efficiency.

[0061] In view of this, this embodiment essentially proposes a software development system that integrates remote warehouse management, unified review, automated build and release. This system includes the following core components:

[0062] 1. Remote Repository Management (i.e., warehouse management) Subsystem 150: This subsystem is used to centrally store and manage the development code of each module, supporting concurrent access by multiple users and version control. After completing their development tasks locally, developers can push the code to the remote repository and record the current module's version information and the source of changes (such as requirement changes, defect changes, etc.) according to the required format. The remote repository can be accessed by the build server to automatically trigger the build process.

[0063] 2. Unified Review Platform (which may consist of the aforementioned development subsystem 110 and review subsystem 120): This platform provides a centralized management system, capable of managing the development cycle of each module, including code submission, review, and status tracking. After submitting code to the remote repository, developers must create a submission record on the unified review platform, supplementing information such as module version, change history, and change source, and setting it to a pending review status. Relevant engineers (such as requirements engineers, test engineers, and architects) review the submission, and the review results update the submission status. The platform also manages project requirements and test records, ensuring that each development effort meets project requirements and avoiding unnecessary or illegal development content.

[0064] 3. Automated Build Platform (which can consist of the aforementioned build subsystem 130 and release subsystem 140): Deployable on a dedicated server, it includes a complete build engineering environment. Based on the submission status on the unified review platform, it automatically selects approved submissions for build execution. It can also extract submission information (such as repository address, module version, and change history) and check code version consistency. Furthermore, it calls the compiler to compile the code, generate executable files, and create software change log files, build manifests, and release notes, which are then uploaded to a designated directory for storage. Simultaneously, it modifies the associated change status and records the name of the executable file associated with this change, achieving bidirectional traceability between artifacts and changes. The build results can be fed back to engineers via instant messaging tools. Upon success, the build artifacts are sent to the release engineer for artifact release.

[0065] In one specific implementation, optionally, the review subsystem 120 is at least specifically used for: responding to a review request, judging the module change status associated with each module commit information; if the module change status is a first preset status, setting the value of the status tag to the first preset value; if the module change status is not in the first preset status, keeping the value of the status tag unchanged, adding a comment to the submission to remind the developer to modify the status, and re-triggering the module change status judgment process until the value of the status tag is set to the first preset value; after the value of the status tag is the first preset value, simultaneously requesting the requirements side, development side, and testing side of the project to review the code content, code... Write the format and unit test results for review and verification; after all reviews and verifications pass, set the value of the requirement verification tag to the second preset value through the requirement side, set the value of the development verification tag to the third preset value through the development side, and set the value of the test verification tag to the fourth preset value through the testing side; when the total score of the review verification tags corresponding to any review request reaches the fifth preset value, activate the merging permission for this code submission and notify the developers to merge the code; after the code is merged, change the status of the associated module to the second preset status so that the development manager or project manager can check which changes have been committed and perform code tracking management by filtering changes in the second preset status.

[0066] In another specific implementation, optionally, the build subsystem 130 is at least specifically used for: manually triggering source code compilation or triggering source code compilation on a scheduled basis in response to project development needs; pulling the remote repository code of the corresponding module according to the module code storage location provided by the build file input by the project, and checking whether the version information recorded in the code is consistent with the module version number recorded in the build file; if the versions are inconsistent, the source code file is non-compliant, the build ends, and the build fails; if the versions are consistent, the compilation script is called to execute the architecture module compilation; if the source code compilation fails, the error information is extracted from the compilation log and the error module is locked, and the relevant module owner is notified; if the source code compilation is successful, the change records of the modules required for each architecture build are uniformly organized into a software change record file based on the build file; at the same time, the version numbers recorded in all module code are analyzed, all module versions are recorded and associated with the software version to be released, forming the build list for the current build; and, according to the module commit information, the change status of the modules required for each architecture build is changed to integrated, and the name of the executable file generated this time is written back to the change information for traceability.

[0067] In another specific implementation, optionally, the first preset value, the second preset value, the third preset value and the fourth preset value can be configured to at least 1; the fifth preset value can be configured to at least 4.

[0068] In another specific implementation, optionally, the first preset state refers to at least the Inprogress state, and the second preset state refers to at least the Reslove state.

[0069] In another specific implementation, optionally, the requirements side is at least controlled by the requirements engineer's request to review and verify the code content, code writing format, and unit test results respectively; the development side is at least controlled by the architecture engineer's request to review and verify the code content, code writing format, and unit test results respectively; and the testing side is at least controlled by the test engineer's request to review and verify the code content, code writing format, and unit test results respectively.

[0070] In another specific implementation, the project development may optionally include at least the need for requirement changes and the need for defect changes.

[0071] For example, the following section describes the construction and management system of a multi-module software architecture in conjunction with a practical project.

[0072] 1. Development of Subsystem 110:

[0073] Complete the development of module code according to the project development progress (requirement development, requirement changes, defect changes, etc.) and submit the code to the remote warehouse management subsystem 150. Each commit must strictly adhere to the format requirements and must include the module name, change link, and change-id.

[0074] 2. Review Subsystem 120:

[0075] (1) After the developer successfully submits the code, the unified review platform judges the change status associated with the commit; if it is in the Inprogress status, the value of the change_status tag is automatically set to 1; if it is not in the Inprogress status, the "+1 action" is not executed (i.e. the aforementioned value of the change_status tag is set to 1), and a comment is added to the commit to remind the developer to modify the status and re-trigger the change status judgment and "+1 action" until the value of change_status is successfully 1.

[0076] (2) When the value of change_status is 1, the project’s requirements, development and testing managers (i.e. the aforementioned requirements engineer, architecture engineer and test engineer) review and verify the code content, code writing format and unit test results respectively. After the verification is passed, each manager sets the tag value of req_review_result (i.e. the aforementioned requirements verification tag), code_review_result (i.e. the aforementioned development verification tag) and test_review_result (i.e. the aforementioned test verification tag) to 1 respectively.

[0077] (3) When the score of a certain submission (i.e. the total score of the aforementioned review verification tags) reaches 4, the permission to merge the submitted code will be automatically activated, and the developers will be automatically notified to merge the code. After the code is merged, the associated change status will be automatically changed to resolve. The development manager or project manager can filter changes in the resolve status to check which changes have been submitted and track and manage them.

[0078] 3. Construct subsystem 130:

[0079] (1) Source code compilation can be manually or periodically triggered according to project requirements;

[0080] (2) Retrieve the latest module code from the module code storage location provided in the project's build file, and check whether the version information recorded in the code matches the module version number recorded in the build file. If the versions do not match, the source code file is non-compliant, and the build will fail at the end of the current build.

[0081] (3) After the previous step of inspection is passed, the unified review platform can call the compilation script to start compiling the code. If the code compilation fails, the error information is extracted from the compilation log and the error module is locked, and the relevant person in charge is notified (this function can be achieved by writing a script to analyze the compilation results generated by different compilation software and extract relevant information).

[0082] (4) If the source code is successfully compiled, based on the build file, the change records of each module are organized into a software change record file. At the same time, the version numbers recorded in the code of all modules are analyzed, all module versions are recorded and associated with the software version to be released, forming the build list for this build (the generation of the software change record file and the build list can also be completed by script).

[0083] (5) If the source code is successfully compiled, the status of each module's changes is changed to Integrated according to the commit information, and the name of the executable file generated this time is written back to the change information (which can be done through a script) for easy traceability.

[0084] 4. Release Subsystem 140:

[0085] Once the source code compiles successfully, organize the compilation output, upload it to the specified path, and trigger the notification function to inform relevant project members of the compilation information.

[0086] The technical solution provided in this embodiment, when implementing the construction management of a multi-module software architecture, firstly, executes the development of software architecture modules according to project files and project development needs through the development subsystem, and updates the version number in the module code; further, after the development of any module is completed, the development subsystem submits the corresponding module commit information to the remote warehouse management subsystem, so that after the remote warehouse management subsystem verifies and approves the module commit information, at least the corresponding module code is uploaded to the remote warehouse management subsystem; further, after the module code is uploaded to the remote warehouse management subsystem, the development subsystem records the module information to the review subsystem to trigger a review request; further, in response to the review request, the review subsystem verifies the change status of the corresponding module according to the module commit information in each module information; further, after the change status of the corresponding module is verified and approved, the review subsystem at least performs the required actions on the corresponding module. The process involves three stages: review and verification, development review and verification, and test review and verification. Further, after all reviews and verifications pass, the review subsystem triggers a code merge request and modifies the corresponding module's commit information to compileable. Further, in response to project development needs, the build subsystem pulls the remote repository code for the corresponding module based on the build files and checks the version and module information of each module. Further, after all modules required for architecture construction have passed checks, the build subsystem triggers a compilation script to compile the architecture module. Further, after the architecture module compilation is complete, the build subsystem analyzes the generated log files to verify successful compilation; if successful, it modifies the change status of each module required for architecture construction. Finally, after successful architecture module compilation, the release subsystem uploads the compilation process files to a designated directory for storage and synchronizes the architecture module compilation information with architecture project members.

[0087] Therefore, this embodiment can independently manage each module in a multi-module software architecture, meeting the needs of independent development for each module. The code for each module can be stored in a remote repository (i.e., a remote repository management subsystem), and the module's version information, change records, review records, storage links, and other related information are managed on a unified platform (i.e., a collective term for the development subsystem and review subsystem). The entire code build process can be deployed on a server, which can retrieve relevant information for each module from the unified platform according to development requirements and complete the code retrieval, compilation, change statistics, and software release processes according to predetermined rules. The build management system provided in this embodiment can meet the needs of distributed project development and improve development efficiency. Simultaneously, the system can utilize platform tools to make pre-compilation review and checks a necessary process before compilation, effectively avoiding invalid compilation and improving compilation efficiency. Furthermore, the system can introduce various script files to enhance the automation of the entire process. In addition, the system supports richer build result outputs, providing more supporting files for subsequent testing, facilitating the troubleshooting and identification of test issues.

[0088] In summary, the build management system provided in this embodiment can improve the build efficiency of multi-module architecture software, ensure software traceability, and enhance software quality and reliability.

[0089] It should be noted that, Figure 2 This is an interaction flowchart of a development subsystem and a review subsystem provided in an embodiment of the present invention. Figure 3 This is an interactive flowchart of a development subsystem, a review subsystem, and a construction subsystem provided in an embodiment of the present invention. Figure 4 This is an interactive flowchart of a development subsystem, a construction subsystem, and a release subsystem provided in an embodiment of the present invention. Figure 5 This is a flowchart of a publishing subsystem provided in an embodiment of the present invention.

[0090] See Figure 2 Input the project files into the development subsystem (corresponding to...) Figure 2 The development modules shown will undergo code development (i.e.,...) within the development subsystem. Figure 2 In the process of development, version updates, commit information checks, and remote repository submissions, the process involves submitting data to the review subsystem (corresponding to...). Figure 2 (The review module shown) submits a request. Figure 2In the development process, modules are developed according to project documents and project progress (requirement changes, test defects, etc.); in the version update process, the version number in the module code is updated based on the completed module development; in the code repository process, the commit information at the time of submission is checked, and the code is submitted to the remote repository after passing the check; in the remote repository submission process, the module information is recorded and placed in the review subsystem to trigger a review request.

[0091] like Figure 3 As shown, the review subsystem includes change status checks, requirements / development / test reviews (i.e., ... Figure 3 The process includes steps such as review execution, code merging, and change status updates. Figure 3 In the code review process, the change status is checked based on commit information during the change status check step. During the review execution step, different roles review the code quality according to standards in their respective domains. During the code merging step, code merging is automatically triggered based on review results; code merging is not allowed if the review fails. In the change status update step, the change status is modified based on commit information, and the code enters a compileable state. It can be understood that the review subsystem corresponds to... Figure 3 The review module shown corresponds to the development subsystem. Figure 3 The development modules shown correspond to the building subsystems. Figure 3 The compiled module is shown.

[0092] like Figure 4 As shown, construct a subsystem (corresponding to Figure 4 The building blocks shown include code retrieval, version information checking, compilation triggering, compilation result analysis, and output of compiled artifacts (i.e.,...). Figure 4 The steps include product output and status modification. Figure 4 In the code retrieval step, code from the remote repository can be retrieved based on the build file; in the version information check step, the versions of each module can be checked against the build file to ensure they are correct; in the compilation trigger step, after the module version check passes, the compilation script is triggered to execute the compilation; in the compilation result check step, the generated log files can be analyzed to check if the compilation was successful; and in the change status modification step, the associated change status of each module can be modified. It can be understood that the development subsystem corresponds to... Figure 4 The development module shown corresponds to the release subsystem. Figure 4 The publishing module is shown.

[0093] like Figure 5 As shown, the publishing subsystem (corresponding to Figure 5 The published module shown includes steps for uploading compiled output and notifying results. Figure 5In the compilation output upload step, files generated during the compilation process, including executable files and build manifests, can be uploaded to a specified directory for storage. In the result notification step, the compilation and integration information of this code can be notified to project members for use by other colleagues.

[0094] Figure 6 This is a flowchart illustrating a construction management method for a multi-module software architecture provided by an embodiment of the present invention. This embodiment is applicable at least to construction management scenarios for devices and components (such as domain controllers) with multi-module software architectures in various types of vehicles. This construction management method for multi-module software architecture can be, but is not limited to, executed by the construction management system for multi-module software architecture in this embodiment of the present invention as the execution subject. This execution subject can be implemented using software and / or hardware. Figure 6 As shown, the construction and management method of this multi-module software architecture includes at least the following steps:

[0095] S1. The development subsystem performs module development of the software architecture according to the project documents and project development needs, and updates the version number in the module code.

[0096] S2. After any module is developed, submit the corresponding module commit information to the remote warehouse management subsystem through the development subsystem. After the remote warehouse management subsystem verifies and approves the module commit information, at least the corresponding module code will be uploaded to the remote warehouse management subsystem.

[0097] S3. After the module code is uploaded to the remote warehouse management subsystem, the module information is recorded in the review subsystem through the development subsystem to trigger the review request.

[0098] S4. In response to the review request, the review subsystem verifies the change status of the corresponding module based on the module commit information in each module's information.

[0099] S5. After the change status verification of the corresponding module is passed, the review subsystem shall perform at least the requirement review verification, development review verification and test review verification on the corresponding module.

[0100] S6. After all reviews and verifications have passed, trigger a code merge request through the review subsystem and modify the module commit information of the corresponding module to be compileable.

[0101] S7. In response to project development needs, the subsystem pulls the remote repository code of the corresponding module according to the build file and checks the version and module information of each module.

[0102] S8. After all the modules required for architecture construction have passed the check, the compilation script is triggered by the construction subsystem to compile the architecture modules.

[0103] S9. After the architecture modules are compiled, the build subsystem analyzes the log files generated during compilation to verify whether the compilation was successful. If the compilation is successful, the change status of each module required for architecture construction is modified.

[0104] S10. After the architecture module is successfully compiled, the compilation process files of the architecture module are uploaded to a predetermined directory for storage through the release subsystem, and the compilation information of the architecture module is synchronized to the architecture project members.

[0105] Optionally, steps S4 to S6 described above shall at least specifically include:

[0106] (456-1) In response to the review request, the review subsystem judges the module change status associated with each module commit information; if the module change status is the first preset status, the review subsystem sets the value of the status label to the first preset value; if the module change status is not in the first preset status, the review subsystem keeps the value of the status label unchanged, adds a comment to the submission to remind the developer to modify the status, and re-triggers the module change status judgment process until the value of the status label is set to the first preset value.

[0107] (456-2) After the value of the status label is the first preset value, the review subsystem simultaneously requests the requirements end, development end and testing end of the project to review and verify the code content, code writing format and unit test results respectively; after all reviews and verifications are passed, the review subsystem sets the value of the requirement verification label to the second preset value through the requirements end, sets the value of the development verification label to the third preset value through the development end, and sets the value of the test verification label to the fourth preset value through the testing end.

[0108] (456-3) After the total score of the review verification tag corresponding to any review request reaches the fifth preset value, the merge permission for this code submission is activated through the review subsystem, and the developers are notified to merge the code; after the code is merged, the status of the associated module change is modified to the second preset status through the review subsystem, so that the development manager or project manager can check which changes have been submitted and perform code tracking management by filtering changes in the second preset status.

[0109] Optionally, the aforementioned steps S7 to S9 specifically include at least the following:

[0110] (789-1) In response to project development needs, source code compilation is manually triggered or scheduled by building subsystems;

[0111] (789-2) The build subsystem pulls the remote repository code of the corresponding module according to the module code storage location provided by the build file input by the project, and checks whether the version information recorded in the code is consistent with the module version number recorded in the build file; if the versions are inconsistent, the source code file is non-compliant, the build ends and the build fails; if the versions are consistent, the build subsystem calls the compilation script to execute the architecture module compilation.

[0112] (789-3) When the source code compilation fails, the build subsystem extracts the error information from the compilation log and locks the error module, and notifies the person in charge of the relevant module;

[0113] (789-4) When the source code is successfully compiled, the build subsystem uses the build file to organize the change records of the modules required for each architecture into a unified software change record file; at the same time, the build subsystem analyzes the version numbers recorded in the code of all modules, records all module versions and associates them with the software version to be released, forming the build list for this build; and the build subsystem modifies the change status of the modules required for each architecture to be integrated in this build according to the module commit information, and writes back the name of the executable file generated in this build to the change information for traceability.

[0114] Optionally, the first preset value, the second preset value, the third preset value and the fourth preset value can be configured to at least 1; the fifth preset value can be configured to at least 4.

[0115] Optionally, the first preset state refers to at least the Inprogress state, and the second preset state refers to at least the Reslove state.

[0116] Optionally, the requirements side is at least controlled by the requirements engineer's request to review and verify the code content, code writing format, and unit test results respectively; the development side is at least controlled by the architecture engineer's request to review and verify the code content, code writing format, and unit test results respectively; and the testing side is at least controlled by the test engineer's request to review and verify the code content, code writing format, and unit test results respectively.

[0117] Optionally, project development needs to include at least the need for requirement changes and defect changes.

[0118] Therefore, this embodiment can independently manage each module in a multi-module software architecture, meeting the needs of independent development for each module. The code for each module can be stored in a remote repository (i.e., a remote repository management subsystem), and the module's version information, change records, review records, storage links, and other related information are managed on a unified platform (i.e., a collective term for the development subsystem and the review subsystem). The entire code build process can be deployed on a server, which can retrieve relevant information for each module from the unified platform according to development requirements and complete the code retrieval, compilation, change statistics, and software release processes according to predetermined rules. The build management method provided in this embodiment can meet the needs of distributed project development and improve development efficiency. Simultaneously, the method can leverage platform tools to make pre-compilation review and checks a necessary pre-compilation process, effectively avoiding invalid compilation and improving compilation efficiency. Furthermore, various script files can be introduced to enhance the automation of the entire process. In addition, it supports richer build result outputs, providing more supporting documents for subsequent testing, facilitating the troubleshooting and identification of test issues. In summary, the build management method provided in this embodiment can improve the build efficiency of multi-module architecture software, ensure software traceability, and enhance software quality and reliability.

[0119] This embodiment provides an electronic device. Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 7The electronic device 1000 includes a processor 1001 and a memory 1002. The memory 1002 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 1001, the steps in any of the above-mentioned multi-module software architecture construction management methods are performed. Through the above technical solution, the processor 1001 and the memory 1002 are interconnected and communicate with each other via a communication bus and / or other forms of connection mechanism (not shown). The memory 1002 stores a computer program executable by the processor. When the electronic device 1000 is running, the processor 1001 executes the computer program to perform the multi-module software architecture construction management method in any optional implementation of the above embodiments, so as to at least achieve the following functions: The development subsystem performs module development of the software architecture according to project files and project development needs, and updates the version number in the module code; after any module development is completed, the development subsystem submits the corresponding module commit information to the remote warehouse management subsystem, so that after the remote warehouse management subsystem verifies and passes the module commit information, at least the corresponding module code is uploaded to the remote warehouse management subsystem; after the module code is uploaded to the remote warehouse management subsystem, the development subsystem records the module information to the review subsystem to trigger a review request; in response to the review request, the review subsystem, according to each... The module commit information in the module information verifies the change status of the corresponding module. After the change status verification of the corresponding module passes, the review subsystem performs at least requirement review verification, development review verification, and test review verification on the corresponding module. After all review verifications pass, the review subsystem triggers a code merge request and modifies the module commit information of the corresponding module to compileable. In response to project development needs, the build subsystem pulls the remote repository code of the corresponding module according to the build file and checks the version and module information of each module. After all the modules required for architecture construction pass the check, the build subsystem triggers the compilation script to execute the architecture module compilation. After the architecture module is compiled, the build subsystem analyzes the log files generated by the compilation to verify whether the compilation is successful. If the compilation is successful, the change status of each module required for architecture construction is modified. After the architecture module is successfully compiled, the release subsystem uploads the architecture module compilation process files to a predetermined directory for storage and synchronizes the architecture module compilation information with the architecture project members.

[0120] This embodiment provides a computer-readable storage medium storing a computer program. When executed by a processor, the program implements the multi-module software architecture construction management method provided in all embodiments of this application: A development subsystem performs module development of the software architecture according to project files and project development needs, and updates the version number in the module code; after any module development is completed, the development subsystem submits the corresponding module commit information to the remote warehouse management subsystem, so that after the remote warehouse management subsystem verifies the module commit information, at least the corresponding module code is uploaded to the remote warehouse management subsystem; after the module code is uploaded to the remote warehouse management subsystem, the development subsystem records the module information to the review subsystem to trigger a review request; in response to the review request, the review subsystem verifies the change status of the corresponding module according to the module commit information in each module information; and verifies the change status of the corresponding module. After approval, the review subsystem performs at least requirement review verification, development review verification, and test review verification on the corresponding module. Once all reviews and verifications pass, the review subsystem triggers a code merge request and modifies the module commit information of the corresponding module to compileable. Responding to project development needs, the build subsystem pulls the remote repository code of the corresponding module based on the build file and checks the version and module information of each module. After all modules required for architecture construction have passed checks, the build subsystem triggers a compilation script to compile the architecture module. After the architecture module compilation is complete, the build subsystem analyzes the generated log files to verify successful compilation; if successful, it modifies the change status of each module required for architecture construction. After successful architecture module compilation, the release subsystem uploads the architecture module compilation process files to a designated directory for storage and synchronizes the architecture module compilation information with architecture project members.

[0121] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0122] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0123] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0124] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A construction and management system for a multi-module software architecture, characterized in that, It includes at least a development subsystem, a review subsystem, a build subsystem, a release subsystem, and a remote warehouse management subsystem; The development subsystem establishes connections with the remote warehouse management subsystem and the review subsystem, respectively, and is at least used to perform module development of the software architecture according to project documents and project development needs, and update the version number in the module code; and, after the development of any module is completed, submits the corresponding module commit information to the remote warehouse management subsystem, so that after the remote warehouse management subsystem verifies and approves the module commit information, at least the corresponding module code is uploaded to the remote warehouse management subsystem; Additionally, after the module code is uploaded to the remote warehouse management subsystem, the module information is recorded in the review subsystem to trigger a review request; The review subsystem is connected to the build subsystem and is used at least to respond to the review request by verifying the change status of the corresponding module based on the module commit information in each module information; and, after the change status verification of the corresponding module is passed, to perform at least requirement review verification, development review verification, and test review verification on the corresponding module; and, after all the review verifications are passed, to trigger a code merge request and modify the module commit information of the corresponding module to be compileable. The build subsystem establishes a connection with the release subsystem and is at least used to respond to the project development needs by pulling the remote repository code of the corresponding module according to the build file and checking the version and module information of each module; and after all the modules required for architecture construction have passed the check, triggering the compilation script to execute the architecture module compilation; and after the architecture module compilation is completed, analyzing the log file generated by the compilation to verify whether the compilation was successful, and if the compilation was successful, modifying the change status of each of the modules required for architecture construction. The publishing subsystem is at least used to upload the compilation process files of the architecture module to a predetermined directory for storage after the architecture module is successfully compiled. In addition, the compilation information of the architecture modules is synchronized with the architecture project members.

2. The construction and management system for the multi-module software architecture according to claim 1, characterized in that, The review subsystem is specifically used for at least: In response to the review request, the module change status associated with each module commit information is determined; if the module change status is a first preset status, the value of the status label is set to the first preset value. If the module change status is not in the first preset status, the value of the status tag remains unchanged, and a comment is added to the submission to remind the developer to modify the status and re-trigger the module change status judgment process until the value of the status tag is set to the first preset value. After the value of the status label is the first preset value, requests are simultaneously sent to the requirements end, development end, and testing end of the project to perform review and verification on the code content, code writing format, and unit test results respectively; after all the review and verification are passed, the requirements verification label is set to the second preset value through the requirements end, the development verification label is set to the third preset value through the development end, and the test verification label is set to the fourth preset value through the testing end. Once the total score of the review verification tags corresponding to any of the review requests reaches the fifth preset value, the merge permission for this code submission is activated, and the developer is notified to merge the code. After the code is merged, the associated module change status is modified to a second preset status, so that the development manager or project manager can check which changes have been committed and perform code tracking management by filtering changes in the second preset status.

3. The construction and management system for the multi-module software architecture according to claim 1, characterized in that, The construction subsystem is specifically used for at least: In response to the project development needs, source code compilation can be triggered manually or on a scheduled basis; Based on the module code storage location provided in the build file input by the project, pull the remote repository code of the corresponding module and check whether the version information recorded in the code is consistent with the module version number recorded in the build file; If the versions are inconsistent, the source code files are non-compliant, and the build will fail at the end of the current build. If the versions are consistent, the compilation script will be called to compile the architecture module. If the source code fails to compile, extract the error message from the compilation log, lock the module that caused the error, and notify the person in charge of the relevant module. If the source code compiles successfully, then based on the build file, the change records of each module required for the architecture are uniformly organized into a software change record file; at the same time, the version numbers recorded in the code of all modules are analyzed, all module versions are recorded and associated with the software version to be released, forming the build list for this build; and, based on the module commit information, the change status of each module required for the architecture is changed to integrated, and the name of the executable file generated this time is written back to the change information for traceability.

4. The construction and management system for the multi-module software architecture according to claim 2, characterized in that, The first preset value, the second preset value, the third preset value, and the fourth preset value can be configured to at least 1; the fifth preset value can be configured to at least 4.

5. The construction and management system for the multi-module software architecture according to claim 2, characterized in that, The first preset state refers at least to the Inprogress state, and the second preset state refers at least to the Reslove state.

6. The construction and management system for the multi-module software architecture according to claim 2, characterized in that, The requirements are at least controlled by the requirements engineer's request to review and verify the code content, code writing format, and unit test results respectively. The development team is at least subject to the architect's request to review and verify the code content, code writing format, and unit test results. The testing side is subject to review and verification of the code content, code format, and unit test results at least upon request from the test engineer.

7. The construction and management system for the multi-module software architecture according to claim 1, characterized in that, The project development needs to include at least the need for requirement changes and defect changes.

8. A method for building and managing a multi-module software architecture, characterized in that, The method is executed using a build management system based on the multi-module software architecture of any one of claims 1-7, the method comprising: The development subsystem executes the software architecture module development according to the project files and project development needs, and updates the version number in the module code. After any module is developed, the corresponding module commit information is submitted to the remote warehouse management subsystem through the development subsystem. After the remote warehouse management subsystem verifies and approves the module commit information, at least the corresponding module code is uploaded to the remote warehouse management subsystem. After the module code is uploaded to the remote warehouse management subsystem, the module information is recorded by the development subsystem to the review subsystem to trigger a review request; In response to the review request, the review subsystem verifies the change status of the corresponding module based on the module commit information in each module information. After the change status verification of the corresponding module is passed, the review subsystem shall perform at least the requirement review verification, development review verification and test review verification on the corresponding module. After all the review and verification are passed, the code merging request is triggered through the review subsystem, and the module commit information of the corresponding module is modified to be compilable. In response to the project development needs, the build subsystem pulls the remote repository code of the corresponding module according to the build file and checks the version and module information of each module. After all the modules required for architecture construction have passed the checks, the compilation script is triggered by the construction subsystem to compile the architecture modules. After the architecture modules are compiled, the build subsystem analyzes the generated log files to verify whether the compilation was successful. If the compilation is successful, the change status of each module required for the architecture construction is modified. After the architecture module is successfully compiled, the compilation process files of the architecture module are uploaded to a predetermined directory for storage through the release subsystem, and the compilation information of the architecture module is synchronized to the architecture project members.

9. An electronic device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the construction and management method of the multi-module software architecture of claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps in the construction and management method of the multi-module software architecture of claim 8.

Images