A DevOps-based method for autonomous software quality control

Abstract

The present invention discloses a method for autonomous control of software quality based on DevOps, which belongs to the field of big data technology. It includes providing a framework for autonomous control of software quality and an evaluation assurance model from the aspects of software architecture component design and service reuse evaluation, user demand-based development cost evaluation, microservice construction method, code quality audit, automated testing, CI / CD efficiency, etc., which solves the limitations of traditional software quality management, improves the technical problems of the security of online systems in information communication, reduces external dependence, and prevents production safety, realizes smart operation, fast delivery and fast support, realizes rapid software quality inspection and software application release, realizes visualization, automation and intelligence of operation and maintenance, forms faster and stronger feedback processing capabilities, and promotes the transformation of operation and maintenance models.

Description

Technical Field

[0001] The present invention belongs to the field of big data technology, and in particular relates to a DevOps-based software quality autonomous control method. Background Art

[0002] In the standardized development of the software industry, the value of software has not been fully reflected in my country's industrial development. Software market prices have been suppressed for a long time, seriously affecting the survival and development of software companies and restricting the improvement of the industry's overall competitiveness. Achieving high-quality development still faces many challenges, such as a fragile industrial chain and supply chain, a weak industrial foundation, insufficient breadth and depth of software integration and application in various fields, and a fundamental imbalance in software value. To further address the problem of insufficient independent control over software service quality, we will explore the establishment of a software quality independent control framework and assessment and assurance system based on the DevOps concept. On the basis of security and reliability, we will fully utilize the use value of software products and services, independently control them, and continuously improve them, which will help further enhance the agility, value, and quality of regulatory business.

[0003] In the actual delivery of operator IT software services, most operator IT business projects rely on partners for production delivery, and have weak control over key aspects of software core technology, data, and security. Therefore, operators are required to assume responsibility for cloud, network, DC, data, business, information security, and operational security; take into account both quality and efficiency to provide core measures to ensure customer experience; train personnel capabilities internally, improve tool platforms, mechanisms and processes; and build independent quality control capabilities to facilitate independent operations. Summary of the Invention

[0004] The purpose of this invention is to provide a DevOps-based software quality autonomous control method, which solves the limitations of traditional software quality management and improves the technical problem of the security of online systems in information communication.

[0005] To achieve the above object, the present invention adopts the following technical solutions:

[0006] A DevOps-based method for autonomous software quality control includes the following steps:

[0007] Step 1: Build a DevOps platform and standardize development from bottom to top within the DevOps platform.

[0008] Step 2: Establish a demand workload assessment mechanism within the DevOps platform, including using the FPA function point + DELPHI estimation method to calculate the number of function points based on internal and external data items. A comprehensive assessment of adjustment factors is conducted based on preset standards and specifications, industry benchmark data, and GZW internal and expert experience to determine the range of project quantities.

[0009] Step 3: Establish a code quality and security audit module within the DevOps platform. This module uses the specifications written by the operator to benchmark scanning rules. Custom rules or self-developed plug-ins are then added. These rules are then configured on the CI / CD platform. Finally, scanning tasks are created, test scans are conducted, problem baselines are determined, and rectification and implementation plans are developed to close the problem loop.

[0010] Step 4: Within the DevOps platform, focus on single-system testing, moving from functional point-oriented WebUI, interface, and data testing to business scenario-oriented combination testing and cross-system, cross-domain, and cross-pool linkage testing for network-wide integrated services. Select a CPCP two-tiered coordination system to form a closed loop for customer-perceived operations.

[0011] Step 5: In the DevOps platform, based on the quality capability domain and subdomains, collect software quality capability domain data as sample data for the quality self-assessment algorithm model. Quality capability domain types include architecture quality, requirements analysis quality, CI / CD quality, multi-layer testing quality, data quality, release quality, configuration, and change. Based on the sample data, evaluate the degree of self-control of software quality, recommend weak links in quality control, and optimize and improve the system.

[0012] Preferably, when executing step 1, the following steps are specifically included:

[0013] Step S1-1: Standardize frameworks, components, microservice development specifications, construction technologies and methods, and coding standards for mainstream languages ​​​​Java, Python, and Vue;

[0014] Step S1-2: Standardize the development and testing environment and test entry and exit;

[0015] Step S1-3: Unified implementation of the tool platform and implementation of the guidance tool platform;

