Code branch processing method and device, program product and electronic equipment

Abstract

The invention discloses a code branch processing method and device, a program product and electronic equipment, and relates to the technical field of software development.The method comprises the steps that the branch priority and the environment configuration strategy of a target branch are determined based on the development requirement of the target branch; distributing a test environment for the target branch based on the branch priority and an environment configuration strategy; executing a test operation on the target branch in the test environment to obtain a test result; and under the condition that the test result reaches the preset commissioning condition, deploying the packaging file corresponding to the target branch to a production environment, and switching the branch state of the target branch to a commissioning state. According to the method and the device, the technical problem of low production delivery efficiency of code branches caused by inconsistency of a test environment and a production environment in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of software development technology, and more specifically, to a method, apparatus, program product, and electronic device for processing code branches. Background Technology

[0002] In the field of software development technology, code branch management plays a crucial role. This technology helps development teams effectively manage development code and ensures the smooth progress of the software development process. Currently, the code branch model is widely used in software development. This model isolates the development and production environments by setting feature branches and release branches. However, existing technologies suffer from delays during branch merging, leading to integration conflicts and low efficiency in release branch verification. Several existing code branch management technologies are introduced below:

[0003] (1) The main branch development mode directly submits code to the main branch in small batches, which has a high automated test coverage. However, manual version cutting is still required when releasing to production, which poses a risk of environmental differences. In addition, static environment allocation under this development mode can lead to inconsistent configurations between the test environment and the production environment, such as differences in operating system version, middleware parameters, etc., which can easily cause the production problem of "test passed ≠ production usable".

[0004] (2) Containerization technology can achieve infrastructure consistency, but it is still difficult to fully synchronize data status, network policies and service version dependencies, and it increases the complexity of code branch environment management.

[0005] (3) Traditional CI / CD (Continuous Integration / Continuous Delivery) pipelines execute tests and build artifacts in a general environment and deploy them to the production environment after manual approval. However, the topology of the test environment and the production environment are inconsistent (e.g., differences in microservice links), which may still lead to the problem that the test passes but the production environment is unusable. Secondly, when deploying to production, the artifacts are rebuilt, which may introduce new problems due to environmental differences (e.g., dependency version drift), thus affecting the production delivery of the code branch.

[0006] (3) As a linear and sequential development method, the waterfall model is characterized by entering the next stage only after each code processing stage is completed. However, in the short-frequency and rapid code iteration scenario in the financial industry, if a large number of code defects are found during the testing phase, the development team needs to repeatedly fix and test the defects, which will cause the test environment to be occupied by a certain development branch for a long time, thus affecting the deployment and testing progress of other production branches, and ultimately slowing down the overall project progress and team efficiency. In addition, due to the limited number of test environments and unreasonable resource allocation, when multiple projects or teams use them at the same time, there will be a shortage of resources or the inability to obtain them in time, which further exacerbates the delay in code production and delivery.

[0007] There is currently no effective solution to the above problems. Summary of the Invention

[0008] This application provides a method, apparatus, program product, and electronic device for processing code branches, to at least solve the technical problem of low efficiency in production delivery of code branches caused by inconsistencies between the test environment and the production environment in the prior art.

[0009] According to one aspect of this application, a method for processing code branches is provided, comprising: determining the branch priority and environment configuration strategy of the target branch based on the development requirements of the target branch, wherein the target branch is a code branch to be tested submitted by the developer; allocating a test environment to the target branch based on the branch priority and environment configuration strategy, wherein the environment configuration parameters of the test environment are the same as the environment configuration parameters of the production environment; performing test operations on the target branch in the test environment to obtain test results; and, if the test results meet the preset production conditions, deploying the packaged file corresponding to the target branch to the production environment and switching the branch status of the target branch to the production state, wherein the packaged file includes at least the branch identifier of the target branch, the code compilation file, and the environment configuration parameters.

[0010] Optionally, based on the development requirements of the target branch, the branch priority of the target branch is determined, including: parsing the development requirements to obtain the parsing results, wherein the parsing results include at least one of the following: business priority, used to characterize the priority of the business implemented by the target branch; branch timeliness, used to characterize the duration of the development task corresponding to the target branch; resource usage, used to characterize the amount of resources required to run all the code included in the target branch; and determining the branch priority of the target branch based on the parsing results and the preset rules in the strategy rule base.

[0011] Optionally, based on the development requirements of the target branch, the environment configuration strategy for the target branch is determined, including: obtaining the test requirements of the development requirements, wherein the test requirements include at least one of the following: basic tests, used to characterize static analysis and unit testing of the code included in the target branch; integration tests, used to characterize testing the interaction process between the target branch and components; specialized tests, used to characterize testing the security and performance level of the target branch; and determining the environment configuration strategy for the target branch based on the test requirements and preset rules in the strategy rule base.

[0012] Optionally, test operations are performed on the target branch in the test environment to obtain test results, including: determining test cases for the target branch based on the test requirements corresponding to the target branch, wherein the test cases include at least the execution steps and expected results of the test operations; running the automated test program corresponding to the test cases in the test environment; collecting code performance metrics corresponding to the target branch during the execution of the automated test program; and using the test report obtained after the automated test program finishes running and the code performance metrics corresponding to the target branch as the test results of the target branch.

[0013] Optionally, the state machine is used to monitor the branch status of the target branch, wherein the branch status is one of the following: created, indicating that the developer has committed all the code involved in the target branch; deployed, indicating that all the code included in the target branch has been deployed to the test environment and is waiting for testing; verified, indicating that the test operation corresponding to the target branch has been completed and the test results have met the preset production conditions; and deployed, indicating that the packaged file corresponding to the target branch has been deployed in the production environment.

[0014] Optionally, after obtaining the test results, the code branch processing method further includes: if the test results do not meet the preset production conditions, parsing the test results to obtain the test failure reason for the target branch, wherein the test failure reason is one of the following: a first preset reason, used to characterize the code defect in the target branch; a second preset reason, used to characterize the environment defect in the test environment of the target branch; if the test failure reason is the first preset reason, generating a test ticket based on the test results, wherein the test ticket is used to prompt developers to fix the code defect; if the test failure reason is the second preset reason, performing a rollback operation on the test environment, wherein the rollback operation is used to update the environment configuration parameters of the test environment based on the preset environment snapshot in the environment snapshot library; and re-executing the test operation on the target branch in the new test environment obtained by performing the rollback operation.

[0015] Optionally, after allocating a test environment to the target branch, the code branch processing method further includes: scanning the test environment to obtain the environment performance indicators and environment configuration parameters of the test environment, wherein the environment performance indicators include at least one of the following: a first performance indicator, used to characterize the operating information of the processor, memory, and disk of the test environment; a second performance indicator, used to characterize the operating information of the components that interact with the target branch in the test environment; a third performance indicator, used to characterize the operating information of the server where the test environment is located; and generating a warning message if the environment performance indicators of the test environment exceed a preset environment performance threshold or if the environment performance indicators of the test environment differ from the environment performance indicators of a preset environment snapshot.

