Front-end gray release method, device, equipment and medium

Abstract

The invention relates to the technical field of computers, in particular to a front-end gray release method and device, equipment and a medium, which are used for improving the flexibility of gray release. The method comprises the following steps: in response to an access request of an object for a client, obtaining gray level configuration information of the client from a server; the client provides a plurality of pages; the gray level configuration information is used for indicating access paths corresponding to the plurality of pages; in response to a jump request which is triggered by the object and is used for jumping from a first page in the plurality of pages to a second page in the plurality of pages, determining an access path of the second page by the front-end routing interface according to the gray level configuration information; wherein the access path comprises a rollback path and a gray level path; and loading the front-end resource file of the corresponding version based on the access path, and rendering the second page according to the front-end resource file.

Description

Technical Field

[0001] This application relates to the field of computers, specifically to a front-end grayscale release method, apparatus, device, and medium. Background Technology

[0002] In the current mainstream front-end and back-end separation development model, front-end projects are usually built on frameworks such as Vue, and code projects often use compilation tools such as Webpack or Vite during the packaging and deployment process.

[0003] To meet information security and code confidentiality requirements, front-end code is often compressed and obfuscated before release. While this improves security, it also makes it difficult to quickly locate and roll back issues in the packaged front-end code. If an emergency occurs in the online version, the entire front-end package usually has to be rolled back, increasing operational risks and recovery costs.

[0004] To mitigate the risks of launching new features, related technologies employ a canary release mechanism, allowing select users, pages, or organizations to access the new version first to verify stability before gradually increasing deployment. However, existing front-end canary release solutions largely rely on server-side or Nginx-layer rule configurations, and rule updates are complex and lack real-time performance.

[0005] In summary, improving the flexibility of canary releases is an urgent issue that needs to be addressed. Summary of the Invention

[0006] This application provides a front-end grayscale release method, apparatus, device, and medium to improve the flexibility of grayscale release.

[0007] Firstly, this application provides a front-end canary deployment method, applied to a client, the method comprising: In response to an access request from the client, the grayscale configuration information of the client is obtained from the server; the client provides multiple pages; the grayscale configuration information is used to indicate the access path corresponding to each of the multiple pages; In response to a redirection request triggered by the object, from a first page among the plurality of pages to a second page among the plurality of pages, the front-end routing interface determines the access path of the second page based on the grayscale configuration information; wherein, the access path includes: a fallback path and a grayscale path; the fallback path is a front-end resource access path preset by the server for the client before the client's grayscale release; the grayscale path is a front-end resource access path preset by the server for the client after the client's grayscale release; The corresponding version of the front-end resource file is loaded based on the access path, and the second page is rendered according to the front-end resource file.

[0008] Through the above implementation methods, this application enables the client to autonomously determine and switch page access paths. It directly determines the page access path based on the canary deployment configuration information using the front-end routing interface, thus eliminating the need for server-side request routing or Nginx forwarding logic, reducing backend pressure and operational complexity. Furthermore, by loading the corresponding version of the front-end resource file on the client and rendering the page, this application achieves page-level canary deployment and rollback control. This allows canary deployment logic to take effect quickly on the front end, with fast response times and seamless switching for users, significantly improving the flexibility of canary deployment and the stability of the system.

[0009] In one possible embodiment, the grayscale configuration information includes grayscale enable parameters for indicating the grayscale release enable status and fallback parameters for indicating the grayscale path to switch to the fallback path, and the method includes: If the grayscale enable parameter indicates that grayscale publishing is not enabled, then the access path of the second page is determined to be the grayscale path; If the grayscale enable parameter indicates that grayscale release is enabled, the access path to the second page is determined according to the fallback parameter.

[0010] Through the above implementation methods, this application achieves dynamic switching between canary release and version rollback logic by jointly controlling the canary release enable parameter and the rollback parameter. When the canary release enable parameter is not enabled, the system can uniformly access the canary path to maintain the stability of the front-end version; when the canary release enable parameter is enabled, the system can flexibly decide whether the page should roll back to the old version path based on the rollback parameter. This allows for rapid switching between canary and rollback versions without redeploying or modifying server rules, effectively improving the flexibility of the canary release process and the controllability of the system.

[0011] In one possible embodiment, the grayscale configuration information further includes a grayscale list, and the method includes: If the fallback parameter indicates that all fallbacks are enabled, then the access path of the second page is determined to be the fallback path; If the rollback parameter indicates that full rollback is not enabled, the access path to the second page is determined based on the grayscale list.

[0012] Through the above implementation methods, this application can achieve precise control over the accessed version through the gray-scale list during the gray-scale release process, so that the system can uniformly access the old version when all rollbacks are performed, and can also flexibly allocate access paths according to the list when not all rollbacks are performed, thereby improving the flexibility and accuracy of gray-scale control.

[0013] In one possible embodiment, the grayscale configuration information further includes a rollback list, and the method includes: If the organization to which the object belongs is in the gray list, and the access path of the first page is not in the gray path, then the access path of the second page is determined to be the gray path.

[0014] If the organization to which the object belongs is not in the gray list, the access path to the second page is determined according to the fallback list.

[0015] Through the above implementation methods, this application can comprehensively determine the access path of the user's organization based on the gray list and the rollback list, making the page access strategies of different organizations clearer and more controllable, thereby ensuring the correctness of the page access logic and the stability of the system operation.

[0016] In one possible embodiment, the grayscale configuration information further includes version control parameters for each page, and the method includes: If the organization to which the object belongs is in the rollback list, the access path of the second page is determined based on the access path of the first page and the version control parameters of the second page.

[0017] Through the above implementation methods, this application introduces page-level version control parameters, enabling the front-end to determine the page version based on the parameters when navigating between pages, thereby achieving fine-grained version management, effectively avoiding the problem of inconsistent versions between pages, and ensuring the continuity of navigation logic.

[0018] In one possible embodiment, each version control parameter includes grayscale jump and rollback parameters and rollback jump grayscale parameters; the method includes: If the access path of the first page is the grayscale path, and the version control parameters of the second page are configured with grayscale jump back parameters, then the back path in the grayscale jump back parameters shall be used as the access path of the second page. If the access path of the first page is the back path, the access path of the second page is determined according to the grayscale jump back parameters and the back jump grayscale parameters of the second page.

[0019] Through the above implementation methods, this application enables flexible switching of access paths between pages based on the current access status by setting grayscale jump back parameters and back jump grayscale parameters, thereby achieving smooth jumps between different versions and improving the flexibility and controllability of the system.

[0020] In one possible embodiment, the method includes: If the version control parameters of the second page are configured with grayscale jump and rollback parameters, the rollback path in the grayscale jump and rollback parameters shall be used as the access path of the second page; If the grayscale jump and rollback parameters are not configured in the version control parameters of the second page, then the access path of the second page is determined to be the grayscale path based on the rollback and grayscale parameters of the second page.

[0021] Through the above implementation methods, this application can automatically switch the access path according to the grayscale parameters when no grayscale jump back parameters are configured, thereby achieving adaptive switching of the page access path and ensuring the correct execution of the jump logic.

[0022] In one possible embodiment, the grayscale configuration information is defined by the client in the grayscale configuration interface and then reported to the server; the method includes: The client obtains the corresponding grayscale configuration information from the server and loads the grayscale configuration information into the client's local cache, so that the front-end routing interface can directly read the grayscale configuration information in response to a jump request from the first page among the multiple pages to the second page among the multiple pages, thereby determining the access path of the second page without real-time interaction with the server.

[0023] Through the above implementation methods, this application enables the front-end route to directly determine the access path locally by caching grayscale configuration information on the client side, without needing to interact with the server in real time, thereby reducing network overhead and improving page redirection efficiency and response speed.

[0024] Secondly, this application provides a front-end canary deployment method, applied to a server, the method comprising: Receive a grayscale configuration information upload request from the client, and extract grayscale configuration information from the grayscale configuration information upload request; The grayscale configuration information is generated by the client through its provided grayscale configuration interface. This grayscale configuration information is used by the client to obtain the client's grayscale configuration information from the server after responding to an access request from an object. The client provides multiple pages. The grayscale configuration information indicates the access path corresponding to each of the multiple pages. In response to a redirection request triggered by the object, from the first page to the second page among the multiple pages, the front-end routing interface determines the access path of the second page based on the grayscale configuration information. The access path includes a fallback path and a grayscale path. The fallback path is a front-end resource access path preset by the server for the client before the client's grayscale release. The grayscale path is a front-end resource access path preset by the server for the client after the client's grayscale release. Based on the access path, the corresponding version of the front-end resource file is loaded, and the second page is rendered according to the front-end resource file. The grayscale configuration information is stored in the grayscale configuration database for subsequent access and updates by the client.

[0025] Through the above implementation methods, this application enables centralized management and persistent storage of canary deployment configuration information on the server side, allowing clients to dynamically determine page access paths based on the unified configuration information provided by the server during the canary deployment process. This solution not only ensures the consistency of canary deployment control logic but also reduces the complexity of client-server interaction, thereby improving the flexibility, maintainability, and overall system stability during the canary deployment process.

