Decision method, device, storage medium and product for blue-green release of application software

Abstract

The application discloses a decision method, device, storage medium and product for application software blue-green release. The method comprises the following steps: obtaining second JIRA identifiers of various requirements associated with a first JIRA identifier of a release version of application software; establishing an association relationship between the requirements and deployed service engineering on a CI / CD pipeline corresponding to the release version and based on an association relationship between the requirements extracted based on the second JIRA identifiers and the service engineering; constructing a graph model based on the first JIRA identifier, the second JIRA identifier and the association relationship between the requirements and the deployed service engineering; generating an initial release strategy of each service engineering based on attribute configuration information and historical blue-green release information of each service engineering in the graph model; determining a blocking point in a blue-green release process of the application software based on the initial release strategy of each service engineering in the graph model, and updating an actual release strategy of the requirements in the graph model based on the blocking point.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a decision-making method, device, storage medium, and product for blue-green deployment of application software. Background Technology

[0002] In software development and operations practices, continuous integration / continuous delivery (CI / CD) has become a core process for ensuring rapid software iteration and stable release. In a CI / CD environment, blue-green deployment, as a zero-downtime deployment strategy, maintains two identical production environments (blue for the currently running older version and green for the new version to be released). This allows for the release of a new version without impacting existing users, achieving a smooth transition to the new version and a rapid rollback of the old version. It is widely used in scenarios with high service availability requirements.

[0003] As cloud computing users place increasingly higher demands on the stability and reliability of cloud services, better implementation of blue-green deployments has become crucial. However, not all software requirements are suitable for blue-green deployment strategies. Traditional methods rely on human experience for judgment, necessitating a new approach to address the blue-green deployment evaluation problem. Summary of the Invention

[0004] In view of this, embodiments of this application provide a decision-making method, device, storage medium, and product for blue-green deployment of application software, aiming to improve the success rate and efficiency of blue-green deployment of application software.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a decision-making method for blue-green deployment of application software, including: Obtain the second JIRA identifier for various associated requirements based on the first JIRA (Project and Transaction Tracking Tool) identifier of the application software release version; Based on the service projects already deployed in the continuous integration / continuous delivery (CI / CD) pipeline corresponding to the release version and the association between requirements and service projects extracted based on each second JIRA identifier, establish the association between requirements and deployed service projects; A graph model is constructed based on the first JIRA identifier, the second JIRA identifier, and the relationship between the requirement and the deployed service engineering. Based on the attribute configuration information and historical blue-green deployment information of each service project in the graph model, an initial deployment strategy for each service project is generated. Based on the initial release strategy of each service project in the graph model, the blocking points in the blue-green deployment process of the application software are determined, and the actual release strategy of the requirements in the graph model is updated based on the blocking points.

[0006] In the above scheme, the construction of a graph model based on the first JIRA identifier, the second JIRA identifier, and the association between the requirement and the deployed service project includes: A first node indicating the release version is created based on the first JIRA identifier; Based on each of the second JIRA identifiers associated with the first JIRA identifier, a second node indicating the requirement is created and associated with the first node; Based on the association between the requirements and the deployed service projects, a third node is created that is associated with the second node and indicates the service projects. Based on the dependency information between each service project, the association relationship between the third nodes is established.

[0007] In the above scheme, generating the initial release strategy for each service project based on the attribute configuration information and historical blue-green deployment information of each service project in the graph model includes: Based on the attribute configuration information of each service project in the graph model, determine the first score value of the current blue-green release for each service project; Based on the historical blue-green release information of each service project, determine the second score of the historical blue-green release of each service project; Based on the first and second scores of each service project and the set weight values, a third score is generated for each service project. Based on the comparison results between the third score of each service project and the set threshold, an initial release strategy for each service project is generated.

[0008] In the above scheme, the blocking point is the third node in the graph model corresponding to the service project whose initial distribution strategy does not support blue-green deployment. Updating the actual deployment strategy of the associated requirements in the graph model based on the blocking point includes: Obtain the target second node in the graph model that is associated with the blocking point, determine the actual release strategy of the requirement corresponding to the target second node as a release strategy that does not support blue-green release, and determine the actual release strategy of the service engineering corresponding to each third node associated with the target second node as a release strategy that does not support blue-green release; until the actual release strategy of all requirements associated with service engineering that does not support blue-green release is updated to a release strategy that does not support blue-green release.

[0009] In the above scheme, before updating the actual release strategy of the associated requirements in the graph model based on the blocking point, the method further includes: The graph model is visualized; wherein the blocking point is displayed in a way that distinguishes it from other third nodes. The blocking points in the graphical model are manually verified.

[0010] The above-described scheme further includes one or more of the following: Based on the newly deployed service project in the continuous integration / continuous delivery pipeline, update the graph model, and based on the attribute configuration information of the newly deployed service project, update the actual release strategy of the requirements associated with the newly deployed service project; Based on the updated target service project already deployed in the continuous integration / continuous delivery pipeline, the initial release strategy of the target service project is updated, and the actual release strategy of the requirements associated with the target service project is updated.

[0011] The method in the above scheme further includes: Based on the actual release strategies of each requirement in the graph model, the release order of service projects and the project list information of the actual release strategies are generated.

[0012] In a second aspect, embodiments of this application provide an electronic device, including: a processor and a memory for storing a computer program capable of running on the processor, wherein, when the processor is used to run the computer program, it executes the steps of the method described in the first aspect of embodiments of this application.

[0013] Thirdly, embodiments of this application provide a computer storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described in the first aspect of embodiments of this application.

[0014] Fourthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect of embodiments of this application.

[0015] The technical solution provided in this application embodiment obtains second JIRA identifiers for various associated requirements based on the first JIRA identifier of the application software release version; establishes a relationship between requirements and deployed service projects based on the service projects already deployed in the CI / CD pipeline corresponding to the release version and the relationship between requirements and service projects extracted based on each second JIRA identifier; constructs a graph model based on the first JIRA identifier, the second JIRA identifier, and the relationship between requirements and deployed service projects; generates an initial release strategy for each service project based on the attribute configuration information and historical blue-green deployment information of each service project in the graph model; determines the blocking points in the application software blue-green deployment process based on the initial release strategies of each service project in the graph model, and updates the actual release strategy of requirements in the graph model based on the blocking points. In this way, blocking points in the application software blue-green deployment process can be automatically identified, and the actual release strategy of requirements in the graph model can be updated based on the blocking points. This enables intelligent identification of requirements that do not meet the blue-green deployment requirements, significantly improving the success rate and efficiency of application software blue-green deployment. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the decision-making method for blue-green deployment of application software in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of the blue-green intelligent decision-making system in the application embodiment of this application; Figure 3 This is a schematic diagram illustrating the process of constructing the graph model in the application embodiments of this application; Figure 4 This is a schematic diagram of the structure of the decision-making device for the application software Blue-Green Release in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0017] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0019] Among related technologies, some solutions focus on optimizing the execution process of blue-green deployments. For example, this involves dynamically controlling traffic allocation based on soft load balancing mechanisms, or using ephemeral nodes in a Kubernetes environment to meet double the resource requirements and ensure a smooth load transition during resource release. Other solutions attempt to evaluate the service performance of upgraded versions, generating assessment information by comparing the differences in request processing between the old and new versions to assist in decision-making regarding deployment. These methods typically evaluate single applications or services and do not fully consider the dependency chains in scenarios involving collaborative changes across multiple applications. In other words, these technologies only focus on the independent deployment process of a single application requirement, lacking the ability to identify and manage the topological dependencies between application requirements, leading to risks in scenarios involving collaborative changes across multiple application requirements. For example, requirement A may be associated with multiple project deployments, including front-end and back-end projects. The project deployments associated with requirement A may also be associated with requirement B, and requirement B may be associated with multiple project deployments. When one project in requirement B cannot perform a blue-green deployment, it is necessary to identify, based on topological dependencies, that requirement A also cannot be blue-green deployed.

[0020] Based on this, in various embodiments of this application, by establishing topological dependencies between application requirements, the bottlenecks in the blue-green deployment process can be identified in advance, transforming "post-event failures" into "pre-event insights," thereby improving the success rate and efficiency of application software blue-green deployment.

[0021] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0022] 1) JIRA: JIRA stands for Project and Issue Tracking Tool. Developed by Atlassian, it's a collaborative tool widely used in software development, project management, defect tracking, requirements gathering, and task approval. In this application, JIRA is used as the core platform for version management, requirements tracking, and task assignment. Each release version corresponds to a primary JIRA identifier (first JIRA identifier), while the various specific requirements contained within that version have their own sub-JIRA identifiers (second JIRA identifiers). Through JIRA identifiers, the system can trace the hierarchical relationships between requirements (such as primary and sub-requirements) and the relationships between requirements and service engineering.

