Method and apparatus for managing or performing software version release tasks

Abstract

The present application relates to the technical field of software version automatic publishing and intelligent scheduling, in particular to a method for managing software version publishing tasks, a method for executing software version publishing tasks, a computer system implementing the above methods, and a non-transitory computer storage medium storing computer programs / instructions implementing the above methods. The method for planning software version publishing tasks comprises: determining a plurality of software versions to be published; optimizing the publishing arrangement of the plurality of software versions to be published within a set of available publishing time windows, wherein the objective optimization function for optimization is a linear combination of the following items: the overall delivery value of the plurality of software versions to be published, the overall delivery cycle, and the overall change risk caused by publishing changes within the available publishing time windows, wherein the constraint conditions for optimization at least include that the overall delivery cycle and the overall change risk do not exceed the respective upper limit values.

Description

Technical Field

[0001] This application relates to the field of automated software release and intelligent scheduling technology, and in particular to a method for managing software release tasks, a method for executing software release tasks, a computer system for implementing the above method, and a non-transitory computer storage medium for storing computer programs / instructions for implementing the above method. Background Technology

[0002] Software release is a crucial link between R&D results and business implementation throughout the entire software development lifecycle. Its core purpose is to securely and stably deliver software versions with clear business requirements (such as feature iteration and experience optimization) or technical changes (such as performance upgrades and vulnerability fixes) to the target operating environment through standardized build packaging, multi-dimensional automated testing, and tiered environment deployment.

[0003] With the deepening of digital transformation, software application scenarios are becoming increasingly diversified—from single-terminal deployment to multi-terminal compatibility, from local environments to hybrid cloud architectures. Simultaneously, the scale of software development continues to expand, the number of modules under microservice decomposition is surging, and the complexity of cross-team collaborative tasks is rising. Traditional manual or semi-automated version release methods are no longer adequate to meet these demands. These traditional methods not only face problems such as reliance on human experience for task scheduling and low efficiency in resource coordination, but are also prone to risks such as version conflicts and deployment failures due to human error. Summary of the Invention

[0004] One object of this application is to provide a method and apparatus for planning and executing software release tasks, which has the advantages of high execution efficiency and low resource consumption.

[0005] According to one aspect of this application, a method for planning software version release tasks is provided, comprising:

[0006] Step A. Identify multiple software versions to be released, A1…A m ;as well as

[0007] Step B. Optimize the multiple software versions A1…A to be released. m Within a set of available release time windows W1…W n Release schedule X within the scope,

[0008] Wherein, the objective optimization function maxF(X) used for the optimization is a linear combination of the following terms: the plurality of software versions to be released A1…A m The total delivery value V(X), the total delivery cycle T(X), and the changes due to the changes in the release time window W1…W n The overall change risk R(X) arising from the release within the period,

[0009] The constraints used for the optimization include at least the overall delivery cycle T(X) not exceeding the upper limit T0 and the overall change risk R(X) not exceeding the upper limit R0.

[0010] According to another aspect of this application, a computer system is provided, comprising:

[0011] At least one memory;

[0012] At least one processor; and

[0013] A computer program / instruction stored in the memory and executable on the processor, the execution of which results in the following operations:

[0014] Operation A. Identify multiple software versions to be released, A1…A m ;as well as

[0015] Operation B. Optimize the multiple software versions A1…A to be released. m Within a set of available release time windows W1…W n Release schedule X within the scope,

[0016] Wherein, the objective optimization function maxF(X) used for the optimization is a linear combination of the following terms: the plurality of software versions to be released A1…A m The total delivery value V(X), the total delivery cycle T(X), and the changes due to the changes in the release time window W1…W n The overall change risk R(X) arising from the release within the period,

[0017] The constraints used for the optimization include at least the overall delivery cycle T(X) not exceeding the upper limit T0 and the overall change risk R(X) not exceeding the upper limit R0.

[0018] According to another aspect of this application, a method for performing a software version release task is provided, comprising:

[0019] Retrieve multiple software versions A1…A within the current release time window W that are yet to be released. k ;as well as

[0020] Optimize the multiple software versions A1…A to be released k The release order Y within the current release time window W; and

[0021] The multiple software versions A1…A to be released are executed in an optimized release order. k The release,

[0022] Wherein, the objective optimization function used for the optimization is min∑ j∈H y j H represents the multiple software versions A1…A to be released. k A collection of software versions to be released that have defined attributes, y i The release sequence number of the software versions to be released in set H within the current release time window W.

