Version subscription and automatic delivery method and device based on DevOps, equipment, medium and product

Abstract

The invention discloses a version subscription and automatic delivery method and device based on DevOps, equipment, a medium and a product, and relates to the technical field of software version publication. Through a version subscription mechanism provided by the invention, key information such as a version number, branches, plan publication time, a person in charge and demand change can be recorded in a centralized manner; and an automatic notification and progress tracking mechanism is combined, so that all roles can obtain accurate and consistent version states in the same platform in real time. Therefore, the problem of information asynchronization is solved, the progress visualization level is indirectly improved, the exception discovery time is shortened, reliable data support is provided for responsibility division, and the version release efficiency and quality are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software version release, in particular to a version subscription and automatic delivery method and device based on DevOps, equipment, medium and product. BACKGROUND

[0002] In the current software development and delivery process, version release usually relies on the coordination of multiple roles such as the development team, the test team, and the operation and maintenance team. Although many enterprises have introduced continuous integration / continuous delivery (CI / CD) platforms to achieve automation of building, testing, and deployment, there are still problems in version target management, progress tracking, and responsibility division.

[0003] The main problem in the prior art in the software version release process is that the release information is not synchronized and the transmission efficiency is low, which leads to inconsistent goals and uncontrollable progress in each link, and further causes abnormal delay and unclear responsibility. SUMMARY

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

[0005] To achieve the above-mentioned purpose, the present application provides the following solutions: In a first aspect, the present application provides a version subscription and automatic delivery method based on DevOps, comprising: receiving a version subscription operation or a requirement change operation initiated by a version requirement person, and creating a version subscription record; the version subscription record includes version identification information, planned release time, responsibility subject information, associated requirement list, and notification object information; After uniqueness verification of the version identification information, the planned time of each stage of the version is generated by back calculation according to the preset gray duration, scene test duration, and regression test duration, to obtain a version notification plan and a version release plan; Every preset time interval scans the difference between the planned time of each stage and the current actual time, and if the difference is a preset time difference, an IssueTracking module interface is called to pull the progress data of the associated requirement list, judge the requirement progress state, and push a timed notification containing the progress state to the corresponding responsibility subject; When the planned time of each stage is reached or the stage is completed, the notification object of each stage is determined according to the responsibility subject information, and the stage completion information is pushed accordingly; at the same time, the version state in the version subscription record is updated according to the completion state of each stage; Based on the phase completion information, the phase progress of the version release whole process is calculated, progress visualization data is generated, and the progress visualization data is synchronized to the responsible subject and the notification object; If the difference between the planned time of each phase in the version release plan and the actual completion time of each phase exceeds the preset threshold, an abnormal log is generated and written into the BlockLog table, the blocking responsible subject is determined based on the responsible subject information, and the abnormal notification is pushed to the blocking responsible subject and the version demand person; receiving the solution submitted by the blocking responsible subject; According to the planned release time, the abnormal log and the actual completion time of each phase, the total delay days of the version are calculated; if the total delay days are 0, the version is classified as automatic release; if the total delay days> 0, the delay index corresponding to each responsible subject is determined, the delay index is assigned a preset weight and weighted summation is performed to obtain the responsibility division result.

[0006] Optionally, the planned time of each key phase of the version is generated by backtracking according to the preset gray time length, customer scene test time length and regression test time length, specifically including: The gray test start time is obtained by subtracting the preset gray time length from the planned release time; The scene test start time is obtained by subtracting the preset scene test time length from the gray test start time; The regression test start time is obtained by subtracting the preset regression test time length from the scene test start time; The regression test start time is set as the R&D completion time.

[0007] Optionally, the notification object information includes: R&D responsible person information, test responsible person information, subscriber information, notifier information and webhook list information; the webhook list information is used to push version related information to the specified DingDing group; The responsible subject information includes: R&D responsible person information, test responsible person information, operation and maintenance responsible person information and audit responsible person information.

[0008] Optionally, after obtaining the version notification plan and the version release plan, it further includes: The notification object information is extracted from the version subscription record, the DingDing enterprise open interface is called to map the mobile phone number or work number of the notification object to the DingDing internal UserID, the JSON format message body is generated, and the initial notification is pushed to the object corresponding to the UserID.

[0009] Optionally, the progress data associated with the requirement list includes: requirement state, planned completion time, actual closing time and responsible person; The specific process of judging the requirement progress state includes: When the current date does not reach the planned completion time and the state is not completed, it is determined as normal progress; When the state is completed and the actual closing time is greater than the planned completion time, it is determined as completed but delayed; When the current date is greater than the planned completion time and the state is not completed, it is determined as overdue.