[0023] 2) Blue-Green Deployment: A zero-downtime deployment strategy that maintains two identical production environments (blue and green). When a new version is released, traffic is gradually switched to the new environment (green). If the new version runs stably, traffic is completely switched and the old environment (blue) is abandoned. If a failure occurs, the system quickly rolls back to the old environment. This strategy significantly reduces deployment risk, but not all service projects support blue-green deployment; a comprehensive evaluation based on project attributes, historical performance, and dependencies is necessary.

[0024] 3) Continuous Integration / Continuous Delivery Pipeline (CI / CD Pipeline): This refers to the automated process system for building, testing, and deploying software, covering stages such as code submission, compilation and packaging, automated testing, and deployment. In this application, the CI / CD pipeline is the primary source for obtaining information about deployed service projects. The system establishes a mapping relationship between requirements and projects by parsing the project names packaged and deployed in the pipeline, ensuring the real-time nature and accuracy of the graphical model data.

[0025] 4) Graph Model: The core data structure constructed in this application is used to represent the complex dependencies between requirements, engineering, and release strategies. The graph model consists of multiple nodes and edges. Nodes include release version nodes, requirement nodes, service engineering nodes, and responsible person nodes, while edges represent the relationships between nodes, such as RELATES (version to requirement), IMPACTS (engineering impacts requirements), and DEPENDS_ON (inter-engineer dependencies). This graph model supports global dependency analysis and dynamic updates, forming the foundation for intelligent decision-making.

[0026] 5) Blocking Point: This refers to the node in the graph model corresponding to a service project whose initial deployment strategy does not support blue-green deployment. Since blue-green deployment requires all service projects in the entire dependency chain to support this strategy, if a project cannot perform blue-green deployment, the actual deployment strategies of all its upstream related requirements and associated projects must also be adjusted to not support blue-green deployment, thus creating a blocking effect. Identifying blocking points is a crucial step in achieving global impact analysis.

[0027] 6) Incremental Subgraph Reconstruction: When code is committed or project configuration changes, the system recalculates dependencies and release strategies only for the affected local subgraphs, rather than rebuilding the entire graph model. This mechanism significantly improves system response speed and resource utilization, supporting rapid iteration and dynamic awareness of dependency changes.

[0028] 7) Visual Decision Interface: Provides a graphical user interface for displaying the graph model, allowing users to view dependency chains, mark bottlenecks, and modify project release attributes or dependencies. After modification, the system automatically triggers incremental subgraph reconstruction, updating the release strategy in real time, enabling interactive intelligent decision-making.

[0029] It should be noted that the embodiments of this application can be applied to various software development and operation and maintenance scenarios, and are especially suitable for complex systems with multi-service collaborative deployment, such as cloud computing platforms, large-scale Internet applications, and enterprise-level microservice architectures.

[0030] For example, this application provides a decision-making method for blue-green deployment of application software, applied to an electronic device with data processing capabilities (also known as a decision system or decision platform). See also... Figure 1 The method includes: Step 101: Obtain the second JIRA identifiers of various associated requirements based on the first JIRA identifier of the application software release version.

[0031] Here, a separate JIRA work item can be created in advance for each release version of the application software, and separate JIRA work items can be created for each of the various requirements associated with that release version. JIRA, a project and task tracking tool from Atlassian, is widely used in defect tracking, customer service, requirements gathering, process approval, task tracking, project tracking, and agile management. A JIRA work item refers to a task for tracking and managing a specific project or task. Each JIRA work item has a corresponding JIRA identifier; for example, the first JIRA identifier corresponds to the JIRA work item for the release version, and the second JIRA identifier corresponds to the JIRA work items for each of the various requirements associated with that release version.

[0032] The primary JIRA identifier refers to the main JIRA identifier directly associated with the release version. It is typically created by project managers in the JIRA system to centrally manage all related requirements for that version. As the unique entry point for the version, the primary JIRA identifier traces back to all secondary JIRA identifiers contained within that version. Secondary JIRA identifiers, on the other hand, refer to individual JIRA identifiers for specific requirements related to that version. Each secondary JIRA identifier corresponds to a specific business or functional requirement, such as user login optimization or payment interface upgrades. These requirements may be distributed across different development teams or modules; the primary JIRA identifier aggregates all secondary JIRA identifiers, forming a complete list of version requirements.

[0033] For example, suppose an application plans to release a new version in Q1 of 2025. The project manager creates a version node in JIRA with the primary JIRA identifier VER-2025-Q1. This node is associated with multiple requirements, such as REQ-2025-001 (front-end page reconstruction), REQ-2025-002 (back-end API upgrade), and REQ-2025-003 (database index optimization). These requirements are the secondary JIRA identifiers. The system automatically extracts all secondary JIRA identifiers by parsing the relationships between the primary JIRA identifiers and includes them in the subsequent analysis.

[0034] Electronic devices can obtain version information and associated requirement data by calling the JIRA API interface. In terms of system architecture, the decision-making method of this embodiment can run on cloud servers, local data centers, or containerized environments, possessing high availability and scalability. In actual implementation, the electronic device first identifies the first JIRA identifier of the released version, and then queries all second JIRA identifiers in the JIRA system that are associated with the first JIRA identifier using the BLOCKS or RELATES relationship, ensuring that all relevant second JIRA identifiers are obtained without omission. The technical effect of this step is to achieve automated collection and structured management of version requirements, avoiding errors and omissions from manual processing, and providing an accurate data foundation for subsequent graph model construction.

[0035] Step 102: Based on the service projects already deployed in the CI / CD pipeline corresponding to the release version and the association between requirements and service projects extracted based on each of the second JIRA identifiers, establish the association between requirements and deployed service projects.

[0036] Here, a CI / CD pipeline refers to a complete process system for automating the building, testing, and deployment of software. It is typically triggered by code commits and encompasses multiple stages, including compilation, unit testing, integration testing, packaging, and deployment. In this application, the CI / CD pipeline is the primary source for obtaining information about deployed service projects. By parsing build logs, deployment records, or configuration files within the CI / CD pipeline, key information such as the name, ID, and deployment time of the deployed service project in the current version can be extracted.

[0037] A service project refers to a specific deployable unit that constitutes application software, such as a front-end project, a back-end microservice, or a database service. Each service project typically corresponds to an independent codebase or module and is built and deployed separately in a CI / CD pipeline. The association between a requirement and a service project refers to the set of service projects affected or driven by a particular JIRA identifier. This association can be established through JIRA identifier annotations in code commit records. For example, when a developer commits code in Gerrit, they will indicate the associated JIRA number in the commit message, such as Fix issue #REQ-2025-001. The system can then use this to bind the code change to the REQ-2025-001 JIRA identifier and identify the service projects affected by the code change.

[0038] For example, for the second JIRA identifier REQ-2025-001 (front-end page reconstruction), the system extracts the service project affected by this JIRA identifier from the CI / CD delivery pipeline as FE-001 (front-end project); for the second JIRA identifier REQ-2025-002 (back-end API upgrade), the affected service projects are BE-002 (back-end service) and DB-003 (database service). The system stores these mapping relationships in a graph model, forming the IMPACTS relationship edge between the second JIRA identifier and the service project.

[0039] In practice, the system periodically polls the continuous integration / continuous delivery pipeline to extract the latest deployed service engineering list. It then scans all commit records using the Gerrit code review system, matching the second JIRA identifier with the service engineering name, thus dynamically updating the association between requirements and service engineering corresponding to the second JIRA identifier. The system merges the associations between the project names of deployed service engineerings on the CI / CD pipeline for each release version and the requirements and service engineerings associated with that release version, obtaining the association between requirements and deployed service engineerings. The technical advantage of this step is that it automates and enables real-time management of the mapping relationship between second JIRA identifiers and service engineerings, and obtains the latest deployed service engineering list. Based on the deployment record information of deployed service engineerings on the CI / CD pipeline and the code commit information of each second JIRA identifier associated with the first JIRA identifier, it can deduce and determine the association between requirements and deployed service engineerings, thereby solving the problems of inaccurate, delayed, or omitted dependencies when manually maintained. This provides a data foundation for subsequent graph model construction, ensuring the accuracy and timeliness of the graph model data and providing a reliable basis for subsequent topology dependency analysis.