[0023] The constraints used for the optimization include at least the plurality of software versions A1…A to be released. k The delivery cycle T'(X) does not exceed the upper limit T'0.

[0024] According to another aspect of this application, a computer system is provided, comprising:

[0025] At least one memory;

[0026] At least one processor; and

[0027] A computer program / instruction stored in the memory and executable on the processor, the execution of which results in the following operations:

[0028] Retrieve multiple software versions A1…A within the current release time window W that are yet to be released. k ;as well as

[0029] Optimize the multiple software versions A1…A to be released k The release order Y within the current release time window W; and

[0030] The multiple software versions A1…A to be released are executed in an optimized release order. k The release,

[0031] Wherein, the objective function of the optimization is min∑ j∈H y j H represents the multiple software versions A1…A to be released. k A collection of software versions to be released that have defined attributes, y i The release sequence number of the software versions to be released in set H within the current release time window W.

[0032] The constraints used for the optimization include at least the plurality of software versions A1…A to be released. k The overall delivery cycle T'(X) does not exceed the upper limit T'0.

[0033] According to another aspect of this application, a non-transitory computer-readable storage medium is provided, wherein a computer program / instructions are stored therein, characterized in that the steps of the method described above are performed by running the computer program / instructions by a processor.

[0034] In some embodiments of this application, by transforming the planning and execution of software version release tasks into a constrained optimization problem, automatic scheduling and deployment of software releases are achieved, improving execution efficiency and enabling adaptation to large-scale complex scenarios. Attached Figure Description

[0035] The above and / or other aspects and advantages of this application will become clearer and more readily understood from the following description taken in conjunction with the accompanying drawings, in which the same or similar elements are denoted by the same reference numerals. The drawings include:

[0036] Figure 1 This is a flowchart of a method for managing software version release tasks according to one embodiment of this application.

[0037] Figure 2 This is a flowchart of a method for planning software version release tasks according to another embodiment of this application.

[0038] Figure 3 This is a flowchart of a method for performing a software version release task according to another embodiment of this application.

[0039] Figure 4 This is a schematic block diagram of a typical computer system. Detailed Implementation

[0040] The present application will now be described more fully with reference to the accompanying drawings, which illustrate exemplary embodiments thereof. However, the present application may be implemented in various forms and should not be construed as being limited to the embodiments given herein. The foregoing embodiments are intended to make the disclosure herein complete and thorough, so as to more fully convey the scope of protection of the present application to those skilled in the art.

[0041] In this application, terms such as “comprising” and “including” indicate that, in addition to the units and steps that are directly and explicitly stated in the specification and claims, the technical solution of this application does not exclude the presence of other units and steps that are not directly or explicitly stated.

[0042] Unless otherwise specified, terms such as “first” and “second” do not indicate the order of units in terms of time, space, size, etc., but are merely used to distinguish between units.

[0043] In some embodiments of this application, by using constrained optimization problems to describe the needs in application scenarios such as planning and scheduling of software version release tasks, and by using optimization algorithms to solve the corresponding constrained optimization problems, automatic scheduling and automatic arrangement of software version releases are realized, thereby improving operational efficiency and reducing the consumption of computing resources.

[0044] Figure 1 This is a flowchart of a method for managing software version release tasks according to one embodiment of this application.

[0045] Figure 1 The process shown begins at step 110. In this step, the computer system (whose specific product form could be a one-stop software release platform) acquires relevant data for the software version to be released. This relevant data includes, but is not limited to, version number, deployment time, specified release time (optional), readiness status and readiness time, relationships between versions, urgency, complexity, and importance. Optionally, the relevant data also includes resources available for software version release (e.g., computing resources and human resources).

[0046] In step 110, optionally, the computer system may also process the acquired data, such as including but not limited to data verification, preprocessing of missing values ​​and outliers.

[0047] Then, in step 120, the computer system obtains the release time window available for publishing the software version (hereinafter referred to as the "available release time window"). A time period can be divided into multiple time segments, each corresponding to a release time window. For example, the time period from 9:00 AM to 5:00 AM the next day can be divided into multiple time segments such as 9:00 AM - 12:00 PM, 12:00 PM - 6:00 PM, 6:00 PM - 11:00 PM, and 11:00 PM - 5:00 AM. The available time window can be determined according to the specific application scenario. For example, for important online applications, updates and releases should avoid peak morning and evening hours, so the available time window can be determined as a window after 11:00 PM; as another example, batch clearing applications should avoid the day-to-day or reconciliation distribution periods, so a release time window covering 9:00 AM is more appropriate.

