A system iterative update method, system, and computer-readable storage medium

Abstract

As systems become increasingly complex and intelligent, they need to be able to propose improvement suggestions based on operational feedback, user opinions, or their own analysis, and automatically update code or configurations. However, existing technologies suffer from low user participation, a lack of flexible approval processes, missing version control, difficulty in rollback, lack of snapshot protection, and limited feedback on verification results. Therefore, a method integrating approval and version control is needed, supporting multiple approval entities and various interaction methods, while utilizing a version control system to record each iteration and provide reliable snapshot and rollback capabilities to adapt to the iterative update needs of various systems. This application provides a system iterative update method, system, and computer-readable storage medium, aiming to enable authorized approvers to view and approve improvement suggestions through multiple interaction methods, automatically create version snapshots during the iteration process, support one-click rollback, and output verification results in multiple formats to adapt to different operation and maintenance scenarios.

Description

Technical Field

[0001] This application relates to software system update technology, and more specifically, to a system iterative update method, system, and computer-readable storage medium. Background Technology

[0002] As the complexity of modern systems continues to increase, system iteration and updates have become a core element in ensuring efficient system operation. However, existing update mechanisms generally suffer from a severe lack of user participation. Users or maintenance personnel cannot obtain detailed information about modifications in a timely manner, and it is even more difficult to effectively intervene in the update process, thus weakening the foundation of trust in system behavior. The rigidity of approval processes further exacerbates risks. Most systems lack multi-level approval mechanisms, and improvement suggestions are often implemented directly without sufficient evaluation. Once modifications cause anomalies, tracing responsibility and restoring the system state becomes extremely difficult. At the version management level, existing technologies have failed to achieve organic integration with version control systems. Key information during the iteration process, such as modification details, approval records, and verification data, cannot be systematically saved, making it difficult to fully trace the system's evolution history. The complexity of rollback operations also poses a significant challenge. When a failure occurs after an update, the system often cannot accurately restore to its previous stable state, potentially leading to service interruptions or data consistency issues. Furthermore, the lack of automated snapshot protection mechanisms before updates exposes critical configuration files and runtime status data to the risk of accidental loss, while the feedback methods for verification results are too simplistic, typically presented only in fixed-format reports, failing to flexibly adapt to the interactive needs of different operational scenarios. These issues collectively lead to a lack of transparency and controllability in the system update process, making it difficult to meet the stringent security requirements of application scenarios such as industrial control, IoT devices, and robotic systems.

[0003] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0004] The purpose of this application is to provide a system for iterative updates, a system, and a computer-readable storage medium, which improves the security and controllability of system iterative updates, enhances user participation, and ensures the traceability and reliability of the update process.

[0005] This application provides a system iterative update method, the technical solution of which is as follows: Includes the following steps: Receive improvement suggestions for the target system; Improvement suggestions are presented interactively for approval by authorized approvers. In response to approval, validate improvement recommendations in an isolated environment; Once verification is complete, a verification result is generated and displayed to the authorized approver. In response to secondary confirmation, version control operations are performed, including creating a system snapshot before the update, merging the changes into the target system, and recording iteration information. It provides version history management functionality and supports rolling back to a specified historical version.

[0006] Furthermore, this application also proposes improvement suggestions, including but not limited to at least one of the following: problem description, modification scheme, expected effect, or risk analysis.

[0007] Furthermore, this application also proposes that system snapshots include, but are not limited to, backups of code versions, state data, or configuration files.

[0008] Furthermore, this application also proposes that the version control operation includes creating a version tag to identify the current iteration.

[0009] Furthermore, this application also proposes to include: when the approval fails, recording the reason for rejection and providing feedback to the relevant module.

[0010] Furthermore, this application also proposes that the rollback operation includes pausing the service, restoring the corresponding version of the code and data, and restarting the service.

[0011] Furthermore, this application also proposes an emergency rollback mechanism: automatic rollback triggered by an external trigger file.

[0012] Furthermore, this application also proposes to include support for manually creating system snapshots for backup before important operations.

[0013] Furthermore, this application also proposes a system iterative update system, comprising: The suggestion receiving module is used to receive improvement suggestions for the target system; The approval interaction module is used to display improvement suggestions and receive approval from authorized approvers through interactive means. The verification scheduling module is used to verify improvement suggestions in an isolated environment in response to approval. The results display module is used to generate and display the verification results; The secondary confirmation module is used to receive secondary confirmation from the authorized approver. The version control module is used to respond to secondary confirmation and perform version control operations, including creating system snapshots, merging modifications, and recording iteration information. The history management module provides version history management functionality and supports rollback.

[0014] Furthermore, this application also proposes to include a rollback module for performing rollback operations.

[0015] Furthermore, this application also proposes to include an emergency rollback monitoring module for triggering automatic rollback via an external trigger file.

[0016] Furthermore, this application also proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0017] As can be seen from the above, the system iterative update method, system, and computer-readable storage medium provided in this application solve the problems of insufficient user participation, rigid approval, unintegrated version management, and complex rollback in the prior art by receiving improvement suggestions, interactive approval, isolation verification, version control operations, and version history management, and have the advantages of improving security and controllability. Attached Figure Description

[0018] Several embodiments of this application are described below with reference to the accompanying drawings. It should be noted that the specific structures, modules, steps, parameters, and connections shown in the drawings are preferred embodiments of this application and not limitations on the scope of protection of this application. Those skilled in the art can make various modifications, substitutions, or combinations to the specific details shown in the drawings based on the teachings of this application, and these modified embodiments should still be considered to fall within the scope of protection of this application.

[0019] Figure 1 This application provides a system architecture diagram for iterative updates. The diagram illustrates an exemplary architecture of the system for iterative updates. The dashed box modules are optional implementations, and the module division and connection relationships are for illustrative purposes only and do not limit the scope of protection.

[0020] Figure 2 This document provides an iterative update approval and verification flowchart for this application. The flowchart illustrates an example of the iterative update process for this application. The specific order of steps can be adjusted according to actual needs and does not constitute a limitation on the claims.

[0021] Figure 3 This diagram illustrates a version history management interface provided for this application. The diagram is an example of a version history management interface for this application. The specific display format and operation method can be designed according to actual applications and do not constitute a limitation on the claims. Detailed Implementation

[0022] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application. Other technologies that may be mentioned in the embodiments can be implemented using existing technology or other patent applications filed by the applicant on the same day, and will not be repeated here. It should be particularly noted that the specific module divisions, process steps, data flow directions, status names, time values, etc., shown in the accompanying drawings are merely illustrative examples and should not constitute a limitation on the scope of protection of the claims of this application. The scope of protection of the claims is determined solely by their wording and should be interpreted in accordance with the overall content of the specification.

[0023] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] During system iteration and updates, existing technologies often suffer from several drawbacks. First, authorized approvers cannot obtain complete information about improvement suggestions through diverse interaction methods, resulting in a lack of awareness regarding system modifications. Second, the approval process is limited to a single interaction mode, failing to adapt to the needs of different operational scenarios. Third, the version control system is not integrated with the update process, leading to missing iteration history records and difficulty in tracing the system's evolution path. Fourth, the rollback mechanism is poorly designed, hindering rapid recovery to a stable state. Fifth, the lack of system snapshots before updates poses data security risks. These issues collectively impact system stability and operational reliability. Specifically, insufficient user participation leads to a lack of transparency in the system update process; rigid approval methods reduce decision-making efficiency; the absence of version control increases the difficulty of fault diagnosis; an inadequate rollback mechanism prolongs system recovery cycles; and the lack of snapshot protection threatens data integrity.

[0025] For example, in industrial control system firmware update scenarios, after the system automatically generates firmware update suggestions, authorized approvers can only view the suggestions through a graphical user interface and cannot conduct real-time approval through API interfaces or voice interaction; after approval, the system directly implements the update in the production environment without verifying compatibility in an isolated environment; if the update introduces logical errors, the control system will experience abnormal operation; because a system snapshot is not automatically created before the update, critical configuration data cannot be recovered, and the version history is incomplete, resulting in the need for manual reconstruction of the historical state during rollback operations, extending service interruption time.

[0026] If the above problems are not addressed, the effective participation of authorized approvers during system iteration and updates cannot be guaranteed, and the approval process may delay critical updates or introduce unverified modifications; the lack of version control will make the system evolution history unauditable, increasing the complexity of root cause analysis; insufficient rollback mechanisms and the lack of snapshot protection will significantly prolong the time it takes for the system to recover from failures, and may even cause irreversible data damage, threatening the overall operational security of the system.

[0027] To address this, this application provides a system iterative update method, comprising the following steps: Receive improvement suggestions for the target system; Improvement suggestions are presented interactively for approval by authorized approvers. In response to approval, validate improvement recommendations in an isolated environment; Once verification is complete, a verification result is generated and displayed to the authorized approver. In response to secondary confirmation, version control operations are performed, including creating a system snapshot before the update, merging the changes into the target system, and recording iteration information. It provides version history management functionality and supports rolling back to a specified historical version.