[0010] Optionally, the push stage completion information specifically includes: The R&D completion stage notifies the R&D person in charge, the subscriber and the test person in charge; the stage completion information of the R&D completion stage includes branch information, actual completion time and planned deviation, and to-be-tested case link; The regression test start stage notifies the test person in charge and the R&D person in charge; the stage completion information of the regression test start stage includes a test plan link; The scene test start stage notifies the scene test person in charge, the test person in charge and the R&D person in charge; the stage completion information of the scene test start stage includes a test environment address; The gray release start stage notifies the operation and maintenance person in charge, the R&D person in charge and the test person in charge; the stage completion information of the gray release start stage includes a gray group range; The version formal release stage notifies the PM, all subscribers, the list of notifiers and Dingding groups; the version formal release stage includes a version number and a ReleaseNote link.

[0011] Optionally, a preset weight is given to the delay index, specifically including: The R&D person in charge related index weight accounts for 30%-40%; The test person in charge related index weight accounts for 20%-30%; The scene test person in charge related index weight accounts for 10%-15%; The release person in charge related index weight accounts for 10%-15%; The version demand person related index weight accounts for 5%-10%; The audit person in charge related index weight accounts for 5%-10%.

[0012] In a second aspect, the present 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 DevOps-based version subscription and automatic delivery method in any one of the above.

[0013] In a third aspect, the present application provides a computer readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the DevOps-based version subscription and automatic delivery method in any one of the above.

[0014] In a fourth aspect, the present application provides a computer program product comprising a computer program which, when executed by a processor, implements the DevOps-based version subscription and automatic delivery method of any one of the above.

[0015] According to the specific embodiments provided in the present application, the following technical effects are disclosed: The present application provides a DevOps-based version subscription and automatic delivery method, device, equipment, medium and product, which comprises the following steps: receiving a version subscription operation or a demand change operation initiated by a version demand person, and creating a version subscription record; the version subscription record comprises version identification information, planned release time, responsible subject information, associated demand list and notification object information; after the uniqueness of the version identification information is verified, the planned time of each stage of the version is generated by back calculation according to the preset gray duration, scene test duration and regression test duration, and the version notification plan and the version release plan are obtained; every preset time interval scans the difference between the planned time of each stage and the current actual time, if the difference is a preset time difference, an IssueTracking module interface is called to pull the progress data of the associated demand list, the demand progress state is judged, and a timing notification containing the progress state is pushed to the corresponding responsible subject; when the planned time of each stage is reached or the stage is completed, the notification objects of each stage are determined according to the responsible subject information, and the stage completion information is pushed correspondingly; at the same time, the version state in the version subscription record is updated according to the completion state of each stage; based on the stage completion information, the stage progress of the version release whole process is calculated, the progress visualization data is generated, and the progress visualization data is synchronized to the responsible subject and the notification object; the planned time of each stage in the version release plan is compared with the actual completion time of each stage, if the difference between the two exceeds a preset threshold, an exception log is generated and written into a BlockLog table, and the blocking responsible subject is determined based on the responsible subject information, and an exception notification is pushed to the blocking responsible subject and the version demand person; receiving the solution submitted by the blocking responsible subject; calculating the total delay days of the version according to the planned release time, the exception log and the actual completion time of each stage; if the total delay days are 0, the version is classified as automatic release; if the total delay days > 0, the delay indicators corresponding to each responsible subject are determined, the delay indicators are given a preset weight and weighted summation, and the responsibility division result is obtained. Through the version subscription mechanism provided in the present application, the version number, branch, planned release time, responsible person, demand change and other key information can be recorded centrally, and combined with the automatic notification and progress tracking mechanism, all roles can obtain accurate and consistent version state in real time in the same platform. In this way, not only the problem of information asynchronization is solved, but also the progress visualization level is indirectly improved, the exception discovery time is shortened, and reliable data support is provided for responsibility division, thereby significantly improving the efficiency and quality of version release. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description only constitute some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0017] Figure 1 A flowchart of a version subscription and automatic delivery method based on DevOps provided by an embodiment of the present application.

[0018] Figure 2 A flowchart of a version subscription and automatic delivery method based on DevOps provided by an embodiment of the present application.

[0019] Figure 3 An abnormality detection and blocking processing flowchart provided by the second embodiment of the present application.

[0020] Figure 4 A functional module schematic diagram of a version subscription and automatic delivery based on DevOps provided by the third embodiment of the present application.

[0021] Figure 5 A structural schematic diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0022] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments only constitute some embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort belong to the protection scope of the present application.