[0040] Step 103: Construct a graph model based on the first JIRA identifier, the second JIRA identifier, and the association between the requirement and the deployed service engineering.

[0041] Here, the electronic device can construct a graph model based on the first JIRA identifier, the second JIRA identifier, and the association between the requirement and the deployed service engineering. This graph model at least indicates the topological dependencies between distribution versions, various requirements, and service engineering.

[0042] In this embodiment, the graph model includes at least three types of nodes: release versions, requirements, and service projects. A release version can be associated with one or more requirements, and the release of a requirement depends on the release of one or more service projects. Specifically, the release version of the application software packages different types of requirements, such as business requirements, functional requirements, and non-functional requirements. These requirements collectively define the entire capability boundary to be delivered in this version. Requirements cannot be directly deployed; they need to be broken down into different independent service projects, such as front-end, back-end, and middleware. Each project produces a corresponding software package, and the requirement is ultimately implemented by deploying these software packages.

[0043] Step 104: Based on the attribute configuration information and historical blue-green release information of each service project in the graph model, generate the initial release strategy for each service project.

[0044] Here, after constructing a graph model, the electronic device can generate an initial release strategy for each service project based on its attribute configuration information and historical blue-green release information. This initial release strategy indicates whether a service project supports blue-green releases. Attribute configuration information refers to the pre-configured attribute parameters for a service project indicating whether it supports blue-green releases. For example, attribute configuration information includes, but is not limited to, one or more of the following: service project ID, service project name, release type (e.g., blue-green release, regular release), whether blue-green releases are supported (Boolean value), and responsible person information. Historical blue-green release information can include metrics such as the success rate, failure rate, and rollback count of the service project in past releases, or can be quantified as a score indicating whether blue-green releases are supported. Generating an initial release strategy for each service project based on its attribute configuration information and historical blue-green release information in the graph model enables preliminary decision-making on whether a service project should be blue-green released, improving decision-making efficiency. Furthermore, the automatically generated initial distribution strategy achieves quantitative evaluation and automated generation of release strategies, avoiding the subjectivity and inconsistency of human experience judgment and improving the scientific nature and accuracy of the decision.

[0045] Step 105: Determine the blocking points in the blue-green deployment process of the application software based on the initial deployment strategies of each service project in the graph model, and update the actual deployment strategies of the requirements in the graph model based on the blocking points.

[0046] Here, electronic devices can determine the bottlenecks in the blue-green deployment process of the application software based on the initial deployment strategies of each service project in the graph model, and update the actual deployment strategies of the requirements in the graph model based on the bottlenecks. Specifically, the bottlenecks correspond to service projects in the graph model whose initial distribution strategies do not support blue-green deployment. Based on the graph model, service projects that do not support blue-green deployment in the initial decision can be automatically identified, and the actual deployment strategies of the relevant requirements in the graph model can be updated based on these unsupported service projects. Furthermore, by leveraging the topological dependencies between requirements and between requirements and service projects established by the graph model, bottlenecks in the blue-green deployment process can be identified in advance, and requirements that do not meet the blue-green deployment requirements can be intelligently identified during the blue-green deployment process. This transforms "post-event failure" into "pre-event insight," thereby improving the success rate and efficiency of application software blue-green deployment.

[0047] It is understood that the application software blue-green deployment decision-making method in this embodiment achieves a leap from single service project evaluation to global link analysis by constructing a graph model based on topological dependencies. The system obtains a version-associated second JIRA identifier based on a first JIRA identifier, extracts deployed service projects based on the CI / CD pipeline, and updates the association between the second JIRA identifier and the service project. This establishes the association between requirements and deployed service projects, thereby constructing a graph model, generating initial deployment strategies for each service project, and dynamically updating the actual deployment strategy of the second JIRA identifier through a blocking point identification mechanism, ensuring the global consistency and accuracy of deployment decisions. The application software blue-green deployment decision-making method provided in this embodiment moves deployment risk assessment to the code merging stage, significantly reducing online failure rates and improving the success rate of blue-green deployments and the overall stability of the system.

[0048] For example, constructing a graph model based on the first JIRA identifier, the second JIRA identifier, and the association between the requirement and the deployed service engineering includes: A first node indicating the release version is created based on the first JIRA identifier; Based on each of the second JIRA identifiers associated with the first JIRA identifier, a second node indicating the requirement is created and associated with the first node; Based on the association between the requirements and the deployed service projects, a third node is created that is associated with the second node and indicates the service projects. Based on the dependency information between each service project, the association relationship between the third nodes is established.

[0049] Here, in the graph model, the first node can represent the release version, the second node represents the requirement, and the third node represents the service project. Based on each of the second JIRA identifiers associated with the first JIRA identifier, a relationship can be established between the first and second nodes; based on the relationship between the requirement and the deployed service projects, a relationship can be established between the second and third nodes; and based on the dependency information between the service projects, a relationship can be established between the third nodes. The dependency information between the service projects can be pre-set and stored in a knowledge base.

[0050] In some embodiments, the graph model may further include a fourth node indicating the person in charge of a service project. Specifically, the person in charge information for a service project can be obtained from a database. For example, the person in charge information, such as the person in charge ID and name, can be obtained by matching the name of the service project and stored as a person in charge node (i.e., the fourth node). The association between the third node and the fourth node is established based on the correspondence between service projects and persons in charge. By introducing the fourth node, the association between service projects and persons in charge can be automatically realized, facilitating subsequent manual review.

[0051] It should be noted that the graph model is the core data structure constructed in this application, used to represent the complex dependencies between requirements, service engineering, and release strategies. The graph model is implemented using graph database technology and consists of multiple nodes and edges. Node types include release version nodes, requirement nodes, service engineering nodes, and responsible party nodes; edge types include RELATES (version and second JIRA identifier, primary second JIRA identifier and child second JIRA identifier), IMPACTS (influence of service engineering on second JIRA identifiers), DEPENDS_ON (dependencies between service engineerings), and OWNS (relationship between responsible party and service engineering), etc.

[0052] For example, under version VER-2025-Q1 (release version node), there are two second JIRA identifiers, REQ-2025-001 and REQ-2025-002 (second JIRA identifier nodes). Second JIRA identifier REQ-2025-001 is affected by service project FE-001, while second JIRA identifier REQ-2025-002 is affected by service projects BE-002 and DB-003 (service project nodes). If service project BE-002 depends on service project DB-003, add a DEPENDS_ON edge to the graph with a weight strength=1. Simultaneously, if the owner of service project FE-001 is User-A, add an OWNS edge connecting the two.

[0053] In actual implementation, the system initializes the graph model, creates corresponding nodes, and establishes edge relationships based on the data obtained in steps 101 and 102. The graph model supports dynamic updates; when a second JIRA identifier or service project is added, the system automatically expands the graph structure. The technical effect of this step is to construct a global, visible, and computable dependency network, enabling a structured expression of complex multi-service project collaborative deployment scenarios, and providing a foundational platform for subsequent deployment strategy evaluation and bottleneck identification.

[0054] For example, generating the initial release strategy for each service project based on the attribute configuration information and historical blue-green deployment information of each service project in the graph model includes: Based on the attribute configuration information of each service project in the graph model, determine the first score value of the current blue-green release for each service project; Based on the historical blue-green release information of each service project, determine the second score of the historical blue-green release of each service project; Based on the first and second scores of each service project and the set weight values, a third score is generated for each service project. Based on the comparison results between the third score of each service project and the set threshold, an initial release strategy for each service project is generated.

[0055] The initial score for a blue-green deployment is a quantitative assessment value calculated based on the service project's own attribute configuration information, reflecting whether the service project possesses the capability for blue-green deployment. This assessment value is primarily assigned based on the core attribute of whether the service project supports blue-green deployment. If the service project is explicitly configured to support blue-green deployment, the initial score is typically set to 1 (full marks), indicating that it fully meets the conditions for blue-green deployment; if it is not configured or configured not to support blue-green deployment, the initial score is 0. This assessment value reflects the static capabilities of the service project itself and serves as the base score for the assessment.

[0056] In a real-world system, attribute configuration information originates from the metadata of service engineering nodes, such as the `releaseType` field stored in a graph database. When the value of this field is "blue-green release," it indicates that the service engineering node possesses blue-green release capabilities. The development team uses tools like Gerrit to associate and annotate attribute configuration information with JIRA requirements during the CI / CD pipeline configuration phase or code submission, ensuring data accuracy and timeliness.