[0028] For ease of understanding, the following explains some key terms in this embodiment: A target system refers to a software system, hardware system, or a combination of both that requires iterative updates. This system can be an operational industrial control system, an intelligent vehicle system, a robot operating system, enterprise-level application software, or a mobile application, etc.

[0029] Improvement suggestions refer to proposals for optimization, repair, or functional enhancement of the target system. These suggestions can be automatically generated by the system's internal analysis module or submitted manually by users or operations and maintenance personnel.

[0030] An authorized approver is an entity authorized to review and approve improvement suggestions. This entity can be one or more users, a system administrator, or a pre-defined automated approval process.

[0031] Interaction method refers to the means by which the authorizing party exchanges information and operates the system. This can include graphical user interface (GUI), application programming interface (API), speech recognition interface, or other forms of human-computer interaction interface.

[0032] An isolated environment refers to a runtime space that is independent of and does not affect the production environment of the target system. This environment is typically used to test and verify improvement proposals to ensure their stability and compatibility, and to avoid potential risks to the production system.

[0033] Validation results refer to the evaluation information generated after testing the improvement suggestions in an isolated environment. These results typically include whether the test passed, performance metrics, potential risk warnings, and detailed test logs.

[0034] Secondary approval refers to the final confirmation by the authorized approver after the improvement proposal has been verified, regarding whether the changes will be formally applied to the target system. This step aims to provide additional security and prevent the deployment of unconsidered modifications.

[0035] Version control refers to a series of activities that manage the code, configuration, and data of a target system. This operation aims to record the system's evolution history, ensure that every modification is traceable, and support the system's restoration to a previous state.

[0036] A system snapshot is a complete record of the state of a target system at a specific point in time. This snapshot typically includes the code, data, and configuration files required for system operation, and is used to quickly restore the system in the event of an update failure.

[0037] Iteration information refers to a detailed record of each system update. This information typically includes the update time, submitter, identifier of the improvement suggestion, summary of the changes, and verification results, and is used to construct a complete history of the system's evolution.

[0038] Version history management is a capability provided by the system for storing, querying, and displaying all historical versions of the target system and their related information. This feature allows users to clearly understand the system's evolution process.

[0039] Rollback refers to the operation of restoring a target system to a previous version. This operation is typically performed when problems occur after a system update, to undo unwanted changes and restore stable system operation.

[0040] This embodiment provides a system iterative update method, which aims to solve the problems of low user participation, single approval method, lack of version control, difficulty in rollback, and lack of snapshot protection in the existing system iterative update process.

[0041] Specifically, this method first receives improvement suggestions for the target system. These suggestions can be simple text descriptions, such as a message manually entered by the system administrator, explaining the bugs that need fixing or the features that need to be added. Alternatively, suggestions can be submitted via a predefined form, which includes a brief description of the modifications.

[0042] Subsequently, this method interactively displays the aforementioned improvement suggestions for approval by the authorized approver. For example, the system can display the improvement suggestions in plain text on a command-line interface, where the authorized approver can complete the approval by entering "Approve" or "Reject". Alternatively, the system can also list the suggestions to be approved on a simple web page and provide basic "Agree" or "Reject" buttons for the authorized approver to click.

[0043] In response to approval, this method validates the aforementioned improvements in an isolated environment. Specifically, the system can launch a separate virtual machine and deploy the modifications to be validated to that virtual machine for testing. Alternatively, the system can deploy the modifications to a physical test server, where testers manually execute test cases to verify their functionality.

[0044] Upon successful verification, this method generates a verification result and displays it to the authorizing approver. For example, the system can generate a simple text file containing only the words "Verification passed" or "Verification failed" and send it to the authorizing approver via email. Alternatively, the system can also directly output log information generated during the verification process to the console for the authorizing approver to view.

[0045] In response to secondary confirmation, this method performs version control operations. These operations include creating a system snapshot before the update, merging the changes into the target system, and logging iteration information. Specifically, when creating a system snapshot, the system can simply copy the current code directory of the target system as a backup. When merging the changes into the target system, the system can directly replace the old files with the new ones. When logging iteration information, the system can append a brief description of the update to a log file.

[0046] Finally, this method provides version history management functionality, supporting rollback to a specified historical version. For example, the system can maintain a directory containing backup files of all historical versions and provide a list displaying these backup files. When a rollback is needed, the authorizing approver can select a backup file from the list, and the system can then manually restore the contents of that backup file to the target system.

[0047] The following example will provide a more detailed explanation of the above technical solution: Suppose a customer relationship management (CRM) system (the target system) within an enterprise encounters a calculation error while processing specific customer data. After discovering the problem, the system administrator (User A) manually writes an improvement suggestion to fix the error, containing only one line of text: "Fix customer data calculation error." This suggestion is submitted to the system. The system then displays the suggestion to the department manager responsible for approval (the authorized approver) through a simple internal web interface. After reviewing the brief description, the department manager clicks the "Approve" button on the webpage.

[0048] Upon receiving the approval instruction, the system automatically deployed a CRM system version containing the fix on a pre-configured test server (isolated environment). On this test server, the system executed a series of pre-defined automated test cases. After the tests were completed, the system generated a simple text file as verification results, containing only the words "Test passed," and sent it to the department manager via the internal messaging system. Upon receiving the verification notification, the department manager clicked the "Confirm Deployment" button in the messaging system, completing a secondary confirmation.

[0049] Following the department manager's second confirmation, the system initiated version control operations. First, the system automatically copied all code files from the current production CRM system, creating a system snapshot. Next, the system merged the changes, including code fixes, into the production CRM system. Simultaneously, the system appended a line to an internal log file, containing the update time and the iteration information: "Fixed customer data calculation error."

[0050] Afterward, the CRM system continued to run. The system also provides a version history management function, allowing operations personnel to view all historical update records. For example, if new compatibility issues are discovered after deploying a new version, operations personnel can use this function to choose to roll back to the previous stable version. The system will then restore the corresponding code files from backup to the production environment based on the selected historical version, thereby restoring the CRM system to its previous stable state.

[0051] The aforementioned system iterative update method systematically addresses the shortcomings of existing iterative updates by integrating interactive approval, isolated verification, version control, and rollback mechanisms. Compared to traditional system update methods, this method, upon receiving improvement suggestions for the target system, no longer directly updates the system. Instead, it interactively displays the suggestions for authorized approvers to review, thus resolving the issues of low user participation and a single approval method. For example, in the CRM system update example above, department managers can clearly understand and approve each modification, rather than relying on automatic system updates. This significantly improves trust in and control over the system's behavior.

[0052] Furthermore, this method, in response to approval, verifies the improvement suggestions in an isolated environment, generates verification results upon completion, and presents them to the authorized approver. This contrasts with existing technologies that lack effective verification or offer only single verification result feedback, ensuring that modifications are thoroughly tested before deployment and reducing risk. In the CRM system example, the verification of the fix code on the test server effectively prevents potential new issues from directly impacting the production environment.

[0053] Furthermore, this method responds to a second confirmation to perform version control operations, including creating a system snapshot before the update, merging the changes into the target system, and recording iteration information. This directly solves the problems of missing version control and lack of snapshot protection in existing technologies. By creating a system snapshot before the update, even if the update fails, the system can quickly recover to a safe state, avoiding data loss. Recording iteration information makes every modification traceable, facilitating subsequent auditing and troubleshooting.

[0054] Finally, this method provides version history management functionality, supporting rollback to a specified historical version. This effectively solves the problem of difficult rollback in existing technologies. In the CRM system example, if a problem occurs with the new version, operations and maintenance personnel can quickly restore the system to a previous stable version, ensuring business continuity and system stability. Thus, through the close coordination of the above series of steps, this method forms a complete, secure, and controllable system iteration and update process, significantly improving the reliability and efficiency of system updates.

[0055] In some of the solutions described above in this application, improvement suggestions are proposed to receive modification proposals for the target system and submit them to the authorized approver for approval. However, in this process, the improvement suggestions may lack key information details, which may prevent the approver from fully understanding the root cause of the problem, the specific content of the modification, the expected improvement effect and the potential risks, thereby affecting the accuracy of the approval decision and the comprehensiveness of the risk assessment.

[0056] In response, this application further proposes improvement suggestions, including but not limited to at least one of the following: problem description, modification scheme, expected effect, or risk analysis.