[0016] Step S1-4: Classify the rule base, standardize the use cases and precipitate the use case library.

[0017] Preferably, when executing step 1, the CI / CD platform built by each operator is used to implement application development standards, demand analysis and workload assessment and development cost estimation, code quality and security audit and testing from an operational perspective. All-round layered testing.

[0018] Preferably, when executing step 2, the FPA function point + DELPHI estimation method specifically includes the following steps:

[0019] Step S2-1: Function Point Calculation: During the project budget phase, the unadjusted function points are calculated using the estimated function point calculation method. The specific formula is as follows:

[0020] UFP = 35 × ILF + 15 × ELF;

[0021] Among them, UFP is the unadjusted function point number, the unit is function point; 35 is the internal logic file function point allocation constant; ILF is the number of internal logic files, the unit is piece; 15 is the external interface file function point allocation constant; ELF is the number of external interface files, the unit is piece;

[0022] In the case of demand cleaning, the estimated function point calculation method is used to calculate the adjusted function points. The specific formula is as follows:

[0023] UFP=10×ILF+7×ELF+4×EL+5×EO+4×EQ;

[0024] Among them, UFP is the unadjusted function point number, the unit is function point; 10 is the internal logic file function point allocation constant; ILF is the number of internal logic files, the unit is piece; 7 is the external interface file function point allocation constant; ELF is the number of external interface files, the unit is piece; 4 in 4×EL is the external input function point allocation constant; EL is the external input number, the unit is piece; 5 is the external output function point allocation constant; EO is the external output number, the unit is piece; 4 in 4×EQ is the external query function point allocation constant; EQ is the external query number, the unit is piece;

[0025] Step S2-2: Scale adjustment, specifically including adjustment of reuse degree and adjustment of implicit requirements and requirement changes;

[0026] The degree of reuse is adjusted to evaluate the reuse level of the function to be realized and adjust the scale according to the degree of reuse. The specific formula is as follows:

[0027] US = RUF × UFP;

[0028] Among them, US is the unadjusted software size, the unit is function point; RUF is the reuse adjustment factor, which is an arbitrary real number between 0 and 1; UFP is the unadjusted function point number, the unit is function point;

[0029] When calculating the scale using estimated function points, adjust the scale based on the impact of implicit demand and future demand changes. The specific formula is as follows:

[0030] S = US × CF;

[0031] Where S is the adjusted software size, in function points; US is the unadjusted software size, in function points; CF is the size change adjustment factor, which can be any real number between 1 and 2.

[0032] Step S2-3: Workload calculation, the specific formula is as follows:

[0033] AE = (S × PDR) × X;

[0034] Among them, AE is the measured workload, the unit is man-hours; S is the adjusted software size, the unit is function point; PDR is the function point time rate, the unit is man-hours per function point.

[0035] Preferably, the adjustment factor is obtained by calculating the application type adjustment factor and the quality characteristic adjustment factor, wherein the application type adjustment factor includes business processing, application integration, technology, multimedia, intelligent information, system, communication control and flow control; and the quality characteristic adjustment factor includes response speed, integration environment complexity, reliability and system design capacity.

[0036] Quality characteristic adjustment factor = (response speed + integration environment complexity + reliability + system design capacity) × 0.14 ÷ 4 + 0.65;

[0037] Adjustment factor = application type adjustment factor × quality characteristic adjustment factor.

[0038] Preferably, when executing step 3, the specific steps are as follows:

[0039] Step 3-1: Party A confirms the release date and version requirements;

[0040] Step S3-2: The partners clarify the code branching strategy, code submission rules and specifications;

[0041] Step S3-3: The code is submitted to the git-master branch. The designated person in charge of each system submits the code of the current month's version to the master branch, and a centralized scan is performed two working days before the launch;

[0042] Step S3-4: The operation team performs sonar code detection to determine whether the acceptance meets the standards: if it meets the standards, execute step S3-8; if it does not meet the standards, execute step S3-5;

[0043] Step S3-5: The scanned bugs are returned to the partner for development and modification;

[0044] Step S3-6: If it is not the working day before the launch, then after the modification is completed, execute step S3-3 again; if it is the working day before the launch, execute step S3-7;

[0045] Step S3-7: The operations team conducts a centralized code scan to determine whether the code meets the standards. If so, proceed to step S3-8. If not, the decision on whether to release the code to Party A is made. If not, proceed to step S3-8. If not, proceed to step S3-9.

