A version subscription and automatic delivery method, device, medium and product

Abstract

The application discloses a version subscription and automatic delivery method, device, medium and product, relates to the technical field of software version release, and through the version subscription mechanism provided in the application, key information such as a version number, a branch, a planned release time, a person in charge and demand changes can be recorded centrally, and an automatic notification and a progress tracking mechanism are combined to ensure that all roles can obtain accurate and consistent version states in real time in the same platform. In this way, the problem of information asynchronization is solved, the progress visualization level is indirectly improved, the abnormal discovery time is shortened, reliable data support is provided for responsibility division, and therefore the efficiency and quality of version release are significantly improved.

Description

Technical Field

[0001] This application relates to the field of software version release technology, and in particular to a version subscription and automatic delivery method, device, medium and product. Background Technology

[0002] In current software development and delivery processes, version releases typically rely on the collaboration of multiple roles, including development, testing, and operations teams. While many enterprises have adopted Continuous Integration / Continuous Delivery (CI / CD) platforms to automate builds, tests, and deployments, issues remain regarding version target management, progress tracking, and responsibility allocation.

[0003] The main problem with existing technologies in the software release process is that release information is not synchronized and the transmission efficiency is low, which leads to inconsistent goals and uncontrollable progress at each stage, resulting in abnormal delays and unclear responsibilities. Summary of the Invention

[0004] The purpose of this application is to provide a version subscription and automatic delivery method, device, media and product that can ensure that all roles obtain accurate and consistent version status in real time on the same platform, and realize unified management and automatic synchronization of release information within the CI / CD platform.

[0005] To achieve the above objectives, this application provides the following solution:

[0006] Firstly, this application provides a version subscription and automatic delivery method, including:

[0007] Receive version subscription or requirement change requests initiated by users who request version changes, and create version subscription records. The version subscription records include: version identification information, planned release time, responsible entity information, associated requirement list, and notification recipient information.

[0008] After verifying the uniqueness of the version identifier information, the planned time for each stage of the version is generated by working backward from the preset gray-scale duration, scenario test duration, and regression test duration, thus obtaining the version notification plan and version release plan.

[0009] The difference between the planned time and the current actual time of each stage is scanned at preset time intervals. If the difference is equal to the preset time difference, the IssueTracking module interface is called to retrieve the progress data of the associated requirement list, determine the progress status of the requirement, and push a timed notification containing the progress status to the corresponding responsible entity.

[0010] When the planned time for each stage is reached or a stage is completed, the notification recipients for each stage are determined based on the information of the responsible entity, and the corresponding stage completion information is pushed; at the same time, the version status in the version subscription record is updated according to the completion status of each stage.

[0011] Based on the information on the completion of each stage, the progress of each stage in the entire version release process is calculated, progress visualization data is generated, and the progress visualization data is synchronized to the responsible parties and notification recipients.

[0012] Compare the planned time of each stage in the version release plan with the actual completion time of each stage. If the difference between the two exceeds the preset threshold, an exception log is generated and written to the BlockLog table. Based on the responsible party information, the responsible party for the blockage is determined, and an exception notification is pushed to the responsible party for the blockage and the version requester. The solution submitted by the responsible party for the blockage is received.

[0013] Based on the planned release time, exception logs, and actual completion time of each stage, calculate the total delay days for the version. If the total delay days are 0, the version is classified as an automated release. If the total delay days are greater than 0, determine the delay indicators corresponding to each responsible party, assign preset weights to the delay indicators, and sum them up to obtain the responsibility allocation results.

[0014] Optionally, the step of generating the planned time for each key stage of the version based on the preset gray-scale duration, customer scenario testing duration, and regression testing duration specifically includes:

[0015] The start time of the gray-scale test is obtained by subtracting the preset gray-scale duration from the planned release time.

[0016] The start time of the scene test is obtained by subtracting the preset scene test duration from the start time of the grayscale test.

[0017] The regression test start time is obtained by subtracting the preset regression test duration from the scenario test start time.

[0018] Set the regression test start time to the R&D completion time.

[0019] Optionally, the notification recipient information includes: R&D manager information, test manager information, subscriber information, notify recipient information, and webhook list information; the webhook list information is used to push version-related information to a specified DingTalk group.

[0020] The information on the responsible parties includes: information on the R&D manager, information on the testing manager, information on the operations and maintenance manager, and information on the audit manager.

[0021] Optionally, after receiving the version notification plan and version release plan, it may also include:

[0022] Extract notification object information from the version subscription record, call the DingTalk enterprise open interface to map the mobile phone number or employee number of the notification object to the DingTalk internal UserID, generate a JSON format message body, and push the initial notification to the object corresponding to the UserID.

[0023] Optionally, the progress data of the associated demand list includes: demand status, planned completion time, actual closing time, and responsible person;

[0024] The specific process for determining the progress status of a requirement includes:

[0025] If the current date has not reached the planned completion time and the status is not yet complete, it is considered normal progress.

[0026] If the status is "completed" and the actual closing time is longer than the planned completion time, it is judged as "completed but delayed".

[0027] If the current date is later than the planned completion time and the status is incomplete, it is considered overdue.

[0028] Optionally, information regarding the completion status of the push phase may include:

