Version iteration method for new code deployment and test

Abstract

The invention relates to a version iteration method for new code deployment and test, which comprises the following steps of: creating a shunting strategy, and matching traffic sent to a new code and an old code through the shunting strategy; creating target content, and setting routing information and a first access interface of a new code and routing information and a second access interface of an old code; when a client initiates a traffic acquisition request, determining which proportion the traffic to be processed is sent to the new code and the old code according to a shunting strategy, and determining an access interface corresponding to the client; and the client receives execution results fed back by the first access interface and the second access interface, and records logs and monitoring data. According to the method, a progressive deployment strategy is adopted, old codes are replaced step by step, new codes are fully tested and verified, the risk of code deployment and testing is reduced, the testing efficiency is improved, stable operation of the new codes is ensured through real-time monitoring and dynamic adjustment, and smooth transition of a system and continuity of services are both considered.

Description

Technical Field

[0001] The present invention relates to the technical field of software updating and deployment, and in particular to a version iteration method for new code deployment and testing. Background Art

[0002] At the critical stage of the initial deployment of new code to the production environment, since the new code has not been fully tested and verified, it may contain some unknown defects and potential risks. If the existing old code is directly replaced without sufficient inspection, it will bring extremely high risks. Specifically, the following points need to be considered when the new code is first deployed:

[0003] First, if the new code is not fully verified, it may cause abnormalities in the business process in the production environment, thus affecting the stability of the entire system. This will not only interfere with the normal operation of the enterprise, but may also cause dissatisfaction and complaints from users.

[0004] Secondly, the comprehensive replacement of old codes may involve multiple modules and components. If the new code has defects, it may cause the entire system to crash, resulting in serious economic and reputational losses.

[0005] Thirdly, since the new code has not been tested in actual operation, its performance and stability may not meet the requirements of the production environment. During business peaks, the system may crash due to insufficient carrying capacity, seriously affecting the business development of the enterprise.

[0006] In addition, completely replacing old codes may also bring compatibility issues, causing some old systems or third-party applications to fail to operate normally, further exacerbating the company's operational risks.

[0007] In the new code deployment phase, existing technologies have the following deficiencies:

[0008] Lack of progressive deployment strategy: New code is often directly deployed to the production environment. There is no mechanism to gradually replace old code, which increases potential risks.

[0009] Lack of traffic control: After the new code is deployed, there is no effective traffic control mechanism to gradually guide user requests to access the new code, increasing the risk of system instability.

[0010] Inflexible rule configuration: Existing diversion control methods often lack flexible rule configuration and cannot meet the diversion requirements in different scenarios.

[0011] Insufficient dynamic refresh capability: The diversion strategy is difficult to update in real time after deployment, and lacks dynamic refresh capability, resulting in the inability to adjust the diversion effect in a timely manner.

[0012] The information disclosed in this background technology section is only intended to deepen the understanding of the overall background technology of the present invention, and should not be regarded as acknowledging or suggesting in any form that the information constitutes the prior art already known to those skilled in the art. Summary of the invention

[0013] In view of the defects existing in the prior art, the purpose of the present invention is to provide a version iteration method for new code deployment and testing, adopt a progressive deployment strategy, gradually replace the old code, and fully test and verify the new code, thereby reducing the risks of code deployment and testing, improving testing efficiency, and ensuring the stable operation of the new code through real-time monitoring and dynamic adjustment, taking into account the smooth transition of the system and the continuity of the business.

[0014] In order to achieve the above purpose, the technical solution adopted by the present invention is:

[0015] A version iteration method for new code deployment and testing, characterized by comprising the following steps:

[0016] Create a traffic diversion strategy and use it to match the traffic sent to the new and old codes.

[0017] Create target content, set routing information and a first access interface of the new code through the target content, and set routing information and a second access interface of the old code;

[0018] When the client initiates a traffic acquisition request, the proportion of the traffic to be processed to be sent to the new and old codes is determined according to the diversion strategy, and the first access interface and the second access interface corresponding to the client are determined according to the target content;

[0019] The client receives the execution results fed back by the first access interface and the second access interface, and records logs and monitoring data.