[0057] By incorporating the initial score of the current blue-green deployment, the system can quickly identify projects that are theoretically eligible for blue-green deployment, avoiding ineffective calculations for projects lacking the necessary capabilities and thus improving decision-making efficiency. Simultaneously, this blue-green deployment screening mechanism also compels engineering teams to consider deployment strategy compatibility during the design phase, promoting the implementation of R&D standards.

[0058] The second score for historical blue-green deployments refers to the rating score corresponding to each of the past blue-green deployment records of the service engineering, used to measure the stability and reliability of the service engineering in the actual deployment process. This score is usually a value between 0 and 1, and the calculation method can be based on a comprehensive score of factors such as the number of failures, rollback frequency, and user complaint rate during each deployment, to quantify the stability of blue-green deployments.

[0059] Historical blue-green deployment information is derived from deployment logs, monitoring data, and operational feedback reports recorded in a cold storage database (such as MySQL). The system periodically crawls and cleans these deployment logs, monitoring data, and operational feedback reports to construct a service quality profile for each service project. The second score of the historical blue-green deployment reflects the performance of the project in a real-world environment, compensating for the shortcomings of relying solely on static configurations and making the evaluation more practically instructive.

[0060] By introducing a second score from historical blue-green deployments, the deployment strategy generation system can identify projects that, while technically supporting blue-green deployments, have historically been unstable and prone to problems. This allows the system to issue higher risk warnings to these projects during deployment strategy generation, effectively reducing the probability of online failures.

[0061] The third score is the final evaluation score generated by comprehensively considering both the project's static capabilities (the first score currently released by the blue-green exchange) and its dynamic performance (the second score released by previous blue-green exchanges). It is used to comprehensively determine whether the project is suitable for this blue-green exchange. The formula for calculating the third score can be a weighted summation, for example: The third score value=α*S0 + α(1-α) * S1 + α(1-α)^2 * S2 + α(1-α)^3 * S3 + ... Here, α is a set weight value, which can be set based on expert experience; for example, α can be 0.8. S0 represents the first score of the current blue-green deployment. For example, if the attribute configuration information determines that blue-green deployment is supported, then S0 is 1; if it determines that blue-green deployment is not supported, then S0 is 0. S1, S2, S3… represent the second scores of historical blue-green deployments in order from most recent to oldest. Each second score value is between 0 and 1, used to measure the stability and reliability of the service project during the actual deployment process. It can be understood that the weight values ​​corresponding to each second score value gradually decrease along the distribution order from most recent to oldest.

[0062] The process of generating the third score based on the current blue-green deployment score, the historical blue-green deployment score, and the set weight values ​​for each service project is executed in the topology dependency analysis module. The system traverses all service project nodes in the graph model, calculates the third score for each service project node, and uses the results as key inputs for subsequent strategy generation. The set weight values ​​can be flexibly adjusted according to different business scenarios. For example, for newly launched projects, the set weight values ​​can be appropriately increased to encourage experimentation; while for core business systems, the set weight values ​​can be decreased to prioritize stability.

[0063] By generating a third score, the system achieves a multi-dimensional and refined evaluation of the project release capability. It avoids over-reliance on a single indicator while balancing short-term goals with long-term stability, providing solid data support for intelligent decision-making.

[0064] The initial release strategy refers to the release method automatically recommended for each service project based on the comparison between the third score and a preset threshold (e.g., 0.85). If the third score is greater than or equal to the set threshold, a blue-green release is recommended; if the third score is lower than the set threshold, a regular release is recommended. The process of generating the initial release strategy based on the comparison between the third score of each service project and the set threshold is automated and batch-processed, allowing for rapid evaluation of all projects before version release.

[0065] The threshold is a critical point determined based on extensive historical data and expert experience, used to distinguish between high-reliability and low-reliability projects. For example, a threshold of 0.85 means that only projects that are currently fully configured and have a good historical performance are allowed to enter the blue-green deployment process, while the remaining projects must be deployed in a more conservative manner to control overall risk.

[0066] In practical applications, the system will display the generated initial release strategy in a visual format on the decision-making interface for operations and maintenance personnel to review and fine-tune. If it is found that individual projects need to be forced to release via blue-green due to special reasons, the release type of the project can be manually modified through the interface. The system will automatically trigger incremental subgraph reconstruction to recalculate the dependencies within the affected scope, ensuring the consistency and accuracy of the decision.

[0067] Understandably, by using the attribute configuration information of each service project in the graph model and historical blue-green deployment information, the first score of the current blue-green deployment and the second score of historical blue-green deployments are calculated respectively. These are then combined with set weight values ​​to generate a third score. Finally, an initial deployment strategy is generated based on the comparison between the third score and a set threshold. This allows for a systematic and intelligent evaluation of blue-green deployment capabilities in multi-project collaborative deployment scenarios, enabling accurate identification of deployment bottlenecks and significantly improving deployment success rates and system stability.

[0068] For example, the blocking point is the third node in the graph model corresponding to the service project whose initial distribution strategy does not support blue-green deployment. Updating the actual deployment strategy of the associated requirements in the graph model based on the blocking point includes: Obtain the target second node in the graph model that is associated with the blocking point, determine the actual release strategy of the requirement corresponding to the target second node as a release strategy that does not support blue-green release, and determine the actual release strategy of the service engineering corresponding to each third node associated with the target second node as a release strategy that does not support blue-green release; until the actual release strategy of all requirements associated with service engineering that does not support blue-green release is updated to a release strategy that does not support blue-green release.

[0069] Here, the target second node refers to a requirement node in the graph model that has a direct or indirect connection with the blocking point. The target second node is typically connected to the service engineering node corresponding to the blocking point via IMPACTS or RELATES relationships, meaning that the release of requirements corresponding to this requirement node will be affected by the blocking point. Once the blocking point is identified, the system needs to trace the upstream dependencies of the service engineering node corresponding to the blocking point, find all affected requirement nodes (i.e., target second nodes), and update the actual release strategy for the requirements corresponding to these target second nodes to not support blue-green releases, ensuring the consistency and security of release decisions.

[0070] The third node is a node representing a service project in the graph model. Each third node contains attributes such as project ID (projectId), project name (projectName), and release type (releaseType). When the initial release strategy of a service project does not support blue-green deployment, the corresponding service project node constitutes a blocking point. As the basic unit in the graph model, the third node carries the technical attributes and release constraints of the service project and is an important basis for evaluating whether the entire dependency chain can be blue-green deployed.

[0071] The actual release strategy refers to the specific release method adopted for a particular requirement or service project within the current release context. In this application, the actual release strategies include blue-green release and regular release. When the system detects a blocking point, it automatically adjusts the actual release strategy of the requirements and projects associated with the blocking point to not support blue-green release, i.e., forcibly downgrading them to regular release to avoid release risks. This strategy adjustment is dynamic and recursive, ensuring that all requirements and projects affected by the blocking point are correctly marked.

[0072] In actual implementation, the system first identifies service projects whose initial release strategy does not support blue-green deployment (i.e., the blocking point). Then, it traverses the graph model, searching for all requirement nodes (target second nodes) connected to the blocking point through dependencies (such as DEPENDS_ON and IMPACTS), and updates the actual release strategy of the requirements corresponding to these target second nodes to not support blue-green deployment. Next, the system continues to search for all service project nodes associated with the target second node (third nodes), similarly updating the actual release strategy of the service projects corresponding to these third nodes to not support blue-green deployment. This process iterates until no new requirements or projects need updating, forming a complete blocking propagation path.

[0073] For example, in a certain release, if project A (the third node) only supports regular releases due to technical limitations, then project A will become a bottleneck. The system will find all requirements B and C (the target second nodes) that depend on project A, and set the actual release strategy of requirements B and C to not support blue-green releases. At the same time, the system will also check other projects D and E (the third nodes) associated with requirements B and C. If projects D and E are not marked as bottlenecks, the actual release strategies of projects D and E will also be updated synchronously to ensure that the entire dependency chain remains consistent.

[0074] In actual implementation, the system initiates a blocking point propagation algorithm. Starting from all service engineering nodes that are initially not eligible for blue-green deployment, the blocking effect is propagated upstream along the dependency path, updating the corresponding second JIRA identifier and the actual deployment strategy of the service engineering node. The technical effect of this step is to achieve global consistency verification and dynamic adjustment of the deployment strategy. This ensures that in multi-service engineering collaborative deployment scenarios, any single point of failure or limitation can be promptly identified and propagated to all dependent links, effectively mitigating deployment risks and improving the overall system stability and security.