[0023] In the current software version release process, the following problems exist: Information is not synchronized: There is a lack of unified version release target, time node and task range information among version demand persons, development, testing, security, operation and maintenance and other links, which leads to poor communication and easy occurrence of version delay or target deviation.

[0024] Progress is not visualized: The existing version release process often relies on manual tracking, lacks automatic progress feedback and key node notification mechanism, and the team cannot grasp the project status in real time.

[0025] Abnormality processing is lagging: When there is a blockage or abnormality in the release link, there is a lack of timely notification and solution mechanism, and the problem is easy to be amplified in the subsequent link, affecting the overall delivery progress.

[0026] 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.

[0027] 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.

[0028] 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: 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.

[0029] Information dissemination relies on manual processes, which are inefficient and prone to errors: When a version needs to be released, it requires manual notification to 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] The present application aims to solve the problems of information opacity, progress invisibility, exception handling lag and unclear responsibility division in the existing version release process.

[0035] Abbreviations and key terms are defined as follows: DevOps (Development and Operations): a concept and methodology that combines software development (Development) and information technology operations (Operations), through means such as continuous integration, continuous delivery, automated testing and monitoring, to achieve rapid iteration and high-quality delivery of software products.

[0036] CI (Continuous Integration): refers to the integration of code by developers into the main branch frequently (usually multiple times a day), and the rapid verification of code correctness through automated building and testing, thereby reducing integration risks and improving development efficiency.

[0037] CD (Continuous Delivery / Continuous Deployment): Continuous Delivery emphasizes that on the basis of Continuous Integration, software products can be safely and reliably deployed to production environment at any time; Continuous Deployment, on the basis of Continuous Delivery, automatically deploys verified software versions to production environment, achieving fully automated online process.

[0038] To make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application will be further described in detail below in conjunction with the drawings and specific embodiments.

[0039] Embodiment one: In an exemplary embodiment, as shown in Figure 1 A DevOps-based version subscription and automatic delivery method is provided, which is executed by a CI / CD platform and includes the following steps S1 to S7. Among them: S1, receiving version demand person initiated version subscription operation or demand change operation, and creating version subscription record; the version subscription record includes: version identification information, planned release time, responsibility subject information, associated demand list and notification object information.

[0040] The notification object information includes: R&D responsible person information, test responsible person information, subscriber information, notifier information and webhook list information; the webhook list information is used to push version related information to the specified DingDing group.

[0041] The responsibility subject information includes: R&D responsible person information, test responsible person information, operation and maintenance responsible person information and audit responsible person information.

[0042] S2, after the uniqueness verification of the version identification information, the planned time of each stage of the version is generated by backtracking according to the preset gray scale time length, scene test time length and regression test time length, and version notification plan and version release plan are obtained.

[0043] The planned time of each key stage of the version is generated by backtracking according to the preset gray scale time length, customer scene test time length and regression test time length, and specifically includes: The gray scale test start time is obtained by subtracting the preset gray scale time length from the planned release time; The scene test start time is obtained by subtracting the preset scene test time length from the gray scale test start time; The regression test start time is obtained by subtracting the preset regression test time length from the scene test start time; The regression test start time is set as the R&D completion time.

[0044] After obtaining the version notification plan and the version release plan, the notification object information is extracted from the version subscription record, the Dingding enterprise open interface is called to map the mobile phone number or the work number of the notification object to the Dingding internal UserID, the JSON format message body is generated, and the initial notification is pushed to the object corresponding to the UserID.

[0045] S3, the difference between the planned time of each stage and the current actual time is scanned every preset time interval, if the difference is a preset time difference, the IssueTracking module interface is called to pull the progress data of the associated requirement list, the requirement progress state is judged, and the timing notification containing the progress state is pushed to the corresponding responsible subject.

[0046] The progress data of the associated requirement list includes: requirement state, planned completion time, actual closing time and responsible person.

[0047] The specific process of judging the requirement progress state includes: When the current date does not reach the planned completion time and the state is not completed, it is judged as normal progress.

[0048] When the state is completed and the actual closing time is greater than the planned completion time, it is judged as completed but delayed.

[0049] When the current date is greater than the planned completion time and the state is not completed, it is judged as overdue.

[0050] S4, when the planned time of each stage is reached or the stage is completed, the notification object of each stage is determined according to the responsible subject information, and the stage completion information is pushed correspondingly; at the same time, the version state in the version subscription record is updated according to the completion state of each stage.

