A DevOps integrated management system, method, device and medium

Abstract

The application discloses a DevOps integrated management system, method, device and medium, and relates to the technical field of computer software. The system comprises: an application management module for managing the whole life cycle of an application; a requirement branch management module for managing the whole life cycle of a requirement branch; a pipeline deployment module for triggering a pipeline task for a code branch in response to a code change event; a quality threshold mechanism module for quality checking of the code branch at a key link; when the checking does not meet the standard, the current process is terminated and code modification and resubmission are triggered; and a dependency management module for establishing a dependency relationship between the application and a dependency item and detecting the network connection state between the two, and generating a dependency alarm information when the network connection state meets a preset abnormal condition. Through the technical scheme, the whole-process automation, standardization and refinement management of research and development, deployment and quality control can be realized.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to an integrated DevOps management system, method, device and medium. Background Technology

[0002] As software development evolves towards agility and microservices, enterprises commonly adopt a development model of parallel iteration across multiple projects and collaborative deployment across multiple environments. The DevOps (a combination of Development and Operations) framework has been widely introduced to improve delivery efficiency and system stability. Currently, the industry typically uses a combination of GitLab, Jenkins, SonarQube, and a simple self-developed backend to build basic DevOps capabilities, enabling functions such as code hosting, pipeline building, and basic code inspection. However, existing solutions still have significant drawbacks: First, application management lacks a unified entry point, with application creation, information maintenance, and access control scattered across different tools, leading to inconsistencies and lax access control. Second, requirement management and code branch management are fragmented, with branches typically relying on manual creation and association, lacking automated synchronization and outdated warning mechanisms, easily causing merge conflicts and difficulties in version tracing. Third, the deployment process lacks mandatory closed-loop constraints, making it difficult to automatically synchronize code changes to multiple environments, resulting in frequent version inconsistencies between environments. Fourth, quality control measures are weak, lacking mandatory entry mechanisms such as unavoidable unit test coverage, static code inspection, and code review, allowing defective code to easily enter the production environment. Fifth, the dependencies between microservices lack systematic modeling and connectivity inspection capabilities, making it difficult to detect and locate dependency failures in a timely manner, affecting the overall stability of the system.

[0003] The aforementioned issues have resulted in current DevOps practices still heavily relying on manual operations, lacking sufficient automation, exhibiting poor process coordination, and failing to meet enterprises' comprehensive requirements for R&D delivery efficiency, code quality, and system stability. Therefore, providing a solution to these technical problems is a problem that those skilled in the art need to address. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide an integrated DevOps management system, method, device, and medium, applicable to scenarios involving application lifecycle management, requirement branch management, pipelined deployment, quality control, and dependency management. It enables automated, standardized, and refined management of the entire process of R&D, deployment, and quality control, significantly improving R&D and deployment efficiency, reducing the risks of manual operation, and ensuring software development quality and system stability. The specific solution is as follows: In a first aspect, this application discloses an integrated DevOps management system, comprising: The application management module is used to generate a unique application identifier in response to an application creation request, and to perform full lifecycle management of the target application based on the application identifier; The requirement branch management module is used to receive requirement information selected from the requirement management platform and pull the code branch corresponding to the requirement information; establish the association between the requirement information and the code branch, and perform full lifecycle management of the requirement information based on the association; and associate the requirement information with the corresponding application identifier in the application management module. The pipeline deployment module is used to respond to code change events generated by the requirement branch management module to trigger pipeline tasks for the code branch; the pipeline tasks include packaging the code branch, deploying the packaged file to the target environment, initiating testing, and determining whether to deploy to the production environment based on the test results; The quality threshold mechanism module is used to perform quality checks on the code branch at preset stage nodes in the pipeline task; when the check fails, the current process of the pipeline deployment module is terminated, and feedback is sent to the requirement branch management module to trigger code modification and resubmission. The dependency management module is used to establish the dependency relationship between the target application and the dependency item, and to detect the network connectivity status between the target application and the dependency item based on the dependency relationship. When the network connectivity status meets the preset abnormal conditions, a dependency alarm message is generated. The dependency item includes other applications and / or target components.

[0005] Optionally, the application management module includes: An application creation unit is used to receive basic application information input by the user; initialize and create the target application based on the basic application information, and generate a unique application identifier; and associate and store the application identifier with the basic application information in the platform database. The information update unit is used to respond to the user's modification or supplementation of the application basic information and configuration information of the target application, synchronize and update the corresponding information in the platform database in real time, and push information update notifications to users with relevant permissions. The permission management unit is used to set the permission scope of different roles based on the role-based access control mechanism, so as to manage the permissions of the target application and to allocate, modify and revoke the permission scope.

[0006] Optionally, the requirement branch management module includes: The branch retrieval unit is used to receive requirement information selected from the requirement management platform and associate the requirement information with the corresponding application identifier in the application management module; retrieve the code branch corresponding to the requirement information according to the preset branch naming rules, and associate the requirement information with the code branch and store it in the platform database; The change tracking unit is used to monitor code change events of the code branch in real time and record the change content, the person making the change, and the change time of the code change event to generate a branch change log; The branch reminder unit is used to periodically compare the code differences between the code branch and the main branch. When the code branch is detected to be lagging behind the main branch to a preset threshold, a lagging reminder message is automatically pushed to the branch manager. The branch merging unit is used to respond to user-initiated branch merging requests to merge the code branch into the main branch or other code branches; automatically detect merging conflicts during the merging process, and when a merging conflict is detected, handle it using a preset conflict resolution strategy or push a conflict reminder for manual intervention; and record the merging result after the merging is completed.

[0007] Optionally, the pipeline deployment module includes: The packaging unit is used to package the target code branch when a code change trigger signal is received, so as to generate a package file and record the packaging information; wherein, the code change trigger signal includes a user-manual trigger signal and a branch change automatic trigger signal; The environment deployment unit is used to receive the packaged file, automatically complete the deployment of at least one environment in the development environment, testing environment and production environment according to the preset environment configuration, and push the deployment result notification after the deployment is completed. The testing unit is used to respond to testing requests initiated by developers, and after associating with the target code branch and its corresponding packaged file, push testing notifications to testers. The testing and verification unit is used to receive the test results from the testers. If the test passes, it triggers the production environment deployment process. If the test fails, it pushes a test failure notification to the developers to trigger code modification and resubmission, and restarts the packaging unit.

[0008] Optionally, the pipeline deployment module further includes: The process enforcement constraint unit is used to force the pipeline task to be re-executed completely from the code packaging stage when the code change event is detected.