[0048] After step 120, Figure 1 The process shown proceeds to step 130. In this step, the computer system completes the planning of the software version release task. The planning mentioned here refers to allocating corresponding release time windows for multiple software versions to be released under specific optimization objectives and constraints. The specific implementation method of the planning will be discussed below. Figure 2 Provide a detailed description.

[0049] Then, proceeding to step 140, for each release time window, the computer system executes the release of the software version to be released within that window. Optionally, after executing step 140, Figure 2 The illustrated process returns to one of steps 110–130. The release described here involves specifying a release order for multiple software versions to be released within a release time window under specific optimization objectives and constraints, and performing release operations in that order. Specific implementation details of the release will be discussed below. Figure 3 Provide a detailed description.

[0050] Figure 2 This is a flowchart of a method for planning software version release tasks according to another embodiment of this application.

[0051] Figure 2 The process shown begins at step 201. In this step, the computer system determines multiple software versions to be released. For example, the computer system may obtain a list input by the user containing m software versions to be released (hereinafter referred to as A1…A1). m (A list of items.)

[0052] Then proceed to step 202, where the computer system optimizes multiple software versions A1…A1 to be released. m Within a set of available release time windows (hereinafter referred to as W1…W) n The release schedule X within ) . In this embodiment, the available release time windows W1…W can be obtained using the aforementioned step 120. n This is obtained in step 120 above. The release schedule mentioned here refers to the release time window W1…W n The middle part represents software version A1…A m Each allocation corresponds to a release time window.

[0053] The optimization methods are described in detail below.

[0054] In some specific implementations, the objective optimization function max F(X) used for optimization can be a linear combination of the following: multiple software versions to be released A1…A m The total delivery value V(X), the total delivery cycle T(X), and the changes due to the changes in the release time window W1…W n The overall change risk R(X) caused by the release within the scope. That is, the objective optimization function max F(X) can be expressed as:

[0055] max F(X)=ω1V(X)+ω2T(X)+ω3R(X) (1)

[0056] ω1+ω2+ω3=1 (2)

[0057] ω1>0, ω2<0, ω3<0 (3)

[0058] Wherein, ω1, ω2 and ω3 are the weights of the total delivery value V(X), the total delivery cycle T(X) and the total change risk R(X), respectively, which can be determined through experiments.

[0059] Optionally, the total delivery value V(X) can be determined as the software version A to be released under release arrangement X. i The publication value V of (i=1…m) i The sum of . Furthermore, the release value V described here. i Based on the software version A to be released i The degree of importance assigned I i and urgency level E i Sure.

[0060] For example, importance can be divided into 5 levels, identified by Ia, Ib, Ic, Id, and Ie, with importance increasing sequentially. Similarly, urgency can be divided into 3 levels, identified by Ea, Eb, Ec1, and Ec2. For instance, a software version that needs to be released as soon as possible and whose release value decreases over time can be assigned an urgency level of Ea, and its release value V(t) can be expressed as follows:

[0061] V(t) = V0a -kt (4a)

[0062] Where V(0) is the basic release value determined based on importance, t is time, a and k are positive constants, and 0 < a < 1.

[0063] Alternatively, by way of example, a software version without special time-sensitive requirements (and therefore whose release value is essentially unchanged over time) can be assigned an urgency level Eb, whose release value V(t) can be expressed, for example, as:

[0064] V(t)=V0 (4b)

[0065] Alternatively, by way of example, an urgency level Ec1 can be assigned to a software version that needs to be released on a specified date (so that its release value jumps between the specified date and other dates), and its release value V(t) can be expressed, for example, as:

[0066]

[0067] Where t0 is the specified date.

[0068] Alternatively, by another example, an urgency level Ec2 can be assigned to a software version that needs to be released before a specified date (so that its release value jumps before and after the specified date), and its release value V(t) can be expressed as:

[0069]

[0070] In some specific implementations, the overall delivery cycle T(X) is determined as the time from multiple pending software versions A1…A under release schedule X. m The first software version was released, followed by multiple software versions A1…A m The time taken to complete the release of the last software version in the project.