[0026] In one possible embodiment, the server further includes a grayscale parameter synchronization module for grayscale configuration management, and the method further includes: This is used to push the latest grayscale configuration information to the client when an update to the grayscale configuration information is detected, so that the grayscale configuration information of the client and the grayscale configuration information of the server remain consistent in real time.

[0027] Through the above implementation methods, this application realizes the real-time push of grayscale configuration information on the server side through the grayscale parameter synchronization module, so that the client can obtain the latest parameters immediately after the grayscale configuration is updated, ensuring the consistency and real-time performance of the grayscale logic on the front end and back end, thereby improving the coordination of the grayscale release process and the dynamic response capability of the system.

[0028] Thirdly, this application provides a front-end canary deployment device for use on a client side, the device comprising: The acquisition unit is used to obtain the grayscale configuration information of the client from the server in response to the access request of the client; the client provides multiple pages; the grayscale configuration information is used to indicate the access path corresponding to each of the multiple pages; A redirection unit is used to respond to a redirection request triggered by the object, requesting a redirection from a first page among the plurality of pages to a second page among the plurality of pages. The front-end routing interface determines the access path to the second page based on the grayscale configuration information. The access path includes a fallback path and a grayscale path. The fallback path is a front-end resource access path preset by the server for the client before the client's grayscale release. The grayscale path is a front-end resource access path preset by the server for the client after the client's grayscale release. The rendering unit is used to load the corresponding version of the front-end resource file based on the access path, and render the second page according to the front-end resource file.

[0029] In one possible embodiment, the grayscale configuration information includes grayscale enable parameters for indicating the grayscale release enable status and fallback parameters for indicating the grayscale path to switch to the fallback path, and the jump unit is used for: If the grayscale enable parameter indicates that grayscale publishing is not enabled, then the access path of the second page is determined to be the grayscale path; If the grayscale enable parameter indicates that grayscale release is enabled, the access path to the second page is determined according to the fallback parameter.

[0030] In one possible embodiment, the grayscale configuration information further includes a grayscale list, and the jump unit is used for: If the fallback parameter indicates that all fallbacks are enabled, then the access path of the second page is determined to be the fallback path; If the rollback parameter indicates that full rollback is not enabled, the access path to the second page is determined based on the grayscale list.

[0031] In one possible embodiment, the grayscale configuration information further includes a fallback list, and the jump unit is used for: If the organization to which the object belongs is in the gray list, and the access path of the first page is not in the gray path, then the access path of the second page is determined to be the gray path.

[0032] If the organization to which the object belongs is not in the gray list, the access path to the second page is determined according to the fallback list.

[0033] In one possible embodiment, the grayscale configuration information further includes version control parameters for each page, and the jump unit is used for: If the organization to which the object belongs is in the rollback list, the access path of the second page is determined based on the access path of the first page and the version control parameters of the second page.

[0034] In one possible embodiment, each version control parameter includes grayscale jump / rollback parameters and rollback / jump grayscale parameters; the jump unit is used for: If the access path of the first page is the grayscale path, and the version control parameters of the second page are configured with grayscale jump back parameters, then the back path in the grayscale jump back parameters shall be used as the access path of the second page. If the access path of the first page is the back path, the access path of the second page is determined according to the grayscale jump back parameters and the back jump grayscale parameters of the second page.

[0035] In one possible embodiment, the jump unit is used for: If the version control parameters of the second page are configured with grayscale jump and rollback parameters, the rollback path in the grayscale jump and rollback parameters shall be used as the access path of the second page; If the grayscale jump and rollback parameters are not configured in the version control parameters of the second page, then the access path of the second page is determined to be the grayscale path based on the rollback and grayscale parameters of the second page.

[0036] In one possible embodiment, the grayscale configuration information is defined by the client in the grayscale configuration interface and then reported to the server; the acquisition unit is used for: The client obtains the corresponding grayscale configuration information from the server and loads the grayscale configuration information into the client's local cache, so that the front-end routing interface can directly read the grayscale configuration information in response to a jump request from the first page among the multiple pages to the second page among the multiple pages, thereby determining the access path of the second page without real-time interaction with the server.

[0037] Fourthly, this application provides a front-end canary deployment device applied to a server, the device comprising: The receiving unit is configured to receive a grayscale configuration information upload request from the client and extract grayscale configuration information from the grayscale configuration information upload request; wherein the grayscale configuration information is generated by the client after setting it through the grayscale configuration interface provided by the client; The storage unit is used to store the grayscale configuration information into the grayscale configuration database for subsequent access and updates by the client.

[0038] In one possible embodiment, the server further includes a grayscale parameter synchronization module for grayscale configuration management, and the apparatus further includes: The synchronization unit is used to push the latest grayscale configuration information to the client when the grayscale configuration information is detected to be updated, so as to keep the grayscale configuration information of the client consistent in real time.

[0039] Fifthly, this application provides an electronic device, comprising: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method described in any one of the first aspects according to the obtained program instructions.

[0040] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a computer, cause the computer to perform the method described in any one of the first aspects.

[0041] In a seventh aspect, this application provides a computer program product comprising: computer program code, which, when executed on a computer, causes the computer to perform the method described in any one of the first aspects. Attached Figure Description

[0042] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this application; Figure 2 A flowchart illustrating the implementation of a front-end canary deployment method provided in this application embodiment; Figure 3A This is a schematic diagram of a grayscale configuration information configuration interface provided in an embodiment of this application; Figure 3B This is a schematic diagram of a front-end grayscale release provided in an embodiment of this application; Figure 4A A schematic flowchart illustrating a front-end canary deployment method provided in an embodiment of this application; Figure 4B A schematic flowchart illustrating another front-end canary deployment method provided in this application embodiment; Figure 5 A flowchart illustrating another front-end canary release method provided in this application embodiment; Figure 6A A structural diagram of a front-end grayscale publishing device provided in an embodiment of this application; Figure 6B A structural diagram of another front-end grayscale publishing device provided in the embodiments of this application; Figure 7 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments 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. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0044] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0045] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0046] The acquisition, transmission, storage, and use of data in this application all comply with relevant national laws and regulations.

[0047] Before introducing the methods provided in the embodiments of this application, for ease of understanding, the technical background of the embodiments of this application will be described in detail below.

[0048] In the current mainstream front-end and back-end separation development model, front-end projects are mostly developed based on frameworks such as Vue. Vue projects are typically compiled using build tools such as Webpack or Vite during the packaging and deployment process. For information security and code confidentiality needs, front-end code is often compressed and obfuscated before deployment. While such processing can improve system security, it also makes it difficult to directly modify the front-end code or quickly replace some modules after packaging.

[0049] During system operation, if an emergency occurs in the online version or some business functions need to be rolled back to the old version, the existing solution can usually only roll back the entire front-end version package as a whole, and cannot roll back a single page or a specific module locally. This results in low rollback efficiency, a large scope of business impact, and increased operation and maintenance risks and recovery costs.

[0050] Existing technologies suffer from insufficient flexibility in canary deployment control, lack of partial canary deployment and rollback capabilities, and over-reliance on server-side rule forwarding. Configuring canary deployment rules and whitelist rules via Nginx cannot be updated in real time, rule activation is delayed, and it requires backend maintenance. Furthermore, existing solutions cannot perform canary deployments or version rollbacks on specific pages or modules; only overall version switching is possible. Moreover, canary deployment control logic is largely implemented through Nginx or server-side rule matching, leaving clients unable to manage canary deployment strategies independently, resulting in poor flexibility and real-time performance.

[0051] Therefore, how to implement flexible page-level grayscale control and rollback mechanisms on the client side has become an urgent problem to be solved in the current technology field.

[0052] In view of this, this application proposes a front-end canary release method. The beneficial effect of this application is that the control logic of canary release is implemented on the front end, and version judgment and page switching are completed independently by the client, without relying on the server or middleware for traffic distribution, thereby improving response speed and flexibility.

[0053] First, when the client receives an access request, it retrieves the canary deployment configuration information from the server once and loads it locally. The frontend can then directly execute canary deployment control based on this configuration information during subsequent operation, without needing to interact with the server again, thereby reducing network latency and improving the real-time effectiveness of the rules.

[0054] Secondly, when a user accesses a page or navigates to another page within the client, the front-end routing interface directly determines the version path to be loaded based on the local grayscale configuration information, and automatically selects between the grayscale path and the fallback path, thus enabling front-end autonomous control of the version switching logic.

[0055] Finally, the frontend loads the corresponding version of the frontend resource files based on the determined access path and performs rendering, achieving a unified approach to page display and version control on the frontend. This solution makes the canary release and rollback process entirely frontend-driven, without relying on server configuration updates, thus significantly improving the flexibility of canary releases and the stability of the system.

[0056] The preferred embodiments of this application will be described in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0057] like Figure 1 The diagram shown is an application scenario illustration of an embodiment of this application. The application scenario diagram includes a terminal device 110 and a server 120.

[0058] In this embodiment, the terminal device 110 includes, but is not limited to, mobile phones, tablets, laptops, desktop computers, e-book readers, smart voice interaction devices, smart home appliances, and in-vehicle terminals. The terminal device may have a client application related to front-end canary release installed. This client can be software (such as a browser, web application, front-end management system, etc.), or it can be a webpage, mini-program, etc. The server 120 is the back-end server corresponding to the client, or a server specifically used for canary configuration information management, parameter distribution, and version resource storage; this application does not specifically limit this.