[0009] Optionally, the quality threshold mechanism module includes: The unit test coverage verification unit is used to pre-set multiple unit test coverage thresholds for each application, including thresholds for class coverage, method coverage, line coverage, and branch coverage. During the code packaging process, it automatically detects the unit test coverage of the current code branch and compares the detection result with the unit test coverage thresholds. If any dimension fails to meet the standard, the code packaging process is terminated and a coverage failure reminder is pushed. The static code inspection unit is used to call the static code inspection tool to perform static inspection on the current code branch during the code packaging process, and determine whether the inspection result is qualified according to the preset inspection rules; if the inspection is unqualified, the code packaging process is terminated and a static inspection exception report is pushed. The code review unit is used to set up a mandatory code review process before starting the testing unit, in order to respond to code review requests and designate reviewers; if the current code branch passes the review, the testing request is allowed to be initiated; if the current code branch fails the review, the review comments are pushed and fed back to the requirement branch management module to trigger code modification and resubmission until the review is passed.

[0010] Optionally, the dependency management module includes: The dependency relationship input unit is used to receive the dependency relationship between the target application and the dependency item entered by the user, and store it in the platform database after associating it with the dependency item identifier to generate a dependency relationship graph. A network connectivity checking unit is used to automatically check the network connectivity between the target application and the dependency item in response to the input or change operation of the dependency relationship according to the dependency relationship graph, and generate a connectivity checking report. The timed detection and alarm unit is used to automatically detect the network connectivity according to a preset detection cycle, and generate dependent alarm information when the network connectivity status meets preset abnormal conditions.

[0011] Secondly, this application discloses an integrated DevOps management method, including: In response to an application creation request, a unique application identifier is generated, and the target application is managed throughout its entire lifecycle based on the application identifier. Receive requirement information selected from the requirement management platform and pull the code branch corresponding to the requirement information; establish the association between the requirement information and the code branch, and perform full lifecycle management of the requirement information based on the association; Monitor code change events of the code branch to trigger pipeline tasks for the code branch; the pipeline tasks include packaging the code branch, deploying the packaged file to the target environment, initiating testing, and determining whether to deploy to the production environment based on the test results; At a preset stage node in the pipeline task, the code branch is subjected to quality verification; if the verification fails, the current process is terminated, and the code branch is modified and resubmitted. Establish the dependency relationship between the target application and the dependency, and detect the network connectivity status between the target application and the dependency based on the dependency relationship. Generate dependency alarm information when the network connectivity status meets preset abnormal conditions; wherein, the dependency includes other applications and / or target components.

[0012] Thirdly, this application discloses an electronic device, which includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the aforementioned DevOps integrated management method.

[0013] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the aforementioned DevOps integrated management method.

[0014] The beneficial effects of this application are as follows: 1. Unified management of the entire application lifecycle can integrate all daily management aspects such as application creation, information updates, and permission management, avoiding efficiency losses caused by tool switching, ensuring consistent application information and strict permission control, and improving the standardization and efficiency of application management. 2. Enhance the automation level of requirement branch management: Seamlessly integrate with the requirement management platform, automatically pull requirement information and establish the relationship between requirement information and code branches, so that requirements and code branches maintain a corresponding relationship during the development process. Based on the relationship, the full lifecycle management of requirement information can realize real-time tracking of branch changes, automatic reminders of lagging branches, and automatic handling of simple merge conflicts, reducing manual intervention, reducing the risk of merge errors, and achieving traceable and efficient branch management. 3. Build a closed-loop pipeline deployment module: realize a complete pipeline from branch packaging, environment deployment, testing to production launch; 4. Strengthen code quality control: Embed the quality threshold mechanism module into the pipeline deployment module and give it the decision-making power to control whether to continue execution. Clearly defining the termination of the current process when verification fails means that low-quality code cannot bypass quality checks and enter subsequent testing or production environments. Controlling code quality from the source reduces online failures, lowers R&D and maintenance costs, and improves software product reliability. 5. Implement systematic dependency management: accurately record the dependency relationships between applications and between applications and basic components, monitor network connectivity in real time, detect and alert on a regular basis, avoid system failures caused by dependency anomalies, and improve system stability and maintainability; 6. Integrated and Collaborative System: Deeply integrate application management, branch management, deployment process, quality control, and dependency management. Data from each module is interconnected to form a collaborative management and control system. This breaks down the fragmented barriers of existing DevOps tools, reduces the connection costs between various stages, and improves the overall collaboration, stability, and efficiency of R&D deployment. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the architecture of an integrated DevOps management system disclosed in this application; Figure 2 This is a schematic diagram of an application management module structure disclosed in this application; Figure 3 This is a schematic diagram of the structure of a requirement branch management module disclosed in this application; Figure 4 This is a schematic diagram of a pipeline deployment module structure disclosed in this application; Figure 5 This is a schematic diagram of a quality threshold mechanism module structure disclosed in this application; Figure 6 This is a schematic diagram of a dependency management module structure disclosed in this application; Figure 7 This application discloses a flowchart of an integrated DevOps management method. Figure 8 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] With the expansion of software development scale and the acceleration of iteration speed, the DevOps concept has been widely applied in the software development field. Its core lies in achieving efficient collaboration across development, testing, and deployment stages, breaking down barriers between these stages. Currently, various DevOps-related tools exist for application management, code branch management, deployment process management, etc. However, these tools are often independent, lacking a unified integration platform, and have significant shortcomings in quality control and dependency management, resulting in the following technical deficiencies: 1. Fragmented application management: Existing application management tools can only cover some aspects of the application lifecycle and cannot achieve unified control over the entire process of application creation, information updates, and permission management. Different tools need to be switched at different stages, which is inefficient and prone to problems such as inconsistent information and lax permission control. 2. Inefficient branch management: Existing branch management tools often require manual connection to the requirement platform (such as TAPD (Tencent Agile Product Development) platform) to pull branches. Branch change tracking is not timely, lagging branches cannot be automatically reminded, branch merging requires manual operation, and merging conflict handling depends on developers to resolve manually, which is time-consuming and labor-intensive, and is prone to merging errors that lead to code exceptions. 3. Inconsistent deployment process: Existing deployment tools are unable to achieve a complete pipeline loop from branch packaging and environment deployment to testing and production deployment. After code changes, manual triggering of each step is required, which cannot ensure that code changes are synchronized to each environment in a timely manner. Furthermore, issues such as process omissions and environment inconsistencies are prone to occur, affecting the progress of R&D iteration. 4. Lack of quality control: Existing DevOps tools lack a sound quality threshold mechanism, making it impossible to effectively control code quality in key stages such as packaging and testing. Insufficient unit test coverage, potential problems in static code, and code that has not undergone code review can still enter the subsequent deployment process, which can easily lead to online failures and increase R&D and maintenance costs. 5. Disorganized dependency management: Existing technologies lack systematic management of dependencies between applications and between applications and basic components. They cannot accurately record dependencies and dependent relationships, nor can they monitor the network connectivity of dependencies in real time. They cannot provide timely alerts when dependencies are abnormal, which can easily lead to the paralysis of the entire system due to dependency failures and affect system stability.