[0046] Step S3-8: The operations team deploys the code online;

[0047] Step S3-9: The operations team manages the code through Yundao Git, performs code quality scans every month, and issues reports.

[0048] The DevOps-based autonomous software quality control method described in this invention addresses the limitations of traditional software quality management and improves the security of online systems in information communications. This method reduces external dependencies, safeguards production safety, and standardizes operational development specifications from the bottom up, establishing unified requirements across architecture, components, and source code. This method uses tool-based testing and acceptance to reduce external dependencies and safeguard production safety, enabling intelligent operations, rapid delivery, and rapid support. It also automates the CI / CD software process, introducing automated methods in continuous integration, continuous testing, and continuous deployment, enabling rapid software quality checks and software application releases. This method builds an integrated, open, and intelligent operations system, achieving visualization, automation, and intelligent operation and maintenance, fostering faster and more robust feedback processing capabilities, and promoting a transformation in operations and maintenance models. This transforms IT support, bringing autonomy and empowerment. Through the practice of this "independent software quality operation" system, customer IT system construction has shifted from a focus on "vendor system development" to one centered on "intellectual property autonomy," enabling capability sharing and empowerment. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 This is a schematic diagram of the DevOps full life cycle practice path of the present invention;

[0050] Figure 2 It is a flowchart of the code quality and security audit implementation of the present invention;

[0051] Figure 3 It is a schematic diagram of the technical quality independent control model of the present invention. DETAILED DESCRIPTION

[0052] Depend on Figure 1-Figure 3 The DevOps-based software quality autonomous control method shown in FIG includes the following steps:

[0053] Step 1: Build a DevOps platform and standardize development from bottom to top within the DevOps platform.

[0054] When executing step 1, the specific steps include:

[0055] Step S1-1: Standardize frameworks, components, microservice development specifications, construction technologies and methods, and coding standards for mainstream languages ​​​​Java, Python, and Vue;

[0056] Step S1-2: Standardize the development and testing environment and test entry and exit;

[0057] Step S1-3: Unified implementation of the tool platform and implementation of the guidance tool platform;

[0058] Step S1-4: Classify the rule base, standardize the use cases, and consolidate the use case library, shifting the focus from results to processes to ensure standardized, secure, and high-quality delivery.

[0059] When executing step 1, use the CI / CD platforms built by each operator to implement application development standards, demand analysis, workload assessment, development cost estimation, code quality and security audits, and comprehensive layered testing from an operational perspective.

[0060] Step 2: Establish a demand workload assessment mechanism within the DevOps platform, including using the FPA function point + DELPHI estimation method to calculate the number of function points based on internal and external data items. A comprehensive assessment of adjustment factors is conducted based on preset standards and specifications, industry benchmark data, and GZW internal and expert experience to determine the range of project quantities.

[0061] When executing step 2, the FPA function point + DELPHI estimation method specifically includes the following steps:

[0062] Step S2-1: Function Point Calculation: During the project budget phase, the unadjusted function points are calculated using the estimated function point calculation method. The specific formula is as follows:

[0063] UFP = 35 × ILF + 15 × ELF;

[0064] Among them, UFP is the unadjusted function point number, the unit is function point; 35 is the internal logic file function point allocation constant; ILF is the number of internal logic files, the unit is piece; 15 is the external interface file function point allocation constant; ELF is the number of external interface files, the unit is piece;

[0065] In the case of demand cleaning, the estimated function point calculation method is used to calculate the adjusted function points. The specific formula is as follows:

[0066] UFP=10×ILF+7×ELF+4×EL+5×EO+4×EQ;

[0067] Among them, UFP is the unadjusted function point number, the unit is function point; 10 is the internal logic file function point allocation constant; ILF is the number of internal logic files, the unit is piece; 7 is the external interface file function point allocation constant; ELF is the number of external interface files, the unit is piece; 4 in 4×EL is the external input function point allocation constant; EL is the external input number, the unit is piece; 5 is the external output function point allocation constant; EO is the external output number, the unit is piece; 4 in 4×EQ is the external query function point allocation constant; EQ is the external query number, the unit is piece;