[0059] Server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0060] It should be noted that the front-end canary release method in each embodiment of this application can be executed by an electronic device, which can be a terminal device 110 or a server 120. That is, the method can be executed by the terminal device 110 or the server 120 alone, or by both the terminal device 110 and the server 120. For example, when executed by the terminal device 110, the client can respond to an access request from an object (e.g., a user), obtain canary configuration information from the server 120, and complete version path determination and page rendering on the front end.

[0061] In one alternative implementation, the terminal device 110 and the server 120 can communicate via a communication network.

[0062] Furthermore, the embodiments of this application can be applied to a variety of scenarios, including not only the front-end canary release of Web systems, but also cloud application canary updates, mobile application canary control, and front-end interface updates of smart devices.

[0063] The following describes the front-end canary release method provided by the exemplary embodiments of this application in conjunction with the application scenarios described above and with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way in this respect.

[0064] See Figure 2 The diagram shown is an implementation flowchart of a front-end canary release method provided in this application embodiment, applied to the client. The specific implementation flow of this method is as follows: steps S21~S23: S21: In response to the client's access request, obtain the client's grayscale configuration information from the server.

[0065] The client provides multiple pages; the grayscale configuration information is used to indicate the access path corresponding to each of the multiple pages, so as to realize page-level grayscale control and version switching.

[0066] See Figure 3A As shown, it is a schematic diagram of a grayscale configuration information configuration interface provided in an embodiment of this application.

[0067] exist Figure 3AThe interface displays grayscale configuration settings, including overall grayscale configuration information and page grayscale configuration information. The overall grayscale configuration information section lists multiple grayscale configuration items, such as Overall Grayscale Configuration Information 1, Overall Grayscale Configuration Information 2, Overall Grayscale Configuration Information 3, etc. Each configuration item has a "Yes" or "No" option to enable or disable the corresponding grayscale function. The page grayscale configuration information section is used to set grayscale configuration items for different pages, such as Page Grayscale Configuration Information 1, Page Grayscale Configuration Information 2, etc., also with "Yes" or "No" buttons for selection. Confirm and save buttons are located at the bottom of the interface for submitting or saving the current grayscale configuration information.

[0068] During subsequent operation, when the client loads a page or performs a page redirect, it can obtain the corresponding grayscale configuration information from the server and cache it locally. This allows the frontend to directly perform version judgment and page rendering based on the cached grayscale rules without having to frequently interact with the server.

[0069] S22: In response to a redirection request triggered by an object, from the first page of multiple pages to the second page of multiple pages, the front-end routing interface determines the access path of the second page based on the canary configuration information.

[0070] The access paths include: rollback paths and grayscale paths; the rollback path is a pre-set path for front-end resources on the server before the grayscale release on the client; the grayscale path is a pre-set path for front-end resources on the server after the grayscale release on the client.

[0071] In one alternative implementation, to achieve the aforementioned path differentiation, multiple versions can be deployed on the server side using Nginx. Specifically, two sets of front-end code are pre-deployed in Nginx, using paths to distinguish page resources for different versions. When a new version is deployed, the entire code package of the old version is backed up to the designated backUp directory; and in the old version's entry file index.html, the referenced static resource paths are uniformly prefixed with "backUp," thus forming an access channel completely isolated from the resource paths of the new version.

[0072] With this path differentiation mechanism, when the front-end route performs page navigation, it only needs to select to access the "grayscale path" (new version) or the "fallback path" (old version) according to the grayscale configuration information to achieve dynamic loading and independent rendering of front-end pages of different versions, without having to modify the original business logic or packaging script.

[0073] See Figure 3BAs shown, this is a schematic diagram of a front-end canary deployment provided in an embodiment of this application. The process mainly includes three stages: configuring canary configuration information, obtaining canary configuration information, and determining the access path and loading the corresponding functional modules based on the canary configuration information.

[0074] In one optional implementation, when an object access client issues an access request (e.g., by clicking an access link or initiating a page request), grayscale configuration information is first set in the grayscale configuration interface and reported to the server. After the server receives and stores the information, the client can retrieve the corresponding grayscale configuration information from the server in subsequent accesses based on the object's identity, organization information, or other characteristics. The front-end routing interface determines whether the access path is a grayscale path or a fallback path based on the obtained grayscale configuration information. If it is a grayscale path, the new version (version A) of the feature page is loaded; if it is a fallback path, the old version (version B) of the feature page is accessed. Through this mechanism, grayscale control and rapid rollback between different versions can be flexibly implemented within the same business framework, thereby improving the flexibility and controllability of the grayscale release process while ensuring stability.

[0075] Considering that traditional solutions often rely on servers or Nginx for unified traffic control during front-end canary releases, they cannot achieve fine-grained canary releases and partial rollbacks at the page level. Furthermore, when problems occur in the canary version, only a complete rollback is usually possible, lacking flexibility and real-time capability. Therefore, this application proposes a front-end canary release scheme based on canary release enable and rollback parameter control.

[0076] Optionally, the canary configuration information includes canary enable parameters to indicate the canary release enabled status and fallback parameters to indicate the canary path switching to the fallback path.

[0077] If the grayscale enable parameter indicates that grayscale release is not enabled, the access path of the second page is determined to be the grayscale path; if the grayscale enable parameter indicates that grayscale release is enabled, the access path of the second page is determined according to the fallback parameter.

[0078] In one optional implementation, by introducing grayscale enable and rollback parameters into the grayscale configuration information, the client can select the page-level path locally based on the grayscale status and rollback instructions. When the grayscale enable parameter indicates that grayscale release is not enabled, all pages uniformly access the grayscale path (i.e., the new version resource); when the grayscale enable parameter indicates that grayscale release is enabled, the front-end routing interface determines whether the current second page needs to perform a rollback based on the rollback parameter. If so, it accesses the rollback path (old version resource); otherwise, it accesses the grayscale path (new version resource).

[0079] Through the above implementation method, the canary release control logic can be completed entirely on the front end, without relying on server-level forwarding and configuration modifications, achieving rapid response and path switching in canary release states. Simultaneously, this solution supports page-level granular canary release management and partial rollback, effectively reducing the risk of new version deployment and improving the flexibility, stability, and user experience of front-end canary releases.

[0080] Considering that during front-end canary deployments, when the system (i.e., the client) detects a serious anomaly or requires an emergency rollback, it is usually necessary to use the old version on all pages of the client to ensure business continuity and access stability. Therefore, this application proposes a front-end canary deployment scheme that supports both full rollback and canary rollback by a select group.

[0081] Optionally, the grayscale configuration information also includes a grayscale list. If the fallback parameter indicates that all fallbacks are enabled, the access path of the second page is determined as the fallback path; if the fallback parameter indicates that all fallbacks are not enabled, the access path of the second page is determined according to the grayscale list.

[0082] In one alternative implementation, when the fallback parameter indicates that full fallback is enabled, the front-end routing interface will determine the access path of all pages provided by the client for all objects as the fallback path, that is, uniformly access the old version resources before the canary release, and realize full page fallback for all objects.

[0083] Considering that in a full rollback scenario, the system typically switches all objects to the old version to ensure stability, but in actual business operations, some users or organizations may still need to continue testing canary features or verifying new features. Therefore, this application proposes a front-end canary release scheme that allows for canary verification even in a "full rollback" state.

[0084] In one optional implementation, when the fallback parameter indicates that full fallback is enabled, the front-end routing interface will determine all page access paths provided by the client for all objects as fallback paths, that is, uniformly accessing the old version resources before the canary release, realizing full page fallback; at the same time, the canary configuration information can still include a canary list to identify objects that still need to access the canary version in the full fallback state. For objects that belong to the canary list, the system will maintain access to the canary path according to their canary list configuration when they access pages (including the first page and the second page).

[0085] Once defined, if the first page is a grayscale path, when the user navigates from the first page to the second page, the front-end routing interface continues to maintain the grayscale path access logic based on the navigation parameters between pages. This avoids conflicts between the fallback path and the grayscale path, thereby ensuring that grayscale test users can still stably access the new version page in a fully rolled-back system environment.

[0086] Through this implementation method, this application takes into account the gray-scale verification requirements in the security mechanism of full rollback, realizes the flexibility of version switching and the fine-grained management of gray-scale control, which not only ensures system stability, but also supports the continuous testing and gradual launch of new functions.

[0087] Optionally, if the fallback parameter indicates that all fallbacks are enabled, the access path to the second page is determined based on the grayscale list.

[0088] If the organization to which the object belongs is in the gray list, and the access path on the first page is not a gray path, then the access path on the second page is determined to be a gray path.

[0089] If the organization to which the object belongs is not in the gray list, analyze whether a fallback list exists. If no fallback list exists, then if the access path of the first page is not a gray path, determine that the access path of the second page is a gray path. If there is no rollback list, analyze whether the object is in the rollback list. If the organization to which the object belongs is in the rollback list, and the access path on the first page is a grayscale path, determine that the access path on the second page is the rollback path; if the organization to which the object belongs is not in the rollback list, and the access path on the first page is not a rollback path, determine that the access path on the second page is a grayscale path.