[0019] Furthermore, existing technologies lack an integrated platform that deeply integrates application lifecycle management, requirement branch lifecycle management, pipelined deployment processes, quality threshold mechanisms, and dependency management. Poor coordination among these stages and excessive manual intervention result in low R&D deployment efficiency, high error rates, unreliable quality, and insufficient system stability, failing to meet the high-efficiency, high-quality management requirements of large-scale software development. Therefore, there is an urgent need for an integrated DevOps management platform that can address these technological shortcomings.

[0020] To address the technical shortcomings of existing DevOps tools, such as fragmentation, poor collaboration, excessive manual intervention, low efficiency, and lack of a sound quality control and dependency management mechanism, this application provides an integrated DevOps management solution. This solution enables deep integration of the entire application lifecycle, the entire requirement branch lifecycle, pipeline deployment processes, quality threshold control, and dependency management. It automates the operation of each stage, reduces manual intervention, improves R&D deployment efficiency, reduces operational risks, and ensures code quality and system stability.

[0021] This application discloses an integrated DevOps management system, such as... Figure 1 As shown, the system includes: Application management module 11 is used to generate a unique application identifier in response to an application creation request, and to perform full lifecycle management of the target application based on the application identifier.

[0022] In this embodiment, the application management module is the core of the system's foundational data, responsible for providing unified application metadata to all other modules. This module is configured to provide unified management and control over the entire lifecycle of software applications, from creation to deregistration, covering all aspects of daily application management, including at least three core dimensions: application creation, information maintenance, and access control. Through this module, the system generates a unique application identifier for each managed application. This identifier serves as the application's globally unique identity credential within the system, permeating the entire data chain of the requirement branch management module, pipeline deployment module, and dependency management module, and is crucial for achieving data interoperability and collaborative operation between modules.

[0023] Specifically, when a user initiates a management request for a target application through the platform interface, the application management module first completes the initial creation of the application, assigns it a unique application identifier, and persists it. Subsequently, all subsequent activities of the application, including pulling requirement branches (which require specifying the application), packaging and deploying code (which requires associating with the target application), configuring quality thresholds (which require setting coverage thresholds independently for each application), and entering dependencies (which requires establishing topology connections based on the application identifier), all use its unique application identifier as the association index. Any changes to application information are automatically pushed to relevant authorized users by the platform, ensuring that the application information used in each stage is consistent and synchronized in real time.

[0024] The requirement branch management module 12 is used to receive requirement information selected from the requirement management platform and pull the code branch corresponding to the requirement information; establish the association between the requirement information and the code branch, and perform full lifecycle management of the requirement information based on the association; and associate the requirement information with the corresponding application identifier in the application management module.

[0025] In this embodiment, the requirement branch management module is the core hub connecting the requirement management platform (such as TAPD) and the code repository. It is configured to establish data interfacing with the requirement management platform, enabling fully automated association and bidirectional traceability between software development requirements and code branches. Based on business requirement documents in the requirement management platform, this module automatically parses metadata such as requirement number, requirement title, project, and responsible person, and automatically performs operations such as branch retrieval, change tracking, lagging alerts, and branch merging. This ensures that each business requirement forms a strong association with its corresponding code branch from the outset, thereby achieving full lifecycle management of requirement branches from retrieval to merging. This breaks the traditional manual binding model of requirements and branches, eliminating the problems of requirement-branch disconnect and error-prone manual association in traditional development models.

[0026] In the workflow, the requirement branch management module associates the application identifier provided by the application management module to determine the application context to which the branch belongs. The branch information and change status generated by it will be transmitted to the pipeline deployment module as a trigger signal, driving the automatic execution of the subsequent packaging and deployment process. At the same time, the review results of the quality threshold mechanism module in the code review stage are also fed back to the developers through this module, forming a closed-loop control.

[0027] It should be noted that in this embodiment, a two-way linkage and traceability capability between requirement information and code branches is established: on the one hand, users can start from a requirement item in the requirement management platform and trace back to its associated code branch, branch development progress, commit records, and merging status; on the other hand, users can also start from a code branch and query its associated requirement, requirement priority, and business scope. This completely solves the problems of requirement and branch disconnection, chaotic association, difficulty in version traceability, and easy errors and omissions in manual binding under the traditional method, and realizes a strong, traceable, and controllable full-link binding between R&D requirements and code branches.

[0028] The pipeline deployment module 13 is used to respond to code change events generated by the requirement branch management module to trigger pipeline tasks for the code branch; the pipeline tasks include packaging the code branch, deploying the packaged file to the target environment, initiating testing, and determining whether to deploy to the production environment based on the test results.

[0029] In this embodiment, the module is configured to respond to code change events generated by the requirement branch management module, automatically triggering and executing the complete pipeline process from code packaging to environment deployment. Through standardized and automated process design, this module solidifies the entire chain operation from branch to multi-environment deployment into a repeatable pipeline, ensuring the standardization, consistency, and traceability of the R&D delivery process.

[0030] Specifically, code change events include at least user-triggered events (such as branch code commits and branch merges) and automatic triggering events due to branch changes. Any code change falling under any of these categories will be detected by the requirement branch management module and transmitted as a trigger signal to the pipeline deployment module, initiating a complete pipeline execution cycle.

[0031] This module forms an embedded collaborative control relationship with the quality threshold mechanism module: during the pipeline packaging stage, the pipeline execution permission is controlled by the verification results of the quality threshold mechanism module. If the verification passes, the pipeline continues; if it fails, the pipeline is terminated and feedback is sent to the requirement branch management module to trigger code modifications. Simultaneously, the execution results of this module (such as the deployment completion status of each environment and the test pass status) can serve as a prerequisite for the dependency management module to perform connectivity monitoring. Therefore, the pipeline deployment module plays a pivotal role in the integrated collaborative management system of this invention.

[0032] The quality threshold mechanism module 14 is used to perform quality verification on the code branch at a preset stage node in the pipeline task; when the verification fails, the current process of the pipeline deployment module is terminated and feedback is sent to the requirement branch management module to trigger code modification and resubmission.