[0057] In the system iterative update methodology, improvement suggestions are proposed modifications to the target system, aiming to solve existing problems, optimize performance, or add new features. They can be generated from various sources, such as internal system analysis modules, user feedback analysis modules, or external interfaces. Problem descriptions are clear and accurate textual descriptions of the defects, deficiencies, or aspects requiring improvement in the current system. They can include information such as the problem's symptoms, scope of impact, and reproduction path, and can be presented in forms such as natural language text, structured forms, or predefined tags. Modification plans are specific technical measures proposed to solve the problems identified in the problem description or achieve the expected results. They can include code changes, configuration file adjustments, database structure modifications, and hardware parameter adjustments, and can be presented in forms such as code patches, configuration scripts, links to design documents, or detailed lists of operation steps. Expected results refer to the improvement goals or positive impacts that the system is expected to achieve after implementing the modification plans. They can include performance improvements, enhanced functionality, reduced error rates, and improved user experience, and can be presented in forms such as quantitative indicators (e.g., reduced response time, reduced resource consumption), functional descriptions, or user benefit descriptions. Risk analysis refers to the assessment and explanation of the potential negative impacts, side effects, or likelihood of failure that may result from implementing the modification plan. It may include compatibility issues, performance degradation, security vulnerabilities, data loss, or difficulty in rollback, and can be presented in the form of risk level assessments, lists of potential impacts, mitigation recommendations, or predictions of failure scenarios.

[0058] This application's solution describes the improvement suggestions by including at least one of the following: a problem description, a proposed modification, expected results, or a risk analysis. When the system receives such an improvement suggestion, it is no longer a vague intention to modify, but contains sufficient information. Specifically, the problem description provides the authorized approver with the background and necessity of the modification, enabling them to understand why this iteration is needed; the proposed modification details the specific implementation path, allowing the approver to assess technical feasibility and potential impact; the expected results depict the positive prospects after successful modification, helping the approver weigh the input and output; and the risk analysis reveals potential risks in advance, enabling the approver to anticipate and formulate response strategies. When the improvement suggestions are presented to the authorized approver interactively, this detailed information allows the approver to fully understand all aspects of this iteration, thereby making an informed approval decision. For example, the approver can determine the urgency of the modification based on the problem description, assess the technical difficulty of the proposed modification, judge the value based on the expected results, and assess potential hazards based on the risk analysis. In response to approval, when verifying the improvement suggestions in an isolated environment, the verification process can design test cases based on the proposed modification and expected results, and combine risk analysis to focus on potential weaknesses. Once verification is complete, the generated verification results are presented to the authorized approver. These results can be compared with the expected effects and risk analyses in the improvement suggestions, providing stronger data support for the authorized approver's secondary confirmation. Finally, when version control operations are executed in response to secondary confirmation, this detailed iteration information (including problem descriptions, modification plans, expected effects, and risk analyses) can be recorded as metadata for system snapshots and version tags. This greatly enriches version history management capabilities, enabling subsequent rollback operations to be decided and executed based on more comprehensive contextual information. This comprehensive set of improvement suggestions makes the entire system iteration and update process more transparent, controllable, and secure, effectively avoiding blind approvals and potential risks caused by missing information.

[0059] The following example illustrates this. Suppose a smart home system needs an iterative update to address a data reporting delay issue with a certain sensor. The system or developers can submit an improvement proposal containing the following: First, a problem description, such as: "The temperature sensor (ID: (T001) Over the past 24 hours, the average data reporting latency exceeded 5 seconds, causing untimely triggering of automation rules and impacting user experience. The proposed changes include: "Modifying the data queue processing logic in the sensor data processing module (`sensor_data_processor.py`), changing the original single-threaded processing to multi-threaded concurrent processing, and optimizing database write operations. Specific code changes are attached in `patch_T001_v1.diff`." Next, the expected effects are outlined, such as: "It is expected that the temperature sensor data reporting latency will be reduced to an average of less than 1 second, improving the response speed of automation rules and enhancing the user's perception of the smoothness of the smart home system." Finally, the risk analysis is presented, such as: "Introducing multi-threading may increase CPU resource consumption, potentially leading to increased system load in extreme cases; the transaction consistency of multi-threaded concurrent database writes needs to be verified. The rollback plan is to directly restore to the previous stable version." When the authorized approver (e.g., the system administrator) views this improvement suggestion through the interactive interface, they can clearly understand the root cause of the problem, the specific solutions, the expected positive impact, and the potential risks. Based on this comprehensive information, the administrator can decide whether to approve the update. If approved, the system will validate the modified scheme in an isolated environment and evaluate the validation results based on the expected effects and risk analysis.

[0060] Through the aforementioned technical solution, improvement suggestions are no longer simple modification requests, but rather structured information including problem descriptions, modification plans, expected effects, or risk analyses. This allows authorized approvers to comprehensively and deeply understand the background, content, potential benefits, and risks of each iteration during the approval process, significantly improving the accuracy and reliability of approval decisions. Specifically, the problem description provides a clear basis for approval, avoiding blind modifications; the modification plan enables approvers to assess technical feasibility and implementation complexity, ensuring the rationality of technical decisions; the expected effects help approvers weigh the value of modifications and optimize resource allocation; and the risk analysis reveals potential negative impacts in advance, enabling approvers to develop contingency strategies and effectively reduce the risks of system iteration updates. This information completeness not only enhances the authorized approvers' trust and control over system behavior but also provides a solid foundation for subsequent verification, secondary confirmation, version control, and rollback operations, thereby avoiding misjudgments, system instability, or difficulty in traceability caused by missing information, greatly improving the security, controllability, and efficiency of system iteration updates.

[0061] In some of the solutions mentioned above in this application, system snapshots are proposed to create backups before updates for rollback. However, in this process, the snapshot content may be incomplete and unable to cover all critical system components, resulting in inconsistent system states or data loss during rollback.

[0062] In response, this application further proposes system snapshots that include backups of code versions, state data, and configuration files.

[0063] In this context, code version refers to the specific state or revision of the program code currently running on the target system. Its purpose is to ensure that, in the event of a rollback, the program logic and functionality can be accurately restored to their state before the system update. This can be achieved by identifying and retrieving the code through specific commit IDs or tags from version control systems (such as Git or SVN), or by packaging and compressing the entire code directory and storing it as part of a snapshot. State data refers to the runtime data of the target system at a specific point in time. Its scope is broad, including but not limited to database content, critical variables in memory, cached data, and user data in the file system. Its purpose is to ensure that after a rollback, not only is the program logic correct, but the internal data state can also be restored to its exact state before the update, avoiding data inconsistency or loss. Specifically, for databases, this can be achieved by performing database backups (e.g., logical or physical backups) or utilizing the database's transaction logs and point-in-time recovery capabilities; for data in the file system, file system snapshots (e.g., LVM snapshots, ZFS snapshots) or by directly copying critical data directories. Configuration files are files that control the behavior and parameter settings of the target system, such as application settings files, operating system service configurations, and network configurations. Its purpose is to ensure that the system's operating environment and behavioral parameters are completely consistent with those before the update after a rollback, avoiding compatibility issues or functional abnormalities caused by configuration differences. This can be achieved by copying critical configuration files to a specified backup directory, or by using configuration management tools (such as Ansible or Chef) to export and store the current configuration state.

[0064] This application ensures that the complete runtime environment of the target system is accurately recorded before system iterations and updates by explicitly including code version, state data, and configuration files within the scope of system snapshots. When the system needs to be rolled back to a specified historical version, these three parts work together to ensure that the system's program logic, internal data, and external configuration can be completely and consistently restored to the state before the update. This comprehensive snapshot mechanism greatly enhances the reliability of creating system snapshots in version control operations, enabling subsequent merging modifications, recording iteration information, and supporting rollback to specified historical versions to truly function, thereby effectively solving the problem of inconsistent system states or data loss during rollback due to incomplete snapshot content.

[0065] As a specific implementation method, before iteratively updating a microservice application, the system can automatically create a comprehensive snapshot. First, for code versioning, the system can record the latest commit hash of the currently deployed Git repository and simultaneously package the entire application's code directory (e.g., ` / opt / myapp / current`) into a compressed file. Second, for state data, the system can perform a logical backup of the database (e.g., MySQL), generate an SQL file, and package it along with the application's critical data directories (e.g., ` / var / lib / myapp / data`). Finally, for configuration files, the system can copy the application's service configuration files (e.g., ` / etc / systemd / system / myapp.service`), environment variable files (e.g., ` / etc / myapp / env.conf`), and relevant configuration snippets from the web server (e.g., Nginx) to the snapshot directory. All these backup files and recorded information are stored uniformly and associated with a unique identifier for this iteration, forming a complete system snapshot.

[0066] Through the above technical solution, this application ensures that the snapshots created during system iteration and updates are comprehensive and complete. This allows the system to accurately restore to any specified historical version before the update when a rollback operation is required, restoring not only the program code but also the matching data state and configuration environment. This greatly improves the reliability and integrity of the rollback operation, effectively avoiding the risk of inconsistent system states or loss of critical data due to incomplete snapshot content, thereby ensuring the stability and security of the system iteration and update process.

[0067] In some of the solutions mentioned above in this application, version control operations are proposed to record iteration information and support historical version management. However, in this process, there is a lack of a unique identification mechanism for each iteration, which leads to confusion in historical version tracking, makes it difficult to quickly locate and roll back to a specific iteration, and increases the complexity of system maintenance and the risk of errors.

[0068] In this regard, this application further proposes that version control operations also include creating version tags to identify the current iteration.