[0090] In one optional implementation, when the fallback parameter indicates that all fallbacks are enabled, the system defaults to using the fallback path for all objects' page access paths. This means that all users accessing the front-end page will point to the old version of the resource, ensuring overall system stability in the event of version issues or anomalies. However, to accommodate the needs of specific organizations or users who still require testing of the gray-scale version, the system can further refine its judgment based on the gray-scale list and the fallback list. Only if the organization to which the object belongs is included in the fallback list will its access path remain on the old version; otherwise, access to the gray-scale version page will continue.

[0091] If the organization to which the object belongs is on the gray-scale list, and the access path of the first page is not currently a gray-scale path, the front-end routing interface will switch the access path of the second page to a gray-scale path. This ensures that gray-scale users can still access the new version page in a full rollback state, meeting the needs of functional verification or pre-release testing. If the organization to which the object belongs is not on the gray-scale list, the system will continue to analyze whether a rollback list is configured. If the system does not configure a rollback list, and the access path of the first page is not a gray-scale path, then the access path of the second page will be determined to be a gray-scale path. This is to ensure that the system maintains consistent access logic when there is no explicit rollback target configuration, preventing user experience interruptions caused by page loops or access anomalies.

[0092] When a rollback list exists in the system, if the organization to which the object belongs is included in the rollback list, and the access path of the first page is currently in the gray-scale testing phase, then the access path of the second page is switched to the rollback path, allowing the organization to access the old version page and preventing objects that did not participate in the gray-scale testing from mistakenly using the new version's features. If the organization to which the object belongs is not on the rollback list, and the access path of the first page is not in the rollback path, then the access path of the second page is determined to be the gray-scale testing path, ensuring that normal users continue to access the new version, improving version verification coverage, and maintaining the consistency of page redirection logic.

[0093] For example, consider an internal service system of a company. This system is a front-end application released in a canary release phase and contains multiple pages, such as "Homepage," "Task Center," and "Data Analysis Page." During a system optimization update, to prevent unknown errors in the new version from affecting business operations, the administrator enabled the "Roll Back All" option through the canary release configuration interface, causing all employees to access the old version pages by default. However, because the R&D and testing departments still need to verify new features, the administrator added these two departments to the canary release list, ensuring their access path remained the canary path. Simultaneously, for security reasons, the finance and audit departments were added to the rollback list, ensuring they always access the old version interface to avoid using new features that have not been fully verified.

[0094] Through the above mechanism, this application realizes a layered gray-scale strategy in the "full rollback" state: on the one hand, it ensures that ordinary users can immediately switch to the stable version, and on the other hand, it allows specific departments to continue to access the new version for testing, thereby taking into account both system stability and the verification needs of the new version, and improving the flexibility and reliability of front-end gray-scale release.

[0095] The above embodiments describe the scenario where the rollback parameter indicates that all rollbacks are enabled. That is, the system defaults to allowing all organizations to access the old version path, but still allows specific organizations in the gray list to access the new version to meet testing or verification needs.

[0096] When the rollback parameter indicates that full rollback is not enabled, the client makes a judgment based on the graylist.

[0097] In one alternative implementation, considering that during partial rollback (i.e., partial rollback is not enabled), in addition to the gray-scale list, it may also be necessary to enforce rollback control on some institutions, this application further introduces a rollback list in the gray-scale configuration information.

[0098] Optionally, the grayscale configuration information also includes a fallback list. The access path for the second page is determined based on this list. If the organization to which the object belongs is in the grayscale list, and the access path for the first page is not a grayscale path, then the access path for the second page is determined to be a grayscale path. If the organization to which the object belongs is not in the grayscale list, the access path for the second page is determined based on the fallback list.

[0099] When a user accesses a client-side page, the front-end routing interface first determines whether the user's organization is included in the gray-scale list. If the user is in the gray-scale list, and the current access path to the first page is not a gray-scale path, the front-end routing interface will switch the user's access path to a gray-scale path, enabling them to access the new version of the page. If the user is not in the gray-scale list, the system will further determine the appropriate path based on the fallback list to avoid potential compatibility or security issues.

[0100] Through the above implementation methods, this application realizes a dual judgment mechanism based on the gray-scale list and the rollback list, enabling the client to flexibly switch between gray-scale release and rollback control. This not only ensures the stable operation of key institutions but also allows some institutions to experience new features in advance, thereby further improving the security and controllability of the gray-scale release process.

[0101] In one alternative implementation, considering that there may be dependencies between different pages, relying solely on organizational-level judgments during page navigation can easily lead to path confusion. Therefore, this application introduces page-level version control parameters in the grayscale configuration information.

[0102] Optionally, the grayscale configuration information also includes version control parameters for each page. If the organization to which the object belongs is in the rollback list, the access path of the second page is determined based on the access path of the first page and the version control parameters of the second page.

[0103] In one optional implementation, when the organization to which the object belongs is included in the fallback list, the front-end routing interface will determine the path by combining the currently accessed first page path with the version control parameters of the target second page. For example, if the access path of the first page is a gray-scale path, and the version control parameters of the second page indicate that the page needs to perform a version fallback, then the access path of the second page is determined to be the fallback path; if the version control parameters of the second page do not indicate a fallback, then the access gray-scale path remains unchanged. In this way, the logical consistency of the page versions before and after the page jump can be ensured, avoiding functional abnormalities caused by cross-version resource loading.

[0104] Through the above implementation methods, this application can achieve fine-grained version control at the page level at the client level, making the switching logic of canary release and partial rollback more flexible and controllable, thereby effectively improving the stability and user experience of the system in multi-page scenarios.

[0105] Considering that page navigation during canary releases may involve loading resources from different versions, the lack of an effective path identification mechanism can easily lead to cross-version access errors or functional abnormalities. This application proposes a front-end page navigation path determination scheme based on version control parameters. This scheme achieves bidirectional path mapping between different version pages by configuring canary navigation fallback parameters and fallback-to-canary navigation parameters for each page on the client side, thereby ensuring the correctness and consistency of page navigation logic in complex canary release scenarios.

[0106] Optionally, each version control parameter includes grayscale jump and fallback parameters and fallback jump grayscale parameters. If the access path of the first page is a grayscale path and the version control parameters of the second page are configured with grayscale jump and fallback parameters, then the fallback path in the grayscale jump and fallback parameters will be used as the access path of the second page. If the access path of the first page is a fallback path, the access path of the second page will be determined according to the grayscale jump and fallback parameters and fallback jump grayscale parameters of the second page.

[0107] In one alternative implementation, when a user navigates from the first page to the second page, the front-end routing interface makes a judgment based on the current access path of the first page and the version control parameters of the second page.

[0108] If the current page's access path is a grayscale path, and the second page's version control parameters are configured with a grayscale jump back parameter urlInfo, then during the route interception phase, the path switching is performed through urlInfo, and the specified fallback path is used as the access path of the second page, achieving a smooth jump from the grayscale version page to the fallback version page.

[0109] If the current page's access path is a fallback path, the routing interception will determine whether to switch between different version paths based on the fallback parameters urlInfo and toNewUrlInfo of the second page, thereby ensuring the correctness and consistency of the page access logic.

[0110] Through the above implementation methods, this application utilizes front-end routing parameterization control to achieve flexible switching and automatic recognition between grayscale and rollback versions, effectively improving page switching efficiency and system stability in grayscale release scenarios.

[0111] Optionally, if the version control parameters of the second page include a grayscale jump and rollback parameter, the rollback path in the grayscale jump and rollback parameter will be used as the access path of the second page; if the version control parameters of the second page do not include a grayscale jump and rollback parameter, the access path of the second page will be determined as the grayscale path based on the grayscale rollback parameter of the second page.

[0112] In one optional implementation, when the access path of the first page is a fallback path, the front-end routing interface reads the version control parameters of the second page and makes a judgment based on the gray-scale jump fallback parameter urlInfo and the fallback jump gray-scale parameter toNewUrlInfo. For example, when the second page is configured with urlInfo, the system will prioritize using the fallback path when navigating between pages; while when urlInfo is not configured but toNewUrlInfo is configured, the system will automatically switch to the gray-scale path to ensure that the page navigation logic conforms to the expected gray-scale strategy.

[0113] Through the above implementation methods, this application implements path switching logic based on parameterized judgment between pages on the front end, making the jump control between grayscale versions and rollback versions more refined and automated, and further improving the stability and compatibility of the system in multi-version parallel scenarios.

[0114] Considering that in the actual gray-scale release process, the system may have multiple historical versions or gray-scale versions at the same time, a single path differentiation method cannot meet the needs of multiple version switching in complex scenarios. This application proposes a gray-scale control scheme that supports multiple version specification.

[0115] Optionally, the grayscale configuration information also includes a version identifier parameter, which determines the access path to the second page, including: If the version identifier parameter indicates the target version number, then the corresponding front-end resource access path is selected from the multiple version paths preset on the server according to the version number, and used as the access path for the second page.