[0016] According to another aspect of this application, a code branch processing apparatus is also provided, comprising: a target determination unit, configured to determine the branch priority and environment configuration strategy of the target branch based on the development requirements of the target branch, wherein the target branch is a code branch to be tested submitted by the developer; a test environment allocation unit, configured to allocate a test environment to the target branch based on the branch priority and environment configuration strategy, wherein the environment configuration parameters of the test environment are the same as the environment configuration parameters of the production environment; a testing unit, configured to perform test operations on the target branch in the test environment and obtain test results; and a production deployment unit, configured to deploy the packaged file corresponding to the target branch to the production environment and switch the branch status of the target branch to the production state when the test results meet the preset production conditions, wherein the packaged file includes at least the branch identifier of the target branch, the code compilation file, and the environment configuration parameters.

[0017] According to another aspect of this application, a computer program product is also provided, which stores a computer program, wherein a processing method for controlling the computer program product to execute any of the code branches mentioned above is provided during the execution of the computer program.

[0018] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a processing method for code branches of any of the above.

[0019] In this application, firstly, based on the development requirements of the target branch, the branch priority and environment configuration strategy of the target branch are determined. The target branch is the code branch to be tested submitted by the developer. Then, based on the branch priority and environment configuration strategy, this application allocates a test environment to the target branch. The environment configuration parameters of the test environment are the same as those of the production environment. Then, test operations are performed on the target branch in the test environment to obtain test results. Subsequently, if the test results meet the preset production conditions, the packaged file corresponding to the target branch is deployed to the production environment, and the branch status of the target branch is switched to the production status. The packaged file includes at least the branch identifier of the target branch, the code compilation file, and the environment configuration parameters.

[0020] As can be seen from the above, this application adopts a dynamic branch management and environment awareness approach. By dynamically binding the environment and driving state transitions based on test results, it achieves the goal of automatically allocating a test environment consistent with the production environment configuration and automatically advancing branches to the production stage. This achieves a high degree of consistency between the test environment and the production environment, improves the processing efficiency of code branches, and solves the technical problem of low efficiency in production delivery of code branches caused by inconsistencies between the test environment and the production environment in the prior art.

[0021] Specifically, this application dynamically allocates a test environment that highly simulates the production environment by intelligently evaluating the priority and environmental requirements of the target branch, thus ensuring the accuracy of the test results. After the test passes and the preset production conditions are met, this application directly deploys the previously verified immutable artifacts (i.e., the packaged files corresponding to the target branch values) to the production environment, avoiding the uncertainty and code delivery delay caused by rebuilding artifacts in the production environment. This achieves the delivery effect of "what is tested is what is deployed", while improving the efficiency and reliability of code from development to production deployment. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 This is a hardware structure block diagram of an optional computer terminal (or mobile device) for implementing a code branching processing method according to an embodiment of this application.

[0024] Figure 2 This is a flowchart of an optional code branch processing method according to an embodiment of this application;

[0025] Figure 3This is an architecture diagram of an optional code branch processing system according to an embodiment of this application;

[0026] Figure 4 This is a schematic diagram of the topology of an optional code branch according to an embodiment of this application;

[0027] Figure 5 This is a flowchart of an optional code branch release method according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of an optional code branch processing apparatus according to an embodiment of this application;

[0029] Figure 7 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] It should also be noted that all relevant information (including but not limited to information used for display and analysis) and data (including but not limited to development requirement data for the target branch and test code branch data submitted by technical personnel) involved in this application are information and data authorized by the user or fully authorized by all parties. For example, if there is an interface between this system and the relevant user or organization, before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information only after receiving consent from the aforementioned user or organization.

[0033] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary confidentiality measures have been taken. This application does not violate public order and good morals. In addition, this application provides a corresponding operation entry point for users to choose to agree to or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.

[0034] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0035] Branches: A branch is a copy of the code that is separated from the master branch. Technical personnel can perform operations that need to be isolated on this branch, such as developing new features.

[0036] The master branch: It is consistent with the production version and is a long-term branch.

[0037] Feature branches: These are used to develop new feature code and are short-lived branches.

[0038] Environment standardization refers to the standardized settings for basic development, testing, and pre-production environments to ensure that the environment configurations of the corresponding environments are consistent with those of the production environment.

[0039] The present invention will now be described in detail with reference to various embodiments.

[0040] Example 1

[0041] According to an embodiment of this application, an embodiment of a code branch processing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0042] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a code branching processing method according to an embodiment of this application. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0043] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0044] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the code branch processing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the above-mentioned code branch processing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0045] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0046] The display can be configured as a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0047] Under the aforementioned operating environment, this application provides a code branch processing system (hereinafter referred to as the processing system) for executing the code branch processing method in this application. Figure 2 This is a flowchart of an optional code branch processing method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0048] Step S201: Based on the development requirements of the target branch, determine the branch priority and environment configuration strategy of the target branch, where the target branch is the branch of code to be tested submitted by the developers.

[0049] Optionally, the target branch refers to the local code branch submitted by the developer for testing, which is used to implement new features of the software.

[0050] Optionally, branch priority refers to the order in which the processing system determines the branch processing order based on factors such as the type of business implemented by the target branch, the urgency of developing customer needs, and the current test environment resource status.

[0051] Optionally, the processing system determines the branch priority and environment configuration strategy of the target branch based on the development requirements of the target branch. The environment configuration strategy is used to determine the environment configuration parameters of the test environment, thereby ensuring the consistency between the test environment and the production environment, reducing test failures caused by environmental differences, and improving the reliability of test results. The branch priority is used to determine the resource allocation results when processing multiple branches. By pre-setting the branch priority, the processing system can prioritize the processing of relatively important or urgent branches.

[0052] Step S202: Based on branch priority and environment configuration strategy, allocate a test environment to the target branch, wherein the environment configuration parameters of the test environment are the same as those of the production environment.

[0053] Optionally, environment configuration parameters include, but are not limited to, operating system version, middleware settings, network topology, and storage scheme.

[0054] Optionally, the processing system allocates test environments to target branches based on branch priority and environment configuration strategies, which can ensure the authenticity of the test environment. By aligning the configuration parameters of the test environment with those of the production environment, the processing system enables the test results to more accurately reflect the actual operation of the production environment, avoiding inconsistencies between the test environment and the production environment. Furthermore, the processing system intelligently allocates test resources according to branch priority, achieving effective utilization of test resources and improving the overall branch testing efficiency in multi-branch parallel testing scenarios.

[0055] Step S203: Perform test operations on the target branch in the test environment to obtain test results.

[0056] Optionally, test operation refers to the entire process of full-scale automated testing, which is implemented through interface calls. The test items include at least basic tests, integration tests, and special tests.

[0057] Optionally, the processing system performs multi-level and comprehensive testing operations on the target branch, which improves the reliability of the branch code that passes the tests and is delivered to production. At the same time, through the automated testing process, it reduces the waiting time for testers to perform manual testing and speeds up the production and delivery of software code.