[0069] Creating a version tag refers to assigning a unique identifier to the system's state at a specific point in time or after a specific set of modifications. This identifier can be a string, a version number, a combination of a timestamp and a sequence number, or a unique code generated based on a content hash value. For example, the system can automatically generate version tags according to preset naming rules (such as semantic version number vX.YZ, date and timestamp YYYYMMDDHHMMSS, or combined with iteration sequence number); or, in some scenarios requiring manual intervention, authorized approvers or operations personnel can manually enter or select a meaningful version tag during secondary confirmation.

[0070] This version tag identifies the current iteration, meaning that the created tag will be closely associated with this system iteration update operation, serving as a unique identifier for this update. This tag can be stored in a version control system, such as as a Git tag or an SVN revision property, directly pointing to the code, configuration, and data snapshots generated in this iteration. Furthermore, this tag can also be recorded in the system's iteration log or metadata store, associated with detailed information about this iteration (such as improvement suggestions, approvers, verification results, etc.), thus providing a unified, traceable identifier for easy subsequent querying, management, and rollback operations.

[0071] This application's solution integrates version tag creation into version control operations, giving each system iteration a clear and unique identifier. After the authorizing approver confirms the improvement suggestions, the system simultaneously generates and applies a version tag while performing version control operations such as creating a system snapshot, merging changes into the target system, and recording iteration information. This tag serves as the "fingerprint" of this iteration, unifying all code, configurations, data snapshots, and iteration records involved in the update. Therefore, when it is necessary to view historical versions, perform audits, or execute rollback operations, the authorizing approver or operations personnel can accurately locate specific system states and iteration events using this unique version tag, thereby avoiding version confusion and greatly simplifying the tracking and management of historical versions. This mechanism, combined with basic system snapshot and version history management functions, constructs a more robust and easy-to-use system iteration and update framework.

[0072] The following is a concrete example to illustrate this. In an enterprise software release scenario, after the testing team, product manager, and operations manager have completed multi-level approvals and verification, the system automatically creates a system snapshot before executing the formal release operation, merging the code and configuration involved in this release into the production environment. During this process, the system automatically generates a version tag based on preset rules (e.g., combining the current date and release sequence number), such as "release-20240723-001". This tag is then applied to the snapshot and code repository of this release and recorded in the iteration information. When it is necessary to retrospectively or roll back this release, operations personnel can directly use the tag "release-20240723-001" to quickly and accurately find the corresponding system status and all relevant information.

[0073] The above technical solution provides a unique identifier for each system iteration update, thus solving the problem of chaotic historical version tracking. This allows authorized approvers or operations personnel to clearly identify and distinguish different system versions, greatly improving the accuracy and efficiency of historical version management. When it is necessary to roll back to a specific historical version, the version tag can be used for direct location, avoiding errors and delays caused by unclear version information, and significantly reducing the complexity and potential risks of system maintenance.

[0074] In some of the solutions mentioned above in this application, an approval process is proposed to control the application of improvement suggestions. However, when the approval is not approved, there is a lack of a mechanism to record the reasons for rejection and feedback, which makes it impossible to trace the rejection decision, provide feedback to relevant parties, and optimize subsequent suggestion submissions.

[0075] In response, this application further proposes that when the approval fails, the reason for rejection be recorded and fed back to the relevant module.

[0076] The phrase "when approval is not granted" refers to a situation where the authorized approver, after reviewing the improvement suggestion, explicitly states that they do not approve it. This condition triggers subsequent recording and feedback actions, ensuring that related operations are only performed when the improvement suggestion is explicitly rejected. This can be achieved through various methods, such as a "reject" button provided in the approval interaction module, a rejection command sent via API, or a rejection command received through a voice interaction system.

[0077] "Recording Rejection Reasons" refers to storing the specific reasons or explanations given by the authorized approver for rejecting improvement suggestions. This provides a basis for subsequent auditing, analysis, and improvement, enhancing the transparency and traceability of decision-making. Specifically, the approval interaction module can provide a text input box for the approver to fill in the detailed reasons for rejection. The system stores this text in a database or log file and associates it with the corresponding improvement suggestion identifier. In addition, the system can also provide a preset list of rejection reasons for the approver to choose from, or extract key rejection reasons from the approver's voice or text input through speech recognition and natural language processing technologies and store them in a structured manner.

[0078] "Feedback to relevant modules" refers to transmitting the rejection reason information to the system components or personnel related to the improvement suggestion. This ensures that the submitter or relevant person in charge of the improvement suggestion can understand the rejection reason in a timely manner, thereby making adjustments, optimizations, or resubmissions, forming a closed-loop feedback mechanism. For example, the system can send the rejection reason to the suggestion receiving module via a message queue, and the suggestion receiving module can notify the original submitter of the suggestion. The notification method can include email, instant messaging, or internal system notification. Alternatively, the system can write the rejection reason to the system log and trigger an alarm mechanism to notify the operations and maintenance personnel or development team responsible for improving suggestion management or system optimization.

[0079] This application's solution addresses the inadequacy of rejection handling in the approval process by introducing a mechanism that records rejection reasons and provides feedback to relevant modules when approval fails. This ensures the system maintains transparency and traceability even in decision-making failures. Specifically, the conditional action triggered when approval fails focuses on the failure scenario, avoiding wasted resources on ineffective operations; recording rejection reasons provides audit evidence, helping to analyze the root causes of rejection and optimize subsequent suggestions; and feedback to relevant modules ensures timely information delivery to the submitter or system components, promoting iterative improvement and user participation. These features work synergistically to improve the completeness of the approval process. In this method, when the authorized approver approves a received improvement suggestion, if they decide not to approve it, the system immediately captures this rejection decision and prompts the approver to enter specific rejection reasons. These reasons are accurately recorded by the system and stored in association with the unique identifier of the improvement suggestion. Subsequently, the system proactively pushes this rejection reason information to the relevant module or personnel who initially submitted the improvement suggestion. For example, if the improvement suggestion was submitted by an internal analysis module or developer, the system will promptly inform that module or personnel of the rejection reason through internal messaging systems, emails, or API callbacks. In this way, the submitter can clearly understand the specific reasons why their suggestion was rejected, and thus be able to modify, improve or resubmit the improvement suggestion in a targeted manner, avoiding blind guessing and repeatedly submitting unqualified solutions.

[0080] The following example illustrates this. Taking a robot system update as an example, when maintenance personnel view and approve an improvement suggestion for a new robot control algorithm through a web interface, if they find that the algorithm may pose potential risks under certain extreme operating conditions, they can choose to "reject" the suggestion. At this time, the system will pop up a dialog box, requiring the maintenance personnel to fill in the specific reason for rejection, such as "The new algorithm may cause the robot to go out of control under extreme loads, and its robustness needs further optimization." After the maintenance personnel submit this reason, the system will record this information and immediately notify the developers who submitted the algorithm via WeChat or email. Upon receiving the feedback, the developers will clearly understand the direction in which the algorithm needs improvement, allowing them to make targeted adjustments and tests before resubmitting a more comprehensive improvement suggestion.

[0081] Through the aforementioned technical solution, this application ensures that the decision-making process remains transparent and traceable even if an improvement suggestion is not approved. This allows the submitter of the improvement suggestion to obtain clear reasons for rejection in a timely manner, thereby enabling targeted optimization of subsequent suggestions, reducing ineffective work, and improving iteration efficiency. Simultaneously, the system can accumulate rejection reason data, providing valuable evidence for analyzing common problems and optimizing the suggestion submission process, thus promoting continuous improvement in the system's iterative update process and enhancing overall efficiency.

[0082] In some of the embodiments described above in this application, a rollback operation is proposed to support the system rolling back to a specified historical version. However, in its implementation, the rollback operation may lack specific execution steps, leading to data inconsistencies or operational conflicts due to the service not being paused during system recovery. An incomplete recovery process may affect system stability, and the lack of a restart mechanism may prevent the system from resuming normal operation after rollback. To address this, this application further proposes that the rollback operation includes pausing the service, restoring the corresponding version of code and data, and restarting the service.

[0083] Service suspension refers to temporarily halting the operation of a target system or its related modules before performing critical operations (such as data recovery or code updates). This prevents new data write / read requests or business logic execution during the operation, ensuring data consistency and atomicity of operations. Service suspension can be achieved by sending a termination signal to the target system's main process (such as the SIGTERM signal in Linux) or by calling service management interfaces provided by the operating system (such as the `systemctl stop` command in systemd or Windows Service Manager). Alternatively, the system load balancer configuration can be modified to remove traffic from the target service instance, preventing it from receiving new requests and thus achieving a logical service suspension while allowing currently processed requests to complete.