[0116] In one optional implementation, when the system has multiple grayscale versions or historical versions, the server can preset corresponding front-end resource access paths for different versions, such as / release / v1.0, / release / v2.0, / gray / v2.1, etc. After receiving the grayscale configuration information from the server, the front-end will read the version identifier parameter containing the version number.

[0117] When navigating between pages, the front-end routing interface selects the corresponding resource path from a pre-defined pool of multiple version paths based on the target version number indicated by the version identifier parameter and loads the relevant front-end resource files. For example, when the version identifier parameter indicates that the target version is v2.1, the front-end will access the grayscale path / gray / v2.1 and load the component resources corresponding to that version; if the indicated version is v1.0, it will access the older version path / release / v1.0, thus enabling seamless switching between different versions.

[0118] Through the above implementation methods, this application can realize the coexistence and flexible selection of multiple versions on the client side, and support precise access control of any historical version, current version and gray-scale version, effectively improving the flexibility and stability of the system in the gray-scale release stage.

[0119] Through the above implementation methods, this application achieves precise access control in scenarios where multiple versions coexist by introducing version identifier parameters, enabling canary releases to flexibly specify any historical version or a specific canary version for access, thereby further improving the system's compatibility and the flexibility of the release strategy.

[0120] It should be noted that the above implementation method achieves page-level version switching. Specifically, when a functional control in the client (such as a button, menu item, or jump link) triggers a jump behavior, it calls the front-end routing interface to determine the access path to the next page. This access path is determined based on gray-scale configuration information and can be flexibly switched between old and new versions.

[0121] For example, if a control on the first page points to the second page, and the first page is a grayscale version while the second page is configured as a fallback version, the system will automatically switch the jump path to the fallback path according to the grayscale configuration parameters, thus achieving a "new → old" page transition. Similarly, if the second page then points to a third page, and the third page is configured as a grayscale path, a "old → new" version switch can be achieved.

[0122] Through the above mechanism, this application can realize cross-page and cross-version continuous jump logic on the front end, so that multiple access paths such as "new-old-new" or "old-new-old" can be flexibly combined between pages, thereby achieving more refined gray-scale release control and flexible page interaction experience.

[0123] Additionally, it's important to consider that "new" and "old" here are relative version concepts used to represent different version states of the front-end page during a canary release: The "new" version refers to the latest front-end resource path loaded by the client after the canary release (i.e., the canary path), typically containing new features, interfaces, or optimizations currently being tested or trialed; the "old" version refers to the historical front-end resource path before the canary release (i.e., the rollback path), preserving existing stable functions and page logic for compatibility or quick rollback in case of issues. Therefore, "new→old→new" means the user first accesses the canary version page, then switches to the old version page during certain page or control operations, and then jumps back to the new version page; "old→new→old" means the user initially accesses the old version page, some functions or paths are configured to jump to the new version page, and then return to the old version page. This flexible combination of jump methods allows the system to freely switch between new and old versions during the canary release process, achieving the effect of gradual deployment and safe rollback.

[0124] It should be noted that, in this embodiment of the application, the grayscale enable parameters, rollback parameters, grayscale list, and rollback list belong to the overall grayscale configuration information, which are used to control the overall grayscale release enable status of the client and the global version switching logic; while the page version control parameters and page jump parameters (including grayscale jump rollback parameters and rollback jump grayscale parameters) belong to the page grayscale configuration information, which are used to realize page-level version judgment and jump control.

[0125] Considering that the above implementation methods are mainly aimed at page-level version switching, this application further proposes a scheme that supports gray-scale rollback at the functional control level in order to achieve more refined functional management.

[0126] Optionally, in response to the user's operation event triggering the target functional control on the first page, the fallback parameters of the functional control are read by the front-end routing interface; If the fallback parameter of a function control indicates that the function control needs to perform a fallback operation, then the old version of the resource file associated with the function control is loaded; If the fallback parameter of the function control does not indicate a fallback operation, then a new version of the resource file associated with the function control is loaded.

[0127] In one alternative implementation, when a new feature control malfunctions or requires verification of old logic during a canary release, the system can quickly switch to the old version using the control's fallback parameter. For example, on a new report page, if a user clicks the "Export" button and the control is configured to require a fallback, the front-end will directly load the old version's export logic module without affecting the rendering of the entire page.

[0128] Through the above implementation methods, this application can realize differentiated grayscale control and independent rollback at the control level, thereby significantly improving the flexibility and security of the system in the grayscale release process, reducing the risks brought by large-scale rollback, and improving the controllability and testing efficiency of function iteration.

[0129] By using the local caching mechanism in the grayscale configuration information mentioned above, the grayscale control logic can be front-end processed on the client side, avoiding reliance on server requests for each page jump, thereby improving the real-time performance of page jumps and the overall system performance.

[0130] In view of the need to further reduce the latency and stability risks caused by front-end and back-end communication during actual canary releases, this application proposes a scheme for local caching of canary configuration information on the client side.

[0131] Optionally, the canary configuration information is defined by the client in the canary configuration interface and then reported to the server; The client obtains the corresponding grayscale configuration information from the server and loads it into the client's local cache. This allows the front-end routing interface to directly read the grayscale configuration information when responding to a redirection request from the first page of multiple pages to the second page of multiple pages, thereby determining the access path of the second page without real-time interaction with the server.

[0132] In one optional implementation, when the canary configuration information changes, the server will actively push an update instruction to the client. After receiving the update notification, the client will automatically refresh the local cached data to ensure the timeliness and consistency of the canary configuration.

[0133] Optionally, after the canary configuration information is loaded into the local cache, the client can also update the canary configuration information in real time during operation to avoid the need to restart the client for it to take effect.

[0134] In one optional implementation, when the server detects an update to the gray-scale rule or rollback rule, the client receives an update notification to accept the update. After receiving the notification, the client automatically retrieves the gray-scale configuration information again and refreshes the cache, so that the updated configuration information takes effect immediately.

[0135] Through the above implementation methods, this application can realize a dynamic update mechanism for grayscale configuration information on the client side, avoiding the drawbacks of traditional methods that require repackaging or restarting the client to take effect, thereby significantly improving the real-time performance of grayscale rule adjustments and the system's operational efficiency.

[0136] Furthermore, the canary deployment configuration information is generated by the client through its provided canary deployment configuration interface. This interface allows developers or operations personnel to intuitively define canary deployment parameters, rollback parameters, list rules, and page version correspondences, and can be directly submitted to the server for unified storage and distribution. Through the above implementation method, this application can achieve flexible configuration and rapid activation of canary deployment strategies in a visual and low-intrusion manner, further reducing maintenance costs and improving the controllability and convenience of front-end canary deployment.

[0137] S23: Load the corresponding version of the front-end resource file based on the access path, and render the second page according to the front-end resource file.

[0138] In one optional implementation, after the front-end routing interface determines the access path to the second page, the client loads the corresponding version of the front-end resource files based on that path, such as JavaScript scripts, CSS style files, and page template files. If the access path is a grayscale path, the grayscale version of the resource package is loaded from the server or local cache; if the access path is a fallback path, the historical version of the resource package is loaded. After loading is complete, the client dynamically renders the second page through the rendering module to ensure that the page content is consistent with the selected version.

[0139] For example, when a user accesses the new version of the report page during the gray-scale testing phase, the front end determines that the access path of the page is a gray-scale path based on the gray-scale configuration information, and then loads the new version of the report components and interaction logic for rendering; if the gray-scale rules instruct the user to revert to the old version, the front end will load the old version of the report template and script, thereby achieving parallel presentation of the new and old versions in the same system.

[0140] Through the above implementation methods, this application can achieve automatic selection and dynamic rendering of version resources at the client level without reloading the entire application or relying on server redirection, thereby effectively improving the speed of page switching and user experience, and ensuring the flexibility and stability of the gray release and partial rollback process.

[0141] See Figure 4A As shown, it is a schematic flowchart of a front-end grayscale release method provided in an embodiment of this application.

[0142] S41: Is there grayscale configuration information?

[0143] If yes, proceed to step S42; otherwise, proceed to step S43.

[0144] In this embodiment, step S41 is used to determine whether the system has issued gray-scale release configuration information. If no gray-scale rules have been issued, the client cannot distinguish between the old and new version states. In this case, all pages will default to accessing the gray-scale path, i.e., version A, to ensure that users access the latest stable version.

[0145] S42: Should we enable canary release?

[0146] If yes, proceed to step S45; otherwise, proceed to step S43.

[0147] In this embodiment, step S42 is used to determine whether the grayscale function is enabled. When grayscale is not enabled, the system assumes that all grayscale versions (Version A) are used, maintaining a unified and up-to-date front-end resource access logic; when grayscale is enabled, the grayscale / rollback determination process will then be entered.

[0148] S43: Is the first page in a grayscale path?

[0149] Otherwise, proceed to step S44.

[0150] The grayscale path here refers to version A. The system determines whether the current page is already in the new version path. If not, it means that the current access is still to the old version (version B), and it needs to be adjusted to the new version path to ensure access consistency.

[0151] S44: Determine that the access path for the second page is a grayscale path.