[0051] The corresponding push stage completion information specifically includes: The development completion stage notifies the development person in charge, the subscriber, and the test person in charge; the stage completion information of the development completion stage includes branch information, actual completion time and plan deviation, and to-be-tested use case link.

[0052] The regression test start stage notifies the test person in charge and the development person in charge; the stage completion information of the regression test start stage includes a test plan link.

[0053] The scenario test start stage notifies the scenario test person in charge, the test person in charge, and the development person in charge; the stage completion information of the scenario test start stage includes a test environment address.

[0054] The gray release start stage notifies the operation and maintenance person in charge, the development person in charge, and the test person in charge; the stage completion information of the gray release start stage includes a gray group range.

[0055] The version formal release stage notifies the PM, all subscribers, the list of notifiers, and Dingding groups; the version formal release stage includes a version number and a ReleaseNote link.

[0056] S5, based on the stage completion information, calculate the stage progress of the version release whole process, generate progress visualization data, and synchronize the progress visualization data to the responsible subject and the notification object.

[0057] 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 a preset threshold, generate an exception log and write it into a BlockLog table, and determine the blocking responsible subject based on the responsible subject information, push the exception notification to the blocking responsible subject and the version demand person; receive the solution submitted by the blocking responsible subject.

[0058] S7, according to the planned release time, the exception log and the actual completion time of each stage, calculate the total delay days of the version; if the total delay days is 0, the version is classified as an automatic release; if the total delay days > 0, determine the delay index corresponding to each responsible subject, assign a preset weight to the delay index, and weighted sum to get the responsibility division result.

[0059] Among them, the preset weight is assigned to the delay index, specifically including: the weight proportion of the development person in charge related index is 30%-40%. The weight proportion of the test person in charge related index is 20%-30%. The weight proportion of the scenario test person in charge related index is 10%-15%. The weight proportion of the release person in charge related index is 10%-15%. The weight proportion of the version demand person related index is 5%-10%. The weight proportion of the audit person in charge related index is 5%-10%.

[0060] As a specific implementation, the present application can be specifically implemented by the following steps: Step 1, version subscription: 1.1, creating a subscription: The "subscription" in the present application refers to that a version demander (PM or development owner) registers and confirms the release plan of a version on the CI / CD platform, thereby forming a subscription record tracked and managed by the system.

[0061] The specific operation is that the version demander logs in the CI / CD platform, selects the target code branch (Branch Name) in the "version subscription" interface, fills in the planned release date (planned_release_date) and development owner (dev_owner) of the version plan, and confirms the subscriber (which is automatically obtained by the platform, i.e., the current login user).

[0062] In the generated subscription record, the system also requires filling in: bug / issue list (issue_list), which is used to explain which functions or repair items are included in the version; notify_users, i.e., the specific personnel to which the version progress information needs to be synchronized; ding_webhooks, which is used for group notification.

[0063] When the subscription is created, the system automatically writes the field version_status="subscription" in the subscription record, which indicates that the version is in the planning stage. The Release Note field is not filled in at this time, and the corresponding ReleaseNote URL will be automatically filled in by the system when the version enters the "release" state. Release Note is the detailed information of all requirements included in the release version.

[0064] After a subscription record is stored, it represents the "subscription" of the user to the version, i.e., the user and the related responsible person, the department manager of each stage participant automatically enter the version process managed by the system, and the system will trigger the subsequent milestone calculation, progress notification and version tracking based on this record.

[0065] 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 in csv format (each subscription is expanded / formatted as a field, forming a row) to the company's Dingding space for nearly half a year, and automatically pushes the table to the company's R&D group to synchronize all R&D facts in real time to update the product's release plan and release content for nearly half a year.

[0066] 1.3. The value of the planned release time field in the version subscription is calculated according to the company's gray time (14d), RC / customer scenario test time (3d), regression test time (1d), and the research and development completion time, regression test start time, scenario test start time, and gray test start time are calculated, and the version notification plan and version release plan are generated.

[0067] The milestone time of the embodiment is calculated as follows: Gray test time = 14 days before release; RC / customer scenario test time = 3 days before gray test; Regression test time = 1 day before RC; Research and development completion time = regression test time.

[0068] Step 2, automatic notification of release information: 2.1, initial notification: After creating a subscription, the platform immediately calls the notification module (NotificationService) to map the mobile phone number or employee ID filled in from the research and development owner (dev_owner), test owner (qa_owner), subscriber, notifier (notify_users), and webhook list included in the subscription information to DingTalk internal UserID by calling the DingTalk enterprise open interface ( / user / get_by_mobile / user / listid). All collected UserID form a list as the target user set for message pushing. After obtaining the target UserID set, a JSON message body is generated, and the first notification is sent through the DingTalk API.