[0033] In this embodiment, this module is a mandatory quality control node configured between the packaging and testing stages of the pipeline deployment module. Its core function is to set mandatory, unavoidable, multi-dimensional quality entry thresholds along the critical path of code flow from the development stage to the testing and production environments, constructing an automated code quality checkpoint blocking system, which differs from the traditional model of manual inspection without mandatory constraints. Based on the verification results, it outputs two types of control signals: a pass signal, allowing the pipeline deployment module to continue executing subsequent packaging, environment deployment, and testing processes; and a block signal, immediately terminating the current pipeline execution and reporting non-compliance quality information to the requirement branch management module to trigger code modification and resubmission.

[0034] The dependency management module 15 is used to establish the dependency relationship between the target application and the dependency item, and to detect the network connectivity status between the target application and the dependency item based on the dependency relationship, and to generate dependency alarm information when the network connectivity status meets preset abnormal conditions; wherein, the dependency item includes other applications and / or target components.

[0035] In this embodiment, the module is used to realize the systematic modeling of dependencies between applications and between applications and basic components, and the observability of network connectivity. Its overall functional positioning includes: input and storage of dependencies, network connectivity inspection capability, and real-time alarm of abnormal status.

[0036] It's important to note that this module doesn't operate in isolation; rather, it collaborates with other modules within the system at the data and process levels. For example, at the data level, the dependency management module uses unique application identifiers generated and maintained by the application management module to identify each node in the dependency relationship. Each application and basic component uses its application identifier or component identifier as its unique identity in the dependency graph, ensuring that the entry, query, modification, and deletion of dependencies accurately correspond to the specific application in the application's entire lifecycle management, avoiding dependency confusion caused by changes in application information. Simultaneously, the recorded dependency direction (dependent / depended on) is stored in association with the application identifier, forming a complete bidirectional dependency topology. At the process level, the network connectivity check in this module can be configured as a pre-validation condition for the pipeline deployment module. That is, before the pipeline deployment module executes deployment operations, it can trigger the dependency management module to perform an immediate network connectivity check on all dependencies of the current application. If an anomaly is found in the dependency link, the pipeline can be configured to pause or block, preventing system failures after deployment due to dependency unavailability. In addition, the generated dependency alarm information can be accurately pushed to the responsible person based on the information set in the permission management unit in the application management module, ensuring that the fault information reaches the responsible person in a timely manner.

[0037] The beneficial effects of this application are as follows: 1. Unified management of the entire application lifecycle can integrate all daily management aspects such as application creation, information updates, and permission management, avoiding efficiency losses caused by tool switching, ensuring consistent application information and strict permission control, and improving the standardization and efficiency of application management. 2. Enhance the automation level of requirement branch management: Seamlessly integrate with the requirement management platform, automatically pull requirement information and establish the relationship between requirement information and code branches, so that requirements and code branches maintain a corresponding relationship during the development process. Based on the relationship, the full lifecycle management of requirement information can realize real-time tracking of branch changes, automatic reminders of lagging branches, and automatic handling of simple merge conflicts, reducing manual intervention, reducing the risk of merge errors, and achieving traceable and efficient branch management. 3. Build a closed-loop pipeline deployment module: realize a complete pipeline from branch packaging, environment deployment, testing to production launch; 4. Strengthen code quality control: Embed the quality threshold mechanism module into the pipeline deployment module and give it the decision-making power to control whether to continue execution. Clearly defining the termination of the current process when verification fails means that low-quality code cannot bypass quality checks and enter subsequent testing or production environments. Controlling code quality from the source reduces online failures, lowers R&D and maintenance costs, and improves software product reliability. 5. Implement systematic dependency management: accurately record the dependency relationships between applications and between applications and basic components, monitor network connectivity in real time, detect and alert on a regular basis, avoid system failures caused by dependency anomalies, and improve system stability and maintainability; 6. Integrated and Collaborative System: Deeply integrate application management, branch management, deployment process, quality control, and dependency management. Data from each module is interconnected to form a collaborative management and control system. This breaks down the fragmented barriers of existing DevOps tools, reduces the connection costs between various stages, and improves the overall collaboration, stability, and efficiency of R&D deployment.

[0038] In a preferred embodiment, such as Figure 2 As shown, the application management module 11 further includes: The application creation unit 11a is used to receive application basic information input by the user; initialize and create the target application based on the application basic information, and generate a unique application identifier; and associate the application identifier with the application basic information and store it in the platform database.

[0039] This unit receives basic application information input by the user, which includes at least the application name, application type, project name, and responsible person information. After the user fills in the above information through the platform's front-end interface, the application creation unit performs format validation and integrity checks on the information. If the validation passes, the application initialization and creation process is executed. Specifically, the application creation unit generates a globally unique application identifier according to preset encoding rules, associates this identifier with the application basic information input by the user to form a complete application record, and persistently stores it in the platform database through the data interaction interface.

[0040] In one feasible implementation, after creation is complete, the application creation unit can return a creation success message and the application identifier of the target application to the submitting user, and can also broadcast a notification of application addition to the user. This application identifier will then serve as the associated primary key for all operations of the target application within the platform (such as branch pulling, packaging and deployment, dependency entry, etc.), ensuring that operations of each module can be traced back to a specific application entity.

[0041] The information update unit 11b is used to respond to the user's modification or supplementation of the application basic information and configuration information of the target application, to update the corresponding information in the platform database in real time, and to push information update notifications to users with relevant permissions.

[0042] This unit supports users with appropriate permissions to modify or supplement the basic and configuration information of created applications. After a user submits an information update request through the platform interface, the information update unit first verifies whether the user has editing permissions for the target application. If the permission verification is successful, the unit receives the update content, performs the data update operation, and synchronizes the updated application information to the platform database in real time to ensure information consistency. At the same time, it pushes information update notifications to relevant users with permissions for the application (including but not limited to the application owner, project administrator, and other users with viewing permissions for the application) so that relevant users are promptly informed of changes to the application information and avoid collaboration discrepancies caused by information asynchrony.

[0043] The permission management unit 11c is used to set the permission scope of different roles based on the role-based access control mechanism, so as to manage the permissions of the target application and to allocate, modify and revoke the permission scope.

[0044] This unit employs a role-based access control (RBAC) mechanism to achieve fine-grained permission control for application-level operations. It pre-defines various roles, including but not limited to administrators, developers, testers, and operations personnel. Each role is assigned different scopes of operational permissions, enabling permission control for operations such as viewing, editing, deleting, and deploying applications. It supports the allocation, modification, and revocation of permissions, ensuring the security of application management.