[0020] Based on the above technical solution, the diversion strategy includes the following parameters:

[0021] The enabled control parameter is used to set whether to enable a certain diversion strategy;

[0022] The return value parameter variations is used to represent different versions of code or services;

[0023] The rule list rules is used to select a value from variations based on the conditions and return it;

[0024] The default service configuration defaultServe is used to select the return value based on this configuration when the diversion policy match fails.

[0025] Based on the above technical solution, in response to the received request, the diversion strategy determines the corresponding return value from the return value parameter variations according to the rules defined in the rule list rules;

[0026] If the match cannot be completed according to the rules defined in the rule list rules, the corresponding return value is determined from the default service configuration defaultServe;

[0027] The return value defaults to setting the ratio of traffic sent to the new and old codes.

[0028] On the basis of the above technical solution, the rule list rules pre-sets one or more rules, each rule is constrained by a set of conditions, and when all the conditions are met, the match is successful and the corresponding rule takes effect.

[0029] On the basis of the above technical solution, when matching through the diversion strategy, each condition constituting the rule is matched based on string comparison, or based on numerical comparison, or based on weight strategy.

[0030] On the basis of the above technical solution, each parameter in the diversion strategy is configured and adjusted through a visual management interface.

[0031] On the basis of the above technical solution, each parameter in the diversion strategy is stored in the configuration class after setting, and the diversion rules are defined and managed through the configuration class, supporting nacos dynamic refresh.

[0032] Based on the above technical solution, the parameters in the diversion strategy are stored in the policy management function module of the client after setting. The function module controls the enabling or disabling of specific function switches, and completes the matching processing based on the diversion strategy according to the function switch in the turned-on state.

[0033] Based on the above technical solution, each parameter in the diversion strategy is written into the source code in the form of annotations after setting. The annotations are used to mark methods and / or parameters, including:

[0034] @FlowSplitter: This annotation is used to mark the method that needs to be split and contains the configuration information of the splitter: the key, properties and methods of the switch;

[0035] @FlowSplitterAttribute: This annotation is used to define the attributes passed to the splitter for rule matching.

[0036] Based on the above technical solutions, when recording logs and monitoring data, use monitoring tools to collect real-time running status data of the new code, including response time, error rate, and resource consumption;

[0037] Dynamically adjust the traffic proportion carried by the new code based on the recorded logs and monitoring data. When performance problems are found in the new code, reduce the traffic proportion it carries or suspend deployment in a timely manner.

[0038] The version iteration method for new code deployment and testing described in the present invention adopts a progressive deployment strategy to gradually replace the old code and fully test and verify the new code, thereby reducing the risk of code deployment and testing, improving the testing efficiency, and ensuring the stable operation of the new code through real-time monitoring and dynamic adjustment, taking into account the smooth transition of the system and the continuity of the business, and having the following beneficial effects:

[0039] 1. Reduce deployment risks: Through progressive deployment and traffic control, the high risks that may be caused by direct and comprehensive deployment of new codes are avoided, ensuring the stable operation of the production environment.

[0040] 2. Improve testing efficiency: Through the intelligent traffic distribution mechanism, new codes can be quickly tested in the real user environment, effectively shortening the testing cycle and improving testing efficiency.

[0041] 3. Real-time monitoring and dynamic adjustment: The system can monitor the running status of the new code in real time and dynamically adjust the traffic distribution strategy based on the monitoring data to ensure that the new code runs stably and reliably while gradually expanding the carrying range.

[0042] 4. Ensure user experience: During the deployment and testing process, by controlling the traffic ratio, the decline in user experience caused by new code problems is avoided, ensuring the continuity of user service quality.

[0043] 5. Promote smooth transition of the system: By gradually increasing the traffic proportion of the new code, the new and old codes will eventually be completely replaced, ensuring a smooth transition of the system and reducing potential problems caused by code switching.

[0044] 6. Enhance system flexibility: The diversion control method supports flexible rule configuration and dynamic refresh mechanism, which can quickly adjust the diversion strategy according to actual needs, improving the adaptability and flexibility of the system.