[0069] 2.2, timed / periodic notification: The background scheduling module (based on Quartz / Cron timer) scans the MilestoneSchedule table every day, and if the "current date" is equal to 7, 3, 2, and 1 days away from the planned completion date of a task, the system triggers the corresponding reminder, and the scheduling module reads the task assignee (issue.assignee, issue.creator) and calls the notification module to push the progress of the issue in the subscription (including exceptions and overdue). If it is overdue, DingTalk will notify the project manager and assignee to pay attention.

[0070] Progress data source: The platform will regularly call the IssueTracking module interface (interface to Jira / GitLab Issue API) to pull the fields of the issue: Status (status, such as Open / InProgress / Done); Creation time, planned completion time (due_date); Actual closing time (closed_at); Responsible person (assignee), creator (creator).

[0071] Progress calculation method: Normal progress: current_date≤due_date and status≠Done→progress remains normal; Completed: status=Done→compare due_date and closed_at, if the difference>0, mark as "completed but delayed xx days"; Abnormal / overdue: current_date>due_date and not closed→marked as "overdue, delayed xx days".

[0072] Acquirer and performer: Automatically acquired by system background service (Scheduler+IssueTracking monitor job), scan all Issue IDs bound to this subscription once a day.

[0073] The processing result is written into the IssueProgress table (issue_id, status, delay_days, update_time).

[0074] Notification mechanism: After each detection, the platform judges whether there is an exception (overdue, blocked).

[0075] If there is, call NotificationService to send DingTalk message.

[0076] The notification objects include: the creator (creator) of the issue, the assignee (assignee), and the user (the relevant responsible person filled in the subscription table).

[0077] 2.3, Key stage notification node: Development completion time (dev_done_at); Notify the development responsible person, subscriber, and test responsible person.

[0078] The notification content includes: branch information, development completion actual time, deviation from planned time, and test case list link.

[0079] Regression test start (qa_start_at); Notification object: test responsible person (QA), development responsible person (Dev).

[0080] Notification content: Test plan link, defect list to be tested, version status updated to "Regression testing".

[0081] Hang test / scene test start (env_test_at); Notification object: Scene test responsible person (Env), QA, R&D responsible person.

[0082] Notification content: Test environment address, scene test case set, latest build package link.

[0083] Gray release start (gray_start_at); Notification object: Operation responsible person (Ops), R&D responsible person, test responsible person.

[0084] Notification content: Gray group range, change description, gray monitoring index.

[0085] Version official release (release_at); Notification object: PM, all subscribers, notification list, Dingding group Webhook.

[0086] Notification content: Version number, release time, Release Note link.

[0087] 2.4, Status update: According to the time node of each stage (saved in the database), CI / CD platform automatically checks the time point to update the field version_status in VersionSubscription table: subscribed-> released-> gray-> released.

[0088] 2.5, ReleaseNote automatic backfill: When subscription enters "released", the platform automatically reads releasenote_url from the table where the platform saves releasenote, writes back to VersionSubscription table, and displays it on the web page.

[0089] 2.6, Version subscription supports modification, and after modifying the subscription, the full export is used and Dingding notification is used: The whole process is almost the same as creation (rebuild Excel-> upload-> summarize notification ID-> calculate milestone time-> send personal and group messages), according to the value of the planned release time field, the time is deduced to generate version notification plan and version release plan. R&D responsible person, subscriber supports incremental display.

[0090] Step 3, progress tracking and stage notification: 3.1、System automatically calculates the key stages in the version release process (development completion, test completion, security assessment completion, regression test completion, etc.) according to the node time saved in 2.3, 2.6.

[0091] 3.2、After the completion of each stage, the CI / CD platform automatically triggers the notification mechanism and automatically pushes notifications to the relevant responsible persons to ensure the transparency of the progress of the release chain.

[0092] Step 4, Abnormality detection and blocking processing: 4.1、Abnormality detection: The system compares the planned_time in the MilestoneSchedule table with the actual_time in the ProgressLog table at regular intervals.

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

[0094] 4.2、Abnormal notification and responsibility handling: Call the notification module to push the delay notification to the version requirement person and the blocking link responsible person (assignee). The blocking responsible person saves the department managers of the participants in each stage to the system when creating the subscription in step 1.

[0095] The blocking responsible person submits the solution (solution text) through the "CI / CD platform task board" and clicks the "report button" if necessary to push the event to his superior's account.