[0058] Step S204: If the test results meet the preset production conditions, deploy the packaged file corresponding to the target branch to the production environment and switch the branch status of the target branch to the production status. The packaged file includes at least the branch identifier of the target branch, the code compilation file, and the environment configuration parameters.

[0059] Optionally, preset production conditions refer to the software quality indicator thresholds set by the processing system based on project development needs and business rules, such as test coverage, defect density, and performance baseline. The target branch must meet the preset production conditions before it can be submitted to the production environment.

[0060] Optionally, the packaged file, i.e. the immutable artifact, contains the code version of the target branch, the compilation artifact, and the necessary environment configuration parameters. When the test results meet the preset production conditions, the processing system deploys the packaged file corresponding to the target branch to the production environment, realizing "what is tested is what is deployed". By directly copying the immutable artifact in the test environment to the production environment, the processing system avoids the environmental differences introduced by rebuilding artifacts or configuring environment parameters in the production environment, reduces the unknown risks of the production environment, ensures the consistency between production and testing, and improves the stability of the production environment.

[0061] As can be seen from the above, this application adopts a dynamic branch management and environment awareness approach. By dynamically binding the environment and driving state transitions based on test results, it achieves the goal of automatically allocating a test environment consistent with the production environment configuration and automatically advancing branches to the production stage. This achieves a high degree of consistency between the test environment and the production environment, improves the processing efficiency of code branches, and solves the technical problem of low efficiency in production delivery of code branches caused by inconsistencies between the test environment and the production environment in the prior art.

[0062] Specifically, this application dynamically allocates a test environment that highly simulates the production environment by intelligently evaluating the priority and environmental requirements of the target branch, thus ensuring the accuracy of the test results. After the test passes and the preset production conditions are met, this application directly deploys the previously verified immutable artifacts (i.e., the packaged files corresponding to the target branch values) to the production environment, avoiding the uncertainty and code delivery delay caused by rebuilding artifacts in the production environment. This achieves the delivery effect of "what is tested is what is deployed", while improving the efficiency and reliability of code from development to production deployment.

[0063] In one optional embodiment, the processing system first parses the development requirements to obtain the parsing results, and then determines the branch priority of the target branch based on the parsing results and the preset rules in the policy rule base.

[0064] Optionally, the parsing results include at least one of the following:

[0065] Business priority is used to characterize the priority of the business to be implemented by the target branch.

[0066] Branch timeliness is used to characterize the duration of the development task corresponding to the target branch;

[0067] Resource usage is used to characterize the amount of resources required to run all the code included in the target branch.

[0068] Optionally, development requirements refer to the functions or optimizations that need to be implemented in a software development project, which are proposed by the product or business department and implemented by the development team.

[0069] Optionally, the processing system can quantify the importance, urgency, and resource consumption of each project by analyzing development requirements, thereby providing data support for subsequent branch and environment management.

[0070] Optionally, the processing system determines the branch priority of the target branch based on the parsing results and the preset rules in the policy rule base. In this process, the processing system can automatically prioritize high-priority branches by dynamically adjusting the branch priority, ensuring that critical business is not delayed. In addition, the processing system balances the utilization rate of test environment resources by reasonably arranging the testing and deployment order of branches, avoiding the problems of idle or excessive competition of test environment resources, and improving the overall efficiency of code branch testing.

[0071] In summary, the processing system analyzes development requirements and determines branch priorities based on analytical indicators such as business priority, branch timeliness, and resource usage, as well as preset strategy rules. This enables intelligent management of test environment resources, thereby improving the overall efficiency of code branch development.

[0072] In one alternative embodiment, the processing system first obtains the test requirements of the development requirements, and then determines the environment configuration strategy of the target branch based on the test requirements and the preset rules in the policy rule base.

[0073] Optionally, the testing requirements include at least one of the following:

[0074] Basic tests are used to characterize the static analysis and unit testing performed on the code included in the target branch;

[0075] Integration testing is used to characterize and test the interaction process between target branches and components;

[0076] Specialized tests are used to characterize the security and performance levels of the target branch.

[0077] Optionally, by clearly defining the test requirements of development needs, the processing system can ensure the test coverage and test type of the code branch corresponding to each development task, avoiding unnecessary testing work and saving test resources and testing time. Based on the test requirements of development needs, the processing system directly determines the type of test operation to be executed, and then directly calls the automated test program through interface testing, avoiding the need to manually formulate test cases and improving the testing efficiency of the target branch code.

[0078] Optionally, the processing system determines the environment configuration strategy for the target branch based on test requirements and preset rules in the strategy rule base. Subsequently, the environment configuration parameters of the test environment are configured according to the environment configuration strategy, which can reduce the differences between the test environment and the production environment and improve the accuracy of test results.

[0079] In summary, the processing system formulates environment configuration strategies based on test requirements and preset rules in the strategy rule base, achieving precise test scope coverage. This approach not only improves the comprehensiveness and effectiveness of testing but also dynamically updates the test environment configuration, ensuring that different types of development branches can be fully tested in a test environment suitable for their development needs. This improves the quality and speed of software development and reduces the risks associated with software code branch deployment and launch.

[0080] In one optional embodiment, the processing system first determines test cases for the target branch based on the test requirements corresponding to the target branch, wherein the test cases include at least the execution steps of the test operation and the expected results; then, in the test environment, the processing system runs the automated test program corresponding to the test cases; then, during the execution of the automated test program, the processing system collects the code performance indicators corresponding to the target branch; finally, the processing system uses the test report obtained after the automated test program finishes running and the code performance indicators corresponding to the target branch as the test results of the target branch.

[0081] Optionally, test cases are used to describe at least the execution steps and expected results of the test operation to verify the correctness and performance of the target branch code.

[0082] Optionally, the processing system determines the test cases for the target branch based on the test requirements corresponding to the target branch. By transforming the test requirements into specific test cases, it ensures that every functional point of the target branch is covered by tests, thereby improving the relevance and efficiency of the tests.

[0083] Optionally, the processing system can quickly execute test cases by directly calling the automated test program corresponding to the test cases in the test environment without manual intervention, saving test time and test costs. After the automated test is completed, the processing system can immediately generate a test report, which speeds up the iteration speed of development-testing-defect correction and improves the overall efficiency of software code development.

[0084] Optionally, code performance metrics refer to data on code execution efficiency collected by the processing system during testing, such as response time, throughput, and resource consumption. By collecting code performance metrics corresponding to the target branch during the execution of the automated test program, the processing system can obtain the performance of the target branch under high load, thereby ensuring the robustness of the software code that passes the test.

[0085] Optionally, a test report refers to a document generated after the automated test program has finished running, which summarizes the execution results of all test cases.

[0086] Optionally, the processing system provides a comprehensive overview of test results by using the test report obtained after the automated test program finishes running and the code performance indicators corresponding to the target branch as the test results of the target branch. This is beneficial for a comprehensive evaluation of the code's quality and stability. Furthermore, the test results serve as the basis for subsequent branch state transitions and resource scheduling decisions, achieving seamless integration between test automation and branch management, reducing manual intervention, and accelerating the software delivery process.