[0045] 7. Improve business continuity: Through diversion control, the continuity of business during code deployment and testing is ensured, reducing business interruptions caused by code switching, and providing guarantees for the company's continued operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The present invention has the following accompanying drawings:

[0047] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0048] Figure 1 A flowchart of embodiment 1 of a version iteration method for new code deployment and testing described in the present invention. DETAILED DESCRIPTION

[0049] The present invention is further described in detail below in conjunction with the accompanying drawings. The detailed description is an explanation made in conjunction with the exemplary embodiments of the present invention, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0050] like Figure 1 As shown, the version iteration method for new code deployment and testing described in the present invention includes the following steps:

[0051] Create a traffic diversion strategy and use it to match the traffic sent to the new and old codes.

[0052] Create target content, set routing information and a first access interface of the new code through the target content, and set routing information and a second access interface of the old code;

[0053] When the client initiates a traffic acquisition request, the proportion of the traffic to be processed to be sent to the new and old codes is determined according to the diversion strategy, and the first access interface and the second access interface corresponding to the client are determined according to the target content;

[0054] The client receives the execution results fed back by the first access interface and the second access interface, and records logs and monitoring data.

[0055] Embodiment 1:

[0056] Step 1: Create a traffic diversion strategy

[0057] In the first embodiment, a diversion strategy S is first created, and the strategy S includes the following parameters: a diversion ratio P and an identifier of the old and new codes. The diversion strategy S can be created through a management console. The diversion ratio P is used to determine the distribution ratio of traffic between the old code and the new code. For example, when P=70%, 70% of the traffic is sent to the old code and 30% of the traffic is sent to the new code.

[0058] Step 2: Create targeted content

[0059] Then, a target content T is created, which includes routing information R1 and a first access interface A1 of the new code, and routing information R2 and a second access interface A2 of the old code. The creation of the target content T can also be completed through the management console.

[0060] Step 3: Handle client request

[0061] When client C initiates a traffic acquisition request, the system determines the ratio of the traffic to be processed to the new and old codes according to the diversion strategy S. For example, if the traffic ID requested by client C matches the ID in the diversion strategy S, the system will distribute the traffic to the new code or the old code according to the diversion ratio P.

[0062] Step 4: Determine the access interface

[0063] Next, the system determines the first access interface A1 and the second access interface A2 corresponding to the client C according to the target content T. For example, if the request of the client C is assigned to the new code, the system routes the request of the client C to the first access interface A1; if the request of the client C is assigned to the old code, the system routes the request of the client C to the second access interface A2.

[0064] Step 5: Feedback execution results

[0065] The client C receives the execution results fed back by the first access interface A1 and the second access interface A2, and records logs and monitoring data, which can be used for subsequent performance analysis and troubleshooting.

[0066] Embodiment 2:

[0067] Embodiment 2 is based on Embodiment 1, and adds a step of dynamically adjusting the diversion strategy. The details are as follows:

[0068] Steps 1-5: Create diversion strategies and target content to process client requests

[0069] Similar to the first embodiment, the diversion strategy S and the target content T are first created, and then the request of the client C is processed to determine the access interface.

[0070] Step 6: Dynamically adjust the diversion strategy

[0071] In the second embodiment, the system can dynamically adjust the diversion strategy S according to the monitoring data. For example, if it is found in the testing phase that the performance of the new code is better than the old code, the system can automatically adjust the diversion ratio P so that more traffic is sent to the new code.

[0072] The above embodiments have the following advantages: 1) It can dynamically allocate traffic according to the diversion strategy to reduce the risk of new code deployment; 2) It can set the access interface according to the target content to improve the flexibility and scalability of the system; 3) It can timely understand the system operation status by recording logs and monitoring data, which is convenient for performance analysis and troubleshooting.

[0073] Based on the above technical solution, the diversion strategy includes the following parameters:

[0074] The enabled control parameter is used to set whether to enable a certain diversion strategy;

[0075] The return value parameter variations is used to represent different versions of code or services;

[0076] The rule list rules is used to select a value from variations based on the conditions and return it;

[0077] The default service configuration defaultServe is used to select the return value based on this configuration when the diversion policy match fails.