[0071] Changing the original release schedule for a software version may result in the software version, as well as other software versions, being unable to be released on time. In some specific implementations, under release schedule X, for release time windows W1…W n Each window W in j This allows you to identify the individual change risk (hereinafter referred to as R) arising from changes to one or more software version releases within this window. j Optionally, the individual change risk R j At least based on the release time window W j The number of software versions to be released, urgency factors, and complexity factors within the scope are used to determine this. Typically, individual change risk R... j It increases with increasing quantity, urgency, and complexity. For example, the urgency factor can be determined as the number of publications within the time window W. j Software versions with a higher urgency level (e.g., the aforementioned Ea level) are relative to those released within the W release window. j The percentage of software versions within a given timeframe, and the complexity factor can be determined as the percentage within the release window W. j The number of time-related relationships between software versions within a given timeframe, including but not limited to sequential and simultaneous releases. In other specific implementations, the release time window W1…W n The maximum value of the individual change risk is determined as the overall change risk R(X).

[0072] In some specific implementations, the constraints used for optimization include at least the overall delivery cycle T(X) not exceeding the upper limit T0 (i.e., T(X) ≤ T0) and the overall change risk R(X) not exceeding the upper limit R0 (i.e., R(X) ≤ R0).

[0073] In addition to the constraints mentioned above, some specific implementations may also include time constraints and resource constraints. Optionally, time constraints may include one or more of the following: multiple software versions to be released are released on a specified date, released before a specified date, released after a specified date, two or more of the multiple software versions to be released are released sequentially or simultaneously, and multiple software versions to be released are prohibited from being released on a set date. Additionally, resource constraints may be defined as an upper limit on the number of software versions released each day.

[0074] In some specific implementations, a genetic algorithm can be used to solve the objective optimization function max F(X) defined by equations (1) to (3) under the above constraints to obtain multiple software versions A1…A to be released. m Optimal release schedule X best Optionally, a non-dominated sorting genetic algorithm II (meme NSGA-II) with local search can be used first to find a set of feasible solutions to the Pareto front that satisfy all constraints. Then, based on this front, a "preference region" that best meets the optimization objectives (maximizing the overall delivery value V(X), minimizing the overall delivery cycle T(X), and minimizing the overall change risk R(X)) can be selected. The weights corresponding to this region can then be backfitted as the weights ω1, ω2, and ω3 of the objective optimization function in equation (1), thereby transforming the multi-objective constrained optimization problem into a single-objective constrained optimization problem. In the subsequent optimization of the release schedule, the meme algorithm (genetic algorithm with local search) can be used to quickly solve the objective optimization function with weights ω1, ω2, and ω3 determined in the above manner.

[0075] It should be noted that in real-world software release scenarios, even with the same overall delivery value, overall delivery cycle, and overall change risk, different release schedules may exhibit significant differences in resource consumption. To achieve a balance between delivery value, release cycle, and change risk while effectively avoiding excessive resource consumption (e.g., computing and infrastructure resources) caused by release schedules, some specific implementations, in addition to the overall delivery value V(X), overall delivery cycle T(X), and overall change risk R(X), also introduce an overall resource consumption function C(X) into the objective optimization function to characterize the software versions A1…A1 to be released under release schedule X. m During the release time window W1…W n The amount of resources consumed by the internal deployment (e.g., including computing resources). In this case, the objective function maxF(X) can be expressed as:

[0076] max F(X)=ω1V(X)+ω2T(X)+ω3P(X)+ω4C(X) (5)

[0077] ω1+ω2+ω3+ω4=1 (6)

[0078] ω1>0, ω2<0, ω3<0, ω4<0 (7)

[0079] The meanings of ω1, ω2 and ω3 are the same as above, and ω4 is the weight of the overall resource consumption function C(X), which can also be determined experimentally.

[0080] Optionally, the total resource consumption C(X) can be determined as the aggregation of resource consumption within each release time window, i.e.:

[0081]

[0082] Among them, C j To be in the release time window W j Resource consumption required to execute software version release tasks.

[0083] Optionally, resource consumption within each release time window can be determined by the following formula:

[0084]

[0085] Where α and β are configurable weights, D i P represents the complexity of the software version (e.g., code size). j The concurrency stacking factor is used to characterize the peak resource penalty caused by concurrent deployments. For example, the concurrency stacking factor P... j It can be defined as window W j Number of software versions released internally, N j Nonlinear functions, for example:

[0086] P j =N j logN j (10a)

[0087] or

[0088]

[0089] By incorporating the minimization of resource consumption into the optimization objective, high-value but unsustainable release schedules can be avoided, and resource smoothing can be achieved under multiple release time windows and parallel release of multiple versions.

[0090] It should be noted that for the objective optimization function defined by equation (5) above, the total delivery value V(X), total delivery cycle T(X), total change risk R(X), and constraints can have the same characteristics as the objective optimization function defined by equation (1) above, which will not be elaborated here. In addition, the aforementioned method of meme NSGA-II → preference region → weight back-inference can also be extended to the objective optimization function defined by equation (5) above.

[0091] After performing step 202, Figure 2 The process proceeds to step 203. In this step, the computer system determines the type of the new software version to be released. This determination may be based on the importance and urgency of the software version. For example, software versions with an importance level of Ia and an urgency level of Ec1 may be classified as a first type that should be prioritized or fixed; software versions with an importance level of Ie and an urgency level of Eb or Ec2 may be classified as a second type that can be flexibly arranged; and the remaining software versions may be classified as a third type that should be fixed as much as possible.

[0092] Then, steps 204 and 205 are performed to process different types of software versions accordingly. Specifically, in step 204, the computer system optimizes software version A in the manner described in step 202. 1' …A m' Software versions of type two and type three are available within a set of release time windows W 1' …W n' The release schedule X' within the window. For example, the release time window W. 1' …W n' Following the release time window W1…W n after.

[0093] In step 205, the computer system will release multiple software versions A1…A1 to be released. m The software version has not yet been released and has a second type of software version and software version A. 1' …A m' The software versions of type 1 are merged to obtain the merged software version A to be released. 1” …A m” .

[0094] After performing step 205, Figure 2 The process shown proceeds to step 206. In this step, the computer system optimizes the merged software versions A1"...Am" to be released within a set of available release time windows, as described in step 202. 1” …W n” The release schedule within the window is X. For example, the release time window is W.1” …W n” Included in the publication time window W1…W n This may be within or related to the release time window W1…W n overlapping.

[0095] Figure 3 This is a flowchart of a method for performing a software version release task according to another embodiment of this application.

[0096] Figure 3 The process shown begins at step 301. In this step, the computer system obtains the k software versions to be released within the current release time window W (hereinafter referred to as A1…A1). k For example, a computer system may retrieve software versions A1…A to be released from a storage device. k The list.

[0097] Then proceed to step 302, where the computer system optimizes multiple software versions A1…A1 to be released. k The release order Y within the current release time window. The release order described here covers scenarios such as sequential and simultaneous releases of software versions.

[0098] The optimization methods are described in detail below.

[0099] In some specific implementations, the objective function used for optimization can be expressed as:

[0100] min∑ j∈H y j (11)

[0101] Where H represents multiple software versions A1…A to be released. k A collection of software versions to be released with defined attributes, y i This is the release sequence number of the software versions to be released in set H within the current release time window W. Optionally, the attributes of the software versions include, but are not limited to, release priority, release failure risk, and rollback difficulty. Accordingly, software versions with one or more of the following set attributes can be categorized into set H: high release priority, high release failure risk, and high rollback difficulty.

[0102] In some other implementations, the constraints used for optimization include at least the delivery cycle T'(X) not exceeding an upper limit T'0 (i.e., T'(X) ≤ T'0). Optionally, the delivery cycle T'(X) is determined as the number of software versions A1…A1 to be released under the release order Y. k The first software version was released, followed by multiple software versions A1…A k The time taken to complete the release of the last software version in the project.

[0103] In addition to the constraints mentioned above, some specific implementations may also include time constraints and resource constraints. Optionally, time constraints may include multiple software versions A1…A to be released. k Two or more software versions can be released sequentially or simultaneously. Alternatively, resource constraints can be defined as an upper limit on the number of software versions released at any given time.

[0104] In some specific implementations, a genetic algorithm can be used to optimize the objective function min∑ under the above constraints. j∈H y j Solve to obtain multiple software versions A1…A to be released. k Optimal release order Y best .

[0105] After performing step 302, Figure 3 The process shown proceeds to step 303. In this step, the computer system follows the optimized release sequence Y. best Execute multiple pending software versions A1…A k The release.