[0096] Step 5, Responsibility division and assessment Step 5.1、The version subscription generated in step 1.3 and step 2.6 is planned for smooth release according to the time period in the subscription, classified as automated release, as positive efficiency evaluation.

[0097] Step 5.2、If the version is not released as planned, the responsibility is divided according to the rules, and the rules and proportion are as follows: Roles: issue creator (PM), development responsible person (Dev), test responsible person (QA), scene test responsible person (Env), CI / release responsible person, compliance / security audit responsible person (External) Responsibility person, delay reason classification: Issue creator (PM requirement / changes): The number of new / changed requirements after the freeze point (the development completion time of step 1.3) and the size of the change point (number of requirements, code churn).

[0098] Dev (Dev delay / quality): Days of dev completion time later than regression test time in step 1.3, critical defect density, rework rate, regression test missing.

[0099] Test (QA delay / quality): Automation / manual blocking case ratio, days of test completion time later than RC / customer scenario test time, repeated opening defect ratio.

[0100] Scenario test leader (Env delay / quality): Automation / manual blocking case ratio, days of test completion time later than gray test time, repeated opening defect ratio.

[0101] Test (QA delay / quality): Automation / manual blocking case ratio, days of test completion time later than planned release time in step 1.1, repeated opening defect ratio.

[0102] CI / release (pipeline / product): Pipeline failure duration, product build failure times, script problems; time window between test pass and gray release / publish.

[0103] External dependency (External): Third-party system / interface / approval blocking duration, compliance / security audit waiting.

[0104] Data sources: Planned time: VersionSubscription.planned_release_date→Deduce four milestones.

[0105] Actual time: Status transition time (in subscription→in release→in gray release→published), Jenkins task start / end time, DialyTestResult first pass created_at.

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

[0107] Rule ratio calculation steps (data driven): Step 1: Calculate total delay days: 1.1, the system first determines the actual release time of the version: If the version has been released, take the actual release time of the version; If the version has not been released, take the current system time as the "actual time".

[0108] 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.

[0109] 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.

[0110] Step 2: Collect and quantify the "contribution signals" from each stage: If the delay days are greater than zero, the system will proceed with responsibility allocation calculations. The platform will collect corresponding delay or quality metrics for different roles (R&D, testing, environment, CI, PM, external dependencies) and convert them into numerical contribution signals: Research and Development Leader (Dev): 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 critical defect density and 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.

[0111] Test Lead (QA): 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.

[0112] Scenario / Environment Test Lead (Env): 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.

[0113] Continuous Integration and Release Leader (CI): 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.

[0114] Requirements / Product Manager (PM): 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.

[0115] External dependency: 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.

[0116] Step 3: Formation of Responsibility Results: The system combines the values ​​from each of the above steps to obtain the responsibility contribution level for each role.

[0117] 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; If there is no significant delay or defect in a certain link, the system will automatically reduce its responsibility weight.

[0118] Step 6, Automation Support and Improvement Mechanism: 6.1 Data tracking in manual processes: 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.

[0119] 6.2 Historical Data Analysis: The system periodically calls the DataAnalysis module to statistically analyze areas with high defect density, pipeline failure rates, and common bottlenecks.

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

[0121] Example 2: 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) 1. Version Subscription: 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.

[0122] 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.

[0123] 2. Automatic notification for published information: The system automatically pushes notifications to the DevOps project team leader, system test leader, security test leader, legacy problem assessment leader, and scenario test leader according to the subscription information.

[0124] The notification form supports Dingding robot push (Webhook), email notification, and CI / CD platform system message.

[0125] 3. Progress tracking and stage notification: The system automatically records the progress of each link, including development completion, system test completion, security test completion, and regression test completion.

[0126] Whenever a stage is completed, the CI / CD platform automatically pushes notifications to the next link leader and updates the release progress visual board.

[0127] 4. Please refer to Figure 3 Abnormality detection and blocking processing: The system regularly detects the state and planned time difference of each task.

[0128] If a link is overdue and not completed, the system immediately pushes an abnormality notification to the version requirement person and the blocking link leader.

[0129] The blocking leader needs to submit a solution in the system, and if necessary, can report to his direct leader for support.

[0130] 5. Responsibility division and release evaluation: If the version is released on schedule, the system records it as an automated release and counts it in the process efficiency index.

[0131] If the version is delayed, the system calculates the responsibility proportion according to the responsibility division rules, for example, 60% for the automated release leader and 40% for the delay link leader.

[0132] If the abnormal link responsibility is clear and the leader does not handle it in time, the leader will be held fully responsible.

[0133] 6. Data analysis and process improvement: The system collects and analyzes various data of version release to generate a problem statistics report.