[0078] The following is an example showing how to configure variations, rules, and defaultServe.

[0079]

[0080]

[0081] In this example, there are three return values: 0, 1, and 2. If the value of parameter p1 is "a", the splitter returns 1. If the value of parameter p2 is greater than 10, the splitter returns 2. If none of the above conditions are met, the splitter returns 0. The three return values ​​are only examples, and you are not limited to setting return values ​​in this way.

[0082] Based on the above technical solution, in response to the received request, the diversion strategy determines the corresponding return value from the return value parameter variations according to the rules defined in the rule list rules;

[0083] If the match cannot be completed according to the rules defined in the rule list rules, the corresponding return value is determined from the default service configuration defaultServe;

[0084] The return value defaults to setting the ratio of traffic sent to the new and old codes.

[0085] For example, if no rule matches, 10% of the traffic will be allocated to the old code version (0 in variations), and 90% of the traffic will be allocated to the new code version (1 in variations), which is the default service configuration defaultServe.

[0086] On the basis of the above technical solution, the rule list rules pre-sets one or more rules, each rule is constrained by a set of conditions, and when all the conditions are met, the match is successful and the corresponding rule takes effect.

[0087] The following is an example of a rule list.

[0088] The rule list contains multiple pre-set rules, as follows:

[0089] Rule 1: If condition A, condition B, and condition C are met, perform operation 1;

[0090] Rule 2: When condition D and condition E are met, perform operation 2;

[0091] Rule 3: Condition F, when satisfied, execute operation 3.

[0092] Rules 1-3 are each composed of a set of conditional constraints. The following are examples of some of the conditions:

[0093] Condition A: data item X is greater than threshold Y;

[0094] Condition B: Data item Z is less than threshold W;

[0095] Condition C: Data item P is equal to a specific value Q.

[0096] The matching process is as follows: when the input data meets all the conditions in a rule, the system will perform the corresponding operation.

[0097] On the basis of the above technical solution, when matching through the diversion strategy, each condition constituting the rule is matched based on string comparison, or based on numerical comparison, or based on weight strategy.

[0098] On the basis of the above technical solution, each parameter in the diversion strategy is configured and adjusted through a visual management interface.

[0099] On the basis of the above technical solution, each parameter in the diversion strategy is stored in the configuration class after setting, and the diversion rules are defined and managed through the configuration class, supporting nacos dynamic refresh.

[0100] Based on the above technical solution, the parameters in the diversion strategy are stored in the policy management function module of the client after setting. The function module controls the enabling or disabling of specific function switches, and completes the matching processing based on the diversion strategy according to the function switch in the turned-on state.

[0101] Based on the above technical solution, each parameter in the diversion strategy is written into the source code in the form of annotations after setting. The annotations are used to mark methods and / or parameters, including:

[0102] @FlowSplitter: This annotation is used to mark the method that needs to be split and contains the configuration information of the splitter: the key, properties and methods of the switch;

[0103] @FlowSplitterAttribute: This annotation is used to define the attributes passed to the splitter for rule matching.

[0104] For example, the @FlowSplitter annotation is used as follows:

[0105] @RestController()