[0084] Restoring the corresponding version of code and data means that when rolling back the system to a specified historical version, not only must the program code be restored to that version, but also the system state data and configuration files that match that code version must be restored as well. This ensures that the system can run in a complete and consistent state after the rollback. This is crucial for ensuring the thoroughness of the rollback and the stability of the system. Code restoration can be achieved through checkout or reset operations in version control systems (such as Git and SVN) to restore the code repository to a specified version. Data restoration can extract data backups (such as database backups and file system snapshots) of the corresponding version from pre-created system snapshots and load or overwrite them into the current runtime environment. Another approach is to utilize containerization technology, packaging each historical version into an independent container image. During rollback, the corresponding version of the container is directly deployed and started, while mounting or restoring data volumes compatible with that container version. Configuration files can be version-managed as part of the code or restored separately from snapshots.

[0085] Restarting a service refers to restarting the target system or its related modules after the code and data recovery operation is completed, enabling it to load new code and data and restore normal business functions. This is a necessary step to ensure that the rollback operation ultimately takes effect and restores the system to an available state. The service restart can be initiated by calling the service management interfaces provided by the operating system (such as the `systemctl start` command of systemd, or Windows Service Manager). For distributed systems, new service instances can also be registered with the service registry center through the service registration and discovery mechanism, and the load balancer can then reroute traffic to these newly started service instances.

[0086] This application's solution breaks down the rollback operation into three sequential steps: "pausing service," "restoring the corresponding version of code and data," and "restarting service," forming a complete and reliable system rollback process. When it is necessary to roll back the system to a specified historical version, the service is paused first. This proactively stops the target system's business processing, freezing the system state and preventing interference from new business requests or data writes during subsequent code and data recovery, effectively avoiding data inconsistencies or operational conflicts. After the service is paused, the system immediately restores the corresponding version of code and data. This step is the core of the rollback, ensuring that the system not only returns to the historical version in program logic but also completely matches that historical version in terms of running state and configuration. By accurately checking out and loading the specified version of code, state data, and configuration files from a pre-created system snapshot or version control system, the integrity and accuracy of the rollback are guaranteed, eliminating system errors that may be caused by partial or incomplete recovery. Finally, after the code and data recovery is complete, the system restarts service. This step allows the rolled-back version to be correctly loaded and put into operation, thereby restoring the system's normal functionality and external service capabilities. The entire process is interconnected and logically rigorous, ensuring a smooth transition during rollback and a rapid return to usability upon completion. This approach, combined with version history management functionality that supports rollback to specified historical versions, enables the system to not only choose to rollback when faced with update failures or anomalies, but also to execute the rollback in a safe, reliable, and complete manner. This significantly improves the stability and reliability of system iteration updates and effectively solves problems such as data inconsistency, incomplete recovery, and system malfunction that can result from traditional rollback operations.

[0087] The following is a concrete example. Suppose an online service system needs to roll back to a previous stable version. When the authorizing party selects to roll back to version "v1.0.0" in the version history management interface and confirms, the system will initiate the rollback process. First, the system will suspend the service. Specifically, the system can send a SIGTERM signal to the main process running the online service, requesting it to gracefully stop the currently processed requests and shut down within a certain timeout period. Simultaneously, the system can update the load balancer configuration, temporarily routing all new user requests to the maintenance page or a backup service, ensuring that the target service no longer accepts new connections. Next, the system will restore the corresponding version of the code and data. For the code, the system will connect to the version control repository (e.g., a Git repository) and execute the `git checkout v1.0.0` command, restoring the code files in the service deployment directory to version "v1.0.0". For the data, the system locates the database backup file and configuration file backup corresponding to version "v1.0.0" from pre-stored system snapshots, then performs a database recovery operation (e.g., using the `pg_restore` command to restore the PostgreSQL database), overwriting the current configuration file. Finally, after the code and data recovery are complete, the system restarts the service. The system restarts the online service's main process by calling the operating system's service management commands (e.g., `systemctl start online_service`). Once the service successfully starts and completes its self-check, the load balancer updates its configuration, rerouting user requests back to the rolled-back and restarted service instance, thus restoring the system to normal operation.

[0088] Through the above technical solution, this application effectively addresses the issues of data inconsistency or operational conflicts that may arise during system rollback due to the failure to pause services. By proactively pausing services before restoring code and data, the system state is frozen, avoiding risks associated with concurrent operations. Simultaneously, by clearly defining the two key steps of restoring code and data, the thoroughness and integrity of the rollback are guaranteed, preventing system errors caused by partial restoration. Furthermore, restarting services immediately after restoration ensures the system can quickly return to an available state, resolving the issue of the system failing to function properly after rollback. These measures work together to significantly improve the security, reliability, and efficiency of system rollback operations, enabling the system to operate more stably during iterative updates and to recover quickly from potential problems.

[0089] In some of the embodiments described above in this application, a rollback function is proposed to support one-click rollback to a historical version. However, in its implementation, when the user terminal cannot access the system, the rollback operation cannot be triggered, resulting in the system being unable to recover in a timely manner in the event of a failure.

[0090] In response, this application further proposes an emergency rollback mechanism: triggering automatic rollback via an external trigger file.

[0091] The emergency rollback mechanism is a backup measure to provide system recovery capabilities when the regular interactive rollback method is unavailable. Its purpose is to ensure that the system can be quickly and reliably restored to a previous stable state in the face of emergencies, such as front-end service failures, network connection interruptions, or unresponsive user interfaces. This mechanism can initiate the rollback process in a pre-defined, non-interactive manner, independent of the availability of the user interface. For example, it can be triggered by monitoring changes in the state of specific files or directories, or by receiving specific network signals or hardware commands. An external trigger file is a specific file used to initiate the emergency rollback mechanism. The existence of this file or specific changes to its content are recognized by the system as rollback instructions. Its function is as a non-interactive command input medium, allowing operations personnel or automated scripts to initiate the rollback process by manipulating this file (such as creating, modifying, or deleting) when normal user interfaces or APIs are unavailable. For example, this file can be a simple text file whose content may contain an identifier of the version to be rolled back to, or its very existence may indicate a rollback operation. Automatic rollback triggering refers to the system automatically initiating a pre-defined rollback process without further manual intervention after detecting a specific state of an external trigger file (e.g., the file has been created or its content has been modified to a specific value). Its purpose is to improve the timeliness and automation of rollback operations, especially in urgent scenarios requiring rapid response. Implementation methods can include: deploying a persistent background process (e.g., a daemon or service) that periodically scans a pre-defined directory to check for the existence or content of the external trigger file; or utilizing the operating system's file system event listener to capture operation events on the file in real time and respond immediately.

[0092] This application's solution addresses the issue of inability to trigger rollback when the user interface is unavailable by introducing an emergency rollback mechanism, ensuring automatic system recovery in emergency situations. Specifically, after the system receives improvement suggestions for the target system, interactively displays these suggestions for approval by the authorized approver, verifies the suggestions in an isolated environment in response to approval, generates verification results and displays them to the authorized approver, and performs version control operations (including creating a system snapshot before the update, merging modifications into the target system, and recording iteration information) in response to secondary confirmation and provides version history management functionality to support rollback to a specified historical version, this application provides an emergency rollback mechanism to further enhance the system's robustness and fault tolerance. This mechanism deploys a monitoring component that continuously monitors a preset external trigger file. Once this external trigger file is created, modified, or its content meets preset trigger conditions, the monitoring component immediately recognizes this signal and automatically initiates the rollback process. This rollback process may include steps such as pausing service, restoring the corresponding version of code and data, and restarting service. This approach allows maintenance personnel or automated systems to quickly initiate a rollback by manipulating a simple file, even when the system's front-end services become inaccessible due to a failure. This bypasses the conventional interactive approval and confirmation process, significantly shortening the fault recovery time and ensuring the continuous operation of the system.

[0093] As a specific implementation, a specific directory can be designated, such as ` / opt / system_rollback / `, and an external trigger file named `trigger.txt` can be placed in this directory. The system can deploy a background daemon that scans this directory at a preset frequency (e.g., every 5 seconds). When the daemon detects the existence of the `trigger.txt` file, and its content contains a valid version tag (e.g., `v2.1.0`), or the mere existence of the file is considered a trigger signal, the system will immediately initiate an automatic rollback process. This rollback process first suspends the target system's services to ensure data consistency. Subsequently, the system checks out the corresponding code version from the version control system based on the version tag specified in the `trigger.txt` file, and restores the corresponding state data and configuration files from a pre-created system snapshot. After the code and data restoration is complete, the system will automatically restart the services, restoring the target system to the specified historical version. Simultaneously, the system will record this emergency rollback event in the audit log for subsequent tracing and analysis.

[0094] Through the above technical solution, this application effectively solves the technical problem that the inability to trigger rollback operations when the user terminal is inaccessible, leading to the system's inability to recover in a timely manner during failures. By introducing an emergency rollback mechanism and utilizing an external trigger file as a non-interactive triggering method, the system can automatically initiate the rollback process in emergency situations such as front-end service failures or network interruptions, without manual operation through the user interface. This greatly improves the system's recovery speed and automation level under abnormal conditions, significantly enhances the system's robustness and fault tolerance, and ensures business continuity. Compared to solutions that rely solely on interactive rollback, the emergency rollback mechanism of this application provides a reliable backup channel, enabling the system to be restored promptly and effectively even at the most critical moments, thereby avoiding the risk of prolonged downtime or data loss due to the inability to rollback.