[0045] For example, the administrator role has full permissions to create, edit, delete, and assign permissions to applications; the developer role has permissions to view, edit, and initiate deployments of the applications they are responsible for, but does not have the right to delete applications or modify permission configurations; the tester role has permissions to view applications and submit test results, but does not have the right to modify application configurations or perform deployment operations.

[0046] In various business scenarios on the platform, when a user attempts to perform operations such as viewing, editing, deleting, or deploying applications, the permission management unit performs real-time authentication of the user's role and the scope of their permissions. Only if the user has the corresponding permissions will the operation be allowed to proceed; otherwise, an insufficient permission response is returned, and an abnormal operation log is recorded. This mechanism ensures the security of application data and prevents the risk of information leakage or misoperation due to unauthorized operations.

[0047] In summary, the application management module integrates all daily management aspects such as application creation, information updates, and permission management, achieving unified control over the entire application lifecycle. This avoids efficiency losses caused by tool switching, ensures consistent application information and rigorous permission control, and improves the standardization and efficiency of application management.

[0048] In a preferred embodiment, such as Figure 3 As shown, the demand branch management module 12 further includes: Branch retrieval unit 12a is used to receive requirement information selected from the requirement management platform and associate the requirement information with the corresponding application identifier in the application management module; retrieve the code branch corresponding to the requirement information according to the preset branch naming rules, and associate the requirement information with the code branch and store it in the platform database.

[0049] This unit is configured to receive requirement information selected by the user from the requirement management platform, such as requirement number, requirement title, project, and responsible person. The branch retrieval unit automatically creates and retrieves the code branch corresponding to the requirement information according to the enterprise's preset branch naming rules. Simultaneously, it establishes a bidirectional association between the requirement information and the branch information and stores it in the platform database, forming a globally unique mapping relationship between requirement and branch. This association remains effective during subsequent change tracking, merging, and tracing processes.

[0050] It should be noted that when a user pulls a code branch through the requirement branch management module, the branch pull unit must first reference the application identifier created in the application management module to determine the application context to which the branch belongs. The branch naming rules also include the components of the application identifier or application name to ensure that a traceable association is formed between the branch and the application.

[0051] The change tracking unit 12b is used to monitor code change events of the code branch in real time and record the change content, the person making the change, and the change time of the code change event to generate a branch change log.

[0052] This unit is configured to monitor code change events on pulled code branches in real time. These code change events include, but are not limited to, code commits, modifications, and deletions. The change tracking unit automatically records the content, person making the change, and time of each change, forming an immutable branch change log, including commit history and version evolution. Users can query branch change history by time range, person making the change, branch name, and other multi-dimensional search criteria. Through this logging mechanism, the traceability of the entire branch change lifecycle is achieved, providing data support for version rollback, issue localization, and audit compliance.

[0053] The branch reminder unit 12c is used to periodically compare the code differences between the code branch and the main branch. When the code branch is detected to be lagging behind the main branch to a preset threshold, a lagging reminder message is automatically pushed to the branch manager.

[0054] This unit is configured to periodically traverse all active business development branches at configurable time intervals (e.g., daily or every few hours), automatically comparing code commit records, version nodes, and code differences between each development branch and the main branch to intelligently determine the degree of lag of the current code branch relative to the main branch. When the detected lag of a code branch behind the main branch reaches a preset threshold, the branch reminder unit automatically triggers multi-channel message alerts, pushing lag reminder information including the number of lagging commits, the range of code differences, and the baseline of the version to be synchronized to the branch owner and project administrator, reminding relevant personnel to synchronize the main branch code in a timely manner. This mechanism effectively reduces problems such as large-scale merge conflicts, version inconsistencies, and deployment delays caused by long-term branch lag by identifying potential large-scale merge conflict risks in advance.

[0055] The branch merging unit 12d is used to respond to a branch merging request initiated by a user, so as to merge the code branch into the main branch or other code branches; automatically detect merge conflicts during the merging process, and when a merge conflict is detected, handle it using a preset conflict resolution strategy or push a conflict reminder for manual intervention; and record the merging result after the merging is completed.

[0056] This unit is configured to respond to user-initiated branch merge requests, which specify at least a source branch and a target branch (e.g., merging a feature branch into the main branch, or merging into another specified target branch). During the merge operation, the branch merge unit automatically detects merge conflicts that occur and adopts a tiered handling strategy based on the complexity of the conflicts. In one specific implementation, for simple merge conflicts (such as duplicate lines of code, variable definition conflicts, etc.), the branch merge unit uses a preset conflict resolution strategy (such as retaining the latest modifications and merging code according to rules) to handle them automatically without manual intervention; In another specific implementation, when the branch merging unit cannot automatically resolve complex conflicts involving changes in logical structure or adjustments to cross-file dependencies, it pushes conflict alerts to relevant developers for manual intervention.

[0057] After the merge operation is completed, the branch merge unit records the merge results (including merge time, merge personnel, conflict handling methods, etc.) and updates the branch status synchronously (e.g., marking it as merged).

[0058] In summary, the requirement branch management module improves the automation level of requirement branch management: it seamlessly integrates with the requirement management platform, automatically pulls requirement branches, tracks branch changes in real time, automatically alerts lagging branches, automatically handles simple merge conflicts, reduces manual intervention, lowers the risk of merge errors, and achieves traceability and efficiency in branch management.

[0059] In a preferred embodiment, such as Figure 4 The pipeline deployment module 13 shown further includes: Packaging unit 13a is used to package the target code branch when a code change trigger signal is received, so as to generate a package file and record packaging information; wherein, the code change trigger signal includes a user-manual trigger signal and a branch change automatic trigger signal.

[0060] This unit, acting as the starting node of the pipeline, is configured to receive code change trigger signals (including manual triggering by users and automatic triggering by branch changes) and perform code packaging operations on the target code branch where the change occurred. During the packaging process, the packaging unit automatically calls the quality threshold mechanism module to perform quality verification. Only when all quality verification dimensions meet the standards will the packaging unit generate the packaged file and record packaging information such as packaging time, packaging version, packaging personnel, and branch information, and then push the packaged file to the environment deployment unit. If any quality verification dimension fails to meet the standards, the current process of the pipeline deployment module is terminated, and it will restart after the requirement branch management module sends a code modification completion signal. The verification process of the quality threshold mechanism module will be described in detail in subsequent embodiments and will not be repeated here.