[0106] public class Demo01Ctrl{

[0107] @RequestMapping(" / demo01")

[0108] @FlowSplitter

[0109]

[0110] In this example:

[0111] The @FlowSplitter annotation is applied to the method, instructing the splitter to use demo01 as the switch key.

[0112] The key attribute is set to #p1, which means that the request parameter p1 is used as the hash key for traffic distribution.

[0113] The attributes property defines two properties, p1 and p2, whose values ​​are obtained from the request parameters respectively.

[0114] For example, the @FlowSplitterAttribute annotation is used as shown above. The @FlowSplitterAttribute annotation is used to define attributes that can be used by the flow splitting rules. In the above example, p1 and p2 are defined as attributes, and their values ​​are obtained from the request parameters.

[0115] The flow splitting logic of this example is: when a request reaches the method method, the splitter will decide whether to call method00 or method01 according to the rules defined in the @FlowSplitter annotation. If the request parameters p1 and p2 meet the predefined flow splitting rules, the splitter will select the corresponding method to execute. If no rule matches, the default method will be executed.

[0116] On the basis of the above technical solution, when recording logs and monitoring data, monitoring tools are used to collect the running status data of the new code in real time, including response time, error rate, and resource consumption.

[0117] Based on the above technical solution, the traffic proportion carried by the new code is dynamically adjusted according to the recorded logs and monitoring data. When performance problems are found in the new code, the traffic proportion it carries is reduced or the deployment is suspended in time.

[0118] The contents not described in detail in this specification belong to the prior art known to professional and technical personnel in this field.

[0119] The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiment. Any equivalent modifications or changes made by those skilled in the art based on the contents disclosed by the present invention should be included in the protection scope recorded in the claims.

Claims

1. A version iteration method for new code deployment and testing, characterized in that: The steps include: Create a traffic diversion strategy and use it to match the traffic sent to the new and old codes. Create target content, set routing information and a first access interface of the new code through the target content, and set routing information and a second access interface of the old code; When the client initiates a traffic acquisition request, the proportion of the traffic to be processed to be sent to the new and old codes is determined according to the diversion strategy, and the first access interface and the second access interface corresponding to the client are determined according to the target content; The client receives the execution results fed back by the first access interface and the second access interface, and records logs and monitoring data.

2. A version iteration method for new code deployment and testing as claimed in claim 1, characterized in that: The diversion strategy includes the following parameters: The enabled control parameter is used to set whether to enable a certain diversion strategy; The return value parameter variations is used to represent different versions of code or services; The rule list rules is used to select a value from variations based on the conditions and return it; The default service configuration defaultServe is used to select the return value based on this configuration when the diversion policy match fails.

3. A version iteration method for new code deployment and testing as claimed in claim 2, characterized in that: In response to the received request, the diversion strategy determines the corresponding return value from the return value parameter variations according to the rules defined in the rule list rules; If the match cannot be completed according to the rules defined in the rule list rules, the corresponding return value is determined from the default service configuration defaultServe; The return value defaults to setting the ratio of traffic sent to the new and old codes.

4. A version iteration method for new code deployment and testing as claimed in claim 2, characterized in that: The rule list rules pre-sets one or more rules. Each rule is constrained by a set of conditions. When all the conditions are met, the match is successful and the corresponding rule takes effect.

5. A version iteration method for new code deployment and testing as claimed in claim 4, characterized in that: When matching through the diversion strategy, the various conditions that constitute the rule are matched based on string comparison, or based on numerical comparison, or based on weight strategy.

6. A version iteration method for new code deployment and testing as claimed in claim 2, characterized in that: Each parameter in the diversion strategy is configured and adjusted through a visual management interface.

7. A version iteration method for new code deployment and testing as claimed in claim 2, characterized in that: Each parameter in the diversion strategy is stored in the configuration class after setting. The diversion rules are defined and managed through the configuration class, supporting nacos dynamic refresh.

8. A version iteration method for new code deployment and testing as claimed in claim 2, characterized in that: After the settings are completed, the parameters in the diversion strategy are stored in the policy management function module of the client. The function module controls the enabling or disabling of specific function switches, and completes the matching processing based on the diversion strategy according to the function switches in the turned-on state.

9. A version iteration method for new code deployment and testing as claimed in claim 2, characterized in that: After the parameters in the diversion strategy are set, they are written into the source code in the form of annotations. The annotations are used to mark methods and / or parameters, including: @FlowSplitter: This annotation is used to mark the method that needs to be split and contains the configuration information of the splitter: the key, properties and methods of the switch; @FlowSplitterAttribute: This annotation is used to define the attributes passed to the splitter for rule matching.

10. A version iteration method for new code deployment and testing as claimed in claim 1, characterized in that: When recording logs and monitoring data, use monitoring tools to collect real-time data on the running status of the new code, including response time, error rate, and resource consumption; Dynamically adjust the traffic proportion carried by the new code based on the recorded logs and monitoring data. When performance problems are found in the new code, reduce the traffic proportion it carries or suspend deployment in a timely manner.

Images