[0068] In this embodiment, function point counting items are divided into two categories: data functions and transaction functions, among which data functions include ILF and ELF; transaction functions include EL, EO, and EQ. Data functions are functions provided by the system to users to meet the internal and external data requirements of the product, reflecting which business data (business objects) the system manages or uses. The files referred to by IFL or EIF are not files in the traditional data processing sense, but refer to a set of user-identifiable, logically interrelated data or control information. These files do not necessarily correspond to physical data sets (such as database tables). Transaction functions are functions provided by the system to users to process data, reflecting how the system processes and uses which business data (business objects). Transaction functions, also known as basic processes, are a set of atomic operations in business that are user-identifiable.

[0069] Step S2-2: Scale adjustment, specifically including adjustment of reuse degree and adjustment of implicit requirements and requirement changes;

[0070] The degree of reuse is adjusted to evaluate the reuse level of the function to be realized and adjust the scale according to the degree of reuse. The specific formula is as follows:

[0071] US = RUF × UFP;

[0072] Among them, US is the unadjusted software size, the unit is function point; RUF is the reuse adjustment factor, which is an arbitrary real number between 0 and 1; UFP is the unadjusted function point number, the unit is function point;

[0073] When calculating the scale using estimated function points, adjust the scale based on the impact of implicit demand and future demand changes. The specific formula is as follows:

[0074] S = US × CF;

[0075] Where S is the adjusted software size, in function points; US is the unadjusted software size, in function points; CF is the size change adjustment factor, which can be any real number between 1 and 2.

[0076] Step S2-3: Workload calculation, the specific formula is as follows:

[0077] AE = (S × PDR) × X;

[0078] Among them, AE is the measured workload, the unit is man-hours; S is the adjusted software size, the unit is function point; PDR is the function point time rate, the unit is man-hours per function point.

[0079] The adjustment factor is calculated by applying the application type adjustment factor and the quality characteristic adjustment factor. The application type adjustment factor includes business processing, application integration, technology, multimedia, intelligent information, system, communication control and flow control. The quality characteristic adjustment factor includes response speed, integration environment complexity, reliability and system design capacity.

[0080] Quality characteristic adjustment factor = (response speed + integration environment complexity + reliability + system design capacity) × 0.14 ÷ 4 + 0.65;

[0081] Adjustment factor = application type adjustment factor × quality characteristic adjustment factor.

[0082] The specific types of adjustment factors in this embodiment are shown in Table 1 below:

[0083]

[0084] Table 1

[0085] Table 2 shows an evaluation example given in this embodiment:

[0086]

[0087] Table 2

[0088] Step 3: Establish a code quality and security audit module within the DevOps platform. This module uses the specifications written by the operator to benchmark scanning rules. Custom rules or self-developed plug-ins are then added. These rules are then configured on the CI / CD platform. Finally, scanning tasks are created, test scans are conducted, problem baselines are determined, and rectification and implementation plans are developed to close the problem loop.

[0089] When executing step 3, the specific steps are as follows:

[0090] Step 3-1: Party A confirms the release date and version requirements;

[0091] Step S3-2: The partners clarify the code branching strategy, code submission rules and specifications;

[0092] Step S3-3: The code is submitted to the git-master branch. The designated person in charge of each system submits the code of the current month's version to the master branch, and a centralized scan is performed two working days before the launch;

[0093] Step S3-4: The operation team performs sonar code detection to determine whether the acceptance meets the standards: if it meets the standards, execute step S3-8; if it does not meet the standards, execute step S3-5;

[0094] Step S3-5: The scanned bugs are returned to the partner for development and modification;

[0095] Step S3-6: If it is not the working day before the launch, then after the modification is completed, execute step S3-3 again; if it is the working day before the launch, execute step S3-7;

[0096] Step S3-7: The operations team conducts a centralized code scan to determine whether the code meets the standards. If so, proceed to step S3-8. If not, the decision on whether to release the code to Party A is made. If not, proceed to step S3-8. If not, proceed to step S3-9.

[0097] Step S3-8: The operations team deploys the code online;

[0098] Step S3-9: The operations team manages the code through Yundao Git, performs code quality scans every month, and issues reports.

[0099] Step 4: Within the DevOps platform, focus on single-system testing, moving from functional point-oriented WebUI, interface, and data testing to business scenario-oriented combination testing and cross-system, cross-domain, and cross-pool linkage testing for network-wide integrated services. Select a CPCP two-tiered coordination system to form a closed loop for customer-perceived operations.