[0095] In some of the solutions described above in this application, automatic creation of system snapshots is proposed for backup before updates. However, in this process, for important manual operations that are not related to updates, there is a lack of similar snapshot protection mechanisms, which may lead to data loss or unrecoverable system.

[0096] In this regard, this application further proposes to include support for manually creating system snapshots for backup before important operations.

[0097] Specifically, "supporting manual system snapshot creation" means the system provides a mechanism that allows users or administrators to proactively initiate and complete a full backup of the target system's current state at any desired time. This backup operation is not automatically triggered by the system update process but is driven by external commands, such as the "Create Snapshot" button in the system management interface, dedicated command-line tools or API calls, or triggering through specific configuration files. This mechanism allows users to flexibly control the timing of backups to meet the needs of various non-automatic update scenarios. "Backing up before important operations" clarifies the main application scenarios and purposes of manually creating snapshots: pre-saving the system state before performing operations that may pose risks to system stability or data integrity. This provides a safety net for subsequent operations; if an operation fails or produces unforeseen consequences, the system can quickly roll back to its stable state before the operation. The system can prompt users whether they need to manually create a snapshot and provide a convenient trigger entry point before performing certain pre-defined "important" operations (such as large-scale data migration, core configuration modifications, critical service upgrades, etc.); or users can proactively perform backups based on their own assessment of the operational risks.

[0098] This application expands the application scope of snapshot protection by integrating the function of manually creating system snapshots into existing system iterative update methods. When users or administrators need to perform important operations in non-automated update processes, such as making critical configuration adjustments, manually migrating data, or executing custom scripts, they can actively trigger the creation of a system snapshot. This manually created snapshot has the same mechanism and protection capabilities as the snapshot created before the automated update, and can completely capture the target system's code version, state data, and configuration files before the operation. In this way, even user-initiated operations that may pose risks can obtain a reliable backup of the system state before the operation. If the manual operation fails to achieve the expected results or causes system anomalies, the system can utilize its existing version history management function to restore the system to this manually created snapshot point, thereby effectively avoiding risks caused by manual operation errors or unexpected situations, and ensuring system stability and data integrity.

[0099] As a specific implementation method, during critical operations in a non-iterative update process on the target system, such as a system administrator planning to manually modify critical database configuration parameters or execute a large-scale data cleanup script, the administrator can access the system's web management interface before performing these operations. This interface features a button explicitly labeled "Manually Create System Snapshot." When the administrator clicks this button, the system's background snapshot service is activated. This service immediately performs a complete backup of the target system's current state, including but not limited to the currently running code version, real-time database status data, and all relevant configuration files. This manually created snapshot is assigned a unique identifier and timestamp and stored in the system's version history management module, managed alongside automatically generated snapshots. Once the manual operation is complete, regardless of success or failure, the administrator can view and choose to roll back to this manually created snapshot point through the version history management function, ensuring a rapid recovery of the system to a safe state in case of problems.

[0100] Through the aforementioned technical solution, this application enhances the data security and recoverability of the system in non-automatic update scenarios. It provides users or administrators with security guarantees before performing high-risk manual operations, effectively reducing the risks associated with operational errors or unexpected situations. Furthermore, this solution improves the overall reliability of the system and user confidence in its operation, as even manual operations receive the same level of protection as automated updates. By integrating manual snapshots into the existing version history management functionality, all critical operations (whether automatic updates or manual intervention) become traceable and rollbackable, thus comprehensively ensuring the stable operation of the system.

[0101] Compared with existing technologies, the system iterative update method provided in this application solves the problems of low user participation, lack of security verification, and difficulty in rollback in traditional update methods through a complete closed loop of approval-verification-secondary confirmation-version control-rollback. This method has good versatility and flexibility, and can be widely applied to various systems requiring secure iterative updates, including but not limited to industrial control systems, IoT devices, robots, vehicle systems, and intelligent agents. For example, in industrial control systems, this method can adapt to their high requirements for stability and real-time performance, interacting and transmitting data through API interfaces or specific protocols. In IoT devices, this method can optimize the verification process and version control operations to address resource constraints, such as using lightweight protocols for communication or performing partial verification on edge devices. For robot systems, this method can support the updates of their complex motion control and perception modules, ensuring the security and reliability of the update process. In vehicle systems, this method can integrate voice interaction or vehicle bus communication to adapt to the operational needs of driving environments. For intelligent agent systems, this method can handle the iterative updates of their autonomous learning and decision-making modules, ensuring that the updated behavior is as expected and safe. Furthermore, this method can also be applied to any other system with stringent requirements for security, reliability, and traceability, such as medical devices and aerospace systems, by flexibly configuring their approval processes, verification mechanisms, and rollback strategies to meet the specific needs of different systems.

[0102] The proposed solution fully leverages its advantages in approval, verification, version control, and rollback to address the challenges faced by high-risk and diverse systems such as industrial systems, IoT, robotics, automotive systems, and intelligent agents during iterative updates. Specifically, the method includes receiving improvement suggestions, interactive approval, isolated environment verification, verification result display, secondary confirmation, version control operations (including creating system snapshots before updates, merging modifications into the target system, and recording iteration information), and version history management and support for rolling back to specified historical versions. Together, these constitute a secure, controllable, and traceable update process. When applied to these specific systems—for example, industrial systems with extremely high stability and security requirements—the multi-level approval and isolated verification mechanism provided by this method effectively reduces update risks; IoT devices are typically widely distributed and resource-constrained, and the version control and rollback functions of this method ensure the reliability of remote updates; automotive systems have stringent requirements for real-time performance and security, and the system snapshot and rapid rollback capabilities of this method minimize the impact of failures. By combining these core functionalities with the specific operating environment and security requirements of a system, this approach can provide tailored iterative update solutions for these systems, ensuring that their security, reliability, and availability remain unaffected as the system evolves.

[0103] The following is a specific example to illustrate this. As a concrete implementation, the above method can be applied to the OTA (Over-The-Air) upgrade scenario of intelligent vehicles. When the intelligent vehicle's system detects a new software version or functional improvement suggestion, such as the navigation system needing to update map data or the autonomous driving module needing to optimize its algorithm, the improvement suggestion will be received. The system can display these improvement suggestions to the driver or authorized user through voice interaction, for example, prompting "New version detected, upgrade? The upgrade will take approximately 10 minutes; it is recommended to proceed after parking," for approval by the authorized approver (i.e., the driver or user). In response to approval, the system will verify the improvement suggestion in an isolated environment of the vehicle (e.g., an independent virtual machine or secure partition) to ensure the compatibility and stability of the new version with existing hardware and software. After verification, the system will generate a verification result and display it to the authorized approver through the in-vehicle screen or voice prompts, for example, informing them "New version verification passed, install immediately?" In response to secondary confirmation, the system will perform version control operations, including automatically creating a system snapshot before the update, such as backing up the current in-vehicle system's code version, state data, and configuration files, then merging the modifications into the target system, and recording detailed information about this iteration. In addition, the system also provides a version history management function, which supports rolling back to a specified historical version when needed. For example, if an anomaly occurs during the upgrade process, the system can automatically or manually restore to the stable state before the upgrade.

[0104] This solution not only addresses the potential limitations of existing methods in application scenarios but also enhances the practicality and reliability of the entire iterative update scheme in actual deployment, enabling it to effectively adapt to diverse system environments with extremely high security requirements, such as industrial systems, IoT, robotics, automotive systems, and intelligent agents. This significantly improves the method's versatility and flexibility, allowing core functions such as secure approval, isolation verification, version control, and rapid rollback to be seamlessly integrated into these critical systems. For example, in the industrial control field, it ensures strict approval and secure deployment of firmware updates; in automotive systems, it enables reliable OTA upgrades and user controllability; and in the IoT and robotics fields, it guarantees the stability and traceability of remote updates. It provides strong technical support for various systems requiring secure iterative updates.

[0105] Traditional system iteration updates suffer from low user participation, a single approval process, lack of version control, difficulty in rollback, and no snapshot protection. This results in a lack of transparency and controllability in system updates. Once an error occurs during modification, it is difficult to trace and recover from, which seriously affects system stability and user trust.

[0106] To address this, this application provides a system iterative update system, including a suggestion receiving module, an approval interaction module, a verification scheduling module, a result display module, a secondary confirmation module, a version control module, and a history management module. The suggestion receiving module receives improvement suggestions for the target system; the approval interaction module displays the improvement suggestions interactively and receives approval from authorized approvers; the verification scheduling module verifies the improvement suggestions in an isolated environment in response to approval; the result display module generates and displays the verification results; the secondary confirmation module receives secondary confirmation from authorized approvers; the version control module performs version control operations in response to secondary confirmation, including creating system snapshots, merging modifications, and recording iteration information; and the history management module provides version history management functions and supports rollback.