[0152] "This means redirecting to version A". When the system detects that the first page is not in the grayscale path (i.e., it is still the old version), it uses the front-end routing to uniformly point the redirected page to the grayscale path, thereby switching to version A resources and achieving unified version loading on the front end.

[0153] S45: Enable full rollback?

[0154] If so, proceed to step S46.

[0155] This setting determines whether all accesses are to version B, and is used to decide whether the system has triggered a full rollback. When a full rollback is enabled, it indicates an urgent business issue or a need for a complete rollback test. By default, the system switches all pages to the old version path (version B) for access.

[0156] S46: Is the organization to which the current object belongs on the gray list?

[0157] If yes, proceed to step S47; otherwise, proceed to step S49.

[0158] If the system is in full rollback mode, but a specific organization still needs to test new features, exception control can be implemented through a gray-scale list. If the current organization is included in the gray-scale list, it is allowed to continue accessing the gray-scale path (Version A); if it is not on the list, the subsequent rollback list judgment logic will be entered.

[0159] S47: Is the first page in a grayscale path?

[0160] Otherwise, proceed to step S48.

[0161] S48: Determine that the access path for the second page is a grayscale path.

[0162] S49: Is a rollback list configured in the system?

[0163] If yes, proceed to step S412; otherwise, proceed to step S410.

[0164] Specifically, it checks whether the system has configured data for organizations that can be redirected to version B, and uses this data to determine if a list of organizations requiring forced rollback has been set up in the system. If it exists, it further checks whether the object matches the list; if it does not exist, it continues to execute the default gray-scale logic.

[0165] S410: Is the first page in a grayscale path?

[0166] Otherwise, proceed to step S411.

[0167] S411: Determine that the access path for the second page is a grayscale path.

[0168] S412: Is the organization to which the current object belongs on the rollback list?

[0169] This determines whether the current organization is accessing data from version B. If the organization is one that needs to be rolled back, the rollback decision process begins; otherwise, the gray-scale access logic continues.

[0170] If yes, execute S413; otherwise, execute S415.

[0171] S413: Is the first page in a grayscale path?

[0172] If so, then execute S414.

[0173] S414: Determine that the access path to the second page is the fallback path.

[0174] S415: Is the first page on the back path?

[0175] If so, then execute S416.

[0176] S416: Determine that the access path for the second page is a grayscale path.

[0177] It should be noted here that the steps S41 to S416 described above illustrate the processing procedure of the full rollback logic in the embodiments of this application.

[0178] In this embodiment of the application, when the system detects that the rollback parameter in the grayscale configuration information indicates "Enable all rollback", all pages will access the old version path (i.e., the B version path) by default. In this way, when a major problem or business rollback requirement occurs, the entire client can be quickly switched to the stable version to ensure system availability and data security.

[0179] Building upon this, the embodiments of this application also consider scenarios where special organizations or objects still need to participate in gray-scale testing. When a gray-scale list exists, organizations on the gray-scale list can continue to access the gray-scale path (version A) under full rollback status to test or verify the compatibility and stability of new features. If a rollback list is further configured in the system, a precise matching judgment is made based on this list: organizations on the list are forced to use version B resources, while other organizations continue to maintain gray-scale access paths. Through this layered logic, the system can flexibly support exceptional gray-scale access and differentiated control while achieving "full rollback," thereby balancing system security and version verification requirements.

[0180] See Figure 4B As shown, it is a schematic flowchart of another front-end grayscale release method provided in the embodiment of this application.

[0181] S41: Is there grayscale configuration information?

[0182] If yes, proceed to step S42; otherwise, proceed to step S43.

[0183] S42: Should we enable canary release?

[0184] S43: Is the first page in a grayscale path?

[0185] Otherwise, proceed to step S44.

[0186] S44: Determine that the access path for the second page is a grayscale path.

[0187] S45: Enable full rollback?

[0188] Otherwise, proceed to step S417.

[0189] It should be noted here that steps S41 to S45 are related to... Figure 4A The aforementioned processes maintain a consistent overall logic, both used to determine whether the system has canary deployment configuration information and whether the canary deployment function is enabled. The main difference is that when canary deployment is enabled but the "all rollback" mode is not activated, the process enters the S417 branch, instead of the aforementioned branch. Figure 4A The S46 branch in [the text].

[0190] S417 and S46 belong to different logical branches, corresponding to two scenarios: partial grayscale control and full rollback control, respectively. The former focuses on precise judgment using the organization list and page parameters when grayscale and rollback versions coexist, achieving fine-grained path selection for different objects or pages; while the latter directly switches all access to the old version path to ensure overall system stability. Therefore, this application's embodiment introduces branch S417 to illustrate how, without enabling full rollback, the system uses the grayscale list, rollback list, and page redirection parameters to achieve page-level grayscale and rollback coexistence control logic, thereby improving the flexibility of the grayscale release strategy and the accuracy of front-end routing control.

[0191] S417: Is the organization to which the current object belongs on the gray list?

[0192] If yes, proceed to step S43; otherwise, proceed to step S418.

[0193] S418: Is a rollback list configured in the system?

[0194] If yes, execute S419; otherwise, execute S420.

[0195] S419: Is the organization to which the current object belongs on the rollback list?

[0196] If so, then execute S420.

[0197] S420: Determine if the first page is in the grayscale path?

[0198] Otherwise, execute S421; otherwise, execute S426.

[0199] S421: Analyze whether the grayscale jump and fallback parameters are configured on the second page?

[0200] If yes, execute S422; otherwise, execute S423.

[0201] This involves retrieving whether the current path needs to be redirected to version B from the system. The purpose of this step is to determine whether the front-end page has configured the grayscale jump back parameter (i.e., urlInfo). By reading this parameter, the system can determine whether the current grayscale version page needs to enter the back version path when jumping. This is used to identify the jump logic from version A (grayscale path) to version B (back version path), thereby realizing dynamic judgment and precise control across version pages.

[0202] S422: Based on the fallback path in the grayscale jump fallback parameters, determine the access path of the second page as the fallback path.

[0203] This involves retrieving the adjusted version B path from the system and redirecting to the corresponding version B path. This step is executed when the S421 judgment result is yes. Based on the preset fallback path information in the gray-scale jump fallback parameters, the system switches the page access path to the corresponding version B path, allowing users to directly jump to the old version page resources in the gray-scale release scenario, thereby ensuring page compatibility and business logic stability.

[0204] S423: Analyze whether the second page has a grayscale parameter configured for back navigation?

[0205] Otherwise, execute S424; otherwise, execute S425.

[0206] This involves obtaining the current B version's redirect path and checking if the system is configured to redirect the B version's redirect path to the new A version's path. Step S423 determines whether the second page defines a "retrograde grayscale parameter" (i.e., toNewUrlInfo) when the current page is in a rollback version (B version). By detecting this parameter, the system can identify whether the current old version page should redirect to the A version path during the rollback, thus controlling the page jump logic from the old version to the new version. If this parameter is not configured, it means that the page does not support rollback to the grayscale path and will continue to execute the default jump logic.

[0207] S424: Determine that the access path for the second page is a grayscale path.

[0208] For cases where no fallback / grayscale parameter is configured, meaning the old version page does not have a specific jump logic instruction when redirecting, the system directly sets the access path to the A version path (grayscale path) to ensure that the page after redirection loads the new version's resources. This avoids access errors or resource missing information, ensuring the normality and consistency of page access.

[0209] S425: Based on the grayscale path in the fallback jump grayscale parameters, determine the access path of the second page as the grayscale path.

[0210] The second page contains a fallback / redirect grayscale parameter. The system reads the grayscale path information from this parameter and redirects according to the configured access path for version A, thus achieving a controlled switch from the old version page to the new version page. This process allows developers to customize the redirection target path, making page transitions more flexible and meeting the multi-path access requirements under complex grayscale release strategies.

[0211] S426: Analyze whether the grayscale jump and fallback parameters are configured on the second page?

[0212] If so, then execute S427.

[0213] S427: Based on the fallback path in the grayscale jump fallback parameters, determine the access path of the second page as the fallback path.

[0214] It should be noted here that steps S41-S45 above constitute the basic judgment stage of canary release control, used to confirm whether canary release configuration information exists in the system and whether canary release is enabled. If canary release is not enabled, the system defaults to all pages accessing the canary path (version A) to ensure the stability and consistency of page loading. When canary release is enabled, the system further enters the path determination stage. At this time, if full rollback is not enabled (corresponding to branch S417), the subsequent canary list and rollback list logic is executed to determine whether a specific organization or user should participate in the canary test or maintain access to the old version. Figure 4A Unlike the "Enable full rollback" scenario (S46 branch), the S417 branch corresponds to the partial grayscale scenario, which means that the system only rolls back or performs grayscale updates for some objects in order to flexibly control the version experience of different organizations or users.

[0215] Under this branch, steps S418 to S427 dynamically switch between the grayscale path and the fallback path by determining whether a fallback list is configured and whether redirection parameters (grayscale jump fallback parameter urlInfo and fallback jump grayscale parameter toNewUrlInfo). The system can flexibly switch access paths between version A (grayscale path) and version B (fallback path) based on page redirection requests and parameter configurations, ensuring the correctness and consistency of page access logic in partial grayscale or version trial scenarios, thereby achieving more refined grayscale release control and a dynamic fallback mechanism.