[0087] In one alternative embodiment, the state machine is used to monitor the branch state of the target branch, wherein the branch state is one of the following:

[0088] The "Created" status indicates that the developer has committed all the code involved in the target branch;

[0089] The deployed status indicates that all code included in the target branch has been deployed to the test environment and is awaiting testing.

[0090] The verified status indicates that the test operation corresponding to the target branch has been completed and the test results have met the preset production conditions.

[0091] The "In Production" status indicates that the packaged files corresponding to the target branch have been deployed in the production environment.

[0092] Optionally, branch status refers to different lifecycles of the target branch.

[0093] Optionally, the processing system monitors the branch status of the target branch by setting a state machine, which can clearly track the entire process of the target branch from creation to production, enhance the transparency of the development and testing process, and the state machine can automatically transition and update the branch status according to the test results, reduce the frequency of manual intervention, avoid human errors introduced by manually setting the branch status, and realize the automation and standardization of the branch management process.

[0094] Optionally, the processing system uses a state machine to set different branch states for the target branch. Each branch state represents an independent stage in the development process, which helps developers and project managers intuitively understand the current branch processing progress. At the same time, the target branch can effectively isolate and identify risks at different stages, such as deployment risks and testing risks, through the transition between different branch states. This allows for timely adjustments to the processing strategy. By switching between different branch states, a closed loop is formed from development, testing, verification to production, ensuring that only the target branch that passes testing can enter the production environment, thus improving the overall quality of the delivered software code.

[0095] In summary, the processing system provides an orderly and controllable development process by monitoring and managing branch states through a state machine. This allows for accurate tracking and management of every stage from code writing to release, thereby accelerating development and improving the overall quality of delivered software code.

[0096] In one optional embodiment, after obtaining the test results, if the test results do not meet the preset production conditions, the processing system analyzes the test results to obtain the reason for the test failure of the target branch.

[0097] Optionally, preset production conditions refer to the minimum code quality requirements set by the processing system. The test results of the target branch must meet the preset production conditions before production deployment can proceed.

[0098] Optionally, test result analysis refers to analyzing the test report and code performance metrics obtained after the automated test program has finished running, in order to find out why the conditions for production deployment have not been met.

[0099] Optionally, the processing system can quickly identify the specific reasons for test failure by analyzing the test results when the test results do not meet the preset production conditions, thereby improving the speed of fixing code defects / environment defects.

[0100] Alternatively, the test may fail for one of the following reasons:

[0101] The first presupposed reason is used to characterize the code defect in the target branch;

[0102] The second presupposition is that the test environment used to characterize the target branch has environmental defects.

[0103] Optionally, if the reason for test failure is the first preset reason, the processing system generates a test ticket based on the test result, wherein the test ticket is used to prompt developers to fix the code defect.

[0104] Optionally, the test ticket records at least the specific information of the test failure, such as the error code, the failed test case, and the suggested repair steps. When the test failure reason is the first preset reason, the processing system directly generates a test ticket based on the test results, which speeds up the feedback of code defects, prompts developers to correct code defects in a timely manner, shortens the development-testing-repair cycle, and, by generating test tickets, can track the progress of problem resolution, ensure that code repair measures are implemented in place, and improve the transparency and efficiency of code defect repair.

[0105] Optionally, if the test failure is due to a second preset reason, the processing system performs a rollback operation on the test environment. The rollback operation is used to update the environment configuration parameters of the test environment based on a preset environment snapshot in the environment snapshot library. Then, in the new test environment obtained by performing the rollback operation, the processing system re-executes the test operation on the target branch.

[0106] Optionally, an environment snapshot library stores copies of the test environment configuration parameters at different points in time for rapid recovery of the test environment.

[0107] Optionally, if the test failure is due to the second preset reason, the processing system can restore the test environment to a stable historical state by performing a rollback operation, thereby quickly repairing the test environment and ensuring the continuity and effectiveness of subsequent tests. By performing the rollback, the processing system avoids the resource consumption of rebuilding the test environment, which can save test environment construction costs, especially in scenarios with frequent testing and debugging.

[0108] Optionally, by re-executing the test operation on the target branch in the new test environment obtained after the rollback operation, the processing system can ensure that the target branch is fully verified again after the fix, thereby improving the reliability of the final code. The test failure cause analysis, problem correction, and branch retesting constitute a closed loop of the test process, ensuring the implementation of environmental defect repair measures.

[0109] In summary, when faced with branches that fail to meet test standards, the processing system accelerates the resolution of test failure issues through test result analysis, defect cause classification, and work order feedback / rollback operations.

[0110] In one optional embodiment, after allocating a test environment to the target branch, the processing system first scans the test environment to obtain the test environment's environmental performance indicators and environmental configuration parameters. Then, if the test environment's environmental performance indicators exceed a preset environmental performance threshold or if the test environment's environmental performance indicators differ from the environmental performance indicators of a preset environmental snapshot, an early warning message is generated.

[0111] Optionally, the environmental performance indicators include at least one of the following:

[0112] The first performance metric is used to characterize the operating information of the processor, memory, and disk in the test environment;

[0113] The second performance metric is used to characterize the runtime information of components that interact with the target branch in the test environment;

[0114] The third performance metric is used to characterize the operating information of the server where the test environment is located;

[0115] Optionally, environmental performance indicators refer to quantitative indicators that reflect the current state of the test environment. They are used to monitor and evaluate the health and capabilities of the environment. The processing system sets different environmental performance indicators to achieve the following effects:

[0116] (1) Comprehensive performance coverage: By monitoring performance indicators at different levels, a comprehensive performance evaluation of the test environment is formed, which helps to discover and resolve code defects / environment defects that affect test results in a timely manner.

[0117] (2) Fault prevention and troubleshooting: Real-time monitoring of performance indicators can prevent test failures caused by poor environmental performance, and at the same time, it can provide rich data when test problems occur to support the rapid location of the root cause of test failure.

[0118] Optionally, the processing system provides a proactive early warning mechanism by detecting the environmental performance indicators of the scanned test environment. By setting early warning conditions, when environmental performance indicators reach these conditions, the processing system proactively issues a warning signal to report the anomaly. This helps to intervene and resolve defects in a timely manner before they escalate, reducing uncertainty in code testing and deployment. The processing system ensures consistency between the test environment and the production environment by comparing environmental performance indicators with preset environment snapshots, avoiding the situation where "test passed ≠ production usability." Early warning information can help the team optimize resource allocation or quickly restore the environment when it reaches a critical state, maintaining the continuity and effectiveness of testing.

[0119] As can be seen from the above, this application adopts a dynamic branch management and environment awareness approach. By dynamically binding the environment and driving state transitions based on test results, it achieves the goal of automatically allocating a test environment consistent with the production environment configuration and automatically advancing branches to the production stage. This achieves a high degree of consistency between the test environment and the production environment, improves the processing efficiency of code branches, and solves the technical problem of low efficiency in production delivery of code branches caused by inconsistencies between the test environment and the production environment in the prior art.