[0061] Environment deployment unit 13b is used to receive the packaged file, automatically complete the deployment of at least one environment among the development environment, testing environment and production environment according to the preset environment configuration, and push the deployment result notification after the deployment is completed.

[0062] This unit is configured to support deployment operations in multiple environments (including at least development, testing, and production environments). After receiving the packaged files pushed by the packaging unit, it automatically completes the deployment of the corresponding environment according to the user's pre-set environment configuration for each environment, and pushes the deployment result notification to the relevant users after the deployment is completed.

[0063] The testing unit 13c is used to respond to the testing request initiated by the developer, and after associating it with the target code branch and its corresponding packaged file, push the testing notification to the testers.

[0064] This unit allows developers to initiate test requests, associate the target code branch with its corresponding packaged file, and push test notifications to testers to start the test verification process. It also synchronizes relevant test information (including test scope, test requirements, packaged file path, etc.).

[0065] The test verification unit 13d is used to receive the test results fed back by the testers. If the test passes, the production environment deployment process is triggered. If the test fails, a test failure notification is pushed to the developers to trigger code modification and resubmission, and the packaging unit is restarted.

[0066] This unit is configured to receive test results (pass / fail) from testers. If the test result is pass, the production environment deployment process is triggered, and the environment deployment unit completes the final deployment of the production environment according to the production environment configuration. If the test result is fail, a test failure notification is pushed to the developers, reminding them to modify the code. After the code is modified, the packaging unit is triggered again, and the entire deployment process is re-executed from the packaging stage.

[0067] The process enforcement constraint unit 13e is used to force the pipeline task to be re-executed completely from the code packaging stage when the code change event is detected.

[0068] This unit incorporates a built-in process constraint mechanism, stipulating that every code change event (including branch code modification, merging, etc.) automatically triggers the packaging unit and forces a complete pipeline process to be re-executed from the packaging unit. This means fully experiencing the standardized, closed-loop DevOps pipeline from code branch → packaging → development environment deployment → testing → test environment deployment → production environment deployment. This mechanism prohibits any human intervention such as skipping the packaging step, skipping a certain environment deployment, or directly deploying to the production environment. Through this strong process constraint mechanism, it ensures that every code change is fully synchronized to the development, testing, and production environments, strictly guaranteeing code version consistency across multiple environments and the standardization of deployment processes. It eliminates problems such as environment version differences, missed deployments, and non-standard processes caused by manual step-by-step deployment, achieving a standardized, automated, strongly constrained, and fully closed-loop R&D delivery process.

[0069] In summary, the pipeline deployment module is used to achieve a complete closed-loop pipeline from branch packaging, deployment to the development environment, submission for testing, deployment to the testing environment, successful testing, to deployment to the production environment. Code changes automatically trigger a full re-execution of the entire process, ensuring code consistency across environments, avoiding process omissions and human error, significantly improving R&D deployment efficiency, and shortening iteration cycles.

[0070] In a preferred embodiment, such as Figure 5 As shown, the quality threshold mechanism module 14 further includes: The unit test coverage verification unit 14a is used to pre-set multiple unit test coverage thresholds for each application, including thresholds for class coverage, method coverage, line coverage, and branch coverage. During the code packaging process, it automatically detects the unit test coverage of the current code branch and compares the detection result with the unit test coverage thresholds. If any dimension fails to meet the standard, the code packaging process is terminated and a coverage failure reminder is pushed.

[0071] This unit is used to perform unit test coverage checks on the current code branch during the packaging process startup phase. Specifically, this unit allows users to preset unit test coverage thresholds for each application, including thresholds for four dimensions: class coverage, method coverage, line coverage, and branch coverage. When the packaging unit of the pipeline deployment module is triggered, the system automatically calls the application's unit test suite to execute tests and collects coverage data after the test runs.

[0072] It should be noted that the unit test coverage verification unit supports configuring thresholds for each dimension independently for each application. The storage of threshold configurations is indexed by the application identifier. Therefore, during the packaging process, this unit needs to query and load the corresponding quality threshold configuration based on the application identifier associated with the current packaging branch.

[0073] The verification logic is as follows: The collected coverage values ​​for the four dimensions are compared with the application's preset thresholds for the four dimensions. If all four dimensions meet or exceed the preset thresholds, the unit outputs a verification pass result, and the pipeline proceeds to the next verification stage. If any dimension fails to meet the threshold, the unit immediately outputs a verification fail result, terminates the packaging process, and pushes a coverage failure reminder, specifying the dimension that failed and the current coverage value, reminding developers to optimize the unit test, and re-triggering the pipeline after the code is modified.

[0074] The static code inspection unit 14b is used to call the static code inspection tool to perform static inspection on the current code branch during the code packaging process, and to determine whether the inspection result is qualified according to the preset inspection rules; if the inspection is unqualified, the code packaging process is terminated and a static inspection exception report is pushed.

[0075] This unit integrates the Sonar static code analysis tool to perform automated static analysis on the current code branch during the packaging process. The static analysis covers multiple dimensions, including syntax error detection, potential security vulnerability identification, code redundancy assessment, and coding style violation checks. During execution, this unit determines the compliance of the inspection results according to preset inspection rules. If the inspection is satisfactory, the packaging process continues; if it fails, the packaging process is terminated, a static code analysis anomaly report is sent, clearly stating the violation and rectification suggestions; the process can only continue after the code rectification is completed and packaging is retried.

[0076] Code review unit 14c is used to set up a mandatory code review process before starting the testing unit, in order to respond to code review requests and designate reviewers; if the current code branch passes the review, the testing request is allowed to be initiated; if the current code branch fails the review, the review comments are pushed and fed back to the requirement branch management module to trigger code modification and resubmission until the review is passed.

[0077] Before initiating the testing process, this unit sets up a mandatory code review stage to ensure that the code entering the testing phase has undergone manual review. Specifically, before the pipeline deployment module reaches the testing stage, the system automatically checks whether the current code branch has passed code review. If a review has not yet been initiated or the review status is "failed," the testing request is suspended, and the pipeline enters a waiting state.

[0078] Developers can submit code review requests through the system, specifying relevant reviewers (such as technical leads and senior developers). Reviewers will assess the readability, code quality, security, and logical soundness of the code, and submit their review results (pass / fail) along with comments in the system. A test submission request can only be initiated when the review result is "pass." If the review result is "fail," review comments will be sent to the developers, reminding them to modify and optimize the code. After modification, they must resubmit the review request until it is approved before initiating a test submission.