[0029] The development completion phase will notify the development lead, subscribers, and test lead; the development completion phase information includes: branch information, actual completion time deviation from the plan, and links to test cases;

[0030] The test lead and development lead will be notified at the start of the regression testing phase; the completion information for the start of the regression testing phase includes a link to the test plan;

[0031] The scenario testing phase begins by notifying the scenario testing lead, the testing lead, and the development lead; the completion information for the scenario testing phase includes the test environment address.

[0032] The gray-scale release phase begins by notifying the operations manager, development manager, and testing manager; the completion information for the gray-scale release phase includes the scope of the gray-scale group.

[0033] The official release phase will notify the PM, all subscribers, a list of recipients, and the DingTalk group; the official release phase includes: the version number and the Release Note link.

[0034] Optionally, preset weights are assigned to delay indicators, including:

[0035] The weighting of indicators related to the R&D manager is 30%-40%;

[0036] The weighting of relevant indicators for the test manager is 20%-30%;

[0037] The relevant metrics for the person in charge of scenario testing account for 10%-15% of the weighting;

[0038] The weighting of indicators related to the person in charge of the release is 10%-15%;

[0039] The weighting of version requirement-related metrics is 5%-10%;

[0040] The relevant indicators for the audit manager account for 5%-10% of the weighting.

[0041] In a second aspect, this application provides a computer device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the version subscription and automatic delivery method described in any one of the above.

[0042] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the version subscription and automatic delivery method described in any one of the above descriptions.

[0043] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the version subscription and automatic delivery method described in any one of the above descriptions.

[0044] According to the specific embodiments provided in this application, the following technical effects are disclosed:

[0045] This application provides a version subscription and automatic delivery method, device, medium, and product. The method includes: receiving a version subscription operation or requirement change operation initiated by a version requester, and creating a version subscription record; the version subscription record includes: version identification information, planned release time, responsible entity information, associated requirement list, and notification recipient information; after verifying the uniqueness of the version identification information, the planned time for each stage of the version is generated backward based on preset gray-scale duration, scenario testing duration, and regression testing duration, resulting in a version notification plan and a version release plan; scanning the difference between the planned time of each stage and the current actual time at preset time intervals; if the difference is equal to the preset time difference, calling the IssueTracking module interface to retrieve the progress data of the associated requirement list, determining the requirement progress status, and pushing a timed notification containing the progress status to the corresponding responsible entity; when the planned time of each stage is reached or the stage is completed, determining the relevant responsible entity information to determine the progress status of each stage. The system notifies recipients of stage-specific information and pushes corresponding stage completion status updates. Simultaneously, it updates the version status in the version subscription record based on the completion status of each stage. Based on the stage completion information, it calculates the stage progress of the entire version release process, generates progress visualization data, and synchronizes this data to the responsible parties and notification recipients. It compares the planned time of each stage in the version release plan with the actual completion time of each stage. If the difference exceeds a preset threshold, it generates an exception log and writes it to the BlockLog table. Based on the responsible party information, it identifies the blocking responsible party and pushes exception notifications to the blocking responsible party and the version requester. It receives solutions submitted by the blocking responsible party. Based on the planned release time, exception logs, and actual completion time of each stage, it calculates the total delay days for the version. If the total delay days are 0, the version is classified as an automated release. If the total delay days are greater than 0, it determines the delay indicators corresponding to each responsible party, assigns preset weights to the delay indicators, and performs a weighted summation to obtain the responsibility allocation result. The version subscription mechanism proposed in this application centrally records key information such as version number, branch, planned release date, responsible person, and requirement changes. Combined with automated notifications and progress tracking mechanisms, it ensures that all roles receive accurate and consistent version status in real time on the same platform. This not only solves the problem of information asynchrony but also indirectly improves progress visualization, shortens anomaly detection time, and provides reliable data support for responsibility allocation, thereby significantly improving the efficiency and quality of version releases. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a flowchart illustrating a version subscription and automatic delivery method provided in Embodiment 1 of this application.

[0048] Figure 2 This is a flowchart illustrating a version subscription and automatic delivery method provided in Embodiment 2 of this application.

[0049] Figure 3 This is a schematic diagram of the anomaly detection and blocking process provided in Embodiment 2 of this application.

[0050] Figure 4 This is a schematic diagram of the functional modules of a version subscription and automatic delivery system provided in Embodiment 3 of this application.

[0051] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0053] The current software release process has the following problems:

[0054] Information asynchrony: The lack of unified version release goals, timelines, and task scope among version requesters, developers, testers, security personnel, and operations personnel leads to poor communication and can easily result in version delays or deviations from objectives.

[0055] Lack of visibility into progress: Existing version release processes often rely on manual tracking, lacking automated progress feedback and key milestone notification mechanisms, making it impossible for teams to keep track of project status in real time.

[0056] Delayed handling of anomalies: When blockages or anomalies occur during the release process, the lack of timely notification and resolution mechanisms can easily amplify the problem in subsequent stages, affecting the overall delivery schedule.

[0057] Unclear responsibility: The attribution of responsibility after a failed release is unclear, making it impossible to effectively promote the implementation of improvement and preventive measures at each stage.

[0058] Therefore, there is an urgent need for an automated release management solution that can unify version subscriptions, automatically synchronize release information, track progress, and automatically notify the responsible party in case of anomalies, so as to improve the efficiency and stability of version delivery.