[0120] Specifically, this application dynamically allocates a test environment that highly simulates the production environment by intelligently evaluating the priority and environmental requirements of the target branch, thus ensuring the accuracy of the test results. After the test passes and the preset production conditions are met, this application directly deploys the previously verified immutable artifacts (i.e., the packaged files corresponding to the target branch values) to the production environment, avoiding the uncertainty and code delivery delay caused by rebuilding artifacts in the production environment. This achieves the delivery effect of "what is tested is what is deployed", while improving the efficiency and reliability of code from development to production deployment.

[0121] In one alternative embodiment, Figure 3This is an architecture diagram of an optional code branch processing system according to an embodiment of this application. The processing system includes a control layer, an execution layer, and a data layer. The control layer includes Intelligent Branch Routing (IBR), a policy engine, a state machine, and a resource arbitrator; the execution layer includes an Environment Management System (EMS), a CI system, and a CD system; the data layer includes a configuration management database, an immutable artifact repository, a policy rule base, and an environment snapshot library. The functions of each component are described below:

[0122] 1) Environmental Management System:

[0123] The environment management system is the execution engine of the processing system, primarily responsible for the full lifecycle management of the test environment. Its core functions include:

[0124] (1) Environment provisioning function: Supports multiple test environment creation modes. For the environment application needs of regular branches, the environment management system creates a complete clone environment on the cloud server based on the latest production environment snapshot in the environment snapshot library. For the environment application needs of urgent / short-term branches, the environment management system supports rapid incremental environment creation. The overall environment creation process strictly follows the specifications and standards of the production environment, including node configuration, network topology and storage scheme settings.

[0125] (2) Health monitoring function: used to collect the operating indicators of the test environment in real time. The monitoring scope covers the infrastructure layer (e.g., CPU, memory, disk), middleware layer (e.g., database connection pool, message queue) and application layer (e.g., service response time, error rate). When the indicators exceed the threshold, the environment management system will automatically trigger an alarm or repair process.

[0126] (3) Configuration Management Function: The environment management system will periodically scan the environment configuration and compare it with the baseline snapshot. When a deviation is found, different measures will be taken according to the type of deviation. For example, for critical configurations (such as security policies), automated repair scripts will be immediately enforced; for non-critical configurations, a difference report will be generated for manual review.

[0127] 2) Smart Branch Router:

[0128] The intelligent branch router is the control center of the processing system, and its main functions include: branch lifecycle management, environmental scheduling decision-making, and status tracking. Internally, it consists of the following key sub-modules:

[0129] (1) Strategy Engine: It is responsible for executing the predefined business rules in the strategy rule base, such as calculating branch priority and judging the environment allocation strategy. This module adopts declarative rule configuration, supports dynamic loading of strategy adjustment, and can flexibly adjust the decision logic according to business needs.

[0130] (2) State machine: responsible for managing the state transition of branches, defining a clear state transition path: Created → Staging-Deployed → Staging-Verified → Production-Deployed. Each state transition needs to meet specific preconditions and trigger corresponding subsequent actions.

[0131] (3) Resource Arbitration Module: The core functional module of the intelligent branch router, which is used to comprehensively determine the test environment allocation strategy and test task scheduling strategy by combining the rules executed by the comprehensive strategy engine, the current state of the target branch in the state machine and the load of the test environment collected in real time. This module adopts a multi-factor weighted decision algorithm, considering factors including but not limited to business priority, branch timeliness and resource utilization.

[0132] The resource arbitration module is responsible for receiving event notifications from various subsystems through event listening, including test results from the CI system and changes in the environment status of the environment management system. Through event filtering and priority processing mechanisms, it ensures that critical events can be responded to in a timely manner.

[0133] When a developer triggers a pipeline deployment and submits an environment request, the processing system initiates a standardized allocation process. The intelligent branch router first evaluates the priority of the environment request through a policy engine.

[0134] After prioritizing, the intelligent branch router sends an environment creation request to the environment management system. The system then selects an appropriate environment provisioning strategy based on the type of requirement. For example, for basic functional testing, the existing frozen environment is reused; for special needs such as performance testing, a dedicated environment is created. During environment creation, the system strictly adheres to the corresponding version of the production environment snapshot to ensure consistency of configuration parameters between the test and production environments.

[0135] Once the test environment is ready, the environment management system returns the access endpoint information corresponding to the test environment to the intelligent branch router. The intelligent branch router then establishes a binding relationship between the branch and the environment in the configuration management database. At the same time, the environment management system automatically configures network policies to ensure connectivity between the test environment and related components (such as databases, message middleware, and other dependent service components).

[0136] Subsequently, the intelligent branch router triggers the CI system to start the test pipeline. The testing process is divided into three stages: basic testing (unit testing, static analysis), integration testing (component interaction verification), and specialized testing (performance, security, etc.). Each test stage has clear test pass conditions. During the testing process, the CI system collects test results and corresponding performance indicators of the test environment in real time and feeds them back to the intelligent branch router through callback interfaces.

[0137] The intelligent branch router uses a state machine to determine the state transition of code branches based on feedback information. For example, when all necessary test cases pass and environmental metrics meet the requirements, the branch state changes from "under testing" to "verified." For test cases that fail, different measures are taken depending on the cause of the problem. For example, for environmental defects (such as insufficient resource configuration), an automatic repair script is triggered; for code defects, the testing process is terminated and a work order is submitted to notify the developer. The logs and metrics generated throughout the process are stored in the configuration management database for subsequent analysis and optimization.

[0138] Once a branch enters the "verified" state, the processing system waits for the target branch to trigger preset deployment conditions. These preset deployment conditions include time window detection (such as during off-peak business periods), expert approval detection (for critical systems), and other business rule detection processes (such as when dependent systems are ready).

[0139] After the preset production conditions are met, the smart branch router will retrieve the test-passed product data corresponding to the branch from the immutable product repository in the configuration management database. This data includes at least the build ID. Then, it will be deployed in the production environment. The deployment process strictly uses these pre-validated products and prohibits rebuilding, thereby ensuring the consistency between the production environment and the test environment.

[0140] After the production environment is deployed, the processing system will perform basic health checks, including service availability verification and data consistency checks. At the same time, the environment management system will put the original test environment into a frozen state or release it directly. After the relevant environment resources are released, it will be returned to the resource pool for use by other branches.

[0141] remove Figure 3 In addition to the components, the processing system also includes a workflow engine, which is located between the strategy engine and the execution layer and plays the role of "decision executor". The workflow engine executes branch state transitions, triggers environment operations (deployment, rollback) and triggers downstream processes based on the decisions of the strategy engine.

[0142] For example, interaction with the environment management system: Through standardized interfaces, the workflow engine can instruct the environment management system to perform operations such as environment creation, configuration updates, and resource recycling. Each interaction contains a complete operation context, which facilitates problem tracking.

[0143] For example, collaboration with CI / CD systems: the workflow engine triggers the CI system to execute build and test tasks, monitors the task execution status, and uses an event callback mechanism to ensure timely acquisition of execution results.