[0079] In summary, this invention sets up mandatory, unavoidable multi-layered quality entry thresholds at the pipeline packaging nodes, constructing an automated code quality checkpoint blocking system, which differs from the traditional model of only manual inspection without mandatory constraints. It includes three layers of rigid entry control: 1) Multi-dimensional unit test coverage thresholds: Supports customizable thresholds for four indicators—class coverage, method coverage, line coverage, and branch coverage—configured independently for each application. Test coverage data is automatically collected during the packaging process; if any indicator fails to meet the standard, the packaging process is automatically terminated, and a detailed list of non-compliance is provided; 2) Sonar static code inspection entry: Deeply integrates Sonar static code scanning capabilities, pre-sets verification rules for code style, security vulnerabilities, code smells, and redundant code. If the scan results do not meet the entry standards, packaging is directly blocked, and a problem list and rectification suggestions are output; 3) Mandatory code review before testing: Code review is a mandatory step before testing. Branches that have not completed review or have failed review cannot initiate the testing process, preventing low-quality and non-compliant code from entering the testing and production environments from the process mechanism. This mechanism enables configurable quality thresholds, mandatory process checkpoints, and automatic blocking for non-compliance, controlling code quality from the source of compilation and packaging, reducing online failures, lowering R&D and maintenance costs, and improving the reliability of software products.

[0080] In a preferred embodiment, such as Figure 6 As shown, the dependency management module 15 further includes: The dependency relationship input unit 15a is used to receive the dependency relationship between the target application and the dependency item entered by the user, and store it in the platform database after associating it with the dependency item identifier to generate a dependency relationship graph.

[0081] This unit is configured to provide an interface for inputting and maintaining dependencies. It allows users to manually input other applications and basic components that the current application depends on, clearly defining the dependency direction (dependent and dependent), and automatically associating them with the corresponding application and component identifiers in the application management module. The input dependencies are persistently stored in the platform database after format validation, forming a complete dependency graph. The platform also provides visualization and retrieval functions for the graph, allowing users to query the upstream and downstream dependencies of a specific application, as well as modify or delete existing dependencies.

[0082] The network connectivity checking unit 15b is used to automatically check the network connectivity between the target application and the dependency item in response to the input or change operation of the dependency relationship according to the dependency relationship graph, and generate a connectivity checking report.

[0083] This unit is configured to perform a connectivity verification of all dependencies immediately upon dependency entry or modification, based on the dependency graph stored in the dependency entry unit. Specifically, starting from the current application, this unit sends network probe signals to each dependency (including other applications and basic components), checking metrics including at least network reachability, link latency, and port connectivity status. After the check is complete, the unit generates a connectivity check report, identifying dependencies with normal and abnormal connectivity. The core function of this checking unit is to verify dependency configurations in real time, preventing erroneous or unreachable dependencies from being entered into the system and entering the subsequent deployment process.

[0084] The timed detection and alarm unit 15c is used to automatically detect the network connectivity according to a preset detection cycle, and generate dependent alarm information when the network connectivity status meets preset abnormal conditions.

[0085] This unit is configured to perform 24 / 7 background periodic checks on stored dependencies. The platform allows users to independently configure the detection period for each dependency (e.g., once per minute, hour, or day) based on the importance of different applications or the sensitivity of dependency chains. The unit then automatically probes the network connectivity between applications and dependencies according to the preset detection period, with its core function being continuous monitoring rather than one-time verification. When network connectivity anomalies are detected (e.g., inability to connect, excessive latency), dependency alarm information is immediately pushed to relevant personnel (e.g., application owners, operations personnel), clearly identifying the abnormal application, abnormal dependency, anomaly type, and detection time, facilitating timely troubleshooting and preventing system failures due to dependency connectivity anomalies. This timed detection mechanism transforms the observability of dependency chains from reactive post-event investigation to proactive pre-event warning, significantly improving the system's fault detection speed and availability assurance capabilities.

[0086] In summary, the dependency management module features a unique bidirectional dependency management system between applications and between applications and basic components. It supports visual and manual input of the bidirectional topology relationships between various business applications and between business applications and common basic components, middleware, and basic services, automatically generating a global dependency graph and storing it persistently. This module possesses fully automated network connectivity inspection capabilities, automatically detecting network reachability, link latency, and port connectivity status between the current application and all its dependencies. It supports customizable timed detection cycles and 24 / 7 uninterrupted background inspection. Once anomalies such as network interruptions, connectivity timeouts, or unreachable ports are detected in dependency links, alarm pushes are immediately triggered, accurately locating abnormal applications, abnormal dependent components, and faulty links. This enables dependency modeling, link status detection, and automatic alarm alerts for abnormal faults, solving the pain points of chaotic dependencies, untimely detection of link faults, and difficulty in troubleshooting in microservice architectures.

[0087] Accordingly, embodiments of the present invention disclose an integrated DevOps management method, such as... Figure 7 As shown, the method includes: Step S11: In response to the application creation request, generate a unique application identifier and perform full lifecycle management of the target application based on the application identifier; Step S12: Receive requirement information selected from the requirement management platform and pull the code branch corresponding to the requirement information; establish the association between the requirement information and the code branch, and perform full lifecycle management of the requirement information based on the association; Step S13: Monitor the code change events of the code branch to trigger a pipeline task for the code branch; the pipeline task includes packaging the code branch, deploying the packaged file to the target environment, initiating testing, and determining whether to deploy to the production environment based on the test results; Step S14: At a preset stage node in the pipeline task, perform quality verification on the code branch; if the verification fails, terminate the current process and trigger the modification and resubmission of the code branch; Step S15: Establish the dependency relationship between the target application and the dependency, and detect the network connectivity status between the target application and the dependency based on the dependency relationship. When the network connectivity status meets the preset abnormal conditions, generate dependency alarm information; wherein, the dependency includes other applications and / or target components.

[0088] For more detailed processing procedures regarding the above steps, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0089] Furthermore, embodiments of this application also disclose an electronic device, Figure 8 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of protection of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the DevOps integrated management method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be a computer.

[0090] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0091] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it can include an operating system 221, computer programs 222, and data 223, etc. The data 223 can include various types of data. The storage method can be temporary storage or permanent storage.

[0092] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including computer programs capable of performing the DevOps integrated management method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0093] Furthermore, this application also discloses a computer-readable storage medium, which includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, optical disks, or any other form of storage medium known in the art. The computer program, when executed by a processor, implements the aforementioned DevOps integrated management method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0094] Furthermore, embodiments of this application also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements any of the above-described DevOps integrated management methods.