[0216] Using the method of this application, the client configures grayscale rules in the configuration page, obtains the corresponding grayscale rules from the server, and matches and determines the page access path according to the grayscale rules during the page routing process.

[0217] The method described in this application can significantly improve the flexibility and stability of front-end canary releases and version control. The specific effects are as follows: This application fills the technical gap in the current mainstream front-end and back-end separation model, which lacks an efficient front-end canary release and partial rollback solution.

[0218] This application demonstrates excellent compatibility with a large number of existing projects. The canary release logic is decoupled from the business logic, resulting in minimal intrusion into existing projects and minimal impact on functionality. It can be quickly implemented through simple script modifications. The solution also considers information security requirements; for older versions of pages with security vulnerabilities, routing guards can be configured to force redirection to the new version's path, thereby improving overall system security. Furthermore, this solution can be extended to be compatible with backend interfaces, enabling backend-level canary releases and partial rollbacks, forming a complete canary release system that integrates frontend and backend collaboration.

[0219] Through canary release rules, users can freely switch between old and new versions. Different organizations can access their respective versions independently, and a whitelist mechanism can be used to flexibly limit the canary release range. The system supports differentiated rollback for specific pages and organizations, enabling fine-grained control to ensure functional diversity and system stability in multi-organization, multi-page scenarios. This solution is simple and efficient to configure, taking only about 1 to 2 minutes from configuration to activation. It boasts excellent performance and robustness, implemented based on the powerful route guard mechanism of the Vue framework, ensuring fast response and stable operation. Version switching can be completed without the user's awareness, greatly improving user experience and system maintainability.

[0220] See Figure 5 The diagram shown is an implementation flowchart of another front-end canary deployment method provided in this application embodiment, applied to a server. The specific implementation process of this method is as follows: steps S51~S52: S51: Receive a grayscale configuration information upload request from the client and extract grayscale configuration information from the grayscale configuration information upload request; The grayscale configuration information is generated by the client through its provided grayscale configuration interface. This grayscale configuration information is used to retrieve the client's grayscale configuration information from the server after the client responds to an access request from an object. The client provides multiple pages; the grayscale configuration information indicates the access path for each of the multiple pages. In response to a redirect request triggered by an object, from the first page to the second page, the front-end routing interface determines the access path for the second page based on the grayscale configuration information. The access path includes a fallback path and a grayscale path. The fallback path is a pre-set path for front-end resources on the server before the client's grayscale release; the grayscale path is a pre-set path for front-end resources on the server after the client's grayscale release. The corresponding version of the front-end resource file is loaded based on the access path, and the second page is rendered according to the front-end resource file. In one optional implementation, when performing canary deployment management, the server first receives a canary deployment configuration information upload request from the client in step S51. The client visualizes and sets the canary deployment parameters through its provided canary deployment configuration interface, including canary deployment enable parameters, rollback parameters, canary deployment list, rollback list, and page version control parameters. After the user completes the configuration in the interface, the client generates complete canary deployment configuration information, packages it into an upload request, and sends it to the server.

[0221] In one optional implementation, after receiving an upload request, the server can extract grayscale configuration information from the request and perform legality verification, including field integrity checks, version number comparisons, and data format verification, to ensure the accuracy and consistency of the grayscale configuration content.

[0222] S52: Store the grayscale configuration information in the grayscale configuration database for subsequent calls and updates by the client.

[0223] The server stores the verified canary configuration information in a canary configuration database. This database can use a structured storage method, storing canary configurations for different clients in layers according to version number, update time, and application identifier, thereby facilitating subsequent retrieval and updates. For example, when the client launches the next time or executes page navigation logic, it can directly retrieve the latest canary configuration information from the server, realizing dynamic updates to the front-end logic.

[0224] Considering that canary deployment rules may be frequently adjusted due to business iterations, this application proposes a canary deployment configuration management scheme with a synchronization mechanism to ensure consistency between front-end and back-end configuration information.

[0225] Optionally, the server also includes a grayscale parameter synchronization module for grayscale configuration management, which pushes the latest grayscale configuration information to the client when it detects that the grayscale configuration information has been updated, so as to keep the grayscale configuration information of the client consistent in real time.

[0226] In one optional implementation, when the gray-scale rules may change frequently due to business adjustments or version updates, the server can be configured with a gray-scale parameter synchronization module. This module automatically pushes the latest gray-scale configuration information to registered clients upon detecting a modification. For example, when an administrator updates the gray-scale list or rollback parameters through the server-side gray-scale configuration management interface, the server immediately triggers a synchronization task, distributing the latest configuration to all connected clients via message push or API call. Upon receiving this push information, the client automatically refreshes its locally cached gray-scale rules, ensuring that subsequent page access path determinations are based on the latest configuration. This automatic synchronization mechanism avoids configuration inconsistencies between clients and the server, guaranteeing the consistent effectiveness of gray-scale strategies.

[0227] Through the above implementation methods, this application can achieve centralized management and automatic distribution of gray-scale configurations, enabling real-time synchronization of configuration information between the server and multiple clients, significantly improving the efficiency and consistency of gray-scale release management, avoiding page access anomalies or gray-scale logic errors caused by information lag, thereby further improving system stability and business flexibility.

[0228] In one optional implementation, to further expand the applicability of canary release control, the server can implement canary release and partial rollback of backend functions through interface compatibility design. For example, canary release flag parameters can be set for each functional interface on the server side. When a request is received from different organizations or users, the server can determine whether the request should be routed to the new version service or the old version service based on the canary release flag, the canary release list, and the rollback list, thereby realizing canary release and partial rollback of backend logic. Taking a business approval system as an example, when a new version of a function is launched, requests from organizations on the canary release list will be routed to the new version service instance for function verification, while requests from ordinary organizations will still be routed to the old version service instance to ensure stability. In this way, the backend service can also achieve the same flexible canary release control and rollback mechanism as the frontend, thereby forming an end-to-end unified canary release system, effectively improving the controllability and reliability of the system iteration process.

[0229] Based on the same inventive concept, this application provides a page switching device applied to a client-side application. Please refer to [link / reference needed]. Figure 6A The diagram shows a structural representation of a front-end grayscale publishing device 600A provided in this application embodiment. The device 600A includes: The acquisition unit 601A is used to obtain the grayscale configuration information of the client from the server in response to the access request of the object to the client; the client provides multiple pages; the grayscale configuration information is used to indicate the access path corresponding to each of the multiple pages; The jump unit 602A is used to respond to a jump request triggered by an object, which requests a jump from the first page of multiple pages to the second page of multiple pages. The access path of the second page is determined by the front-end routing interface based on the canary deployment configuration information. The access path includes a fallback path and a canary path. The fallback path is a front-end resource access path preset by the server for the client before the client's canary deployment. The canary path is a front-end resource access path preset by the server for the client after the client's canary deployment. The rendering unit 603A is used to load the corresponding version of the front-end resource file based on the access path and render the second page according to the front-end resource file.

[0230] In one possible embodiment, the grayscale configuration information includes grayscale enable parameters for indicating the grayscale release enable status and fallback parameters for indicating the grayscale path to switch to the fallback path. The jump unit 602A is used for: If the grayscale enable parameter indicates that grayscale publishing is not enabled, then the access path of the second page is determined to be the grayscale path; If the grayscale enable parameter indicates that grayscale release is enabled, the access path to the second page is determined based on the fallback parameter.

[0231] In one possible embodiment, the grayscale configuration information further includes a grayscale list, and the jump unit 602A is used for: If the fallback parameter indicates that all fallbacks are enabled, then the access path of the second page is determined to be the fallback path; If the fallback parameter indicates that full fallback is not enabled, the access path to the second page is determined based on the grayscale list.

[0232] In one possible embodiment, the grayscale configuration information also includes a fallback list, and the jump unit 602A is used for: If the organization to which the object belongs is in the gray list, and the access path on the first page is not a gray path, then the access path on the second page is determined to be a gray path.

[0233] If the organization to which the object belongs is not in the gray list, the access path to the second page is determined based on the rollback list.

[0234] In one possible embodiment, the grayscale configuration information also includes version control parameters for each page, and the jump unit 602A is used for: If the organization to which the object belongs is on the rollback list, the access path of the second page is determined based on the access path of the first page and the version control parameters of the second page.

[0235] In one possible embodiment, each version control parameter includes grayscale jump and rollback parameters and rollback jump grayscale parameters; the jump unit 602A is used for: If the access path of the first page is a grayscale path, and the version control parameters of the second page are configured with grayscale jump back parameters, then the fallback path in the grayscale jump back parameters will be used as the access path of the second page. If the access path of the first page is a back path, the access path of the second page is determined based on the grayscale jump back parameters and the back jump grayscale parameters of the second page.

[0236] In one possible embodiment, the jump unit 602A is used for: If the version control parameters of the second page are configured with grayscale jump and rollback parameters, the rollback path in the grayscale jump and rollback parameters will be used as the access path of the second page. If the grayscale jump and rollback parameters are not configured in the version control parameters of the second page, then the access path of the second page will be determined as the grayscale path based on the rollback and grayscale parameters of the second page.