[0075] In this embodiment, blocking points are identified in the graph model, and the actual deployment strategy of associated nodes is recursively updated. This enables global impact analysis of the multi-application collaborative change scenario, allowing for early detection and mitigation of deployment risks, thereby significantly improving the stability and success rate of the blue-green deployment process.

[0076] For example, before updating the actual release strategy of the associated demand in the graph model based on the blocking point, the method further includes: The graph model is visualized; wherein the blocking point is displayed in a way that distinguishes it from other third nodes. The blocking points in the graphical model are manually verified.

[0077] Here, visualizing the graph model refers to displaying the constructed graph model as a visual decision-making interface (i.e., a visualization interface), enabling operations and maintenance personnel to intuitively observe the topological dependencies between various nodes. This visualization interface typically includes nodes, edges, and node attribute information. Different types of nodes (such as requirement nodes, service engineering nodes, and responsible party nodes) are distinguished by different colors, shapes, or icons, and the relationship types between them (such as RELATES, IMPACTS, DEPENDS_ON, etc.) are indicated by lines. For example, requirement nodes can be displayed as blue circles, service engineering nodes as green rectangles, and responsible party nodes as yellow diamonds, while blocking points are highlighted in striking red or flashing for quick identification by operations and maintenance personnel.

[0078] A blocking point is a node in the graph model corresponding to a service project whose initial deployment strategy does not support blue-green deployment. The existence of a blocking point hinders the entire dependency chain from achieving blue-green deployment. In visualization, blocking points need to be presented in a way that distinguishes them from other nodes, such as using a red background, bold borders, special icons, or dynamic flashing effects to ensure they are visually prominent. This differentiated display helps operations personnel quickly locate potential risk points and prioritize addressing critical nodes with a wide impact.

[0079] In practical applications, after the system completes the construction of the graph model, it automatically launches the visualization module, loads the graph model data, and renders it onto the visualization display decision interface. Operations personnel can interactively browse the graph model structure using functions such as zooming, dragging, and expanding / collapsed nodes. When a service node is marked as a bottleneck, the system adds a red warning ring around the bottleneck or pops up a prompt explaining the reason for the bottleneck (e.g., the service node is not configured with blue-green deployment support or its historical deployment success rate is below a threshold), while providing modification suggestions or operation entry points. This visualization mechanism not only improves the efficiency of problem discovery but also enhances the transparency and traceability of the decision-making process.

[0080] Here, manual review refers to the process by which authorized operations or development personnel reconfirm and intervene in the blocking point identified by the system. This manual review process allows users to determine whether a blocking point should be ignored, or to manually modify the release strategy attribute of the blocking point, based on business context, temporary adjustments, or special scenarios. For example, when a project needs to temporarily adopt blue-green release for an emergency fix, the administrator can select the blocking point on the visualization display decision interface of the graph model and change its release type from non-blue-green to blue-green release. The system then triggers incremental subgraph reconstruction to recalculate the release strategies of the affected requirements and related projects.

[0081] There is a close data and logical connection between the manual review module and the graph model system. The graph model system, as the underlying data source, provides the manual review module with a complete dependency context; conversely, the results of the manual review module, in turn, affect the graph model system, updating node attributes or relationship states, thereby driving subsequent evaluation and decision-making processes. For example, when a user clicks the "Unblock" button on the interface, the system records the user's action, updates the `releaseType` field of the target service project node, and marks the change record set, preparing for a partial recalculation.

[0082] In practice, manual review functionality is typically integrated into the visual decision-making interface of the graph model, supporting multi-level access control. Users can view detailed information about blocking points (such as project ID, responsible person, reason for blocking, historical release records, etc.) and choose to ignore, modify the strategy, or submit for approval. The system records all manual review operation logs, facilitating post-event auditing and experience accumulation. Furthermore, for frequently occurring blocking points, the system can generate statistical reports to assist the team in optimizing project architecture or release specifications.

[0083] In this embodiment, before executing the actual release strategy based on the blocking point to update the associated requirements in the graph model, the graph model is first visualized, and the blocking point is highlighted in a way that distinguishes it from other third nodes. Then, the blocking points in the graph model are manually reviewed. This manual review process improves the intuitiveness and accuracy of problem identification, thereby enhancing the controllability and flexibility of the decision-making process. This effectively reduces the release risk caused by misjudgment or omission, and improves the overall success rate and stability of blue-green deployments.

[0084] Exemplarily, the method further includes one or more of the following: Based on the newly deployed service project in the continuous integration / continuous delivery pipeline, update the graph model, and based on the attribute configuration information of the newly deployed service project, update the actual release strategy of the requirements associated with the newly deployed service project; Based on the updated target service project already deployed in the continuous integration / continuous delivery pipeline, the initial release strategy of the target service project is updated, and the actual release strategy of the requirements associated with the target service project is updated.

[0085] Once a newly deployed service project is identified, the system will find and update the actual release strategy of all requirement nodes affected by the newly deployed service project based on the association between the newly deployed service project and existing requirements (such as establishing the IMPACTS relationship through the JiraID associated in the Gerrit commit record). For example, if the newly deployed service project supports blue-green releases, requirements associated with the newly deployed service project that have not been blocked can continue to be retained or adjusted to blue-green releases; if the newly deployed service project only supports regular releases, requirements associated with the newly deployed service project will be forced to be updated to regular releases, and further recursively check whether other projects that the requirement depends on also have non-blue-green release situations, thus forming a chain update.

[0086] In a real-world application scenario, suppose a new front-end project FE-new is added in a version release. FE-new is successfully deployed via the CI / CD pipeline, and its configuration attribute is blue-green deployment. Upon detecting FE-new, the system immediately creates a corresponding node in the graph model and, by parsing FE-new's commit history, discovers that FE-new is associated with requirement JIRA-123. The system then updates the actual release strategy of requirement JIRA-123 associated with FE-new to blue-green deployment and checks whether other projects that requirement JIRA-123 depends on (such as the back-end project BE-old) also support blue-green deployment. If BE-old supports it, the entire requirement chain maintains blue-green deployment; if BE-old does not support it, the actual release strategy of requirement JIRA-123 will be downgraded to a regular release, triggering a chain reaction of updates to other related requirements.

[0087] When a target service project is updated in the CI / CD pipeline (such as version upgrades, configuration modifications, code refactoring, etc.), the system captures the update event of the target service project and obtains the attribute configuration information of the target service project after the update, especially the change in the target service project's release strategy. For example, if a target service project that originally supported blue-green release no longer supports blue-green release due to an architecture change, the system generates a third score based on the first score of the service project and the second score from its historical distribution, and updates the initial release strategy based on the third score and a set threshold, for example, updating the initial release strategy of the target service project from blue-green release to regular release.

[0088] Subsequently, the system will locate all directly or indirectly related requirement nodes based on the dependencies of the target service project in the graph model. For each requirement associated with the target service project, the system will recalculate the actual release strategy for that requirement. If the requirement originally depended on multiple projects, and other projects still support blue-green deployments, but the target service project in this update becomes a regular deployment, the actual release strategy for that requirement will be downgraded to a regular deployment, triggering recursive checks on the other projects that the requirement depends on to ensure the consistency of the release strategy throughout the dependency chain.

[0089] In practical implementation, for example, if a deployed backend service BE-v1.0 changes its release strategy from blue-green release to regular release due to a security patch update, the system, upon detecting this change, first updates the `releaseType` attribute of the BE-v1.0 node. Then, it iterates through all requirements connected to the BE-v1.0's `IMPACTS` relationships (such as JIRA-456 and JIRA-789). For JIRA-456, if JIRA-456 also depends on another project FE-v2.0, and FE-v2.0 still supports blue-green release, then because a regular release project exists, the actual release strategy for JIRA-456 will be updated to regular release. Simultaneously, the system will check if JIRA-456 is an upstream dependency of other requirements (such as JIRA-101). If so, the actual release strategy for JIRA-101 will also be updated synchronously.

[0090] In this way, by monitoring new deployment events or service project update events in the CI / CD pipeline in real time, the graph model is dynamically updated, and incremental subgraph reconstruction ensures that the system always evaluates release strategies based on the latest project status, avoiding decision lag or errors caused by static models. This allows for timely responses to changes, improving the accuracy and timeliness of release decisions, and reducing the risk of release failures due to outdated dependencies. This, in turn, improves the accuracy and timeliness of blue-green release evaluation, effectively reducing risks and failure rates during the release process.