[0107] The core innovation of this embodiment lies in combining the approval interaction module and the verification scheduling module in a process-oriented manner, and introducing a secondary confirmation module and a version control module, thereby achieving full user control and effective risk management during the system iteration and update process. Specifically, the system first obtains improvement suggestions through the suggestion receiving module, and then the approval interaction module displays the suggestion content to the authorized approver through an interactive method. The authorized approver can make an approval decision based on the suggestion details. In response to approval, the verification scheduling module automatically executes the verification process in an isolated environment to ensure the security of the improvement suggestions; after verification, the result display module generates the verification result and displays it to the authorized approver, and the secondary confirmation module further requests the authorized approver for final confirmation. In response to secondary confirmation, the version control module performs key operations: creating a system snapshot to protect the current system state, merging modifications to the target system, and recording detailed iteration information; the history management module maintains all historical versions and supports rollback to a specified version when needed.

[0108] Through the above technical solution, the authorized approver has the right to know and make decisions regarding each system iteration, enhancing trust in the system's behavior; the triple mechanism of approval, verification, and secondary confirmation significantly reduces the risks associated with modifications; creating system snapshots ensures data security, recording iteration information enables historical traceability; and supporting rollback functionality guarantees system stability. Compared to traditional methods, this solution significantly improves the reliability and efficiency of system updates.

[0109] The following is a concrete example: In industrial control systems, firmware updates for PLCs or industrial PCs require strict approval. After an engineer submits improvement suggestions, the system interactively displays the suggestions, which are then approved by the technical supervisor. The system verifies firmware compatibility in an isolated environment, generates and displays the verification results. After the supervisor's secondary confirmation, the system automatically creates a system snapshot, executes the firmware update, and records iteration information. If the update causes an anomaly, it can be rolled back to a previous secure version through the history management module to avoid service interruption.

[0110] In some of the solutions mentioned above in this application, a version history management function is proposed to support rollback. However, in this process, the rollback operation may lack a dedicated execution mechanism, causing the rollback process to rely on manual operation or integration into other modules, resulting in low efficiency, untimely recovery, or increased operational risks, affecting system stability.

[0111] In this regard, this application further proposes that the system iterative update system also includes a rollback module for performing rollback operations.

[0112] A rollback module is a dedicated software or hardware unit responsible for system state recovery. This module can be a standalone software service or process that receives rollback commands via an API interface; alternatively, it can be a submodule integrated into the system's core components, executing rollback logic through internal function calls. The rollback operation aims to restore the system to a previous stable state to address situations where updates fail or introduce problems. Executing a rollback operation can, based on the received rollback commands, retrieve a system snapshot (including code, data, and configuration) of a specified version from the version history management module and deploy it to the target system; or, by calling the underlying system management interface, coordinate a series of steps such as pausing services, replacing files, restoring the database, and restarting services to ensure the atomicity of system state recovery.

[0113] The system iteration update system of this application, upon receiving improvement suggestions for the target system, displays and receives approval from the authorized approver through the approval interaction module. In response to approval, the verification scheduling module verifies the improvement suggestions in an isolated environment. After verification, the result display module generates and displays the verification result to the authorized approver. In response to secondary confirmation, the version control module performs version control operations, including creating a system snapshot before the update, merging the modifications into the target system, and recording iteration information. The history management module provides version history management functions, supporting rollback to a specified historical version. Based on this, this application further introduces a rollback module. This rollback module works closely with the history management module. When the system needs to perform a rollback, the history management module provides snapshot information and metadata of the specified historical version, while the rollback module, as a dedicated execution unit, receives rollback instructions from the history management module or other control interfaces. According to the instructions, the rollback module automatically performs a series of recovery operations, such as pausing the target system service, checking out the corresponding version of code from the version control system, restoring state data and configuration files from the snapshot, and finally restarting the service. This separate design makes the rollback logic independent and specialized, preventing rollback operations from being scattered across other modules and improving the efficiency, reliability, and controllability of rollback. It ensures that in the event of a system problem, the system can be quickly and accurately restored to the expected stable state, thereby effectively reducing the risks and downtime caused by system failures.

[0114] The following is a concrete example to illustrate this. As a specific implementation method, in an enterprise software release scenario, after the system iterative update (including the suggestion receiving module, approval interaction module, verification scheduling module, result display module, secondary confirmation module, version control module, and history management module) completes the deployment of a new version, the version control module has created a system snapshot and recorded iteration information. If a serious failure occurs after the new version is launched, operations personnel can select to roll back to the previous stable version through the history management module interface. At this time, the rollback module is activated. It first receives the rollback instruction and obtains the snapshot data of the specified stable version from the history management module. This data may include code, database backups, and configuration files. The rollback module then automatically executes the rollback operation: for example, it first sends an instruction to the deployment service to pause the currently running software service, then replaces the target system's codebase with the code version in the specified snapshot, restores the database to the backup state in the snapshot, and updates the configuration files. Finally, the rollback module restarts the software service and records this rollback event. The entire process is completed independently and efficiently by the rollback module, without requiring manual intervention from operations personnel for complex recovery steps.

[0115] Through the aforementioned technical solution, this application introduces a dedicated rollback module, enabling the system to provide an independent and efficient rollback execution mechanism, avoiding coupling and dependency of rollback operations on other modules. This significantly improves the efficiency and reliability of rollback operations, ensuring rapid and accurate recovery to a specified historical version in the event of system anomalies. The automated execution capability of the rollback module reduces manual intervention and operational risks, thereby enhancing system stability and fault tolerance, and effectively shortening system failure recovery time. Combined with the version history provided by the history management module, the rollback module can accurately locate and restore to any recorded stable state, providing a solid security guarantee for the continuous iteration of the system.

[0116] In some of the solutions mentioned above in this application, a rollback module is proposed to support rollback operations. However, in this process, when the system front-end interface is inaccessible, the user cannot trigger the rollback through normal interaction, which may cause the system to fail to recover in time and potentially lead to service paralysis or data loss.

[0117] In this regard, this application further proposes to include an emergency rollback monitoring module, which is used to trigger automatic rollback through an external trigger file.

[0118] The emergency rollback monitoring module is a specially designed software component or service. Its main function is to continuously monitor external trigger files at specific locations and automatically initiate the system's rollback process when the existence or content of such files is detected. This module can run as an independent background service; for example, it can be a resident process, a daemon, or a cron job. Its implementation methods can include, but are not limited to: real-time monitoring of file changes through the operating system's file system event listening mechanism (such as inotify in Linux or FileSystemWatcher in Windows); or periodically polling to check the status of specific files or directories. The external trigger file is a pre-defined file used to issue rollback commands. This file can be a simple empty file, whose very existence represents a trigger signal; or it can be a file containing specific content, such as the target version identifier to be rolled back to, the priority of the rollback operation, or the execution mode. When the emergency rollback monitoring module detects that the external trigger file meets preset conditions, it will trigger an automatic rollback operation. This triggering mechanism aims to provide a non-interactive, interface-free rollback startup method, ensuring that in emergency situations such as when the system interface is unavailable or network connection is interrupted, the system can still be started and restored through simple operations on external files.

[0119] This application's solution addresses the challenge of triggering rollback when the system frontend is unavailable by adding an emergency rollback monitoring module, ensuring system stability even under extreme failures. Specifically, the emergency rollback monitoring module allows the system to continuously monitor changes to external trigger files in the background, without relying on the user interface or interaction channels. When this file is created or modified, the module automatically triggers a rollback operation. This mechanism allows users or administrators to indirectly initiate the recovery process by simply manipulating external files when the frontend fails, thus avoiding service interruption risks. Automatic rollback triggered by external trigger files achieves emergency response independent of frontend interaction, enhancing the system's fault tolerance and reliability. This emergency rollback monitoring module works closely with the history management module and rollback module in the aforementioned system iteration update system, forming a complete, multi-layered system recovery guarantee system. When a serious system failure causes frontend interaction to fail, the emergency rollback monitoring module can quickly respond to the signal from the external trigger file, directly calling the rollback module to execute the preset rollback operation, thereby utilizing the version history data maintained by the history management module to restore the system to a stable historical version. This design enables the entire system to provide more robust and timely recovery capabilities in the face of emergencies, greatly improving the system's availability and stability.

[0120] As a specific implementation, the emergency rollback monitoring module can be implemented as a standalone Python or Shell script, configured to run continuously in the background via a system service (such as the systemd service). This script periodically (e.g., every 5 seconds) checks a pre-defined external trigger file, such as a file located at ` / opt / system_update / rollback_trigger.txt`. When the script detects the existence of the `rollback_trigger.txt` file and that its content conforms to a specific format (e.g., containing a valid version tag, such as `v2.0.0`), or simply that the file has been created or modified, the emergency rollback monitoring module parses the file content to determine the target rollback version and then calls the system's internal rollback interface or executes a pre-defined rollback command. For example, it can execute `systemctl stop my_service` to pause the target service, then call the version control system (such as Git) command `git checkout v2.0.0` to restore the code, restore data and configuration files from a pre-backed snapshot, and finally execute `systemctl start my_service` to restart the service. After the rollback is complete, the trigger file can be automatically deleted or renamed to avoid repeated triggering.