[0237] In one possible embodiment, the grayscale configuration information is defined by the client in the grayscale configuration interface and then reported to the server; the acquisition unit 601A is used for: The client obtains the corresponding grayscale configuration information from the server and loads it into the client's local cache. This allows the front-end routing interface to directly read the grayscale configuration information when responding to a redirection request from the first page of multiple pages to the second page of multiple pages, thereby determining the access path of the second page without real-time interaction with the server.

[0238] Based on the same inventive concept, this application provides a page switching device applied to a server. Please refer to [link / reference]. Figure 6B The diagram shows a structural representation of a front-end grayscale publishing device 600B provided in this application embodiment. The device 600B includes: The receiving unit 601B is used to receive a grayscale configuration information upload request from the client and extract grayscale configuration information from the grayscale configuration information upload request; wherein, the grayscale configuration information is generated by the client after setting through the grayscale configuration interface provided by the client; Storage unit 602B is used to store grayscale configuration information to the grayscale configuration database for subsequent access and updates by the client.

[0239] In one possible embodiment, the server further includes a grayscale parameter synchronization module for grayscale configuration management, and the device 600B further includes: The synchronization unit 603B is used to push the latest grayscale configuration information to the client when the grayscale configuration information is detected to be updated, so as to keep the grayscale configuration information of the client consistent in real time.

[0240] Based on the same inventive concept, this application provides an electronic device that can realize the page switching device function described above. Please refer to... Figure 7 The device includes a processor 701 and a memory 702. Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the page switching methods described above. Since the principle by which the computer-readable storage medium solves the problem is similar to that of the page switching method, the implementation of the computer-readable storage medium can be found in the implementation of the method; repeated details will not be elaborated further.

[0241] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the page switching methods described above. Since the principle by which the above computer program product solves the problem is similar to that of the page switching method, the implementation of the above computer program product can be referred to the implementation of the method, and repeated details will not be described again.

[0242] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0243] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0244] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0245] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of user-operated steps to be executed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0246] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A front-end canary deployment method, characterized in that, Applied to a client, the method includes: In response to an access request from the client, the grayscale configuration information of the client is obtained from the server; the client provides multiple pages; the grayscale configuration information is used to indicate the access path corresponding to each of the multiple pages; In response to a redirection request triggered by the object, from a first page among the plurality of pages to a second page among the plurality of pages, the front-end routing interface determines the access path of the second page based on the grayscale configuration information; wherein, the access path includes: a fallback path and a grayscale path; the fallback path is a front-end resource access path preset by the server for the client before the client's grayscale release; the grayscale path is a front-end resource access path preset by the server for the client after the client's grayscale release; The corresponding version of the front-end resource file is loaded based on the access path, and the second page is rendered according to the front-end resource file.

2. The method as described in claim 1, characterized in that, The grayscale configuration information includes grayscale enable parameters indicating the grayscale release activation status and fallback parameters indicating the grayscale path to switch to the fallback path. Determining the access path of the second page based on the front-end resource access path of the second page indicated by the grayscale configuration information includes: If the grayscale enable parameter indicates that grayscale publishing is not enabled, then the access path of the second page is determined to be the grayscale path; If the grayscale enable parameter indicates that grayscale release is enabled, the access path to the second page is determined according to the fallback parameter.

3. The method as described in claim 2, characterized in that, The grayscale configuration information also includes a grayscale list, and determining the access path to the second page based on the fallback parameters includes: If the fallback parameter indicates that all fallbacks are enabled, then the access path of the second page is determined to be the fallback path; If the rollback parameter indicates that full rollback is not enabled, the access path to the second page is determined based on the grayscale list.

4. The method as described in claim 3, characterized in that, The grayscale configuration information also includes a rollback list, and determining the access path to the second page based on the grayscale list includes: If the organization to which the object belongs is in the gray list, and the access path of the first page is not in the gray path, then the access path of the second page is determined to be the gray path. If the organization to which the object belongs is not in the gray list, the access path to the second page is determined according to the fallback list.

5. The method as described in claim 4, characterized in that, The grayscale configuration information also includes version control parameters for each page, and determining the access path of the second page based on the rollback list includes: If the organization to which the object belongs is in the rollback list, the access path of the second page is determined based on the access path of the first page and the version control parameters of the second page.

6. The method as described in claim 5, characterized in that, Each version control parameter includes grayscale jump and rollback parameters and rollback and grayscale parameters; determining the access path of the second page based on the access path of the first page and the version control parameters of the second page includes: If the access path of the first page is in the grayscale path, and the grayscale jump back parameter is configured in the version control parameters of the second page, then the back path in the grayscale jump back parameter shall be used as the access path of the second page. If the access path of the first page is the back path, the access path of the second page is determined according to the grayscale jump back parameters and the back jump grayscale parameters of the second page.

7. The method as described in claim 6, characterized in that, If the access path of the first page is the back path, the access path of the second page is determined according to the grayscale jump back parameters and the back jump grayscale parameters of the second page, including: If the version control parameters of the second page are configured with grayscale jump and rollback parameters, the rollback path in the grayscale jump and rollback parameters shall be used as the access path of the second page; If the grayscale jump and rollback parameters are not configured in the version control parameters of the second page, then the access path of the second page is determined to be the grayscale path based on the rollback and grayscale parameters of the second page.

8. The method according to any one of claims 1 to 7, characterized in that, The grayscale configuration information is defined by the client in the grayscale configuration interface and then reported to the server; The step of obtaining the grayscale configuration information of the client from the server includes: The client obtains the corresponding grayscale configuration information from the server and loads the grayscale configuration information into the client's local cache, so that the front-end routing interface can directly read the grayscale configuration information in response to a jump request from the first page among the multiple pages to the second page among the multiple pages, thereby determining the access path of the second page without real-time interaction with the server.

9. A front-end canary deployment method, characterized in that, Applied to a server, the method includes: Receive a grayscale configuration information upload request from the client, and extract grayscale configuration information from the grayscale configuration information upload request; The grayscale configuration information is generated by the client through its provided grayscale configuration interface. This grayscale configuration information is used by the client to obtain the client's grayscale configuration information from the server after responding to an access request from an object. The client provides multiple pages. The grayscale configuration information indicates the access path corresponding to each of the multiple pages. In response to a redirection request triggered by the object, from the first page to the second page among the multiple pages, the front-end routing interface determines the access path of the second page based on the grayscale configuration information. The access path includes a fallback path and a grayscale path. The fallback path is a front-end resource access path preset by the server for the client before the client's grayscale release. The grayscale path is a front-end resource access path preset by the server for the client after the client's grayscale release. Based on the access path, the corresponding version of the front-end resource file is loaded, and the second page is rendered according to the front-end resource file. The grayscale configuration information is stored in the grayscale configuration database for subsequent access and updates by the client.

10. The method as described in claim 9, characterized in that, The server also includes a grayscale parameter synchronization module for grayscale configuration management, and the method further includes: The grayscale parameter synchronization module pushes the latest grayscale configuration information to the client when it detects that the grayscale configuration information has been updated, so as to keep the grayscale configuration information of the client consistent with the grayscale configuration information stored in the server in real time.

11. A front-end grayscale publishing device, characterized in that, Applied to a client, the method includes: The acquisition unit is used to obtain the grayscale configuration information of the client from the server in response to the access request of the client; the client provides multiple pages; the grayscale configuration information is used to indicate the access path corresponding to each of the multiple pages; A redirection unit is used to respond to a redirection request triggered by the object, requesting a redirection from a first page among the plurality of pages to a second page among the plurality of pages. The front-end routing interface determines the access path to the second page based on the grayscale configuration information. The access path includes a fallback path and a grayscale path. The fallback path is a front-end resource access path preset by the server for the client before the client's grayscale release. The grayscale path is a front-end resource access path preset by the server for the client after the client's grayscale release. The rendering unit is used to load the corresponding version of the front-end resource file based on the access path, and render the second page according to the front-end resource file.

12. A front-end grayscale publishing device, characterized in that, Applied to a server, the method includes: The receiving unit is configured to receive a grayscale configuration information upload request from the client and extract grayscale configuration information from the grayscale configuration information upload request; The grayscale configuration information is generated by the client through its provided grayscale configuration interface. This grayscale configuration information is used by the client to obtain the client's grayscale configuration information from the server after responding to an access request from an object. The client provides multiple pages. The grayscale configuration information indicates the access path corresponding to each of the multiple pages. In response to a redirection request triggered by the object, from the first page to the second page among the multiple pages, the front-end routing interface determines the access path of the second page based on the grayscale configuration information. The access path includes a fallback path and a grayscale path. The fallback path is a front-end resource access path preset by the server for the client before the client's grayscale release. The grayscale path is a front-end resource access path preset by the server for the client after the client's grayscale release. Based on the access path, the corresponding version of the front-end resource file is loaded, and the second page is rendered according to the front-end resource file. The storage unit is used to store the grayscale configuration information into the grayscale configuration database for subsequent access and updates by the client.

13. An electronic device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method according to any one of claims 1-10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1-10.

15. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of claims 1-10.

Images