[0091] Exemplarily, the method further includes: Based on the actual release strategies of each requirement in the graph model, the release order of service projects and the project list information of the actual release strategies are generated.

[0092] Here, the actual deployment strategy refers to the specific deployment method adopted by each service project during the blue-green deployment process, including blue-green deployment and regular deployment. The actual deployment strategy is determined not only by the technical attributes of the service project itself but also by its upstream and downstream dependencies. For example, if a service project cannot support blue-green deployment due to technical limitations, then the requirements associated with that service project and its downstream dependent service projects must all be adjusted to regular deployment, thus creating a chain reaction. Determining the actual deployment strategy requires comprehensive consideration of the service project's historical deployment success rate, current configuration attributes, and the integrity of its dependency chain.

[0093] A service project refers to a specific software module or service unit participating in this release. It typically corresponds to an independent code repository or deployment unit, such as a front-end page service, a back-end API service, or a database service. Each service project has a unique identifier (e.g., projectId) in the graph model, recording key information such as its release type, responsible node, and dependencies. The service project is the basic execution unit of the release process, and its release order and strategy directly affect the stability and efficiency of the overall release.

[0094] Deployment order refers to the deployment sequence of multiple service projects arranged according to a specific logic during a blue-green deployment process. This aims to avoid deployment failures due to dependency conflicts or resource contention. The deployment order is typically derived by working backward from the topology dependencies, prioritizing the deployment of service projects with no or few dependencies, followed by those that depend on already deployed service projects. For example, middleware service projects are deployed first, followed by application service projects that depend on them, ensuring the continuity of the call chain.

[0095] Project inventory information refers to a structured document or data table that summarizes the release strategies, release order, and related metadata of all service projects, used to guide the operations team in performing release operations. Project inventory information typically includes fields such as service project name, service project ID, release type, release time window, responsible node, dependencies, and blocking point prompts. It can be exported to Excel or PDF format for manual verification, or it can be directly integrated into the CI / CD pipeline for automated release.

[0096] The above concepts are closely linked in terms of data and logic. The graph model, as the core data structure, stores information about all service projects and their actual deployment strategies. The actual deployment strategy is determined by the node attributes in the graph model and propagates through dependencies. Service projects are the basic nodes in the graph model, and their deployment order is derived from the dependency paths within the graph model. The final generated project inventory information serves as the output carrier of the graph model's analysis results, guiding actual deployment operations. For example, when it is detected that service project E3 does not support blue-green deployment, the graph model automatically marks the upstream service project E2 as a regular deployment and places it last in the project inventory information, ensuring the correctness of the dependency chain.

[0097] In practical applications, when this cloud service platform releases a quarterly version, the release management system first constructs a graph model containing 20 service projects and 8 requirements. After topology dependency analysis, it was discovered that two service projects could not be deployed via blue-green deployment due to compatibility issues. The release management system automatically generated the deployment order: first deploying non-dependent service projects, then deploying service project modules that depend on the already released service projects, and finally deploying the blocking service project. Simultaneously, it generated a project list, clearly marking the release strategy and responsible node for each service project, for the operations team to reference and execute. This release process reduced the original hours of manual analysis to just a few minutes, significantly improving release efficiency and accuracy.

[0098] In this embodiment, the release order of service projects and the project list information of the actual release strategy are generated based on the actual release strategies of each requirement in the graph model. This approach transforms the complex problem of collaborative multi-project release into a structured decision output, clearly guiding the release execution process and thereby reducing release risks, improving release success rates, and enhancing operational efficiency.

[0099] The present application will be further described in detail below with reference to application examples.

[0100] This application example demonstrates a blue-green deployment intelligent decision-making system based on topological dependencies. It employs a modular design, with modules interacting through standardized interfaces to ensure system scalability and maintainability. (Refer to...) Figure 2 The system's overall architecture includes a requirements management module, a topology dependency analysis module, and a visualization decision-making module. The auxiliary analysis tools used include JIRA, Gerrit (a free, open-source code review software), and CI / CD. The requirements management module is the system's input end, responsible for receiving and parsing published requirements and managing decision-making knowledge. The topology dependency analysis module is the system's analysis end, responsible for determining global dependencies and accurately locating the scope of impact. The visualization decision-making module is the system's command end, responsible for transforming the analysis results into understandable and executable solutions and granting decision-making authority to these solutions.

[0101] The requirements management module is used to establish requirements-related data management for each release version of the application software, providing a data foundation for the topology dependency analysis module, including but not limited to: requirements data sources, engineering data sources, and knowledge sources related to release strategies. Specifically, refer to... Figure 2 The requirements management module includes the JIRA requirements management module, the CI / CD pipeline module, and the knowledge base module. The JIRA requirements management module provides the source of requirements data, the CI / CD pipeline module provides the source of deployed engineering data, and the knowledge base module provides the source of knowledge related to release strategies.

[0102] In terms of JIRA requirement management, a single release may include multiple JIRA requirements, each involving multiple front-end and back-end projects. These projects have release strategy attributes, such as blue-green releases and regular releases. Based on this, the JIRA requirement management module creates JIRA requirements for each release, and also creates separate JIRA requirements for business requirements, functional requirements, and non-functional requirements, associating these requirement JIRAs with the release JIRAs. The CI / CD pipeline module supports an automated process for building, testing, and deploying software, covering code submission, compilation and packaging, automated testing, and deployment. The knowledge base module can include a release strategy knowledge base and project / strategy metadata.

[0103] The topology dependency analysis module includes a multi-source data collector, a dynamic graph builder, and an impact link analysis engine. The multi-source data collector collects requirement data, engineering data, and knowledge sources related to release strategies based on data managed by the JIRA requirement management module. Specifically, it dynamically retrieves a list of all requirement JIRA versions associated with that version to obtain the requirement data source; it pulls the CI / CD pipeline associated with a specified version and extracts the project name corresponding to the pipeline's packaged deployment; it parses the project name of the code repository associated with the code record submitted by the requirement JIRA number, as well as the project name involved in the configuration code, and establishes the association between the requirement and the deployed service project; and it obtains the attribute configuration information and historical blue-green deployment information of each service project based on the release strategy knowledge base and project / strategy metadata stored in the knowledge base module. The dynamic graph builder dynamically constructs the aforementioned graph model. The impact link analysis engine performs incremental subgraph reconstruction and updates the actual release strategy of associated requirements based on newly deployed service projects and / or updates to already deployed service projects.

[0104] In this application example, the design of the graph database model includes node type definitions and relation type definitions. The node type definitions are shown in Table 1 below: Table 1 Node type Label Key attributes need Requirement jiraId, / / Requirement ID title, / / Requirement title priority, / / Requirement priority OwnerId / / Responsible person ID type / / Requirement type, main requirement, sub-requirement Service Engineering project projectId, / / Project ID projectName, / / Project Name releaseType, / / Project Release Type, e.g., blue-green release Release version Version versionId, / / Version ID jiraId, / / Version Requirement ID person in charge Owner ownerId, / / Owner ID ownerName, / / Owner Name The relation types are defined as shown in Table 2 below: Table 2 Relationship type direction property Semantics RELATES Version → Main Requirements → Sub-requirements link Relationship between requirements and versions, main requirements and sub-requirements IMPACTS Service Engineering → Requirements impactScore,changeType The extent of the project's impact on demand DEPENDS_ON Service Engineering → Service Engineering strength Service Dependency Strength OWNS Person in charge → Service Engineering since Person in charge association BLOCKS Service Engineering → Service Engineering reason Release blocking relationship Referring to Table 1 above, the node types include nodes labeled "requirement" (i.e., the second node mentioned above), with key attributes including Requirement ID (jiraId), Requirement Title (title), Requirement Priority (priority), Owner ID (OwnerId), and Requirement Type (type); nodes labeled "service project" (i.e., the third node mentioned above), with key attributes including Project ID (projectId), Project Name (projectName), and Project Release Type (releaseType); nodes labeled "release version" (i.e., the first node mentioned above), with key attributes including Version ID (versionId) and Version Requirement ID (jiraId); and nodes labeled "owner" (i.e., the fourth node mentioned above), with key attributes including Owner ID (ownerId) and Owner Name (ownerName).

[0105] Referring to Table 2 above, the relationship types include: Relationships (RELATES), which represent the relationship between version → main requirement → sub-requirement; Impact Relationships (IMPACTS), which represent the impact relationship between service project and requirement; Dependency Relationships (DEPENDS_ON), ​​which represent the service dependency strength between service projects; Ownership Relationships (OWNS), which represent the association between owner and service project; and Blocking Relationships (BLOCKS), which represent the release blocking relationship between service projects.