[0059] While many enterprises have adopted Continuous Integration / Continuous Delivery (CI / CD) platforms to automate builds, tests, and deployments, the following issues still exist regarding version target management, progress tracking, and responsibility allocation:

[0060] Version goals and requirements information are not centralized: In the existing process, version release requirements are often recorded in a scattered manner through instant messaging tools (such as DingTalk, WeChat Work), email, or spreadsheet tools (such as Excel, Confluence). This information lacks a unified storage location, making it easy for omissions or untimely updates to occur, resulting in inconsistent understandings of version content and goals among different stages.

[0061] Information dissemination relies on manual processes, which are inefficient and prone to errors: When a version needs to be released, it requires manual notification of each relevant party, including developers, testers, security personnel, and operations staff. Manual dissemination is not only time-consuming and labor-intensive, but also prone to omissions or miscommunication, thus affecting the accuracy of the version schedule.

[0062] Lack of real-time visualization of version progress: Although CI / CD platforms can record build and deployment logs, they often do not provide a cross-team progress overview. Status updates for other stages (such as security testing and regression testing) rely on manual reporting, resulting in a lack of real-time transparency in overall progress and preventing teams from dynamically adjusting their work based on actual conditions.

[0063] Delayed discovery of anomalies and blockages: In the existing process, if a task is not completed on time, the problem is usually not discovered until the next meeting or a critical point. This leads to accumulated delays, missing the best opportunity for remediation, and thus postponing the release of the entire version.

[0064] Vague definition of responsibility: When a version is delayed or a release fails, the lack of unified process data and a traceability mechanism makes it difficult to pinpoint which step or person was responsible for the problem. This not only increases internal conflicts but also hinders subsequent targeted process improvements.

[0065] Incomplete automation capabilities: Although the internal build and deployment processes have been automated, information notification, accountability, and anomaly alerts still rely on manual processes. The level of automation is not high, and efficiency and reliability need to be improved.

[0066] This application aims to address the problems of opaque information, lack of progress visualization, delayed anomaly handling, and unclear division of responsibilities in the existing version release process.

[0067] Definitions of abbreviations and key terms:

[0068] DevOps (Development and Operations): A philosophy and methodology that combines software development with IT operations. Through continuous integration, continuous delivery, automated testing, and monitoring, it enables rapid iteration and high-quality delivery of software products.

[0069] CI (Continuous Integration) refers to developers frequently (usually multiple times a day) integrating code into the main branch and quickly verifying the correctness of the code through automated builds and tests, thereby reducing integration risks and improving development efficiency.

[0070] CD (Continuous Delivery / Continuous Deployment): Continuous delivery emphasizes that, based on continuous integration, software products can be safely and reliably deployed to the production environment at any time; continuous deployment, based on continuous delivery, automatically deploys verified software versions to the production environment, achieving a fully automated deployment process.

[0071] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0072] Example 1:

[0073] In one exemplary embodiment, such as Figure 1 As shown, a version subscription and automatic delivery method is provided, which is executed by a CI / CD platform and includes the following steps S1 to S7. Wherein:

[0074] S1. Receive version subscription or requirement change operations initiated by the version requester and create a version subscription record; the version subscription record includes: version identification information, planned release time, responsible entity information, associated requirement list and notification recipient information.

[0075] The notification recipient information includes: R&D manager information, test manager information, subscriber information, notify recipient information, and webhook list information; the webhook list information is used to push version-related information to designated DingTalk groups.

[0076] The information on the responsible parties includes: information on the R&D manager, information on the testing manager, information on the operations and maintenance manager, and information on the audit manager.

[0077] S2. After verifying the uniqueness of the version identifier information, the planned time for each stage of the version is generated by working backwards based on the preset grayscale duration, scenario test duration, and regression test duration, thus obtaining the version notification plan and version release plan.

[0078] This involves working backward from the preset gray-scale testing duration, customer scenario testing duration, and regression testing duration to generate the planned time for each key stage of the version release, specifically including:

[0079] The start time of the gray-scale test is obtained by subtracting the preset gray-scale duration from the planned release time.

[0080] The start time of the scene test is obtained by subtracting the preset scene test duration from the start time of the grayscale test.

[0081] The regression test start time is obtained by subtracting the preset regression test duration from the scenario test start time.

[0082] Set the regression test start time to the R&D completion time.

[0083] After obtaining the version notification plan and version release plan, the notification object information is extracted from the version subscription record. The DingTalk enterprise open interface is called to map the mobile phone number or employee number of the notification object to the DingTalk internal UserID, generate a JSON format message body, and push the initial notification to the object corresponding to the UserID.

[0084] S3. Scan the difference between the planned time and the current actual time of each stage at preset time intervals. If the difference is equal to the preset time difference, call the IssueTracking module interface to pull the progress data of the associated requirement list, determine the progress status of the requirement, and push a timed notification containing the progress status to the corresponding responsible entity.

[0085] The progress data of the associated requirements list includes: requirement status, planned completion time, actual closure time, and responsible person.

[0086] The specific process for determining the progress status of a demand includes:

[0087] If the current date has not reached the planned completion time and the status is not yet complete, it is considered as normal progress.

[0088] If the status is "completed" and the actual closing time is longer than the planned completion time, it is judged as "completed but delayed".