[0144] For example, collaboration with the configuration management database: all state changes and artifacts generated by operations are synchronized to the configuration management database in real time, and the workflow engine obtains the latest configuration baseline from the configuration management database before executing critical operations.

[0145] 3) Code repository:

[0146] Used to retrieve branch / commit information and perform branch operations (such as creating temporary branches and tagging).

[0147] 4) Continuous Integration / Continuous Deployment (CI / CD) System:

[0148] Used to perform builds, automated tests (in specific environments), deployments, report test results and environment deployment status to the smart branch router, and display them in the pipeline run results.

[0149] 5) Configure and manage the database:

[0150] As the data hub of the system, it is used to store data, which includes at least the following three categories:

[0151] (1) Environment snapshot data: The environment snapshot library stores the complete configuration template of the production environment, including resource definitions, network policies and storage specifications. Each snapshot has a version mark and timestamp, supporting configuration rollback and historical traceability.

[0152] (2) Binding relationship data: used to characterize the mapping relationship between branches, environment and build artifacts. This triple structure mapping relationship representation method is the basis for realizing "what is measured is what is deployed", ensuring full-link traceability from code submission to production deployment.

[0153] (3) Strategy and rule data: Stores dynamically loadable business rules, including environment allocation strategies, test pass standards and release approval processes. These rules support condition judgment and priority settings, and can adapt to the personalized needs of different projects.

[0154] Optionally, the processing system also records all branch state changes, environment operations, test results, deployment decisions, and execution details through monitoring and auditing logs for traceability, auditing, and troubleshooting.

[0155] In one alternative embodiment, Figure 4 This is a schematic diagram of the topology of an optional code branch according to an embodiment of this application. Figure 4 Taking the deployment of new feature branches in the system as an example, the release short branch takes into account development, testing, and deployment functions. Compared with the master main distribution branch, it is more flexible and can support the parallel development of multiple versions in the same stage. The release short branch should be deleted immediately after deployment.

[0156] Optionally, Figure 5 This is a flowchart of an optional code branch release method according to an embodiment of this application. (In conjunction with...) Figure 4 and Figure 5 The code branch processing flow is described below:

[0157] (1) Branch creation and development: Developers create feature branches based on the master branch to develop new features (e.g., features a and b). Among them, the release-20250513 branch needs to be put into production on May 13, and the release-20250515 branch needs to be put into production on May 15.

[0158] (2) Development environment integration and testing: Developers of branches that need to be put into production on May 13 should review the code submitted locally. After the code indicators are reviewed and the code review is passed, basic tests (unit and static analysis) should be performed in the local development environment to quickly find code defects.

[0159] (3) Applying for a production-like environment (i.e., a test environment) to perform testing: During the software development process, when the development team believes that the code review of the new feature has been completed, they will apply for verification in a test environment (a production-like environment). At this time, the intelligent branch router first queries the environment management system to obtain an available test environment. The environment management system will determine the test environment corresponding to the target branch based on the current production environment configuration or snapshot. Subsequently, the intelligent branch router automatically binds the development team's release-20250513 branch to the proxy deployment component, so that the branch status becomes a pending deployment status. This process ensures that the developed features can be fully verified in the test environment, thereby improving the overall development and testing efficiency.

[0160] (4) Automated deployment and testing:

[0161] The CI / CD system will deploy the code of the release-20250513 branch to the specified test environment and mark the environment as occupied. The CI / CD system will then execute a complete automated test suite (integration testing, end-to-end testing, performance testing, security scanning, compliance checks, etc.) on this environment.

[0162] To address the drawback of the release-20250513 branch being deployed to the test environment and requiring long-term use of test environment resources for retesting, thus preventing the production-deployment branch release-20250515 from being tested, the intelligent branch router uses intelligent routing addressing. If there is no available test environment, it creates a new namespace, creates a complete resource topology according to the snapshot template, and configures new DNS (Domain Name System) resolution records pointing to the new Ingress IP. Through dynamic routing policies, the allocation of test environments can be adjusted according to the real-time usage of the test environment, thereby enabling parallel testing of multiple branches and accelerating the overall testing cycle.

[0163] (5) Test results drive decision-making:

[0164] If the test is successful, the CI / CD system will report the successful test result of branch release-20250513 to the smart branch router. The smart branch router will then generate a test report, link the report to the pipeline deployment page, and send an email notification to the developers.

[0165] The policy engine of the smart branch router verifies the test report and checks whether all predefined tests for this environment have passed. If they have passed, the smart branch router updates the status of the release-20250513 branch to verified. After that, the smart branch router automatically captures the exact code version (Commit ID) and the corresponding immutable deployment artifact deployed on the verified branch at this time and stores them in the immutable artifact repository. The smart branch router automatically creates an immutable tag or temporary branch pointing to the Commit ID for this verified status.

[0166] The intelligent branch router waits for the release conditions according to the release strategy (such as rolling release or automatic release after manual approval).

[0167] In the event of a test failure, the CI / CD system reports the failure result to the intelligent branch router. The intelligent branch router's policy engine performs a rollback operation, which automatically rolls back the code deployment on the current branch, restoring the current test environment image to its state before deployment. At the same time, the intelligent branch router updates the status of the release-20250513 branch to Staging-Failed and notifies the relevant personnel via email.

[0168] (6) Production Deployment:

[0169] When the release conditions are met, the release window is open, and the branch has the highest priority, IBR does not rebuild or test. Instead, it directly retrieves the immutable artifact associated with the Staging-Verified state (i.e., the packaged file of the branch code that has passed all tests on the pre-inspection pipeline) from the immutable artifact repository. Then, it safely deploys this artifact to the production environment through the change pipeline. At this point, the deployed artifact is the verified artifact, not a rebuilt artifact from the branch. This ensures, to the greatest extent possible, that the production deployment is a rigorously tested deployment artifact.

[0170] (7) Production validation and branch termination:

[0171] Perform a lightweight smoke test in the production environment and send simulated messages for verification.

[0172] If verification is successful: merge the changes from the release branch back into the master branch, and delete or archive the release branch.

[0173] If verification fails: trigger the production rollback process (rollback to the previous version). After troubleshooting the failure, you need to start from step (3) again.

[0174] This application addresses three major pain points in current software development and delivery processes: environmental discrepancies, delays in human decision-making, and breaks in product consistency. It proposes corresponding solutions. Through dynamic environment mirroring technology, the application can dynamically mirror and deploy the production environment in real time, effectively solving the problem of test environment distortion and ensuring a high degree of consistency between the test and production environments. By binding branches, environments, and tests, it automates the binding of development branches to the test environment, reducing the lag in human decision-making and improving delivery efficiency. Through dynamic routing, frozen environment reuse, and versioned incremental cloning technology, the application monitors the resource usage of the test environment in real time and can clone a new test environment for development and testing when an environment is occupied. Furthermore, the immutable product penetration deployment technology ensures that the code version verified in the test environment is completely consistent with the production deployment version, avoiding the problem of "testing what is not deployed," thus achieving the ideal state of "testing is production, zero discrepancies in release."