[0100] In this embodiment, the CPCP two-stage joint debugging system is selected and the implementation steps are as follows:

[0101] Step A: Launch and formulate a plan: Cooperate with R&D departments to organize learning of testing theory, master the platform's automatic testing tools and methods, and formulate a test evolution plan.

[0102] Step B: Sort out typical business scenarios, organize all business office staff to independently write test scripts, promote coverage of common scenarios, and test coverage of interfaces, data, and business test types.

[0103] Step C: Analyze and combine business scenarios across the two levels of testing, and implement two-level joint debugging testing.

[0104] Step D: Add regression tags and inspection tags to key business scenarios. The regression tags are used for release regression testing, and the inspection tags are used for daily inspections of the production system.

[0105] Step 5: In the DevOps platform, based on the quality capability domain and subdomains, collect software quality capability domain data as sample data for the quality autonomous assessment algorithm model. The quality capability domain types include architecture quality, requirement analysis quality, CI / CD quality, multi-layer testing quality, data quality, release quality, configuration and change. Based on the sample data, the degree of self-control of software quality is evaluated, and weak links in quality control are recommended. The system is optimized and improved, thereby achieving the improvement of the maturity of self-control of software quality.

[0106] Table 3 shows a list of software quality capability domains in this embodiment:

[0107]

[0108] Table 3

[0109] The DevOps-based autonomous software quality control method described in this invention addresses the limitations of traditional software quality management and improves the security of online systems in information communications. This method reduces external dependencies, safeguards production safety, and standardizes operational development specifications from the bottom up, establishing unified requirements across architecture, components, and source code. This method uses tool-based testing and acceptance to reduce external dependencies and safeguard production safety, enabling intelligent operations, rapid delivery, and rapid support. It also automates the CI / CD software process, introducing automated methods in continuous integration, continuous testing, and continuous deployment, enabling rapid software quality checks and software application releases. This method builds an integrated, open, and intelligent operations system, achieving visualization, automation, and intelligent operation and maintenance, fostering faster and more robust feedback processing capabilities, and promoting a transformation in operations and maintenance models. This transforms IT support, bringing autonomy and empowerment. Through the practice of this "independent software quality operation" system, customer IT system construction has shifted from a focus on "vendor system development" to one centered on "intellectual property autonomy," enabling capability sharing and empowerment.

Claims

1. A DevOps-based software quality autonomous control method, characterized by: The steps include: Step 1: Build a DevOps platform and standardize development from bottom to top within the DevOps platform. Step 2: Establish a demand workload assessment mechanism within the DevOps platform, including using the FPA function point + DELPHI estimation method to calculate the number of function points based on internal and external data items. A comprehensive assessment of adjustment factors is conducted based on preset standards and specifications, industry benchmark data, and GZW internal and expert experience to derive a range of project quantities. Step 3: Establish a code quality and security audit module within the DevOps platform. This module uses the specifications written by the operator to benchmark scanning rules. Custom rules or self-developed plug-ins are then added. These rules are then configured on the CI / CD platform. Finally, scanning tasks are created, test scans are conducted, problem baselines are determined, and rectification and implementation plans are developed to close the problem loop. Step 4: Within the DevOps platform, focus on single-system testing, moving from functional point-oriented WebUI, interface, and data testing to business scenario-oriented combination testing and cross-system, cross-domain, and cross-pool linkage testing for network-wide integrated services. Select a CPCP two-tiered coordination system to form a closed loop for customer-perceived operations. Step 5: In the DevOps platform, based on the quality capability domain and subdomains, collect software quality capability domain data as sample data for the quality self-assessment algorithm model. Quality capability domain types include architecture quality, requirements analysis quality, CI / CD quality, multi-layer testing quality, data quality, release quality, configuration, and change. Based on the sample data, evaluate the degree of self-control of software quality, recommend weak links in quality control, and optimize and improve the system.

2. The DevOps-based software quality autonomous control method according to claim 1, characterized in that: When executing step 1, the specific steps include: Step S1-1: Standardize frameworks, components, microservice development specifications, construction technologies and methods, and coding standards for mainstream languages ​​​​Java, Python, and Vue; Step S1-2: Standardize the development and testing environment and test entry and exit; Step S1-3: Unified implementation of the tool platform and implementation of the guidance tool platform; Step S1-4: Classify the rule base, standardize the use cases and precipitate the use case library.