[0089] If the current date is later than the planned completion time and the status is incomplete, it is considered overdue.

[0090] S4. When the planned time for each stage is reached or the stage is completed, determine the notification recipients for each stage based on the information of the responsible entity, and push the corresponding stage completion information; at the same time, update the version status in the version subscription record according to the completion status of each stage.

[0091] Information regarding the completion status of the corresponding push phase includes:

[0092] The development completion phase will notify the development lead, subscribers, and test lead. The development completion phase information includes: branch information, actual completion time deviation from the plan, and links to test cases.

[0093] The regression testing phase begins by notifying the test lead and development lead; the completion information for the regression testing phase includes a link to the test plan.

[0094] The scenario testing phase begins by notifying the scenario testing lead, the testing lead, and the development lead; the completion information for the scenario testing phase includes the test environment address.

[0095] The gray-scale release phase begins by notifying the operations manager, development manager, and testing manager; the completion information for the gray-scale release phase includes the scope of the gray-scale group.

[0096] The official release phase will notify the PM, all subscribers, a list of recipients, and the DingTalk group; the official release phase includes: the version number and the Release Note link.

[0097] S5. Based on the phase completion information, calculate the phase progress of the entire version release process, generate progress visualization data, and synchronize the progress visualization data to the responsible entities and notification recipients.

[0098] S6. Compare the planned time of each stage in the version release plan with the actual completion time of each stage. If the difference between the two exceeds the preset threshold, generate an exception log and write it to the BlockLog table. Based on the responsible entity information, determine the blocking responsible entity and push the exception notification to the blocking responsible entity and the version requester. Receive the solution submitted by the blocking responsible entity.

[0099] S7. Calculate the total delay days for the version based on the planned release time, exception logs, and actual completion time of each stage. If the total delay days are 0, classify the version as an automated release. If the total delay days are > 0, determine the delay indicators corresponding to each responsible party, assign preset weights to the delay indicators, and sum them up to obtain the responsibility allocation results.

[0100] Specifically, the delay indicators are assigned preset weights, including: 30%-40% for indicators related to the R&D lead; 20%-30% for indicators related to the testing lead; 10%-15% for indicators related to the scenario testing lead; 10%-15% for indicators related to the release lead; 5%-10% for indicators related to the version requirement person; and 5%-10% for indicators related to the audit lead.

[0101] As one specific implementation method, this application can be implemented through the following steps:

[0102] Step 1, Version Subscription:

[0103] 1.1 Creating a subscription:

[0104] In this application, "subscription" refers to the process by which the version requester (PM or development lead) registers and confirms a release plan for a particular version on the CI / CD platform, forming a subscription record that is tracked and managed by the system.

[0105] The specific steps are as follows: The person requesting the version logs into the CI / CD platform, selects the target code branch (Branch Name) on the "Version Subscription" interface, fills in the planned release date (planned_release_date) and the development lead (Dev), and confirms the subscriber (automatically obtained by the platform, i.e., the currently logged-in user).

[0106] The system also requires the following information to be entered in the generated subscription record:

[0107] The bug / issue list is used to describe which features or fixes are included in this version.

[0108] The list of notify users (notify_users) refers to the specific individuals whose version progress information needs to be synchronized.

[0109] The list of webhook addresses for DingTalk groups (ding_webhooks) is used for group notifications.

[0110] When a subscription is created, the system automatically writes the field `version_status="Subscribing"`, indicating that this version is in the planning stage. The `Release Note` field is left blank at this time; it will be automatically filled in by the system later when the version enters the "Release" status. The `Release Note` contains detailed information about all the requirements included in the release version.

[0111] Once a subscription record is stored, it represents the user's "subscription" to that version. This means that the user, relevant responsible persons, and department managers of the participants at each stage will automatically enter the version management process of the system. The system will trigger subsequent milestone calculations, progress notifications, and version tracking based on this record.

[0112] 1.2 After the subscriber fills in the above information and clicks save (version number uniqueness verification), the CI / CD platform automatically saves the version subscription list data for the past six months in CSV format (each subscription field is expanded / formatted to form a row) to the company's DingTalk space, and automatically pushes the table to the company's R&D group to keep everyone informed of the product's release plan and content for the past six months in a synchronized manner.

[0113] 1.3 The value of the planned release time field in the version subscription is used to deduce the development completion time, regression test start time, AF test and scenario test start time, and gray-scale test start time based on the company's gray-scale duration (14d), RC / customer scenario test duration (3d), and regression test duration (1d), and then generate the version notification plan and version release plan.

[0114] The milestone time calculation in this embodiment is as follows:

[0115] Gray-scale testing period = 14 days before release;

[0116] RC / Customer Scenario Testing Time = 3 days before Gray-Scale Testing;

[0117] Regression test time = 1 day before RC;

[0118] Research and development completion time = regression testing time.

[0119] Step 2: Automatic notification upon posting information:

[0120] 2.1 Initial Notification:

[0121] After a subscription is created, the platform immediately invokes the NotificationService module. From the subscription information, including the Development Manager (Dev), Test Manager (QA), subscribers, notify users (notify_users), and the webhook list, the system calls the DingTalk enterprise open interface ( / user / get_by_mobile / user / listid) to map the entered mobile phone number or employee ID to a DingTalk internal UserID. All collected UserIDs are compiled into a list, serving as the target user set for message pushes. The target user ID set is then retrieved, a JSON message body is generated, and the initial notification is sent via the DingTalk API.