[0106] In real-world scenarios, releasing a software version involves complex operational steps, including but not limited to installing virtual machine / container applications, maintaining environment parameters, updating NGINX resources, pushing CDN network nodes, database DDL / DML operations, big data processing, configuring public services, enabling / disabling health switches and other platform-related operations, as well as personalized operations such as inserting special records into the version. Existing continuous deployment devices only handle the automated installation of software and typically require additional implementation documents to handle other operational steps.

[0107] In some specific implementations, a one-stop automated software publishing device is used to publish software according to the publishing order Y. best Execute software version A1…A k The software automatic release device supports automatic parsing of version packages, completing the sequential installation of different resources within the version, achieving a one-stop release experience without the need to submit additional implementation requests. When installation anomalies occur, it can automatically collect anomaly information and send it to the anomaly handling center, which analyzes, makes decisions, issues notifications, and initiates relevant handling operations, such as rollback and retry. Furthermore, the device can uniformly monitor the execution status of software version release tasks and proactively alert when anomalies occur. Moreover, after the software version release task is completed, the device can also summarize and generate a result report and push it to relevant parties.

[0108] Figure 4 This is a schematic block diagram of a typical computer system. For example... Figure 4 As shown, computer system 40 includes memory 410 (e.g., non-volatile memory such as flash memory, ROM, hard disk drive, disk, optical disk), processor 420, and computer program / instruction 430.

[0109] Memory 410 stores a computer program / instructions 430 that can be executed by processor 420. Processor 420 is configured to run the computer program / instructions 430 stored in memory 420. The above-mentioned functions can be achieved by running the computer program / instructions 430. Figures 1-3 The method includes one or more steps.

[0110] Those skilled in the art will understand that the various illustrative logic blocks, modules, circuits, and algorithm steps described herein can be implemented as electronic hardware, computer software, or a combination of both.

[0111] To demonstrate the interchangeability between hardware and software, various illustrative components, blocks, modules, circuits, and steps have been generally described above according to their functionality. Whether such functionality is implemented in hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in varying ways for specific applications; however, such implementation decisions should not be construed as departing from the scope of this application.

[0112] Although only some specific embodiments of this application have been described, those skilled in the art will understand that this application can be implemented in many other forms without departing from its spirit and scope. Therefore, the examples and embodiments shown are to be considered illustrative rather than restrictive, and various modifications and substitutions may be made without departing from the spirit and scope of this application as defined by the appended claims.

[0113] The embodiments and examples presented herein are provided to best illustrate embodiments according to the present technology and its particular applications, thereby enabling those skilled in the art to implement and use the application. However, those skilled in the art will understand that the above description and examples are provided for ease of illustration and example only. The descriptions presented are not intended to cover all aspects of the application or to limit the application to the precise forms disclosed.

Claims

1. A method for planning software version release tasks, comprising: Step A. Identify multiple software versions to be released, A1…A m ; as well as Step B. Optimize the multiple software versions A1…A to be released. m Within a set of available release time windows W1…W n Release schedule X within the scope, Wherein, the objective optimization function maxF(X) used for the optimization is a linear combination of the following terms: the plurality of software versions to be released A1…A m The total delivery value V(X), the total delivery cycle T(X), and the changes due to the changes in the release time window W1…W n The overall change risk R(X) arising from the release within the period, The constraints used for the optimization include at least the overall delivery cycle T(X) not exceeding the upper limit T0 and the overall change risk R(X) not exceeding the upper limit R0.

2. The method as described in claim 1, wherein, The total delivery value V(X) is determined as the software version A to be released under the release arrangement X. i Release value V i The sum of the published value V i Based on each software version A to be released i Importance I i and urgency level E i Sure.

3. The method as described in claim 2, wherein, For software versions with the highest urgency, their release value decreases over time. For software versions with the highest urgency, their release value changes dramatically around the specified release date. For software versions with the highest urgency, their release value remains constant over time.

4. The method of claim 1, wherein, The overall delivery cycle T(X) is determined to be, under the release schedule X, from the plurality of software versions A1…A to be released. m The first software version was released, followed by multiple software versions A1…A m The time taken to complete the release of the last software version in the project.

5. The method of claim 1, wherein, Under the release schedule X, the release time window W1…W n Each of the multiple software versions to be released carries an individual change risk R arising from changes to the release of those versions. j The overall change risk R(X) is determined as the release time window W1…W n The maximum value in the individual change risk.