3. The DevOps-based software quality autonomous control method according to claim 1, characterized in that: When executing step 1, use the CI / CD platforms built by each operator to implement application development standards, demand analysis, workload assessment, development cost estimation, code quality and security audits, and comprehensive layered testing from an operational perspective.

4. The DevOps-based software quality autonomous control method according to claim 1, characterized in that: When executing step 2, the FPA function point + DELPHI estimation method specifically includes the following steps: Step S2-1: Function Point Calculation: During the project budget phase, the unadjusted function points are calculated using the estimated function point calculation method. The specific formula is as follows: UFP = 35 × ILF + 15 × ELF; Among them, UFP is the unadjusted function point number, the unit is function point; 35 is the internal logic file function point allocation constant; ILF is the number of internal logic files, the unit is piece; 15 is the external interface file function point allocation constant; ELF is the number of external interface files, the unit is piece; In the case of demand cleaning, the estimated function point calculation method is used to calculate the adjusted function points. The specific formula is as follows: UFP=10×ILF+7×ELF+4×EL+5×EO+4×EQ; Among them, UFP is the unadjusted function point number, the unit is function point; 10 is the internal logic file function point allocation constant; ILF is the number of internal logic files, the unit is piece; 7 is the external interface file function point allocation constant; ELF is the number of external interface files, the unit is piece; 4 in 4×EL is the external input function point allocation constant; EL is the external input number, the unit is piece; 5 is the external output function point allocation constant; EO is the external output number, the unit is piece; 4 in 4×EQ is the external query function point allocation constant; EQ is the external query number, the unit is piece; Step S2-2: Scale adjustment, specifically including adjustment of reuse degree and adjustment of implicit requirements and requirement changes; The degree of reuse is adjusted to evaluate the reuse level of the function to be realized and adjust the scale according to the degree of reuse. The specific formula is as follows: US = RUF × UFP; Among them, US is the unadjusted software size, the unit is function point; RUF is the reuse adjustment factor, which is an arbitrary real number between 0 and 1; UFP is the unadjusted function point number, the unit is function point; When calculating the scale using estimated function points, adjust the scale based on the impact of implicit demand and future demand changes. The specific formula is as follows: S = US × CF; Where S is the adjusted software size, in function points; US is the unadjusted software size, in function points; CF is the size change adjustment factor, which can be any real number between 1 and 2. Step S2-3: Workload calculation, the specific formula is as follows: AE = (S × PDR) × X; Among them, AE is the measured workload, the unit is man-hours; S is the adjusted software size, the unit is function point; PDR is the function point time rate, the unit is man-hours per function point.

5. The DevOps-based software quality autonomous control method according to claim 1, characterized in that: The adjustment factor is calculated by applying the application type adjustment factor and the quality characteristic adjustment factor. The application type adjustment factor includes business processing, application integration, technology, multimedia, intelligent information, system, communication control and flow control. Quality characteristic adjustment factors include response speed, integration environment complexity, reliability, and system design capacity; Quality characteristic adjustment factor = (response speed + integration environment complexity + reliability + system design capacity) × 0.14 ÷ 4 + 0.65; Adjustment factor = application type adjustment factor × quality characteristic adjustment factor.

6. The DevOps-based software quality autonomous control method according to claim 1, characterized in that: When executing step 3, the specific steps are as follows: Step 3-1: Party A confirms the release date and version requirements; Step S3-2: The partners clarify the code branching strategy, code submission rules and specifications; Step S3-3: The code is submitted to the git-master branch. The designated person in charge of each system submits the code of the current month's version to the master branch, and a centralized scan is performed two working days before the launch; Step S3-4: The operation team performs sonar code detection to determine whether the acceptance meets the standards: if it meets the standards, execute step S3-8; if it does not meet the standards, execute step S3-5; Step S3-5: The scanned bugs are returned to the partner for development and modification; Step S3-6: If it is not the working day before the launch, then after the modification is completed, execute step S3-3 again; if it is the working day before the launch, execute step S3-7; Step S3-7: The operations team conducts a centralized code scan to determine whether the code meets the standards. If so, proceed to step S3-8. If not, the decision on whether to release the code to Party A is made. If not, proceed to step S3-8. If not, proceed to step S3-9. Step S3-8: The operations team deploys the code online; Step S3-9: The operations team manages the code through Yundao Git, performs code quality scans every month, and issues reports.

Images