[0122] 2.2 Timed / Periodic Notifications:

[0123] The background scheduling module (based on Quartz / Cron timers) scans the MilestoneSchedule table daily. If the current date is 7, 3, 2, or 1 days away from the planned completion date of a task, the system triggers the corresponding reminder. The scheduling module reads the task's responsible person (issue.assignee, issue.creator) and calls the notification module to push the progress status (including exceptions and overdue issues) of the subscribed issues. If overdue, DingTalk notifications urge the project manager and the assignee to pay attention.

[0124] Progress data source:

[0125] The platform periodically calls the IssueTracking module interface (which connects to the Jira / GitLab Issue API) to retrieve the fields of the issue:

[0126] Status (e.g., Open / InProgress / Done);

[0127] Creation time, planned completion time (due_date);

[0128] Actual closing time (closed_at);

[0129] Assignee, creator.

[0130] Progress calculation method:

[0131] Normal progress: current_date ≤ due_date and status ≠Done → progress remains normal;

[0132] Completed: status=Done → Compare due_date and closed_at. If the difference is > 0, mark it as "Completed but delayed by xx days";

[0133] Abnormal / Overdue: current_date > due_date and not closed → marked as "Overdue, postponed for xx days".

[0134] Acquirer and Executor:

[0135] The system background service automatically obtains the IDs (Scheduler + IssueTracking monitor job) and scans all Issue IDs bound to the subscription once a day.

[0136] The processing results are written to the IssueProgress table (issue_id, status, delay_days, update_time).

[0137] Notification mechanism:

[0138] After each test, the platform determines whether there are any abnormalities (overdue, blocked).

[0139] If it exists, call NotificationService to send a DingTalk message.

[0140] The notification recipients include: the issue's creator, assignee, and users (the relevant responsible persons filled in the subscription form).

[0141] 2.3 Key Stage Notification Nodes:

[0142] Development completion time (dev_done_at);

[0143] Notify the R&D manager, subscribers, and testing manager.

[0144] The notification includes: branch information, actual development completion time, deviation from the planned time, and a link to the list of test cases.

[0145] Regression testing begins (qa_start_at);

[0146] Notification recipients: QA (Quality Assurance) lead and DEV (Development) lead.

[0147] Notification content: Test plan link, list of defects to be tested, and version status updated to "Regression Testing in Progress".

[0148] Scenario testing begins (env_test_at);

[0149] Notification recipients: Scenario testing lead (Env), QA, and R&D lead.

[0150] Notification content: Test environment address, scenario test case set, and link to the latest build package.

[0151] Gray-scale deployment begins (gray_start_at);

[0152] Notification recipients: Operations Manager (Ops), Development Manager, and Testing Manager.

[0153] Notification content: Scope of the gray-scale group, description of the change, and gray-scale monitoring indicators.

[0154] The version has been officially released (release_at);

[0155] Notification recipients: PM, all subscribers, list of notifiers, DingTalk group webhook.

[0156] Notification content: version number, release date, and Release Note link.

[0157] 2.4 Status Update:

[0158] Based on the time nodes of each stage (stored in the database), the CI / CD platform automatically verifies the time points and updates the version_status field of the VersionSubscription table: Subscribing → Publishing → Grayscale → Published.

[0159] 2.5 ReleaseNote Auto-fill:

[0160] When a subscription enters the "Publishing" stage, the platform automatically reads the releasenote_url from the table where the platform saves the releasenote, writes it back to the VersionSubscription table, and displays it on the web page.

[0161] 2.6 Version subscriptions can be modified. After modifying the subscription, the entire data can be exported and a DingTalk notification can be used.

[0162] The entire process is almost identical to the creation process (rebuild Excel → upload → summarize notification IDs → calculate milestone times → send individual and group messages). It uses the value of the planned release time field to work backwards and generates version notification plans and version release plans. Incremental display is supported for R&D leads and subscribers.

[0163] Step 3, Progress Tracking and Stage Notification:

[0164] 3.1 The system automatically calculates the key stages in the version release process (development completion, testing completion, security assessment completion, regression testing completion, etc.) based on the time of the stage nodes saved in 2.3 and 2.6.

[0165] 3.2 Upon completion of each stage, the CI / CD platform automatically triggers a notification mechanism to push notifications to relevant personnel, ensuring transparency in the release chain's progress.

[0166] Step 4, Anomaly Detection and Blockage Handling:

[0167] 4.1 Anomaly Detection:

[0168] The system periodically compares the planned_time in the MilestoneSchedule table with the actual_time in the ProgressLog table.

[0169] If the difference exceeds the threshold (>0 days delay), write it to the BlockLog table.

[0170] 4.2 Notification of Abnormalities and Handling of Responsible Persons:

[0171] The notification module is invoked to push delay notifications to the version requester and the person responsible for the blocked process (assignee). When the person responsible for the blocked process creates a subscription in step 1, the department manager to which each participant belongs is saved to the system.

[0172] The person in charge of the blockage submits a solution text through the "CI / CD platform task board" and, if necessary, clicks the "report button" to push the event to their superior's account.