[0134] Reasons for high-frequency problems (such as code mistakes and RC environment frequently discovering low-level bugs) are analyzed, and protective measures are added in the early stages (unit testing, AI code review, etc.).

[0135] Embodiment three: As shown in Figure 4 , the embodiment provides a DevOps-based version subscription and automatic delivery system, which includes: Version Subscription Module: Receives and manages version information of user subscriptions.

[0136] Information Notification Module: Automatically sends notifications to relevant personnel upon version update or release.

[0137] Progress Tracking Module: Real-time monitoring of version development, testing, and online progress.

[0138] Exception Handling Module: Records, locates, and handles problems when exceptions are found, forming a closed-loop feedback.

[0139] Responsibility Division Module: Automatically analyzes and clarifies responsible parties during exception handling.

[0140] Data Analysis Module: Collects operational data from various stages and conducts statistical analysis to provide a basis for optimizing processes.

[0141] Compared with the prior art, the present application has the following advantages: Full-link transparency: Version targets, progress, and exceptions can be tracked in real time, reducing information asymmetry.

[0142] Automatic notification: Reduces the cost of manual communication, improves the timeliness and accuracy of notifications.

[0143] Risk controllable: Blockage problems are exposed and solved in a timely manner, reducing the risk of delay.

[0144] Clear responsibility: Can be traced back to specific links and responsible persons, promoting process improvement.

[0145] Sustainable optimization: Through data analysis, bottlenecks are found and the release process is optimized.

[0146] The technical key points of the present application are: Version subscription mechanism: Based on user or team version focus, automatically subscribe to version dynamics. Real-time interface with version management systems (such as Git, SVN, CI / CD platform).

[0147] Multi-channel information notification mechanism: Supports DingTalk, WeChat for Enterprise, email, SMS, and other notification methods. According to the role / responsibility scope, it intelligently pushes to relevant personnel.

[0148] Progress tracking and visualization: Real-time monitoring of version status through process nodes (development, testing, online, etc.). Provides visual progress charts and status panels.

[0149] Exception detection and automatic responsibility assignment: Automatically records, classifies, and traces closed-loop processing of exception events. Combined with version change records and operation logs, automatically analyzes the responsible person.

[0150] Historical data analysis and optimization: Collect version flow data throughout the whole process, and perform statistical analysis. Provide process bottleneck analysis and improvement suggestions based on historical data.

[0151] In an exemplary embodiment, a computer device, which can be a server or a terminal, is provided, and an internal structure diagram of the computer device can be as shown in Figure 5 The computer device includes a processor, a memory, an input / output interface (I / O), and a communication interface. The processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is configured to exchange information between the processor and external devices. The communication interface of the computer device is configured to communicate with external terminals through a network connection. The computer program is executed by the processor to implement a version subscription and automatic delivery method based on DevOps.

[0152] Those skilled in the art can understand that Figure 5 The structure shown in the above embodiment is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0153] In an exemplary embodiment, a computer device is also provided, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0154] In an exemplary embodiment, a computer readable storage medium is provided, which stores a computer program. The computer program is executed by a processor to implement the steps in the above method embodiments.

[0155] In an exemplary embodiment, a computer program product is provided, which includes a computer program. The computer program is executed by a processor to implement the steps in the above method embodiments.

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

[0157] It can be understood by those skilled in the art that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing related hardware through a computer program, and the computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments of each method. Among them, any reference to memory, database or other medium used in each embodiment provided by the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (Read-Only Memory, ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetoresistive random access memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric memory (Ferroelectric Random Access Memory, FRAM), phase change memory (Phase Change Memory, PCM), graphene memory, etc. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), etc.

[0158] The database involved in each embodiment provided by the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in each embodiment provided by the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0159] Each technical feature of the above embodiments can be combined arbitrarily. In order to make the description simple, not all possible combinations of each technical feature in the above embodiments are described, but as long as the combination of these technical features does not exist contradictory, it should be considered as the scope of the present application.