[0095] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0096] The steps of the DevOps integrated management method or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly using hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0097] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0098] The above provides a detailed description of the DevOps integrated management system, method, device, and medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A DevOps integrated management system, characterized in that, include: The application management module is used to generate a unique application identifier in response to an application creation request, and to perform full lifecycle management of the target application based on the application identifier; The requirement branch management module is used to receive requirement information selected from the requirement management platform and pull the code branch corresponding to the requirement information; Establish the association between the requirement information and the code branch, and perform full lifecycle management of the requirement information based on the association; and associate the requirement information with the corresponding application identifier in the application management module; The pipeline deployment module is used to respond to code change events generated by the requirement branch management module to trigger pipeline tasks for the code branch; the pipeline tasks include packaging the code branch, deploying the packaged file to the target environment, initiating testing, and determining whether to deploy to the production environment based on the test results; The quality threshold mechanism module is used to perform quality verification on the code branch at preset stage nodes in the pipeline task. If the verification fails, the current process of the pipeline deployment module is terminated, and feedback is sent to the requirement branch management module to trigger code modification and resubmission; The dependency management module is used to establish the dependency relationship between the target application and the dependency item, and to detect the network connectivity status between the target application and the dependency item based on the dependency relationship. When the network connectivity status meets the preset abnormal conditions, a dependency alarm message is generated. The dependency item includes other applications and / or target components.

2. The DevOps integrated management system according to claim 1, characterized in that, The application management module includes: An application creation unit is used to receive basic application information input by the user; initialize and create the target application based on the basic application information, and generate a unique application identifier; and associate and store the application identifier with the basic application information in the platform database. The information update unit is used to respond to the user's modification or supplementation of the application basic information and configuration information of the target application, synchronize and update the corresponding information in the platform database in real time, and push information update notifications to users with relevant permissions. The permission management unit is used to set the permission scope of different roles based on the role-based access control mechanism, so as to manage the permissions of the target application and to allocate, modify and revoke the permission scope.

3. The DevOps integrated management system according to claim 1, characterized in that, The demand branch management module includes: The branch retrieval unit is used to receive requirement information selected from the requirement management platform and associate the requirement information with the corresponding application identifier in the application management module; retrieve the code branch corresponding to the requirement information according to the preset branch naming rules, and associate the requirement information with the code branch and store it in the platform database; The change tracking unit is used to monitor code change events of the code branch in real time and record the change content, the person making the change, and the change time of the code change event to generate a branch change log; The branch reminder unit is used to periodically compare the code differences between the code branch and the main branch. When the code branch is detected to be lagging behind the main branch to a preset threshold, a lagging reminder message is automatically pushed to the branch manager. The branch merging unit is used to respond to user-initiated branch merging requests to merge the code branch into the main branch or other code branches; automatically detect merging conflicts during the merging process, and when a merging conflict is detected, handle it using a preset conflict resolution strategy or push a conflict reminder for manual intervention; and record the merging result after the merging is completed.

4. The DevOps integrated management system according to claim 1, characterized in that, The pipeline deployment module includes: The packaging unit is used to package the target code branch when a code change trigger signal is received, so as to generate a package file and record the packaging information; wherein, the code change trigger signal includes a user-manual trigger signal and a branch change automatic trigger signal; The environment deployment unit is used to receive the packaged file, automatically complete the deployment of at least one environment in the development environment, testing environment and production environment according to the preset environment configuration, and push the deployment result notification after the deployment is completed. The testing unit is used to respond to testing requests initiated by developers, and after associating with the target code branch and its corresponding packaged file, push testing notifications to testers. The testing and verification unit is used to receive the test results from the testers. If the test passes, it triggers the production environment deployment process. If the test fails, it pushes a test failure notification to the developers to trigger code modification and resubmission, and restarts the packaging unit.

5. The DevOps integrated management system according to claim 4, characterized in that, The pipeline deployment module also includes: The process enforcement constraint unit is used to force the pipeline task to be re-executed completely from the code packaging stage when the code change event is detected.

6. The DevOps integrated management system according to claim 4, characterized in that, The quality threshold mechanism module includes: The unit test coverage verification unit is used to pre-set multiple unit test coverage thresholds for each application, including thresholds for class coverage, method coverage, line coverage, and branch coverage. During the code packaging process, it automatically detects the unit test coverage of the current code branch and compares the detection result with the unit test coverage thresholds. If any dimension fails to meet the standard, the code packaging process is terminated and a coverage failure reminder is pushed. The static code inspection unit is used to call the static code inspection tool to perform static inspection on the current code branch during the code packaging process, and determine whether the inspection result is qualified according to the preset inspection rules; if the inspection is unqualified, the code packaging process is terminated and a static inspection exception report is pushed. The code review unit is used to set up a mandatory code review process before starting the testing unit, in order to respond to code review requests and designate reviewers; if the current code branch passes the review, the testing request is allowed to be initiated; if the current code branch fails the review, the review comments are pushed and fed back to the requirement branch management module to trigger code modification and resubmission until the review is passed.

7. The DevOps integrated management system according to claim 1, characterized in that, The dependency management module includes: The dependency relationship input unit is used to receive the dependency relationship between the target application and the dependency item entered by the user, and store it in the platform database after associating it with the dependency item identifier to generate a dependency relationship graph. A network connectivity checking unit is used to automatically check the network connectivity between the target application and the dependency item in response to the input or change operation of the dependency relationship according to the dependency relationship graph, and generate a connectivity checking report. The timed detection and alarm unit is used to automatically detect the network connectivity according to a preset detection cycle, and generate dependent alarm information when the network connectivity status meets preset abnormal conditions.

8. A DevOps integrated management method, characterized in that, include: In response to an application creation request, a unique application identifier is generated, and the target application is managed throughout its entire lifecycle based on the application identifier. Receive requirement information selected from the requirement management platform and pull the code branch corresponding to the requirement information; Establish the association between the requirement information and the code branch, and perform full lifecycle management of the requirement information based on the association; Monitor code change events on the code branch to trigger pipeline tasks for the code branch; The pipeline tasks include packaging the code branch, deploying the packaged file to the target environment, initiating testing, and determining whether to deploy to the production environment based on the test results. In the preset stage nodes of the pipeline task, the code branch is quality checked; If the verification fails, terminate the current process and trigger the modification and resubmission of the code branch. Establish the dependency relationship between the target application and the dependency, and detect the network connectivity status between the target application and the dependency based on the dependency relationship. Generate dependency alarm information when the network connectivity status meets preset abnormal conditions; wherein, the dependency includes other applications and / or target components.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the DevOps integrated management method as described in claim 8.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein the computer programs, when executed by a processor, implement the DevOps integrated management method as described in claim 8.

Images