[0175] Example 2

[0176] This application embodiment can also provide a code branch processing device. It should be noted that the code branch processing device of this application embodiment can be used to execute the code branch processing method provided in this application embodiment. The code branch processing device provided in this application embodiment will be described below.

[0177] According to an embodiment of this application, an apparatus for implementing the above-described code branching processing method is also provided. Figure 6This is a schematic diagram of an optional code branch processing apparatus according to an embodiment of this application, such as... Figure 6 As shown, the device includes: a target determination unit 601, a test environment allocation unit 602, a test unit 603, and a production deployment unit 604.

[0178] Optionally, the target determination unit 601 is used to determine the branch priority and environment configuration strategy of the target branch based on the development requirements of the target branch, wherein the target branch is the code branch to be tested submitted by the developer; the test environment allocation unit 602 is used to allocate a test environment to the target branch based on the branch priority and environment configuration strategy, wherein the environment configuration parameters of the test environment are the same as the environment configuration parameters of the production environment; the testing unit 603 is used to perform test operations on the target branch in the test environment and obtain test results; the production deployment unit 604 is used to deploy the packaged file corresponding to the target branch to the production environment when the test results meet the preset production conditions, and switch the branch status of the target branch to the production status, wherein the packaged file includes at least the branch identifier of the target branch, the code compilation file, and the environment configuration parameters.

[0179] In an optional embodiment, the target determination unit 601 includes a parsing subunit and a first determination subunit.

[0180] Optionally, a parsing subunit is used to parse the development requirements and obtain parsing results, wherein the parsing results include at least one of the following: business priority, used to characterize the priority of the business implemented by the target branch; branch timeliness, used to characterize the duration of the development task corresponding to the target branch; resource usage, used to characterize the amount of resources required to run all the code included in the target branch; and a first determining subunit, used to determine the branch priority of the target branch based on the parsing results and preset rules in the strategy rule base.

[0181] In one optional embodiment, the target determination unit 601 includes: an acquisition subunit and a second determination subunit.

[0182] Optionally, an acquisition subunit is used to acquire test requirements for development needs, wherein the test requirements include at least one of the following: basic tests, used to characterize static analysis and unit testing of the code included in the target branch; integration tests, used to characterize testing the interaction process between the target branch and components; specialized tests, used to characterize testing the security and performance level of the target branch; and a second determination subunit is used to determine the environment configuration strategy of the target branch based on the test requirements and preset rules in the strategy rule base.

[0183] In one optional embodiment, the test unit 603 includes: a third determination subunit, a program execution subunit, an indicator acquisition subunit, and a test result determination subunit.

[0184] Optionally, the third determining subunit is used to determine test cases for the target branch based on the test requirements corresponding to the target branch, wherein the test cases include at least the execution steps and expected results of the test operations; the program running subunit is used to run the automated test program corresponding to the test cases in the test environment; the metric collection subunit is used to collect code performance metrics corresponding to the target branch during the execution of the automated test program; and the test result determining subunit is used to take the test report obtained after the automated test program finishes running and the code performance metrics corresponding to the target branch as the test results of the target branch.

[0185] In one alternative embodiment, the state machine is used to monitor the branch state of the target branch, wherein the branch state is one of the following:

[0186] The "Created" status indicates that the developer has committed all the code involved in the target branch;

[0187] The deployed status indicates that all code included in the target branch has been deployed to the test environment and is awaiting testing.

[0188] The verified status indicates that the test operation corresponding to the target branch has been completed and the test results have met the preset production conditions.

[0189] The "In Production" status indicates that the packaged files corresponding to the target branch have been deployed in the production environment.

[0190] In one optional embodiment, the code branch processing apparatus further includes: a parsing unit, a test ticket generation unit, a rollback operation unit, and a retesting unit.

[0191] Optionally, the parsing unit is used to parse the test results to obtain the test failure reason for the target branch when the test results do not meet the preset production conditions. The test failure reason is one of the following: a first preset reason, used to indicate that there is a code defect in the target branch; a second preset reason, used to indicate that there is an environment defect in the test environment of the target branch; a test ticket generation unit is used to generate a test ticket based on the test results when the test failure reason is the first preset reason. The test ticket is used to prompt developers to fix the code defect; a rollback operation unit is used to perform a rollback operation on the test environment when the test failure reason is the second preset reason. The rollback operation is used to update the environment configuration parameters of the test environment based on the preset environment snapshot in the environment snapshot library; and a retesting unit is used to re-execute the test operation on the target branch in the new test environment obtained by performing the rollback operation.

[0192] In one optional embodiment, the code branch processing device further includes a test environment scanning unit and an early warning information generation unit.

[0193] Optionally, the test environment scanning unit is used to scan the test environment to obtain the environment performance indicators and environment configuration parameters of the test environment. The environment performance indicators include at least one of the following: a first performance indicator, used to characterize the operating information of the processor, memory, and disk of the test environment; a second performance indicator, used to characterize the operating information of the components that interact with the target branch in the test environment; and a third performance indicator, used to characterize the operating information of the server where the test environment is located. The early warning information generation unit is used to generate early warning information when the environment performance indicators of the test environment exceed a preset environment performance threshold or when the environment performance indicators of the test environment are different from the environment performance indicators of a preset environment snapshot.

[0194] As can be seen from the above, this application adopts a dynamic branch management and environment awareness approach. By dynamically binding the environment and driving state transitions based on test results, it achieves the goal of automatically allocating a test environment consistent with the production environment configuration and automatically advancing branches to the production stage. This achieves a high degree of consistency between the test environment and the production environment, improves the processing efficiency of code branches, and solves the technical problem of low efficiency in production delivery of code branches caused by inconsistencies between the test environment and the production environment in the prior art.

[0195] Specifically, this application dynamically allocates a test environment that highly simulates the production environment by intelligently evaluating the priority and environmental requirements of the target branch, thus ensuring the accuracy of the test results. After the test passes and the preset production conditions are met, this application directly deploys the previously verified immutable artifacts (i.e., the packaged files corresponding to the target branch values) to the production environment, avoiding the uncertainty and code delivery delay caused by rebuilding artifacts in the production environment. This achieves the delivery effect of "what is tested is what is deployed", while improving the efficiency and reliability of code from development to production deployment.

[0196] It should be noted that the target determination unit 601, test environment allocation unit 602, test unit 603, and production deployment unit 604 mentioned above correspond to steps S201 to S204 in the method embodiment. The instances and application scenarios implemented by the above units and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and run in the computer terminal 10 provided in the embodiment.

[0197] Example 3

[0198] Embodiments of this application can also provide an electronic device. Figure 7 This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 7 As shown, the electronic device includes: one or more ( Figure 7 (Only one is shown) processor 702, memory 704, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0199] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and devices in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, to implement the above-mentioned code branch processing method.