6. The method of claim 5, wherein, The individual change risk R j At least based on the release time window W j The release time window W is determined by the number of software versions to be released, the urgency factor, and the complexity factor. The urgency factor is determined by the number of software versions to be released with a higher urgency relative to the number of software versions to be released within the release time window W. j The proportion of software versions to be released within the specified time window W, where the complexity factor is determined. j The number of time-related relationships between unreleased software versions, including sequential releases and simultaneous releases.

7. The method of claim 6, wherein, The individual change risk R j It increases with the increase of the quantity, the criticality factor, and the complexity factor.

8. The method of claim 1, wherein, The constraints also include time constraints and resource constraints. The time constraints include one or more of the following: the plurality of software versions to be released are released on a specified date, before a specified date, or after a specified date; two or more of the plurality of software versions to be released are released sequentially or simultaneously; and the plurality of software versions to be released are prohibited from being released on a set date. The resource constraints are determined to be the upper limit on the number of software versions released each day.

9. The method of claim 1, wherein, The objective optimization function max F(X) is solved using a genetic algorithm.

10. The method of any one of claims 1-9, further comprising: Step C. Determine the type of the new software version to be released, including a first type, a second type, and a third type; Step D. Optimize software version A having the second type and the third type in the manner described in step B. 1' …A m' Within a set of available release time windows W 1' …W n' Release schedule X' within; Step E. Transfer the multiple software versions A1…A to be released. m The software version that has not yet been released and has the second type of software version A has not yet been released. 1' …A m' The software versions of the first type are merged to obtain a merged, release-ready software version A. 1” …A m” ;as well as F. Optimize the merged, release-ready software version A following the steps outlined in step B. 1” …A m” Within a set of available release time windows W 1” …W n” "The internal release schedule X".

11. A computer system, comprising: At least one memory; At least one processor; as well as A computer program / instruction stored in the memory and executable on the processor, the execution of which results in the following operations: Operation A. Identify multiple software versions to be released, A1…A m ; as well as Operation B. Optimize the multiple software versions A1…A to be released. m Within a set of available release time windows W1…W n Release schedule X within the scope, Wherein, the objective optimization function maxF(X) used for the optimization is a linear combination of the following terms: the plurality of software versions to be released A1…A m The total delivery value V(X), the total delivery cycle T(X), and the changes due to the changes in the release time window W1…W n The overall change risk R(X) arising from the release within the period, The constraints used for the optimization include at least the overall delivery cycle T(X) not exceeding the upper limit T0 and the overall change risk R(X) not exceeding the upper limit R0.

12. The computer system of claim 11, wherein, The total delivery value V(X) is determined as the software version A to be released under the release arrangement X. i Release value V i The sum of the published value V i Based on each software version A to be released i Importance I i and urgency level E i Sure.

13. The computer system of claim 12, wherein, For software versions with the highest urgency, their release value decreases over time. For software versions with the highest urgency, their release value changes dramatically around the specified release date. For software versions with the highest urgency, their release value remains constant over time.

14. The computer system of claim 11, wherein, The overall delivery cycle T(X) is determined to be, under the release schedule X, from the plurality of software versions A1…A to be released. m The first software version was released, followed by multiple software versions A1…A m The time taken to complete the release of the last software version in the project.

15. The computer system of claim 11, wherein, Under the release schedule X, the release time window W1…W n Each of the multiple software versions to be released carries an individual change risk R arising from changes to the release of those versions. j The overall change risk R(X) is determined as the release time window W1…W n The maximum value in the individual change risk.

16. The computer system of claim 15, wherein, The individual change risk R j At least based on the release time window W j The release time window W is determined by the number of software versions to be released, the urgency factor, and the complexity factor. The urgency factor is determined by the number of software versions to be released with a higher urgency relative to the number of software versions to be released within the release time window W. j The proportion of software versions to be released within the specified time window W, where the complexity factor is determined. j The number of time-related relationships between unreleased software versions, including sequential releases and simultaneous releases.

17. The computer system of claim 16, wherein, The individual change risk R j It increases with the increase of the quantity, the criticality factor, and the complexity factor.

18. The computer system of claim 11, wherein the constraints further include time constraints and resource constraints, the time constraints including one or more of the following: the plurality of software versions to be released are released on a specified date, before a specified date, or after a specified date; two or more of the plurality of software versions to be released are released sequentially or simultaneously; and the plurality of software versions to be released are prohibited from being released on a set date; and the resource constraints are determined to be an upper limit on the number of software versions released per day.

