A method, system, storage medium, and electronic device for canary deployment of web front-ends.
By introducing a canary control SDK and path isolation deployment method at the front-end rendering entry stage, the invasiveness and compatibility issues of existing front-end canary release schemes are solved, achieving flexible, low-cost multi-technology stack adaptation and efficient canary release.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 上海捷晓信息技术有限公司
- Filing Date
- 2026-02-06
- Publication Date
- 2026-05-26
AI Technical Summary
Existing front-end canary release solutions suffer from problems such as high intrusion, high cost, insufficient flexibility, and poor compatibility, making them difficult to adapt to the needs of web systems with high-frequency iteration, multi-scenario deployment, and multiple technology stacks.
A collaborative mechanism between the front-end rendering base and the grayscale control SDK is introduced at the front-end rendering entry stage. The grayscale control SDK completes grayscale distribution and version selection on the front-end side. Combined with the deployment methods of path isolation and resource fingerprint identification, it realizes parallel caching of multiple versions of resources and dynamic grayscale strategy adjustment.
It achieves zero-intrusion, low-cost, and flexible front-end canary releases, reduces dependence on back-end systems, supports multi-technology stack adaptation, and improves release efficiency and system stability.
Smart Images
Figure CN122086435A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet software engineering technology, and in particular to a method, system, storage medium, and electronic device for gray-scale deployment of Web front-end. Background Technology
[0002] With the rapid development of Internet technology, the business scale of Web systems continues to expand, and development models such as Agile Development, Continuous Integration and Continuous Deployment (CI / CD) have become widely popular. This has led to a significant increase in the version iteration and release frequency of front-end applications, placing higher demands on the flexibility, security and efficiency of the release process.
[0003] The release of front-end application versions is directly related to user experience and business stability. Traditional full release solutions have significant drawbacks in practical applications: once a released version has problems such as program vulnerabilities or functional abnormalities, it is difficult to quickly roll back or accurately stop the damage. This can easily lead to the expansion of the scope of the defects, affecting a large number of end users, and causing adverse consequences such as user complaints and business losses. It can no longer meet the release needs of the current high-frequency iteration scenarios.
[0004] To address the drawbacks of full releases, the industry is gradually adopting server-side solutions such as API gateways and Nginx / OpenResty to achieve canary releases, gradually distributing new version traffic to a subset of users to reduce the risk of defect spread. However, existing server-side canary release solutions still face numerous technical bottlenecks, specifically: First, deployment and maintenance costs are high. Implementation typically requires large-scale adjustments to the existing backend service architecture and operations system, consuming significant human and material resources and potentially impacting the normal operation of existing businesses. Second, server-side canary mechanisms and CDN caching strategies struggle to achieve efficient coordination. In global deployments and multi-regional user access scenarios, issues such as cache inconsistency and increased access latency can easily arise, limiting release performance. Third, the configuration and adjustment of canary strategies lack flexibility, relying mostly on manual intervention or hard-coding, making it impossible to dynamically optimize traffic distribution rules in real time based on business needs and user feedback. Fourth, adaptability to multi-technology stack frontend projects and legacy projects is poor. During canary releases of projects with different technology frameworks and versions, additional adaptation plugins or extensive code modifications are required, further increasing maintenance and upgrade costs.
[0005] In summary, existing front-end canary deployment solutions suffer from problems such as high invasiveness, high cost, insufficient flexibility, and poor compatibility, making them unsuitable for the current development needs of web systems, which involve high-frequency iteration, multi-scenario deployment, and the coexistence of multiple technology stacks. Therefore, developing a non-intrusive, low-cost, automatically manageable, CDN-compatible, and multi-technology-stack-compatible front-end canary deployment system has become an urgent technical problem to be solved in this field. Summary of the Invention
[0006] To address the shortcomings of existing technologies, this application provides a method, system, storage medium, and electronic device for canary deployment of web front-ends.
[0007] To achieve the above-mentioned objectives, the present invention provides the following technical solution: A method for canary deployment of a web front-end includes the following steps: S1. Receiving an access request: The end user initiates an access request to the target web application in the browser. The access request first reaches the edge node of the content delivery network CDN. The CDN returns the application's entry resource according to the caching policy or forwards the request to the origin server to obtain the entry resource before returning it. S2. Load the front-end rendering base and initialize the SDK: After the browser loads the entry resources, it starts the front-end rendering base. During the initialization phase, the front-end rendering base loads the grayscale control SDK and establishes a runtime context for grayscale determination. The front-end rendering base serves as the unified rendering entry point for the web application, carrying the page entry file and controlling the application initialization process. The grayscale control SDK is embedded in the front-end rendering base as an independent plugin module and is loaded and executed during the application initialization phase. S3. Obtain and cache grayscale configuration: The grayscale control SDK sends a grayscale policy retrieval request to the grayscale configuration platform to obtain the currently effective grayscale rule configuration. The grayscale configuration platform returns the configuration data, and the grayscale control SDK stores the configuration data in the local cache and records the configuration version number or effective time for subsequent quick determination and incremental updates. S4. Perform grayscale hit calculation: The grayscale control SDK performs hit calculation on the current user request based on the grayscale rule configuration to obtain the grayscale determination result and the target version identifier. S5. Select the target version static resource based on the judgment result: If the grayscale judgment result is that the grayscale is not hit, the front-end rendering base continues to load the default version static resource and complete the page rendering; if the grayscale judgment result is that the grayscale is hit, the grayscale control SDK controls the front-end rendering base to select the static resource entry corresponding to the target version identifier and triggers the loading of the target version static resource. S6. Obtain target version resources via CDN and return rendering results: When the target version static resources are selected, the browser requests the static resources under the resource path corresponding to the target version identifier from the CDN. If the CDN hits the cache, it returns the corresponding cached resources; otherwise, it returns to the origin website.
[0008] In one implementation, it also includes S7, anomaly detection and rollback processing: During static resource loading or page operation, the grayscale control SDK monitors abnormal conditions. When anomalies such as unavailable resources, script errors, or rule failures are detected, a rollback strategy is triggered to control the front-end rendering base to switch to the default version or a preset stable version of resources.
[0009] In one implementation, the entry resource in S1 is index.html; the runtime context in S2 includes user identifier, session information, environment information, and preset grayscale parameters.
[0010] In one implementation, in S3, the configuration data includes grayscale strategy parameters, and the local cache is LocalStorage, IndexedDB, or a memory cache.
[0011] In one implementation, the hit calculation in S4 includes: matching by user identifier, traffic ratio, user group, region or expression rule, where the target version identifier is the version number or resource path identifier, and the user identifier is UserID or account ID.
[0012] In one implementation, the static resource entry point in S5 is the corresponding version of the HTML file or the static resource list; S5 deploys front-end static resources of different versions using path isolation and resource fingerprint identification.
[0013] This application also provides a web front-end canary release system, including: Front-end rendering base module: Used as the unified rendering entry point for web applications, responsible for application initialization process control, loading of the canary control SDK, receiving version determination results, and loading and rendering of static resources of the target version; The grayscale control SDK module is used to obtain and parse grayscale rule configurations at the front-end rendering entry stage, perform grayscale hit calculations on the current user request, generate target version determination results, and output control instructions to the front-end rendering base. Configuration management module: used for centralized storage, maintenance and distribution of gray-scale rule configurations. The gray-scale rules exist in the form of structured configuration data and support dynamic updates and version rollbacks of the rules. Static resource distribution module: used to cache and distribute different versions of front-end static resources, supporting parallel deployment and independent caching of multiple versions of resources; Anomaly detection and rollback module: Used to monitor static resource loading anomalies or runtime anomalies on the front end, and trigger rollback processing when an anomaly occurs; The modules in the system communicate and collaborate through predefined interfaces.
[0014] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.
[0015] This application also provides an electronic device, including: a memory storing a computer program thereon; and a processor configured to execute the computer program in the memory to implement the steps of the above method.
[0016] Compared with the prior art, this application has at least the following beneficial effects: By introducing a canary control mechanism consisting of a front-end rendering base and a pluggable canary control SDK at the front-end rendering entry stage, the canary distribution and version selection logic of user requests are moved to the front-end side to be completed. This allows the target version to be determined at the static resource loading stage, and the canary release and rollback functions to be executed independently of the server gateway and API routing. By using a deployment method that combines path isolation and resource fingerprint identification for front-end static resources of different gray-scale versions, multiple versions of resources can coexist in parallel and be cached by the content distribution network, thereby achieving multi-version gray-scale distribution without affecting the cache hit mechanism. By coordinating the configuration management module and the canary control SDK, canary policies can be dynamically applied on the front end, and version switching or rollback operations can be triggered when abnormal conditions or policy changes are detected, thereby realizing real-time adjustment and rollback control of canary policies.
[0017] By introducing multi-dimensional rule parsing logic into the grayscale control SDK, user requests can be comprehensively judged based on user identifier, traffic ratio or rule expression, thus realizing grayscale traffic control in complex business scenarios. The front-end rendering base of this application introduces grayscale control capabilities on the basis of traditional rendering functions. By loading the grayscale control SDK during the application initialization stage, the front-end rendering entry point has the ability to parse grayscale rules, select versions, and rollback control. This allows the release decision to be moved to the front-end rendering stage, enabling the front-end to independently complete grayscale distribution and version control. This overcomes the limitations of existing technologies where the front-end rendering base can only be used for page rendering and resource loading, and the loaded front-end resource versions are only fixed versions, lacking release control capabilities. The visual interface provided by the operation and maintenance platform in this application system serves only as the entry point for editing and managing configuration data, used to generate or modify canary release rule configuration data. The configuration management module provides rule data to the canary release control SDK through the configuration distribution interface, realizing real-time updates and version rollbacks of canary release rules. In this application, different versions of resources correspond to different access paths, and the CDN can cache each version of resources separately, avoiding cache overwrite issues between different canary release versions and enabling parallel distribution of multiple version resources.
[0018] Other features and advantages of the present invention will be described in detail in the following detailed description section. Attached Figure Description
[0019] Figure 1 This is a timing diagram of the Web front-end canary deployment process in the embodiments of this application; Figure 2 This is a schematic diagram of the configuration center's visual grayscale management in an embodiment of this application; Figure 3 This is a schematic diagram of the grayscale splitting and rollback control process in an embodiment of this application; Figure 4 This is a framework diagram of the Web front-end canary release system in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the electronic device in the embodiments of this application. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention is described below with reference to specific embodiments shown in the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.
[0021] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.
[0022] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms and should not be construed as indicating or implying relative importance. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."
[0023] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical connection or internal connection between two components. They can be direct connection or indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.
[0024] To better understand the technical solution of the present invention, the present invention will be described in detail below with reference to the accompanying drawings.
[0025] As attached Figure 1-3 As shown, this embodiment provides a method for canary deployment of a web front-end, including the following steps: S1. Receiving an access request: The end user initiates an access request to the target web application in the browser. The access request first reaches the edge node of the Content Delivery Network (CDN). The CDN returns the application's entry resource according to the caching policy or forwards the request to the origin server to obtain the entry resource before returning it. In this embodiment, the entry resource is index.html. S2. Load the front-end rendering base and initialize the SDK (Software Development Kit): After the browser loads the entry resources, it starts the front-end rendering base. During the initialization phase, the front-end rendering base loads the grayscale control SDK and establishes a runtime context for grayscale determination. The runtime context includes user identifier, session information, environment information, or preset grayscale parameters. The front-end rendering base serves as the unified rendering entry point for the web application, carrying the page entry file and controlling the application initialization process. The grayscale control SDK is embedded in the front-end rendering base as an independent plugin module and is loaded and executed during the application initialization phase. S3. Obtain and cache grayscale configuration: The grayscale control SDK sends a grayscale policy retrieval request to the grayscale configuration platform to obtain the currently effective grayscale rule configuration. The grayscale configuration platform returns the configuration data, and the grayscale control SDK stores the configuration data in a local cache and records the configuration version number or effective time for subsequent quick determination and incremental updates. The local cache can be LocalStorage, IndexedDB, or memory cache. S4. Perform grayscale hit calculation: The grayscale control SDK performs hit calculation on the current user request based on the grayscale rule configuration to obtain the grayscale judgment result and the target version identifier. The hit calculation includes: matching by user identifier (UserID / account ID), traffic ratio, user group, region or expression rule. The target version identifier is the version number or resource path identifier. S5. Select target version static resources based on the judgment result: If the grayscale judgment result is a missed grayscale, the front-end rendering base continues to load the default version static resources and completes page rendering; if the grayscale judgment result is a hit grayscale, the grayscale control SDK controls the front-end rendering base to select the static resource entry corresponding to the target version identifier and triggers the loading of the target version static resources; wherein, the static resource entry is the corresponding version of the html file or static resource list, and different versions of front-end static resources are deployed using path isolation and resource fingerprint identification, so that multiple versions of static resources can exist in parallel and be cached by the content distribution network, thereby realizing the independent distribution of different versions of resources in the grayscale release scenario.
[0026] S6. Obtain target version resources via CDN and return rendering results: When the target version static resources are selected, the browser requests the static resources under the resource path corresponding to the target version identifier from the CDN. If the CDN hits the cache, it returns the corresponding cached resources; otherwise, it returns to the origin website. S7. Anomaly Detection and Rollback Handling: During static resource loading or page execution, the grayscale control SDK monitors abnormal conditions. When anomalies such as unavailable resources, script errors, or rule failures are detected, a rollback strategy is triggered to control the front-end rendering base to switch to the default version or a preset stable version of resources.
[0027] This embodiment moves the canary-scale distribution and version selection logic to the front-end rendering entry point through S1-S3, so that the user request completes the version determination and resource selection before entering the back-end business processing. Static resources of different versions can be directly returned to the end user through the content delivery network CDN, thereby avoiding the involvement of back-end gateways, server-side routing or middleware in the canary-scale judgment process, and significantly reducing the intrusion and coupling of the back-end system.
[0028] The pluggable SDK architecture collaborates with the front-end rendering base through standardized interfaces. The front-end rendering base provides the SDK with unified loading timing, runtime context, and lifecycle management capabilities, while the SDK exposes control interfaces such as grayscale strategy parsing, version selection, and exception handling to the rendering base. This enables seamless access and upgrades of multi-technology stack front-end applications without modifying existing business code.
[0029] A centralized configuration management mechanism is implemented through S4, where canary deployment rule information is uniformly maintained and dynamically distributed by the configuration management module to support real-time adjustments to canary deployment strategies. Real-time change and multi-level rollback mechanisms are implemented through S6 and S7. The canary deployment control SDK dynamically switches or rolls back the currently effective front-end version based on changes in canary deployment rules distributed by the configuration management module, enabling version rollback control when abnormal conditions or policy changes are detected.
[0030] This embodiment also provides a Web front-end canary deployment system 100, as shown in the attached figure. Figure 4 As shown, it includes: Front-end rendering base module 110: Used as the unified rendering entry point for web applications, responsible for application initialization process control, loading of the grayscale control SDK, receiving version determination results, and loading and rendering of static resources of the target version; Grayscale control SDK module 120: used to obtain and parse grayscale rule configuration at the front-end rendering entry stage, perform grayscale hit calculation on the current user request, generate target version determination result, and output control instructions to the front-end rendering base; Configuration management module 130: used for centralized storage, maintenance and distribution of gray-scale rule configurations, the gray-scale rules exist in the form of structured configuration data, and support dynamic updates and version rollback of rules; Static resource distribution module 140: used to cache and distribute different versions of front-end static resources. It uses path isolation and resource fingerprint identification to deploy different versions of front-end static resources. It supports parallel deployment and independent caching of multiple versions of resources, so that multiple versions of static resources can exist in parallel and be cached by the content distribution network. Anomaly detection and rollback module 150: Used to monitor static resource loading anomalies or runtime anomalies on the front end, and trigger rollback processing when an anomaly occurs; The modules in the system communicate and collaborate through predefined interfaces.
[0031] The system has a standard interface 160 reserved for interaction with external systems to exchange grayscale strategies or experimental information.
[0032] Through the aforementioned canary release method or system, this embodiment enables canary release, version switching, and exception rollback of front-end web applications without relying on backend gateway or server-side modifications, reducing release risks and improving system stability and release efficiency. The canary release method or system in this embodiment can be applied to concurrent release scenarios across multiple business lines, such as e-commerce promotions or multi-regional logistics system deployments. The canary release mechanism enables on-demand releases, quickly locating anomalies and minimizing their impact, ensuring business continuity. This embodiment can also be applied to front-end version comparison testing scenarios, enabling parallel verification of different versions through canary release rules to support version performance evaluation and strategy optimization. Furthermore, this invention supports cross-team use, reducing the cost for developers to participate in release control and improving overall delivery efficiency through a unified canary release configuration and release mechanism.
[0033] In real-world production environments, the canary release method or system described in this embodiment has been deployed and verified across multiple business projects. The integration process for each project requires no large-scale modification of existing business code, with an average integration time of less than 2 hours, supporting rapid migration and deployment. Testing showed that after integrating the system described in this embodiment, the initial page loading performance did not significantly decrease, and the loading time increased by no more than 300ms, meeting the performance requirements of high-concurrency access scenarios. This solution supports high-concurrency user access, and canary release strategy switching and anomaly rollback can be completed in a short time, effectively reducing the scope of anomaly impact and improving overall system stability.
[0034] This embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.
[0035] As attached Figure 5 As shown, this embodiment also provides an electronic device 200, which includes: a memory 201 storing a computer program thereon; and a processor 202 configured to execute the computer program in the memory to implement all or part of the steps of the above-described grayscale release method.
[0036] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them; although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications can still be made to the specific implementation of the invention or equivalent substitutions can be made to some technical features without departing from the spirit of the technical solutions of the present invention, and all such modifications and substitutions should be covered within the scope of the technical solutions claimed in the present invention.
Claims
1. A method for canary deployment of a web front-end, characterized in that, Includes the following steps: S1. Receiving an access request: The end user initiates an access request to the target web application in the browser. The access request first reaches the edge node of the content delivery network CDN. The CDN returns the application's entry resource according to the caching policy or forwards the request to the origin server to obtain the entry resource before returning it. S2. Load the front-end rendering base and initialize the SDK: After the browser loads the entry resources, it starts the front-end rendering base. During the initialization phase, the front-end rendering base loads the grayscale control SDK and establishes a runtime context for grayscale determination. The front-end rendering base serves as the unified rendering entry point for the web application, carrying the page entry file and controlling the application initialization process. The grayscale control SDK is embedded in the front-end rendering base as an independent plugin module and is loaded and executed during the application initialization phase. S3. Obtain and cache grayscale configuration: The grayscale control SDK sends a grayscale policy retrieval request to the grayscale configuration platform to obtain the currently effective grayscale rule configuration. The grayscale configuration platform returns the configuration data, and the grayscale control SDK stores the configuration data in the local cache and records the configuration version number or effective time for subsequent quick determination and incremental updates. S4. Perform grayscale hit calculation: The grayscale control SDK performs hit calculation on the current user request based on the grayscale rule configuration to obtain the grayscale judgment result and the target version identifier. S5. Select the target version static resource based on the judgment result: If the grayscale judgment result is that the grayscale is not hit, the front-end rendering base continues to load the default version static resource and complete the page rendering; if the grayscale judgment result is that the grayscale is hit, the grayscale control SDK controls the front-end rendering base to select the static resource entry corresponding to the target version identifier and triggers the loading of the target version static resource. S6. Obtain target version resources via CDN and return rendering results: When the target version static resources are selected, the browser requests the static resources under the resource path corresponding to the target version identifier from the CDN. If the CDN hits the cache, it returns the corresponding cached resources; otherwise, it returns to the origin website.
2. The Web front-end canary release method according to claim 1, characterized in that, It also includes S7, anomaly detection and rollback handling: During static resource loading or page operation, the grayscale control SDK monitors abnormal conditions. When anomalies such as unavailable resources, script errors, or rule failures are detected, a rollback strategy is triggered to control the front-end rendering base to switch to the default version or a preset stable version of resources.
3. The Web front-end canary release method according to claim 1, characterized in that, The entry resource in S1 is index.html; the runtime context in S2 includes user ID, session information, environment information, and preset grayscale parameters.
4. The Web front-end canary release method according to claim 1, characterized in that, In S3, the configuration data includes grayscale strategy parameters, and the local cache is LocalStorage, IndexedDB, or memory cache.
5. The Web front-end canary deployment method according to claim 1, characterized in that, The hit calculation described in S4 includes: matching by user identifier, traffic ratio, user group, region or expression rules, with the target version identifier being the version number or resource path identifier, and the user identifier being the UserID or account ID.
6. The Web front-end canary deployment method according to claim 1, characterized in that, In S5, the entry point for static resources is the corresponding version of the HTML file or the list of static resources; S5 uses path isolation and resource fingerprint identification to deploy front-end static resources of different versions.
7. A web front-end canary release system, characterized in that, include: Front-end rendering base module: Used as the unified rendering entry point for web applications, responsible for application initialization process control, loading of the canary control SDK, receiving version determination results, and loading and rendering of static resources of the target version; The grayscale control SDK module is used to obtain and parse grayscale rule configurations at the front-end rendering entry stage, perform grayscale hit calculations on the current user request, generate target version determination results, and output control instructions to the front-end rendering base. Configuration management module: used for centralized storage, maintenance and distribution of gray-scale rule configurations. The gray-scale rules exist in the form of structured configuration data and support dynamic updates and version rollbacks of the rules. Static resource distribution module: used to cache and distribute different versions of front-end static resources, supporting parallel deployment and independent caching of multiple versions of resources; Anomaly detection and rollback module: Used to monitor static resource loading anomalies or runtime anomalies on the front end, and trigger rollback processing when an anomaly occurs; The modules in the system communicate and collaborate through predefined interfaces.
8. The Web front-end canary release system according to claim 1, characterized in that, The static resource distribution module deploys different versions of front-end static resources using path isolation and resource fingerprint identification, enabling multiple versions of static resources to coexist in parallel and be cached by the content distribution network. The system has a standard interface reserved for interacting with external systems to exchange grayscale strategies or experimental information.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-7.
10. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor is configured to execute the computer program in the memory to implement the steps of the method according to any one of claims 1-7.