[0200] The memory may include high-speed random access memory (RAM), and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0201] The processor can access information and applications stored in memory via a transmission device to perform the following steps: Based on the development requirements of the target branch, determine the branch priority and environment configuration strategy of the target branch, where the target branch is the code branch submitted by the developer for testing; based on the branch priority and environment configuration strategy, allocate a test environment to the target branch, where the environment configuration parameters of the test environment are the same as those of the production environment; perform test operations on the target branch in the test environment to obtain test results; if the test results meet the preset production conditions, deploy the packaged file corresponding to the target branch to the production environment and switch the branch status of the target branch to the production state, where the packaged file includes at least the branch identifier of the target branch, the code compilation file, and the environment configuration parameters.

[0202] This application provides a code branch processing scheme. It employs dynamic branch management and environment awareness, using dynamic environment binding and test result-driven state transitions to automatically allocate test environments consistent with production environment configurations and automatically advance branches to the production stage. This achieves a high degree of consistency between the test and production environments, improves code branch processing efficiency, and solves the technical problem of low efficiency in production delivery of code branches due to inconsistencies between the test and production environments in existing technologies.

[0203] Specifically, this application dynamically allocates a test environment that highly simulates the production environment by intelligently evaluating the priority and environmental requirements of the target branch, thus ensuring the accuracy of the test results. After the test passes and the preset production conditions are met, this application directly deploys the previously verified immutable artifacts (i.e., the packaged files corresponding to the target branch values) to the production environment, avoiding the uncertainty and code delivery delay caused by rebuilding artifacts in the production environment. This achieves the delivery effect of "what is tested is what is deployed", while improving the efficiency and reliability of code from development to production deployment.

[0204] Those skilled in the art will understand that Figure 7 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, PDAs, mobile internet devices, PADs, and other terminal devices. Figure 7 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 7 The different configurations shown.

[0205] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0206] Example 4

[0207] Embodiments of this application may also provide a storage medium.

[0208] Optionally, in this embodiment of the application, the storage medium can be used to store the program code executed by the code branch processing method provided in the above method embodiment.

[0209] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0210] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform processing method steps of code branches.

[0211] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0212] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0213] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0214] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0215] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0216] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0217] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method of processing a code branch, characterized by, The method comprises the following steps: determining the branch priority and the environment configuration strategy of the target branch based on the development demand of the target branch, wherein the target branch is a branch of code to be tested submitted by a developer; allocating a test environment for the target branch based on the branch priority and the environment configuration strategy, wherein the environment configuration parameters of the test environment are the same as those of the production environment; performing a test operation on the target branch in the test environment to obtain a test result; deploying a packaged file corresponding to the target branch to the production environment and switching the branch state of the target branch to a production state if the test result meets a preset production condition, wherein the packaged file comprises at least the branch identifier, the code compilation file and the environment configuration parameters of the target branch.

2. The method of processing a code branch according to claim 1, wherein, determining the branch priority of the target branch based on the development demand of the target branch, comprising: parsing the development demand to obtain a parsing result, wherein the parsing result comprises at least one of the following: a business priority, used to represent the priority of the business implemented by the target branch; a branch timeliness, used to represent the time length of the development task corresponding to the target branch; a resource usage, used to represent the resource amount required by all the codes included in the target branch; determining the branch priority of the target branch based on the parsing result and a preset rule in a strategy rule library.

3. The method of processing a code branch according to claim 1, wherein, determining the environment configuration strategy of the target branch based on the development demand of the target branch, comprising: obtaining a test demand of the development demand, wherein the test demand comprises at least one of the following: basic testing, used to represent static analysis and unit testing of the codes included in the target branch; integration testing, used to represent testing of the interaction process between the target branch and components; special testing, used to represent testing of the security and performance level of the target branch; determining the environment configuration strategy of the target branch based on the test demand and a preset rule in a strategy rule library.

4. The method of processing a code branch of claim 1, wherein, performing a test operation on the target branch in the test environment to obtain a test result, comprising: determining a test case of the target branch based on the test demand corresponding to the target branch, wherein the test case comprises at least the execution steps and the expected result of the test operation; running an automated test program corresponding to the test case in the test environment; collecting the code performance indicators corresponding to the target branch during the running of the automated test program; taking the test report obtained after the running of the automated test program and the code performance indicators corresponding to the target branch as the test result of the target branch.

5. The method of processing a code branch of claim 1, wherein, A state machine is used to monitor the branch state of the target branch, wherein the branch state is one of the following: a created state, used to represent that the developer has submitted all the codes related to the target branch; a deployed state, used to represent that all the codes included in the target branch have been deployed into the test environment for testing. A verified state, used to represent that a test operation corresponding to the target branch is completed, and the test result reaches the preset production condition; A production state, used to represent that a packaged file corresponding to the target branch is deployed in the production environment.

6. The method of processing a code branch of claim 1, wherein, After obtaining the test result, the processing method of the code branch further includes: In the case where the test result does not reach the preset production condition, the test result is analyzed to obtain a test failure reason of the target branch, wherein the test failure reason is one of: A first preset reason, used to represent that the target branch has a code defect; A second preset reason, used to represent that a test environment of the target branch has an environment defect; In the case where the test failure reason is the first preset reason, a test work order is generated based on the test result, wherein the test work order is used to prompt the developer to repair the code defect; In the case where the test failure reason is the second preset reason, a rollback operation is performed on the test environment, wherein the rollback operation is used to update environment configuration parameters of the test environment based on a preset environment snapshot in an environment snapshot library; In a new test environment obtained by performing the rollback operation, the test operation is re-executed on the target branch.

7. The method of processing a code branch of claim 1, wherein, After the test environment is allocated for the target branch, the processing method of the code branch further includes: The test environment is scanned to obtain environment performance indicators and environment configuration parameters of the test environment, wherein the environment performance indicators include at least one of: A first performance indicator, used to represent running information of a processor, memory and disk of the test environment; A second performance indicator, used to represent running information of a component interacting with the target branch in the test environment; A third performance indicator, used to represent running information of a server where the test environment is located; In the case where the environment performance indicators of the test environment exceed a preset environment performance threshold / the environment performance indicators of the test environment are different from environment performance indicators of a preset environment snapshot, a warning information is generated.

8. A code branch processing apparatus, characterized by comprising: Comprise: A target determination unit, configured to determine a branch priority and an environment configuration strategy of a target branch based on a development requirement of the target branch, wherein the target branch is a to-be-tested code branch submitted by a developer; A test environment allocation unit, configured to allocate a test environment for the target branch based on the branch priority and the environment configuration strategy, wherein environment configuration parameters of the test environment are the same as environment configuration parameters of a production environment; A test unit, configured to execute a test operation on the target branch in the test environment to obtain a test result; A production deployment unit, configured to deploy a packaged file corresponding to the target branch to a production environment and switch a branch state of the target branch to a production state in the case where the test result reaches a preset production condition, wherein the packaged file at least includes a branch identifier, a code compilation file and environment configuration parameters of the target branch.

9. A computer program product, characterised in that, The computer program product comprises a computer program which, when executed, controls the computer program product to perform the processing method of any one of claims 1 to 7.

10. An electronic device, comprising: One or more processors and a memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the processing method of any one of claims 1 to 7.

Images