[0173] Step 5: Division of Responsibilities and Performance Evaluation

[0174] Step 5.1, the version subscriptions generated in Step 1.3 and Step 2.6 are successfully published according to the time period plan in the subscription, and are classified as automated publishing, which serves as a positive evaluation of efficiency.

[0175] Step 5.2: If the version is not released as planned, responsibility will be shared according to the rules, and the rules and proportions are as follows:

[0176] Roles: Requirements / Product Manager (PM), Development Lead (Dev), Test Lead (QA), Scenario Testing Lead (Env), CI / Release Lead, Compliance / Security Audit Lead (External).

[0177] Classification of responsible persons and reasons for delay:

[0178] Requirements / Product Manager (PM Requirements / Scope Changes): Number of new / changed requirements and scale of change points (number of requirement points, code churn) after the freeze point (before the development completion time calculated backwards from step 1.3).

[0179] Research and Development (Dev Delay / Quality): The number of days before the regression test time calculated backward from step 1.3 after the completion time of research and development, the density of critical defects, the rework rate, and the number of regression tests missed.

[0180] Testing (QA Delay / Quality): Percentage of automated / manual blocked test cases, number of days the test completion time is later than the RC / customer scenario test time, percentage of repeated opening defects.

[0181] Scenario Test Manager (Env Delay / Quality): Ratio of automated / manual blocked test cases, number of days the test completion time is later than the gray-scale test time, and percentage of repeated opening defects.

[0182] Testing (QA Delay / Quality): Ratio of automated / manual blocked test cases, number of days the test completion time is later than the planned release time in step 1.1 when creating the subscription, and percentage of duplicated defects.

[0183] CI / Release (Pipeline / Artifact): Pipeline failure duration, number of artifact build failures, script issues; the time window is between successful testing and canary release / release.

[0184] External dependencies: third-party systems / interfaces / approval delays, compliance / security audit waiting times.

[0185] Data source:

[0186] Planned release date: VersionSubscription.planned_release_date → derives four milestones.

[0187] Actual time: Status transition time (subscribing → publishing → canary release → published), Jenkins task start / end time, and the first successful `created_at` value of `DialyTestResult`.

[0188] Quality data: DialyTestResult (pass / fail, failure rate), defect export (IssueExport), pipeline logs, availability monitoring.

[0189] Rule percentage calculation steps (data-driven):

[0190] Step 1: Calculate the total number of days of extension:

[0191] 1.1 The system first determines the actual release time of the version:

[0192] If the version has already been released, use the actual release time of the version;

[0193] If the version has not yet been released, the current system time will be used as the "actual time".

[0194] 1.2 The system compares the actual time with the planned release time recorded in the subscription. If the actual time is later than the planned time, the difference is calculated to obtain the number of days of delay for this version; if the actual time is not later than the planned time, the number of days of delay is recorded as 0.

[0195] 1.3 If the delay period is 0 days, it indicates that the version was released on time, and no further responsibility will be assigned, and the process ends.

[0196] Step 2: Collect and quantify the "contribution signals" from each stage:

[0197] If the delay days are greater than zero, the system will proceed with the responsibility allocation calculation. The platform will collect corresponding delay or quality indicators for different roles (R&D, testing, environment, CI, PM, external dependencies) and convert them into numerical contribution signals:

[0198] Research and Development Leader (Dev):

[0199] The system calculates the difference between the actual and planned completion times of R&D, representing a percentage of the overall delay. It also tracks the density of critical defects and the defect rework rate during the R&D phase. The system assigns weights to the delay percentage, critical defect density, and rework rate to quantify the level of responsibility during the R&D phase.

[0200] Test Lead (QA):

[0201] The system calculates the proportion of blocking test cases in the test cases, and combines this with the difference between the actual test completion time and the planned time, as well as the failure rate of automated tests, to form a comprehensive weighting of responsibility for each test stage.

[0202] Scenario / Environment Test Lead (Env):

[0203] The proportion of blocking test cases in system statistical scenario testing or ad-hoc testing, combined with the difference between actual completion and planned completion, and the failure of automated testing, is used to calculate the responsibility ratio of the environmental testing phase.

[0204] Continuous Integration and Release Leader (CI):

[0205] The system tracks metrics such as pipeline failure time and build failure count during the process from test success to release, and quantifies the degree of responsibility based on their proportion of the total delay time.

[0206] Requirements / Product Manager (PM):

[0207] After the system detects the R&D "freeze point" (i.e. the last allowed change point before the planned R&D completion time), it calculates the number and scale of added or modified requirements, compares them with the total requirements recorded at the time of subscription, and determines the percentage of scope changes, thereby representing the contribution of the requester to the delay.

[0208] External dependency:

[0209] The system tracks the waiting time generated by external interface calls, third-party system approvals, security and compliance audits, and calculates its proportion in the total delay time to indicate the responsibility for delays caused by external dependencies.

[0210] Step 3: Formation of Responsibility Results:

[0211] The system combines the values ​​from each of the above steps to obtain the responsibility contribution level for each role.

[0212] If the degree of delay and quality defects in a certain stage directly correspond to the total delay, the proportion of responsibility for that stage will be correspondingly higher;

[0213] If there is no significant delay or defect in a certain link, the system will automatically reduce its responsibility weight.

[0214] Step 6, Automation Support and Improvement Mechanism:

[0215] 6.1 Data tracking for manual processes:

[0216] For parts that are not yet automated (such as external interface approval), the responsible person should manually fill in the information on the platform and write it into the ManualTaskLog table.

[0217] 6.2 Historical Data Analysis:

[0218] The system periodically calls the DataAnalysis module to statistically analyze areas with high defect density, pipeline failure rates, and common bottlenecks.

[0219] Generate optimization suggestions (such as increasing unit test coverage or introducing AI code review) and push them to administrators.

[0220] Example 2:

[0221] This embodiment provides a method for version subscription and automated release management based on a continuous integration / continuous delivery (CI / CD) platform, including the following steps (corresponding to...). Figure 2 (The process shown in the diagram)

[0222] 1. Version Subscription:

[0223] After logging into the CI / CD platform, users who need version information should enter the version subscription interface and fill in the following fields: Version ID, Branch Name, Version Type (feature update / defect fix / emergency patch, etc.), Feature or Defect Description, Planned Completion Date, and Notification Recipient List (individual / DingTalk group webhook). The system will store the version information in the version management database and automatically associate it with the expected project launch time field to generate a version plan.

[0224] The system stores version information in the version management database and automatically associates it with the expected project launch time field to generate version plans.

[0225] 2. Automatic notification for published information:

[0226] Based on the subscription information, the system automatically pushes notifications to the DevOps project team leader, system test leader, security test leader, legacy issue assessment leader, and scenario test leader of the relevant function.

[0227] Notifications can be sent via DingTalk webhook, email, and system messages within the CI / CD platform.

[0228] 3. Progress tracking and phase notification:

[0229] The system automatically records the progress of each stage, including key phases such as development completion, system testing completion, security testing completion, and regression testing completion.

[0230] Once a phase is completed, the CI / CD platform automatically pushes a notification to the person in charge of the next phase and updates the release progress visualization dashboard.

[0231] 4. Please refer to Figure 3 Anomaly detection and blocking handling:

[0232] The system periodically checks the difference between the status of each task and the planned time.

[0233] If a step fails to complete within the time limit, the system will immediately send an exception notification to the person who requested the version and the person in charge of the blocked step.

[0234] The person in charge of the blockage needs to submit a solution within the system, and if necessary, can report it to their direct supervisor with one click for support.

[0235] 5. Division of Responsibilities and Issuance of Evaluation:

[0236] If the version is released as planned, the system records it as an automated release and includes it in the process efficiency metrics.

[0237] If a version is delayed, the system calculates the responsibility ratio according to the responsibility division rules, for example, 60% for the person in charge of automated release and 40% for the person in charge of the delayed process.

[0238] If the responsibility for the abnormal process is clearly defined and the person in charge fails to handle it in a timely manner, then that person in charge shall bear full responsibility.

[0239] 6. Data Analysis and Process Improvement:

[0240] The system collects and analyzes various data from version releases and generates issue statistics reports.

[0241] Analyze the causes of high-frequency issues (such as typos in code and frequent low-level bugs found in the RC environment) and add protective measures in the early stages (unit testing, AI code review, etc.).

[0242] Example 3:

[0243] like Figure 4 As shown, this embodiment provides a version subscription and automatic delivery system, including:

[0244] Version Subscription Module: Used to receive and manage version information subscribed by users.

[0245] Information notification module: Automatically sends notifications to relevant personnel when a version is updated or released.

[0246] Progress tracking module: Used to monitor the progress of version development, testing, and deployment in real time.

[0247] Exception handling module: Used to record, locate, and handle problems when exceptions are detected, and to form a closed-loop feedback.

[0248] Responsibility Assignment Module: Used to automatically analyze and identify the responsible party during the exception handling process.

[0249] Data analysis module: Used to collect operational data from each stage and perform statistical analysis to provide a basis for process optimization.

[0250] Compared with the prior art, this application has the following advantages:

[0251] Transparent throughout the entire process: Version goals, progress, and anomalies can all be tracked in real time, reducing information asymmetry.

[0252] Automated notifications: Reduce the cost of manual communication and improve the timeliness and accuracy of notifications.

[0253] Risks are manageable: Congestion issues are exposed and resolved in a timely manner, reducing the risk of delays.

[0254] Clear accountability: It can be traced back to specific steps and responsible persons, promoting process improvement.

[0255] Continuous optimization: Identify bottlenecks and optimize the release process through data analysis.

[0256] The key technical point of this application is:

[0257] Version subscription mechanism: Automated subscription to version updates based on user or team version concerns. Real-time integration with version control systems (such as Git, SVN, CI / CD platforms).

[0258] Multi-channel information notification mechanism: Supports multiple notification methods such as DingTalk, WeChat Work, email, and SMS. Intelligent push notifications are sent to relevant personnel based on role / responsibilities.

[0259] Progress tracking and visualization: Monitor version status in real time through process nodes (development, testing, deployment, etc.). Provides visual progress charts and status dashboards.

[0260] Anomaly detection and automatic accountability: Abnormal events are automatically recorded, categorized, and tracked in a closed-loop process. By combining version change records and operation logs, the system automatically analyzes who is responsible.

[0261] Historical data analysis and optimization: Collect data from the entire version flow process and perform statistical analysis. Provide process bottleneck analysis and improvement suggestions based on historical data.