[0121] Through the above technical solution, this application provides a mechanism that can still effectively trigger system rollback in emergency situations where the system front-end interface is inaccessible. This significantly improves the system's fault recovery capability and operational efficiency, reduces the risk of prolonged downtime or data loss due to system failures, and thus ensures the continuous and stable operation of the system.

[0122] In some of the solutions mentioned above in this application, a system iterative update method is proposed to solve the problems of low user participation, single approval method, lack of version control, difficulty in rollback and lack of snapshot protection in the prior art. However, in the actual deployment and execution of computer systems, a carrier that can be permanently stored and automatically triggered to ensure that these methods can be implemented efficiently and reliably, and avoid the risks of execution errors, low efficiency and non-reproducibility of the methods caused by manual operation or lack of dedicated media.

[0123] In response, this application proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method.

[0124] Specifically, the computer-readable storage medium refers to a physical medium capable of storing digital data and readable by a computer system. This medium can be volatile, such as random access memory (RAM), or non-volatile, such as read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state drive (SSD), hard disk drive (HDD), optical disc (CD-ROM, DVD, Blu-ray disc), or magnetic tape. As a carrier of computer programs, this medium ensures the persistent storage and accessibility of the programs. The computer program is a collection of instructions designed to enable the computer to perform specific tasks or operations. The program can be in the form of compiled binary code, interpreted script code, or intermediate code, written in a high-level programming language (such as Java, Python, C++, etc.), and executed on the processor after compilation or interpretation. The program encapsulates all the logic and steps of the system's iterative update method. The processor is the core computing unit in the computer system, responsible for executing instructions and processing data. The processor can be a central processing unit (CPU), graphics processing unit (GPU), microcontroller (MCU), digital signal processor (DSP), or application-specific integrated circuit (ASIC), etc. The processor reads and executes a computer program stored on a computer-readable storage medium, thereby driving the operation of the system iterative update method. Implementing the method means that the processor completes all the steps and functions of the aforementioned system iterative update method by executing the computer program. This includes the processor sequentially executing steps such as receiving improvement suggestions, displaying approval, isolating and verifying, generating verification results, performing version control operations (including creating a system snapshot before the update, merging modifications into the target system, and recording iteration information), and providing version history management functions (supporting rollback to a specified historical version) according to the logical order of program instructions. This process involves data processing, accessing system resources, and interacting with external modules, ensuring the automated, efficient, and accurate execution of the system iterative update method.

[0125] This application's solution automates and standardizes the system iterative update method by embedding it onto a computer-readable storage medium and having a processor execute the computer program stored thereon. The computer-readable storage medium serves as the basic storage unit, providing a stable and reliable storage environment for the computer program. When the system iterative update method needs to be executed, the processor reads and loads the computer program from this medium. This computer program contains all the logic and instructions of the aforementioned system iterative update method. Once executed by the processor, it automatically drives the entire iterative update process according to a preset flow. This includes receiving improvement suggestions for the target system, interactively displaying the improvement suggestions for approval by the authorized approver, verifying the improvement suggestions in an isolated environment in response to approval, generating verification results and displaying them to the authorized approver after verification, performing version control operations in response to secondary confirmation (including creating a system snapshot before the update, merging the changes into the target system, and recording iteration information), and providing version history management functions to support rollback to a specified historical version. This collaborative working mechanism transforms methods that originally required manual intervention or relied on specific operating environments into a set of fixed, repeatable, and highly efficient automated processes. In this way, the solution effectively solves the problems of execution errors, inefficiency, and non-reproducibility that may be caused by traditional manual operation, and ensures the standardization and reliability of the system iteration and update process.

[0126] As a specific implementation, one can envision a system iteration and update service deployed on a server. The service's executable code, i.e., the computer program, is stored on the server's solid-state drive (SSD), which is a computer-readable storage medium. When the service starts, the server's central processing unit (CPU), i.e., the processor, loads and executes the computer program. The program then listens for improvement suggestions from the user interface or API, generates an interactive approval interface through internal modules for authorized approvers to operate, and schedules virtual machines or container environments for isolated verification based on the approval result. After successful verification, the program generates a detailed verification report and pushes it to the authorized approver for secondary confirmation. Once secondary confirmation is obtained, the program automatically calls a version control system (such as Git), creates a system snapshot before the update, merges the changes into the target system codebase, and records detailed information and version tags for this iteration. Furthermore, the program provides a history management interface, allowing authorized approvers to view all historical versions and trigger rollback operations.

[0127] The above technical solution solidifies the system iterative update method into a computer program and stores it on a computer-readable storage medium, which is then automatically executed by the processor. This eliminates the delays and error risks introduced by manual operation, ensuring the standardization and automation of the system iterative update process. This significantly improves the efficiency and reliability of system updates, while also guaranteeing the portability and consistency of the method across different hardware environments. It effectively solves the problems of execution errors, low efficiency, and non-reproducibility caused by manual operation or lack of dedicated media.

[0128] Other application scenarios The following simplified embodiments illustrate the application of the present invention in other fields. Specific implementations of these embodiments can be found in the examples described in the detailed embodiments above, and will not be repeated here.

[0129] Simplified Example 1: OTA Upgrade for Smart Cars Over-the-air (OTA) upgrades for the vehicle's infotainment system require user confirmation. The vehicle's infotainment system will prompt via voice interaction: "A new version has been detected. Do you want to upgrade? The upgrade will take approximately 10 minutes. We recommend that you park the vehicle before proceeding." After the user confirms via voice, the system will download and verify the version in the background. Once verification is complete, the user can confirm again via voice. The system will then automatically create a system snapshot, execute the upgrade, and record the version. If the upgrade fails, the system will automatically roll back to the previous version and notify the user via the vehicle's infotainment system screen.

[0130] Simplified Example 2: Mobile Application Hotfix Hotfixes for mobile applications require rapid response while avoiding impact on user experience. After developers submit fix suggestions, the system can be configured with automatic approval rules (such as "urgent fixes can be automatically approved"). After the system completes verification in the background, it automatically creates a snapshot, releases the hotfix package, and records the version. The entire process requires no manual intervention, yet retains a complete version history and rollback capability.

[0131] The above descriptions are merely embodiments of this application and are not intended to limit the scope of protection of this application. It should be noted that "user" in this application refers to an entity with approval authority, including but not limited to individual users, system administrators, maintenance personnel, automated approval systems, etc. The "user approval" and "user secondary confirmation" in the claims can be executed by approvers with different permissions depending on the actual application scenario. For those skilled in the art, this application can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0132] This solution is applicable not only to local devices but can also be deployed on cloud servers. Those skilled in the art should understand that the technical solution of this invention is not limited to a specific deployment environment, and any implementation based on the technical concept of this application should be considered to fall within the protection scope of this invention.

Claims

1. A system iterative update method, characterized in that, Includes the following steps: Receive improvement suggestions for the target system; The proposed improvements are presented interactively for approval by the authorized approver. In response to approval, validate the proposed improvements in an isolated environment; Once verification is complete, a verification result is generated and displayed to the authorized approver. In response to secondary confirmation, a version control operation is performed, which includes creating a system snapshot before the update, merging the changes into the target system, and recording iteration information. It provides version history management functionality and supports rolling back to a specified historical version.

2. The method according to claim 1, characterized in that, The improvement suggestions include, but are not limited to, at least one of the following: problem description, modification plan, expected effect, or risk analysis.

3. The method according to claim 1, characterized in that, The system snapshots include, but are not limited to, backups of code versions, status data, or configuration files.

4. The method according to claim 1, characterized in that, The version control operation also includes creating a version tag to identify the current iteration.

5. The method according to claim 1, characterized in that, Also includes: When the approval fails, the reason for rejection is recorded and fed back to the relevant module.

6. The method according to claim 1, characterized in that, The rollback operation includes pausing the service, restoring the corresponding version of code and data, and restarting the service.

7. The method according to claim 1, characterized in that, It also includes an emergency rollback mechanism: automatic rollback triggered by an external trigger file.

8. The method according to claim 1, characterized in that, It also includes support for manually creating system snapshots for backup before important operations.

9. A system for iterative updates, characterized in that, include: The suggestion receiving module is used to receive improvement suggestions for the target system; The approval interaction module is used to display the improvement suggestions through an interactive method and receive approval from the authorized approver. The verification scheduling module is used to verify improvement suggestions in an isolated environment in response to approval. The results display module is used to generate and display the verification results; The secondary confirmation module is used to receive secondary confirmation from the authorized approver. The version control module is used to perform version control operations in response to secondary confirmation. The version control operations include creating system snapshots, merging modifications, and recording iteration information. The history management module provides version history management functionality and supports rollback.

10. The system according to claim 9, characterized in that, It also includes a rollback module for performing rollback operations.

11. The system according to claim 9, characterized in that, It also includes a rollback module for performing rollback operations.

12. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any one of claims 1 to 8.

Images