[0106] Reference Figure 3 The graph model construction in this application embodiment specifically includes the following steps: Step 301: Create the first node based on the information related to the release version.

[0107] Here, the version ID and version requirement ID of the release version can be obtained, and the version ID and version requirement ID can be stored as the release version node (i.e., the first node).

[0108] Step 302: Create a second node based on the requirement information associated with the release version.

[0109] Here, you can obtain the requirement ID associated with the version requirement ID based on the version requirement ID, and obtain the basic information of the corresponding requirement based on each requirement ID, including requirement title, requirement priority, responsible person ID, etc. Store this basic information as requirement node (i.e. second node), and establish the association between requirement and release version. The type of this association is defined as RELATES.

[0110] It should be noted that the sub-requirement IDs that have been split and associated with the requirement can also be obtained based on the requirement ID. The basic information of the sub-requirement, such as requirement title, requirement priority, and responsible person ID, can be obtained based on the sub-requirement ID. This basic information is stored as a requirement node. The system then constructs the association relationship between the sub-requirement and the aforementioned requirement (i.e., the main requirement). The association relationship type is RELATES.

[0111] Step 303: Parse the commit information associated with the requirement record when submitting code in Gerrit and create a third node.

[0112] Here, the service project name associated with the requirement ID in the commit message when submitting code in Gerrit is parsed, and the service project name already deployed in the CI / CD pipeline corresponding to the release version is retrieved. The service project name is stored as a service project node (i.e., the third node) based on the union of the service project name and the requirement ID in the code commit message. The association relationship between the requirement node and the corresponding service project node is established, and the association type is IMPACTS.

[0113] Step 304: Obtain the information of the person in charge of the service project and create the fourth node.

[0114] Here, the responsible person information of the service project is obtained from a cold storage database (such as a MySQL database), and the responsible person's ID and name are obtained by matching the service project name. This information is stored as the responsible person node (i.e., the fourth node). The blue-green release support status and project ID of the service project are obtained, and the project ID and project release type information of the service project node are updated. The association relationship between the service project node and the responsible person node is established, and the association type is OWNS. The association relationship between the service project node and another service project node is established, and the association type is DEPENDS_ON. The strength value is 1 to indicate dependency and 0 to indicate no dependency. If there is no dependency, no association relationship needs to be established.

[0115] Based on the constructed graph model, and using the attribute configuration information and historical blue-green deployment information of each service project within the graph model, an initial deployment strategy for each service project is generated, and the blocking points in the entire blue-green deployment process can be identified. The specific process is as follows: Based on expert experience and the impact of historical data on blue-green assessment, combined with the project's historical blue-green release history and the project's own attribute configuration supporting blue-green release, the total score for blue-green release (i.e., the aforementioned third score) is calculated. The calculation formula is as follows: α S0 + α(1 α) S1 + α(1 α)^2 S2 + α(1 α)^3 S3 + ... S0 represents the first score for the current blue-green deployment of the service project, determined based on the service project's own attribute configuration information. If the service project is explicitly configured to support blue-green deployment, the first score is typically set to 1 (full marks), indicating that it fully meets the conditions for blue-green deployment. If it is not configured or is configured not to support blue-green deployment, the first score is 0. This evaluation value reflects the static capabilities of the service project and is the base score for the evaluation. S1, S2, S3… represent the second scores for historical blue-green deployments in ascending order, with each second score ranging from 0 to 1, used to measure the stability and reliability of the service project during the actual deployment process. α represents the current data weight, and is set to a fixed value of 0.8 based on expert experience. Based on the above parameters and calculation formula, the total score for the current blue-green deployment is calculated. If the total score is greater than 0.85, a blue-green deployment is deemed feasible; otherwise, it is not.

[0116] Based on the dependencies between requirements and service projects, update the blue-green deployment status of requirements. The update rules are as follows: when all projects associated with a requirement can be blue-green deployed, the requirement can be blue-green deployed; when any project associated with a requirement only supports regular deployment, the requirement can only be regular deployed, and the service project associated with the requirement is set to regular deployment. At the same time, the impact of the service project set to regular deployment on other dependent requirements is set. The above settings are continuously executed until all service projects associated with affected requirements are set to regular deployment and no new service projects are added for regular deployment.

[0117] During development, the graph model is updated as code is committed incrementally. To minimize global impact and enable rapid iteration, an incremental subgraph reconstruction approach is adopted, recalculating dependencies only for the changed parts. When the system detects a new code commit, it determines whether the associated requirement task is included in the version. If so, it checks if the requirement task corresponds to a newly added service project node. If so, the new service project node is added to the graph model, and the blue-green deployment status of the requirements affected by this service project node and its associated projects is recalculated.

[0118] For example, after completing the configuration of a service project (such as project 1) or the modification of inter-service dependencies, the system will initiate an incremental subgraph reconstruction process. The incremental subgraph reconstruction process will accurately locate the project nodes affected by the changes (such as adjustments made to implement requirement 2) and automatically notify the relevant responsible persons (such as responsible person 1).

[0119] The refactoring process no longer recalculates the global dependency graph for the entire version. Instead, it intelligently constructs a minimal incremental subgraph based on the changeset, containing affected nodes and associated paths, and re-executes dependency assessments and compliance checks only on this incremental subgraph. This ensures that the verification of changes can be completed quickly and securely during the intelligent decision-making process for blue-green deployments, significantly improving the efficiency and reliability of deployment decisions.

[0120] For example, when assisting operations personnel in making visual decisions, the visualization decision-making module can, to facilitate the display of the final blue-green evaluation results and fine-tuning, visualize the blue-green evaluation results based on the release simulator. It also provides functionality based on the release strategy dashboard to modify project release attributes and dependencies between service projects. After operations personnel complete the modification operations, the system uses an incremental subgraph reconstruction method to recalculate dependencies only for the changed parts.

[0121] For example, after completing the configuration of a service project (such as project 1) or modifying the dependencies between services, the system will initiate an incremental subgraph reconstruction process. The incremental subgraph reconstruction process will accurately locate the project nodes affected by the changes (such as adjustments made to implement requirement 2) and automatically notify the responsible persons (such as responsible person 1) corresponding to the affected project nodes.

[0122] Understandably, the refactoring process no longer recalculates the global dependency graph for the entire version. Instead, it intelligently constructs a minimal incremental subgraph based on the changeset, containing affected nodes and associated paths, and re-executes dependency assessments and compliance checks only on this incremental subgraph. This operation ensures that changes can be quickly and securely verified during the blue-green release intelligent decision-making process, significantly improving the efficiency and reliability of release decisions.

[0123] This application example utilizes a blue-green deployment intelligent decision-making method based on topological dependencies. By establishing the aforementioned graph model and building a knowledge base to identify bottlenecks in the dependency chain, it transforms post-event failures into pre-event insights, significantly improving the stability and success rate of the deployment process. Furthermore, the topological dependency analysis engine automatically constructs an inter-application call relationship graph, dynamically sensing dependency changes and ensuring that deployment impact analysis is always based on the latest system state, providing a reliable basis for accurate decision-making. Finally, a visual decision support interface graphically displays the dependency chain, identifies bottlenecks in blue-green deployments, and automatically generates optimal deployment order suggestions and collaborative deployment plans. Thus, it not only guides the current deployment but also allows the data accumulated from the generated suggestions to feed back into subsequent requirement scheduling and R&D planning, thereby systematically improving the success rate of blue-green deployments and iterative delivery efficiency.

[0124] To implement the method of the embodiments of this application, the embodiments of this application also provide a decision-making device for application software blue-green release. This decision-making device for application software blue-green release corresponds to the above-described decision-making method for application software blue-green release, and each step in the above-described decision-making method for application software blue-green release is also fully applicable to the implementation of this decision-making device for application software blue-green release.

[0125] Reference Figure 4 The decision-making device for blue-green deployment of the application software includes: a first acquisition module 401, a second acquisition module 402, a construction module 403, an analysis module 404, and a decision module 405. The first acquisition module 401 is used to acquire second JIRA identifiers of various associated requirements based on the first JIRA identifier of the application software's release version; the second acquisition module 402 is used to establish a relationship between requirements and deployed service projects based on the service projects already deployed in the CI / CD pipeline corresponding to the release version and the relationship between requirements and service projects extracted based on each second JIRA identifier; the construction module 403 is used to construct a graph model based on the first JIRA identifier, the second JIRA identifier, and the relationship between requirements and deployed service projects; the analysis module 404 is used to generate an initial deployment strategy for each service project based on the attribute configuration information and historical blue-green deployment information of each service project in the graph model; the decision module 405 is used to determine the blocking points in the blue-green deployment process of the application software based on the initial deployment strategies of each service project in the graph model, and update the actual deployment strategy of requirements in the graph model based on the blocking points.