19. The computer system of claim 11, wherein, The objective optimization function max F(X) is solved using a genetic algorithm.

20. The computer system according to any one of claims 11-19, wherein, The execution of the computer program / instructions on the processor also results in: Operation C. Determine the type of the new software version to be released, including a first type, a second type, and a third type; Operation D. Optimize software version A, which has the second type and the third type, in accordance with operation B. 1' …A m' Within a set of available release time windows W 1' …W n' Release schedule X' within; Operation E. Step E. Transfer the multiple software versions A1…A to be released. m The software version that has not yet been released and has the second type of software version A has not yet been released. 1' …A m' The software versions of the first type are merged to obtain a merged, release-ready software version A. 1” …A m” ; as well as Operation F. Optimize the merged, release-ready software version A in the manner described in Operation B. 1” …A m” Within a set of available release time windows W 1” …W n” "The internal release schedule X".

21. A non-transitory computer-readable storage medium storing a computer program / instructions, characterized in that, The steps of the method as described in any one of claims 1-10 are performed by the processor running the computer program / instructions.

22. A method for performing a software version release task, comprising: Retrieve multiple software versions A1…A within the current release time window W that are yet to be released. k ; as well as Optimize the multiple software versions A1…A to be released k The release order Y within the current release time window W; as well as The multiple software versions A1…A to be released are executed in an optimized release order. k The release, Wherein, the objective optimization function used for the optimization is min∑ j∈H y j H represents the multiple software versions A1…A to be released. k A collection of software versions to be released that have defined attributes, y i The release sequence number of the software versions to be released in set H within the current release time window W. The constraints used for the optimization include at least the plurality of software versions A1…A to be released. k The delivery cycle T'(X) does not exceed the upper limit T'0.

23. The method of claim 22, wherein, The delivery cycle T'(X) is determined to be, under the release order Y, from the plurality of software versions A1…A1 to be released. k The first software version was released, followed by multiple software versions A1…A k The time taken to complete the release of the last software version in the project.

24. The method of claim 22, wherein, The attributes include one or more of the following: release priority, release failure risk, and rollback difficulty.

25. The method of claim 22, wherein, The constraints also include time constraints and resource constraints. The time constraints include the release of two or more of the plurality of software versions to be released, either sequentially or simultaneously. The resource constraints are determined to be the upper limit on the number of software versions released at the same time.

26. The method of claim 22, wherein, The objective optimization function min∑ is solved using a genetic algorithm. j∈ H y j .

27. A computer system, comprising: At least one memory; At least one processor; as well as A computer program / instruction stored in the memory and executable on the processor, the execution of which results in the following operations: Retrieve multiple software versions A1…A within the current release time window W that are yet to be released. k ; as well as Optimize the multiple software versions A1…A to be released k The release order Y within the current release time window W; and The multiple software versions A1…A to be released are executed in an optimized release order. k The release, Wherein, the objective function of the optimization is min∑ j∈H y j H represents the multiple software versions A1…A to be released. k A collection of software versions to be released that have defined attributes, y i The release sequence number of the software versions to be released in set H within the current release time window W. The constraints used for the optimization include at least the plurality of software versions A1…A to be released. k The overall delivery cycle T'(X) does not exceed the upper limit T'0.

28. The computer system of claim 27, wherein, The overall delivery cycle T'(X) is determined as, under the release order Y, from the plurality of software versions A1…A1 to be released. k The first software version was released, followed by multiple software versions A1…A k The time taken to complete the release of the last software version in the project.

29. The computer system of claim 27, wherein, The attributes include one or more of the following: release priority, release failure risk, and rollback difficulty.

30. The computer system of claim 27, wherein, The constraints also include time constraints and resource constraints. The time constraints include the release of two or more of the plurality of software versions to be released, either sequentially or simultaneously. The resource constraints are determined to be the upper limit on the number of software versions released at the same time.

31. The computer system of claim 27, wherein, The objective optimization function min∑ is solved using a genetic algorithm. j∈H y j .

32. A non-transitory computer-readable storage medium storing a computer program / instructions, characterized in that, The steps of the method described in any one of claims 22-26 are performed by the processor running the computer program / instructions.

Images