[0160] The principles and implementations of the present application are described in the specific examples herein, and the above examples are only used to help understand the method of the present application and its core idea; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation and application range will be changed. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A DevOps-based version subscription and automatic delivery method, characterized by, Comprise: Receiving version demand person initiated version subscription operation or demand change operation, and creating version subscription record; The version subscription record comprises: version identification information, planned release time, responsible subject information, associated demand list and notification object information; After uniqueness verification of the version identification information, according to the preset gray duration, scene test duration and regression test duration, the planned time of each stage of the version is generated by back calculation, and the version notification plan and the version release plan are obtained; Every preset time interval scans the difference value between the planned time of each stage and the current actual time, if the difference value is the preset time difference value, the IssueTracking module interface is called to pull the progress data of the associated demand list, the demand progress state is judged, and the corresponding responsible subject is pushed to the timing notification containing the progress state; When the planned time of each stage is reached or the stage is completed, the notification object of each stage is determined according to the responsible subject information, and the stage completion information is pushed correspondingly; at the same time, the version state in the version subscription record is updated according to the completion state of each stage; Based on the stage completion information, the stage progress of the whole process of version release is calculated, the progress visualization data is generated, and the progress visualization data is synchronized to the responsible subject and the notification object; Comparing the planned time of each stage in the version release plan with the actual completion time of each stage, if the difference value between the two exceeds the preset threshold, an exception log is generated and written into the BlockLog table, and the blocking responsible subject is determined based on the responsible subject information, and the exception notification is pushed to the blocking responsible subject and the version demand person; receiving the solution submitted by the blocking responsible subject; According to the planned release time, the exception log and the actual completion time of each stage, the total delay days of the version are calculated; if the total delay days are 0, the version is classified as automatic release; if the total delay days > 0, the delay index corresponding to each responsible subject is determined, the preset weight is given to the delay index and weighted summation is performed, and the responsibility division result is obtained. 2.The DevOps-based version subscription and automatic delivery method according to claim 1, wherein, The planned time of each key stage of the version is generated by back calculation according to the preset gray duration, customer scene test duration and regression test duration, specifically comprising: The gray test start time is obtained by subtracting the preset gray duration from the planned release time; The scene test start time is obtained by subtracting the preset scene test duration from the gray test start time; The regression test start time is obtained by subtracting the preset regression test duration from the scene test start time; The regression test start time is set as the development completion time. 3.The DevOps-based version subscription and automatic delivery method according to claim 1, wherein, The notification object information comprises: development responsible person information, test responsible person information, subscriber information, notifier information and webhook list information; the webhook list information is used to push version related information to the specified Dingding group; The responsible subject information comprises: development responsible person information, test responsible person information, operation and maintenance responsible person information and audit responsible person information. 4.The DevOps-based version subscription and automatic delivery method according to claim 1, wherein, After obtaining the version notification plan and the version release plan, further comprising: Extracting the notification object information from the version subscription record, calling DingTalk enterprise open interface to map the mobile phone number or work number of the notification object to DingTalk internal UserID, generating a JSON format message body, and pushing the initial notification to the object corresponding to the UserID. 5.The DevOps-based version subscription and automatic delivery method according to claim 1, wherein, The progress data of the association requirement list includes: requirement state, planned completion time, actual closing time, and responsible person; The specific process of judging the requirement progress state includes: When the current date does not reach the planned completion time and the state is not completed, it is judged as normal progress; When the state is completed and the actual closing time is greater than the planned completion time, it is judged as completed but delayed; When the current date is greater than the planned completion time and the state is not completed, it is judged as overdue. 6.The DevOps-based version subscription and automatic delivery method according to claim 1, wherein, The corresponding push stage completion information specifically includes: The R&D completion stage notifies the R&D responsible person, the subscriber, and the test responsible person. The stage completion information of the R&D completion stage includes branch information, actual completion time and planned deviation, and to-be-tested case link; The regression test start stage notifies the test responsible person and the R&D responsible person. The stage completion information of the regression test start stage includes test plan link; The scenario test start stage notifies the scenario test responsible person, the test responsible person, and the R&D responsible person. The stage completion information of the scenario test start stage includes test environment address; The gray release start stage notifies the operation and maintenance responsible person, the R&D responsible person, and the test responsible person. The stage completion information of the gray release start stage includes gray group range; The version formal release stage notifies the PM, all subscribers, the notififier list, and the DingTalk group. The version formal release stage includes version number and ReleaseNote link.

7. The DevOps-based version subscription and automatic delivery method according to claim 1, wherein, The preset weight is given to the delay index, specifically including: The R&D responsible person related index weight accounts for 30%-40%; The test responsible person related index weight accounts for 20%-30%; The scenario test responsible person related index weight accounts for 10%-15%; The release responsible person related index weight accounts for 10%-15%; The version requirement person related index weight accounts for 5%-10%; The audit responsible person related index weight accounts for 5%-10%.

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 DevOps-based version subscription and automatic delivery method of any one of claims 1-7.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the DevOps-based version subscription and automatic delivery method of any one of claims 1-7.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the DevOps-based version subscription and automatic delivery method of any one of claims 1-7.

Images