[0126] In some embodiments, the construction module 403 is specifically used for: A first node indicating the release version is created based on the first JIRA identifier; Based on each of the second JIRA identifiers associated with the first JIRA identifier, a second node indicating the requirement is created and associated with the first node; Based on the association between the requirements and the deployed service projects, a third node is created that is associated with the second node and indicates the service projects. Based on the dependency information between each service project, the association relationship between the third nodes is established.

[0127] In some embodiments, the analysis module 404 is specifically used for: Based on the attribute configuration information of each service project in the graph model, determine the first score value of the current blue-green release for each service project; Based on the historical blue-green release information of each service project, determine the second score of the historical blue-green release of each service project; Based on the first and second scores of each service project and the set weight values, a third score is generated for each service project. Based on the comparison results between the third score of each service project and the set threshold, an initial release strategy for each service project is generated.

[0128] In some embodiments, the blocking point is the third node in the graph model corresponding to a service project whose initial distribution strategy does not support blue-green publishing, and the decision module 405 is specifically used for: Obtain the target second node in the graph model that is associated with the blocking point, determine the actual release strategy of the requirement corresponding to the target second node as a release strategy that does not support blue-green release, and determine the actual release strategy of the service engineering corresponding to each third node associated with the target second node as a release strategy that does not support blue-green release; until the actual release strategy of all requirements associated with service engineering that does not support blue-green release is updated to a release strategy that does not support blue-green release.

[0129] In some embodiments, before updating the actual release strategy of the associated demand in the graph model based on the blocking point, the decision module 405 is further configured to: The graph model is visualized; wherein the blocking point is displayed in a way that distinguishes it from other third nodes. The blocking points in the graphical model are manually verified.

[0130] In some embodiments, the decision module 405 is further configured to perform one or more of the following: Based on the newly deployed service project in the continuous integration / continuous delivery pipeline, update the graph model, and based on the attribute configuration information of the newly deployed service project, update the actual release strategy of the requirements associated with the newly deployed service project; Based on the updated target service project already deployed in the continuous integration / continuous delivery pipeline, the initial release strategy of the target service project is updated, and the actual release strategy of the requirements associated with the target service project is updated.

[0131] In some embodiments, the decision module 405 is further configured to: Based on the actual release strategies of each requirement in the graph model, the release order of service projects and the project list information of the actual release strategies are generated.

[0132] In practical applications, the first acquisition module 401, the second acquisition module 402, the construction module 403, the analysis module 404, and the decision-making module 405 can be implemented by a processor in an electronic device. Of course, the processor needs to run a computer program in memory to perform its functions.

[0133] It should be noted that the decision-making device for blue-green deployment of application software provided in the above embodiments is only illustrated by the division of the above-described program modules. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the decision-making device for blue-green deployment of application software provided in the above embodiments and the decision-making method embodiments for blue-green deployment of application software belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0134] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 5 The diagram shows only an exemplary structure of the electronic device, not the entire structure; implementation is possible as needed. Figure 5 The structure shown may be part or all of the structure.

[0135] like Figure 5 As shown, the electronic device 500 provided in this application embodiment includes: at least one processor 501, a memory 502, a user interface 503, and at least one network interface 504. The various components in the electronic device 500 are coupled together via a bus system 505. It can be understood that the bus system 505 is used to implement communication between these components. In addition to a data bus, the bus system 505 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 5 The general designated all buses as Bus System 505.

[0136] The user interface 503 may include a monitor, keyboard, mouse, trackball, click wheel, buttons, touchpad, or touch screen.

[0137] The memory 502 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0138] The application software blue-green decision-making method disclosed in this application embodiment can be applied to or implemented by processor 501. Processor 501 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the application software blue-green decision-making method can be completed by integrated logic circuits in the hardware of processor 501 or by software instructions. The processor 501 can be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 501 can implement or execute the methods, steps, and logic block diagrams disclosed in this application embodiment. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application embodiment can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in a storage medium, specifically memory 502. Processor 501 reads information from memory 502 and, in conjunction with its hardware, completes the steps of the application software blue-green decision-making method provided in this application embodiment.

[0139] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0140] It is understood that memory 502 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Sync Link Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0141] In an exemplary embodiment, this application also provides a computer storage medium, specifically a computer-readable storage medium, such as a memory 502 storing a computer program, which can be executed by the processor 501 of the electronic device 500 to complete the steps described in the method of this application embodiment. The computer-readable storage medium can be a ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM, etc.

[0142] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by a processor 501 of an electronic device 500 to perform the steps described in the method of this application embodiment.

[0143] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0144] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0145] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A decision-making method for blue-green deployment of application software, characterized in that, include: Based on the first project and transaction tracking tool JIRA identifier of the application software release version, obtain the second JIRA identifier of various related requirements; Based on the service projects already deployed in the continuous integration / continuous delivery pipeline corresponding to the release version and the association between requirements and service projects extracted based on each of the second JIRA identifiers, establish the association between requirements and deployed service projects; A graph model is constructed based on the first JIRA identifier, the second JIRA identifier, and the relationship between the requirement and the deployed service engineering. Based on the attribute configuration information and historical blue-green deployment information of each service project in the graph model, an initial deployment strategy for each service project is generated. Based on the initial release strategy of each service project in the graph model, the blocking points in the blue-green deployment process of the application software are determined, and the actual release strategy of the requirements in the graph model is updated based on the blocking points.

2. The method according to claim 1, characterized in that, The construction of a graph model based on the first JIRA identifier, the second JIRA identifier, and the association between the requirement and the deployed service project includes: A first node indicating the release version is created based on the first JIRA identifier; Based on each of the second JIRA identifiers associated with the first JIRA identifier, a second node indicating the requirement is created and associated with the first node; Based on the association between the requirements and the deployed service projects, a third node is created that is associated with the second node and indicates the service projects. Based on the dependency information between each service project, the association relationship between the third nodes is established.

3. The method according to claim 1, characterized in that, The process of generating an initial deployment strategy for each service project based on its attribute configuration information and historical blue-green deployment information in the graph model includes: Based on the attribute configuration information of each service project in the graph model, determine the first score value of the current blue-green release for each service project; Based on the historical blue-green release information of each service project, determine the second score of the historical blue-green release of each service project; Based on the first and second scores of each service project and the set weight values, a third score is generated for each service project. Based on the comparison results between the third score of each service project and the set threshold, an initial release strategy for each service project is generated.

4. The method according to claim 2, characterized in that, The blocking point is the third node in the graph model corresponding to the service project whose initial distribution strategy does not support blue-green deployment. Updating the actual deployment strategy of the associated requirements in the graph model based on the blocking point includes: Obtain the target second node in the graph model that is associated with the blocking point, determine the actual release strategy of the requirement corresponding to the target second node as a release strategy that does not support blue-green release, and determine the actual release strategy of the service engineering corresponding to each third node associated with the target second node as a release strategy that does not support blue-green release; until the actual release strategy of all requirements associated with service engineering that does not support blue-green release is updated to a release strategy that does not support blue-green release.

5. The method according to claim 4, characterized in that, Before updating the actual release strategy of the associated demands in the graph model based on the blocking point, the method further includes: The graph model is visualized; wherein the blocking point is displayed in a way that distinguishes it from other third nodes. The blocking points in the graphical model are manually verified.

6. The method according to claim 1, characterized in that, The method further includes one or more of the following: Based on the newly deployed service project in the continuous integration / continuous delivery pipeline, update the graph model, and based on the attribute configuration information of the newly deployed service project, update the actual release strategy of the requirements associated with the newly deployed service project; Based on the updated target service project already deployed in the continuous integration / continuous delivery pipeline, the initial release strategy of the target service project is updated, and the actual release strategy of the requirements associated with the target service project is updated.

7. The method according to claim 1, characterized in that, The method further includes: Based on the actual release strategies of each requirement in the graph model, the release order of service projects and the project list information of the actual release strategies are generated.

8. An electronic device, characterized in that, include: The processor and memory for storing computer programs that can run on the processor, wherein, The processor, when running a computer program, performs the steps of the method according to any one of claims 1 to 7.

9. A computer storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images