[0262] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 5 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a version subscription and automatic delivery method.

[0263] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0264] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0265] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0266] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0267] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0268] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0269] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0270] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0271] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A version subscription and automatic delivery method, characterized in that, include: Receive version subscription or requirement change requests initiated by users, and create version subscription records; The version subscription record includes: version identification information, planned release time, responsible entity information, list of related requirements, and notification recipient information; After verifying the uniqueness of the version identifier information, the planned time for each stage of the version is generated by working backward from the preset gray-scale duration, scenario test duration, and regression test duration, thus obtaining the version notification plan and version release plan. The difference between the planned time and the current actual time of each stage is scanned at preset time intervals. If the difference is equal to the preset time difference, the IssueTracking module interface is called to retrieve the progress data of the associated requirement list, determine the progress status of the requirement, and push a timed notification containing the progress status to the corresponding responsible entity. When the planned time for each stage is reached or a stage is completed, the notification recipients for each stage are determined based on the information of the responsible entity, and the corresponding stage completion information is pushed out; at the same time, the version status in the version subscription record is updated according to the completion status of each stage. Based on the information on the completion of each stage, the progress of each stage in the entire version release process is calculated, progress visualization data is generated, and the progress visualization data is synchronized to the responsible parties and notification recipients. Compare the planned time of each stage in the version release plan with the actual completion time of each stage. If the difference between the two exceeds the preset threshold, an exception log is generated and written to the BlockLog table. Based on the responsible party information, the responsible party for the blockage is determined, and an exception notification is pushed to the responsible party for the blockage and the version requester. The solution submitted by the responsible party for the blockage is received. Based on the planned release time, exception logs, and actual completion time of each stage, calculate the total delay days for the version. If the total delay days are 0, the version is classified as an automated release. If the total delay days are greater than 0, determine the delay indicators corresponding to each responsible party, assign preset weights to the delay indicators, and sum them up to obtain the responsibility allocation results.

2. The version subscription and automatic delivery method according to claim 1, characterized in that, The process involves working backward from the preset gray-scale testing duration, customer scenario testing duration, and regression testing duration to generate the planned time for each key stage of the version release, specifically including: The start time of the gray-scale test is obtained by subtracting the preset gray-scale duration from the planned release time. The start time of the scene test is obtained by subtracting the preset scene test duration from the start time of the grayscale test. The regression test start time is obtained by subtracting the preset regression test duration from the scenario test start time. Set the regression test start time to the R&D completion time.

3. The version subscription and automatic delivery method according to claim 1, characterized in that, The notification recipient information includes: R&D manager information, test manager information, subscriber information, notify recipient information, and webhook list information; the webhook list information is used to push version-related information to designated DingTalk groups. The information on the responsible parties includes: information on the R&D manager, information on the testing manager, information on the operations and maintenance manager, and information on the audit manager.

4. The version subscription and automatic delivery method according to claim 1, characterized in that, After receiving the version notification plan and version release plan, it also includes: Extract notification object information from the version subscription record, call the DingTalk enterprise open interface to map the mobile phone number or employee number of the notification object to the DingTalk internal UserID, generate a JSON format message body, and push the initial notification to the object corresponding to the UserID.

5. The version subscription and automatic delivery method according to claim 1, characterized in that, The progress data of the associated requirements list includes: requirement status, planned completion time, actual closure time, and responsible person; The specific process for determining the progress status of a requirement includes: If the current date has not reached the planned completion time and the status is not yet complete, it is considered normal progress. If the status is "completed" and the actual closing time is longer than the planned completion time, it is judged as "completed but delayed". If the current date is later than the planned completion time and the status is incomplete, it is considered overdue.

6. The version subscription and automatic delivery method according to claim 1, characterized in that, Information regarding the completion status of the corresponding push phase includes: The development completion phase will notify the development lead, subscribers, and test lead; the development completion phase information includes: branch information, actual completion time deviation from the plan, and links to test cases; The test lead and development lead will be notified at the start of the regression testing phase; the completion information for the start of the regression testing phase includes a link to the test plan; The scenario testing phase begins by notifying the scenario testing lead, the testing lead, and the development lead; the completion information for the scenario testing phase includes the test environment address. The gray-scale release phase begins by notifying the operations manager, development manager, and testing manager; the completion information for the gray-scale release phase includes the scope of the gray-scale group. The official release phase will notify the PM, all subscribers, a list of recipients, and the DingTalk group; the official release phase includes: the version number and the Release Note link.

7. The version subscription and automatic delivery method according to claim 1, characterized in that, Preset weights are assigned to delay metrics, including: The weighting of indicators related to the R&D manager is 30%-40%; The weighting of relevant indicators for the test manager is 20%-30%; The relevant metrics for the person in charge of scenario testing account for 10%-15% of the weighting; The weighting of indicators related to the person in charge of the release is 10%-15%; The weighting of version requirement-related metrics is 5%-10%; The relevant indicators for the audit manager account for 5%-10% of the weighting.

8. A computer device, comprising: A memory, a processor, and a computer program stored on the memory and capable of running on the processor, characterized in that the processor executes the computer program to implement the version subscription and automatic delivery method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the version subscription and automatic delivery method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the version subscription and automatic delivery method as described in any one of claims 1-7.

Images