CN110244951B

CN110244951B - Application publishing method and device

Info

Publication number: CN110244951B
Application number: CN201810193470.2A
Authority: CN
Inventors: 潘亮; 钱琨
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2018-03-09
Filing date: 2018-03-09
Publication date: 2024-03-12
Anticipated expiration: 2038-03-09
Also published as: WO2019170018A1; CN110244951A

Abstract

One or more embodiments of the present disclosure provide an application publishing method and apparatus, where the method may include: displaying a plurality of release phases of an application; and displaying the code version of the instance in the information display area corresponding to the corresponding release stage according to the instance of the application respectively operated by each release stage.

Description

Application publishing method and device

Technical Field

One or more embodiments of the present disclosure relate to the field of terminal technologies, and in particular, to an application publishing method and device.

Background

In the related technology, a processing thought of a release pipeline is provided, and the release pipeline corresponding to the application is created, so that the release process of the application can be divided into a plurality of release stages connected in series, and the application is orderly subjected to processing operations such as framework, deployment, test and the like by each release stage, thereby being beneficial to rapidly and safely deploying the application into a production environment.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide an application publishing method and apparatus.

In order to achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, there is provided an application publishing method, including:

Displaying a plurality of release phases of an application;

and displaying the code version of the instance in the information display area corresponding to the corresponding release stage according to the instance of the application respectively operated by each release stage.

According to a second aspect of one or more embodiments of the present specification, there is provided an application publishing device comprising:

a stage display unit that displays a plurality of release stages of the application;

and the version display unit displays the code version of the instance in the information display area corresponding to the corresponding release stage according to the instance of the application respectively operated in each release stage.

Drawings

FIG. 1 is a schematic architecture diagram of an application publishing system according to an exemplary embodiment.

Fig. 2 is a flowchart of an application publishing method according to an exemplary embodiment.

FIG. 3 is a flow chart of a creation example provided by an exemplary embodiment.

Fig. 4A-4C are schematic diagrams illustrating performance of feature branch management via a feature branch management interface in accordance with an exemplary embodiment.

Fig. 5 is a schematic diagram showing information about an instance run by the publishing phase according to an exemplary embodiment.

FIG. 6 is a schematic diagram of a new instance creation provided by an exemplary embodiment.

FIG. 7 is a schematic diagram showing information about an instance run by a plurality of publishing stages, respectively, in accordance with an exemplary embodiment.

FIG. 8 is a diagram providing information about an instance run by a selected publishing phase in accordance with an exemplary embodiment.

Fig. 9 is a flow chart of an implementation of a rollback operation provided by an exemplary embodiment.

FIG. 10 is a flowchart providing a method for sharing issue branches among a plurality of issue pipelines in accordance with an exemplary embodiment.

FIG. 11 is a schematic diagram of a method for sharing issue branches among a plurality of issue pipelines provided by an example embodiment.

Fig. 12 is a schematic diagram of an apparatus according to an exemplary embodiment.

Fig. 13 is a block diagram of an application publishing device provided by an example embodiment.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

In an embodiment, the application publishing scheme of the present disclosure may be applied to an electronic device, for example, the electronic device may include a mobile phone, a PC, a tablet device, a notebook computer, a palm computer (PDAs, personal Digital Assistants), a wearable device (such as smart glasses, smart watches, etc.), and the present disclosure is not limited thereto. In the running process, the electronic device can run the application release system to realize the application release scheme of the specification. The application program of the application release system can be pre-installed on the electronic device, so that the application release system can be started and run on the electronic device; of course, when using techniques such as HTML5, the application publishing system can be obtained and run without installing a corresponding application on the electronic device.

In one embodiment, fig. 1 is a schematic architecture diagram of an application publishing system according to an exemplary embodiment. The application distribution system may comprise a server 11, a network 12, several electronic devices as shown in fig. 1, for example the electronic devices may comprise a PC13, a PC14. In the running process, the server 11 can run a program on the server side of the application publishing system to realize related functions such as processing; in the running process of the PC13 and the PC14, the program on the client side of the application publishing system can be run to realize the functions of relevant display, man-machine interaction and the like, so that the application publishing system is realized by cooperation between the server 11 and the PC13 and the PC14.

The server 11 may be a physical server including a separate host, or the server 11 may be a virtual server carried by a host cluster. The electronic device may include other types of devices besides the PC13, PC14 described above, such as the following: cell phones, tablet devices, notebook computers, palm top computers (PDAs, personal Digital Assistants), wearable devices (e.g., smart glasses, smart watches, etc.), etc., as one or more embodiments of the present disclosure are not limited in this regard. And the network 12 for interaction between the PC13, the PC14 and the server 11 may include various types of wired or wireless networks. In one embodiment, the network 12 may include a public switched telephone network (Public Switched Telephone Network, PSTN) and the internet. It should be noted that: an application program of a client of the application publishing system may be pre-installed on the electronic device such that the client may be started and run on the electronic device; of course, when an online "client" such as HTML5 technology is employed, the client can be obtained and run without installing a corresponding application on the electronic device.

Fig. 2 is a flowchart of an application publishing method according to an exemplary embodiment. As shown in fig. 2, the method may include the steps of:

step 202, a plurality of publishing phases of an application are presented.

In one embodiment, the plurality of issue phases of an application belong to a certain issue pipeline corresponding to the application.

In one embodiment, the application's corresponding issue pipeline may be provided with a corresponding pipeline manager and the pipeline manager is responsible for configuring the issue stages contained in the issue pipeline. In other embodiments, the publishing stages of the publishing pipeline may be configured by other identity users, which is not limiting in this description.

In an embodiment, the visualized node icons corresponding to the release phases can be displayed respectively, the visualized node icons are sequentially arranged according to the running sequence among the corresponding release phases, and the visualized node icons are sequentially connected through icons such as arrows, so that the visualized display of the release phases contained in the release pipeline is realized, and users (such as pipeline administrators and application developers) with various roles can clearly and definitely know the running condition of the release pipeline.

In one embodiment, the instances of the application do not necessarily run all the phases of release in sequence from beginning to end, in some cases starting or ending with a certain intermediate phase of release, in other cases running solely at a certain phase of release; the pipeline manager or other users can be adjusted according to the actual situation, and the specification is not limited thereto.

And 204, according to the examples of the application running in each release stage, displaying the code version of the example in the information display area corresponding to the corresponding release stage.

In one embodiment, when an application is loaded into the release pipeline to run, a corresponding instance (or referred to as a running instance) is generated based on the current condition of the application at the loading time, so that the instance runs on the release pipeline, and the running results are all used for reflecting the condition of the application at the loading time. When an application is loaded to the issue pipeline at another time, if the code content of the application and the like are different from the current condition of the loading time, another instance needs to be generated and run in the issue pipeline; even if the code content of the application and the like do not differ from the above-described current situation at the loading time, such as just for the re-execution of the application, it may still be necessary to re-generate an instance, and execute the re-generated instance in the issue pipeline.

In an embodiment, different instances of an application have different code versions for accurately distinguishing between the different instances. Because the application instances run in each release stage of the release pipeline in turn, different release stages can run instances of different code versions; for example, when the issue pipeline includes "first stage→second stage→third stage," after the first stage completes the execution of instance 1, the second stage may continue to execute instance 1, while the first stage may execute subsequently loaded instance 2. Therefore, the code version of the operated instance is displayed in the information display area corresponding to the release stage, so that the user can clearly know the operated instance of each release stage, and the operation condition of each instance is clear.

In an embodiment, the feature branches included in the release branches of the instance may be displayed in the information display area corresponding to the corresponding release phase. When an application contains one or more new properties that need to be published, these new properties are embodied as property branches contained by the published branches of the instance. The characteristic branches contained in the running examples are displayed in the information display area corresponding to the release stage, and the code versions shown in the information display area are combined, so that a user can clearly know new characteristics contained in the examples of each code version, and processing or adjustment can be timely carried out according to the running condition of the examples, and the application release efficiency can be improved.

In one embodiment, the information display area may be a single area, in which the code version and the information of the feature branches are displayed. In another embodiment, the information presentation area may be a combination of multiple sub-areas, such as a first sub-area for presenting a code version and a second sub-area for presenting information of a characteristic branch.

In an embodiment, the instance may include a backbone code of the application, and a release branch code corresponding to the release branch. Wherein the backbone code corresponds to the subject function of the application and the release branch is composed of characteristic branches of the application; accordingly, the release branch codes are obtained by combining characteristic branch codes corresponding to characteristic branches.

In one embodiment, an application may include one or more new properties, and an instance of the application may include corresponding one or more property branches, the property branch code of which may be provided by one or more developers, which is not limited in this specification.

In an embodiment, when an instance includes multiple characteristic branches, an initial release branch code may be formed by the characteristic branch code of the first characteristic branch, and then the characteristic branch codes of other characteristic branches are sequentially combined into the release branch code, so as to finally obtain a complete release branch code. Wherein, when merging the characteristic branch codes of each characteristic branch, it can detect whether code conflict occurs; when code conflict occurs, the corresponding characteristic branch codes can be automatically stripped from the issued branch codes, and corresponding conflict prompts are generated for preset users (such as pipeline administrators, corresponding developers and the like) so that related personnel can adjust the characteristic branch codes and solve the conflict problems.

In one embodiment, when a user wishes to add a feature branch to an application, an audit operation may be performed for that feature branch to limit the addition of feature branches that fail the audit; of course, in some cases, it may be permissible to add feature branches that do not pass the audit, depending on the management policy actually employed, which is not limiting in this specification. The auditing operation can be automatic auditing or manual auditing implemented by auditors, and the specification is not limited to the method. The auditing operation may include at least one of a variety of types of code auditing, security auditing, etc., and this description is not limiting. The auditing operation may be implemented for the characteristic branch code of the characteristic branch, or may be implemented for other information such as the submitter of the characteristic branch, which is not limited in this specification.

In one embodiment, the result of the audit on the characteristic branch can be obtained and recorded into the snapshot data corresponding to the characteristic branch; and when the characteristic branch is unchanged, determining the auditing condition of the characteristic branch according to the auditing result recorded in the corresponding snapshot data, for example, when the characteristic branch is recorded as the passing of the auditing in the snapshot data, the characteristic branch is considered to pass the auditing and is not required to be audited again, and when the characteristic branch is recorded as the failing of the auditing in the snapshot data, the characteristic branch is considered to pass the auditing in the following. When a characteristic branch changes, such as an editing operation for a corresponding characteristic branch code is detected, the corresponding snapshot data can be deleted or marked as unreliable, so that an audit must be re-implemented for the changed characteristic branch.

In an embodiment, a characteristic branch management interface of a release branch may be displayed, where the characteristic branch management interface includes an integration area and a to-be-released area, where the integration area is used to display a selected characteristic branch, and the to-be-released area is used to display an alternative characteristic branch; the issuing branch codes are obtained by combining characteristic branch codes corresponding to the selected characteristic branches; and according to the received characteristic branch selection instruction, transferring the selected alternative characteristic branch to the integration area to display the selected alternative characteristic branch as the selected characteristic branch in the integration area. In other words, by displaying the characteristic branch management interface to the user, the user can quickly and accurately determine the available characteristic branches (i.e. alternative characteristic branches) and the selected characteristic branches (i.e. selected characteristic branches) based on the visual content, and quickly select the characteristic branches which are desired to be added from the to-be-distributed area through the characteristic branch selection instruction, so that the characteristic branches can be quickly added. Accordingly, when any of the alternative feature branches is transferred to the integration zone, the corresponding feature branch code may be automatically merged into the issue branch code without requiring manual processing by the user.

In an embodiment, a characteristic branch management interface of the issuing branch may be displayed, where the characteristic branch management interface includes an integration area and a to-be-issued area, the integration area is used to display the selected characteristic branch, and the to-be-issued area is used to display the alternative characteristic branch; the issuing branch codes are obtained by combining characteristic branch codes corresponding to the selected characteristic branches; and according to the received characteristic branch removing instruction, at least one selected characteristic branch of the integrated area can be transferred to the area to be distributed so as to be displayed as an alternative characteristic branch in the area to be distributed. In other words, by presenting the feature branch management interface to the user, the user can quickly and accurately determine the available feature branches (i.e., alternative feature branches) and the selected feature branches (i.e., selected feature branches) based on the visual content, and quickly select the feature branches desired to be removed from the integration area through the feature branch removal instruction, so as to quickly remove the feature branches. Accordingly, when any selected characteristic branch is transferred to the area to be issued, the corresponding characteristic branch code can be automatically stripped from the issued branch code without requiring manual processing by the user.

In an embodiment, at least one alternative characteristic branch may be added to the characteristic branch management interface according to the received characteristic branch adding instruction, so as to implement quick management of the area to be issued. At the same time, it is convenient to further transfer the alternative feature branch to a selected feature branch in the integration region by a feature branch fetch instruction such as described above.

In an embodiment, at least one alternative characteristic branch may be deleted from the characteristic branch management interface according to the received characteristic branch deletion instruction, so as to implement quick management of the area to be issued.

In an embodiment, when the selected characteristic branch in the integration area changes, for example, the selected characteristic branch increases or decreases, so that the corresponding release branch code changes, a new instance can be generated according to the changed selected characteristic branch, and the code version of the new instance is different from the history code version of the history instance. In one case, a "change in the release branch code" may be understood as a "change" operation occurring in the release branch code, and whether there is a substantial difference between the release branch code before and after the change, a new instance and a new code version thereof need to be regenerated to ensure that all changes are trace-able. In another case, the "issue branch code changed" may be understood as a substantial difference between issue branch codes before and after the change; for example, after a user removes a feature branch from the integration area and adds it again to the integration area, the issue branch code is considered to have no substantial difference before and after the change as long as the feature branch itself has not changed.

In one embodiment, at least one of the following adjustment operations may be performed based on the received issue branch adjustment instruction: and merging the characteristic branch codes corresponding to the at least one characteristic branch into the release branch code, and stripping the characteristic branch code corresponding to the at least one characteristic branch from the release branch code. In one case, the issue branch adjustment instruction may be combined with the above-mentioned characteristic branch management interface, and then the issue branch adjustment instruction may be equivalent to the above-mentioned characteristic branch selection instruction, characteristic branch removal instruction, etc., and may be used to manage characteristic branches of the integrated area and the area to be issued, so as to add or remove characteristic branches included in the issue branch, and implement quick management of the issue branch. In another case, independent of the characteristic branch management interface, the user may issue the issue branch adjustment instruction through non-visualization or other forms to implement quick management of the issue branch.

In an embodiment, an adjusted issue branch code obtained based on the issue branch adjustment instruction is obtained; and generating a corresponding new instance according to the regulated release branch code, wherein the code version of the new instance is different from the historical code version of the historical instance. The history instance refers to an instance generated before the new instance, the history code version is a code version corresponding to the history instance, and the history instance is clearly distinguished from the new instance according to the history code version by distinguishing the code version of the new instance from the history code version.

In an embodiment, the release record information of the corresponding instance of each code version can be respectively stored; after a first instance of a first code version is released to an online environment, if a rollback instruction from the first code version to a second code version is received, release record information corresponding to the second instance of the second code version can be searched; and then, according to the searched release record information, determining the difference between the characteristic branches contained in the second instance and the first instance, and adjusting release branch codes in the first instance according to the difference so as to automatically roll back to be the second instance. Therefore, by generating a corresponding code version for each instance and storing corresponding release record information for each instance of the code version, the corresponding release record information can be obtained by designating the code version, and the instance is quickly and conveniently automatically rolled back based on the release record information, so that manual intervention is avoided, and an error code is prevented from being released to an online environment.

In one embodiment, at least one associated issue pipeline corresponding to the issue pipeline may be determined, and the issue branches of the instances may be provided to the associated issue pipeline to form and run the corresponding instances on the associated issue pipeline, thereby implementing sharing of the issue branches among multiple issue pipelines without repeating merging operations on the corresponding characteristic branches. After the release branches on the release pipeline are combined, sharing the release branches to the associated release pipeline; alternatively, the issue branches may be shared to the associated issue pipeline after the instance is running normally on the issue pipeline, confirming that the issue branches are free of problems.

In order to facilitate understanding, the following describes technical solutions of one or more embodiments of the present specification, taking as an example a process of publishing new characteristics of an application. Assuming that the application is application X, new characteristics needing to be expanded may occur in the update development and product iteration process of the application X, and corresponding developer can develop corresponding characteristic branches to realize the update of the application X. After the updated application X is obtained, the updated application X can be processed through a corresponding release pipeline so as to realize continuous delivery of the application.

When the application X is released through the release pipeline, the release pipeline specifically generates an instance of the application X, and the release pipeline runs the instance. For example, FIG. 3 is a flow chart of a create instance provided by an exemplary embodiment; as shown in fig. 3, the process of creating an instance may include the steps of:

step 302, branch integration is initiated.

In one embodiment, the process of creating an instance may be understood as a branch integration operation, where corresponding property branches may be integrated within an issuing branch according to new properties that need to be added in application X.

In one embodiment, the branch integration operation may act as an issue stage of the issue pipeline. For example, as shown in fig. 4A, the distribution pipeline for one embodiment may include multiple distribution stages of branch integration, construction, daily, formal, etc., corresponding to the visualized icon 40, icon 41, icon 42, icon 43, etc., respectively. Wherein, according to the arrangement sequence between icons 40-43, the branching integration belongs to the first publishing stage in the embodiment shown in fig. 4A; of course, branch integration may also be located anywhere in the issue pipeline, and is not limited to the first issue stage. In other embodiments, the branch integration operation may be used as an independent operation outside the release pipeline, and is different from the release stage of construction, daily, formal, etc., but does not affect the implementation of the technical solution of the present specification; for ease of understanding, the present description will be described with respect to the branch integration operation belonging to the issue pipeline.

Step 304, judging whether a release branch exists; when present, go to step 308, otherwise go to step 306.

At step 306, a release branch is created.

In one embodiment, after the issue branches are created, the property branches are not initially contained, corresponding to "containers" that are just the next added property branches; whereas for an existing distribution branch one or more characteristic branches may already be included. As shown in fig. 4A, the publishing branches correspond to a property branch management interface 400, the property branch management interface 400 includes an integration area 401 and a to-be-published area 402, and the integration area 401 and the to-be-published area 402 are used for respectively managing property branches provided by a developer; wherein, the integration area 401 and the to-be-published area 402 are both empty, and the user can add an alternative feature branch by triggering an add option in the to-be-published area 402. For example, as shown in FIG. 4B, assuming that the developer provides property branch 1, property branch 2, property branch 3, and property branch 4, corresponding to the visualized icon 51, icon 52, icon 53, and icon 54 shown in FIG. 4B, respectively, property branches 1-4 are initially in the region to be published 402, and appear as icons 51-54 are all shown in the region to be published 402.

Step 308, merge the backbone code of application X with the release branch.

In an embodiment, the trunk code is combined with the issuing branch, in which the trunk code is actually combined with the issuing branch code corresponding to the issuing branch, and the issuing branch code is obtained by combining the characteristic branch code corresponding to the characteristic branch included in the issuing branch. When the release branch is newly created, the release branch does not contain the characteristic branch, and after the characteristic branch is added through the subsequent steps, the release branch codes are formed by combining; when the issuing branch exists in advance, the characteristic branches may be included, and the characteristic branch codes corresponding to the characteristic branches are combined to obtain the issuing branch code.

In one scenario, a property branch may be added to the issue branch, involving steps 310A-318 described below.

Step 310A, when a feature branch needs to be added, go to step 312A, otherwise go to step 320.

In an embodiment, new characteristics desired to be released may be determined according to actual requirements, and characteristic branches corresponding to the new characteristics are transferred from the to-be-released area 402 to the integrated area 401. For example, when a new property desired to be released corresponds to the property branch 1-2, the property branch 1-2 may be transferred from the region to be released 402 to the integrated region 401 by such a manner as dragging the icon 51-52 from the region to be released 402 to the integrated region 401, thereby forming a state as shown in fig. 4C.

At step 312A, the characteristic branch is merged into the issue branch.

In one embodiment, when feature branch 1 transitions from region to be issued 402 to integration region 401, feature branch code 1 of feature branch 1 is merged into the issue branch; since the issue branch does not previously include a characteristic branch, the issue branch code at this time is constituted by the characteristic branch code 1. Further, when the characteristic branch 2 is transferred from the area to be issued 402 to the integrated area 401, the characteristic branch code 2 of the characteristic branch 2 is merged into the issue branch; since the issue branch code is constituted by the characteristic branch code 1, it is necessary to combine the characteristic branch code 1 with the characteristic branch code 2 to obtain an updated issue branch code.

In one embodiment, the user only needs to pay attention to the characteristics required to be issued and transfer the corresponding characteristic branch from the area to be issued to the integrated area, and the corresponding characteristic branch code can be automatically combined to the issuing branch without manual operation of the user.

Step 314, judging whether code conflict occurs; if a code conflict occurs, go to step 316, otherwise go to step 318.

Step 316, the user is prompted to resolve the code conflict.

In one embodiment, when the characteristic branch code is merged into the issue branch, existing code conflicts can be monitored and prompt can be sent to the user to facilitate the user to resolve the code conflicts as soon as possible. Meanwhile, characteristic branch codes causing code conflict can be automatically stripped from the issued branch codes; for example, when the issuing branch already contains the characteristic branch 1, if code conflict occurs when the characteristic branch 2 is merged into the issuing branch, the issuing branch can be automatically stripped from the issuing branch code while prompting the user that the characteristic branch code 2 corresponding to the characteristic branch 2 is corresponding to, so that the issuing branch code is restored to the state of the non-merged characteristic branch code 2, and manual operation of the user is not needed.

Step 318, the merging is completed.

In one embodiment, after receiving the prompt of the code conflict, the user may adjust the corresponding characteristic branch code and reconfigures to the release branch; if the code conflict still exists, the prompt can be continued to the user until the code conflict does not exist finally, and the merging can be smoothly implemented on the corresponding characteristic branch and the release branch. Of course, the user may also terminate the merging of the relevant property branches.

In an embodiment, the user may further add more alternative feature branches by triggering an add option in the to-be-published area 402; and, the user may transfer more characteristic branches from the to-be-issued area to the integrated area, and the characteristic branches transferred to the integrated area may be combined with the issued branches, and the process is the same as the above characteristic branches 1-2, which are not repeated here.

It should be noted that:

each feature branch may be triggered by an audit operation, such as a code audit, security audit, etc., for that feature branch when added to the to-be-published area 402 or the integration area 401, which is not limited in this specification. After the auditing is finished, the corresponding auditing result can be recorded in the snapshot corresponding to the characteristic branch, so long as the code of the characteristic branch is not changed, the snapshot and the auditing result contained in the snapshot are valid for the characteristic branch; for example, assuming that a rule is defined that a feature branch added to the integration area 401 must pass an audit, if a snapshot 1 corresponding to the feature branch 1 records an audit result corresponding to the feature branch 1, and the audit result is pass the audit, then, as long as the code of the feature branch 1 does not change, the code can be directly added to the integration area 401 based on the audit result in the snapshot, without repeating the audit operation performed for the feature branch 1.

In one scenario, the characteristic branch may be removed from the issue branch, involving steps 310B-312B described below.

Step 310B, when the characteristic branch needs to be removed, go to step 312B, otherwise go to step 320.

At step 312B, the characteristic branch is stripped from the issue branch.

In one embodiment, in addition to adding a feature branch, the user may remove a previously added feature branch. For example, as shown in FIG. 4C, the user may restore to the condition shown in FIG. 4B by, for example, dragging icons 51-52 from the integration zone 401 to the to-be-published zone 402, such that the property branches 1-2 are removed from the published branches, and the corresponding property branch codes 1-2 may also be automatically stripped from the published branch codes.

Step 320, when no property branches need to be added or removed, creating an instance according to the property branches already contained in the release branch, and generating a code version.

In an embodiment, after completing the addition or removal of the feature branches, the user may trigger to complete the branch integration operation, so that the application publishing system may generate an instance of the application X, where the instance includes a trunk code and a published branch code, where the published branch code is obtained by merging feature branch codes corresponding to all feature branches that are finally included in the integration area 401.

For example, assuming the state shown in FIG. 4C when the branch integration operation is complete, since the integration region 401 contains property branches 1-2 as shown in FIG. 4C, this instance can be used to issue the corresponding new property 1-2. When the user triggers the branch integration operation each time, the application release system can generate a new instance; to distinguish between different instances and to perform accurate traceback or correlation processing for each instance, a corresponding code version may be generated for each instance, e.g., the code version of the corresponding instance of fig. 4C may be V-1.1.1.

After the branch integration stage is completed, the instances generated by the application release system can be sequentially transferred to the subsequent release stage for processing. In order to facilitate the user to determine the instance and the related information thereof operated by each publishing stage, the related information of the instance operated by each publishing stage can be shown in the information display area corresponding to each publishing stage. For example, FIG. 5 is a schematic diagram showing information about an instance run by a publication phase, provided by an exemplary embodiment; as shown in fig. 5, when the above-mentioned instance of code version V-1.1.1 runs in the release phase "build", the information presentation area corresponding to the release phase "build" may include two parts: the first section is located within icon 41 for showing the code version "V-1.1.1" of the executed instance, and the second section includes a property branch showing area 410 shown in FIG. 5 for showing the property branches contained by the executed instance as property branches 1-2, and specifically as icons 51-52 shown within property branch showing area 410. Thus, based on what is shown in FIG. 5, a user can quickly and accurately determine that the release phase "builds" an instance of running code version V-1.1.1, and that instance contains property branches 1-2.

FIG. 6 is a schematic diagram of a new instance creation provided by an exemplary embodiment. As shown in fig. 6, it is assumed that, on the basis of the embodiment shown in fig. 4C, the user can merge the corresponding characteristic branch 3 into the distribution branch by dragging the icon 53 from the area to be distributed 402 to the integrated area 401, similarly to the above-described steps 310A to 318; further, when the user triggers completion of the branch integration operation, the application publishing system may generate a new instance containing a publishing branch merged by the characteristic branches 1-3 finally contained by the integration zone 401 (i.e., a publishing branch code merged by the characteristic branch codes 1-3). Meanwhile, the application publishing system may generate a corresponding code version for the new instance, e.g., the code version of the new instance may be V-1.1.2.

FIG. 7 is a schematic diagram showing information about an instance run by a plurality of publishing stages, respectively, in accordance with an exemplary embodiment. As shown in FIG. 7, it is assumed that after the release phase "build" completes running an instance of code version V-1.1.1, the instance of code version V-1.1.1 is passed to the subsequent release phase "daily" running, and the instance of code version V-1.1.2 goes to the release phase "build" running. Then, similar to the embodiment shown in fig. 5, the relevant information of the instance of the code version V-1.1.2 may be displayed in the information display area corresponding to "build" in the release phase, and the relevant information of the instance of the code version V-1.1.1 may be displayed in the information display area corresponding to "daily" in the release phase. The information display area corresponding to the release stage 'construction' comprises an icon 41 and a characteristic branch display area 410, which are respectively used for displaying icons 51-53 corresponding to the code version 'V-1.1.2' and characteristic branches 1-3; the information display area corresponding to the "daily" release stage includes an icon 42 and a characteristic branch display area 420 for displaying icons 51 to 52 corresponding to the characteristic branches 1 to 2 of the code version "V-1.1.1", respectively.

In an embodiment, when an instance running in the publishing stage exists, the information display area corresponding to the publishing stage can be continuously displayed for the user to view; for example, in the embodiment shown in fig. 5, the icon 41 and the property branch display area 410 corresponding to the release phase "build" are continuously displayed, and in the embodiment shown in fig. 7, the icon 41 and the property branch display area 410 corresponding to the release phase "build" and the icon 42 and the property branch display area 420 corresponding to the release phase "daily" are continuously displayed. In yet another embodiment, the publishing stage of interest may be selected by the user and only the information presentation area corresponding to the selected publishing stage is shown. For example, FIG. 8 is a diagram illustrating information about an instance run by a selected publication phase in accordance with an exemplary embodiment; as shown in FIG. 8, assume that the release phase "builds" an instance of run code version V-1.1.3, the release phase "daily" an instance of run code version V-1.1.2, and the release phase "formal" an instance of run code version V-1.1.1. When the user selects the release phase "formal", the corresponding icon 43 may be a thick frame as shown in fig. 8, so as to distinguish the icons 40 to 42 using thin frames, etc., to indicate that the release phase "formal" is selected by the user; accordingly, a property branch presentation area 430 may be shown and corresponding icons 51-52 are presented in the extra new branch presentation area 430 according to the property branches 1-2 contained in the instance of code version V-1.1.1.

Fig. 9 is a flow chart of an implementation of a rollback operation provided by an exemplary embodiment. As shown in fig. 9, the implementation flow of the rollback operation may include the following steps:

step 902, save the release record.

In one embodiment, when an instance runs in the release pipeline, the application release system may generate corresponding release record information for each instance and record the release record information in the release record.

At step 904, a target version of the rollback is selected.

In one embodiment, assuming that an instance of code version V-1.1.3 is published to the online environment through the publication pipeline, it is found that an operational exception has occurred and it is necessary to roll back to an instance where no exception has previously occurred. The user may select an instance of the target version desired as a rollback by querying the publication record described above, e.g., the target version may be V-1.1.1; for example, a user may cause the issue pipeline to implement a rollback operation for an instance of code version V-1.1.1 by triggering issue record information corresponding to the instance of code version V-1.1.1.

Step 906 rolls back the deployment package to the target version.

In one embodiment, the rollback operation may include two parts: the first part rolls back the deployment package on the server and rolls back the deployment package to the target version; and a second part, updating codes. In some cases only deployment package rollback may need to be implemented, while in other cases code updates may also need to be implemented.

Step 908, when the code needs to be updated, go to step 910, otherwise the rollback ends.

Step 910, determining an instance corresponding to the target version.

At step 912, code updating is performed.

In an embodiment, when it is determined that the instance corresponding to the target version is the instance of the code version V-1.1.1, the code of the instance of the code version V-1.1.1 may be directly acquired to implement the code update.

In an embodiment, when it is determined that the instance corresponding to the target version is the instance of the code version V-1.1.1, the corresponding code update may be implemented according to the difference between the instance of the code version V-1.1.3 and the instance of the code version V-1.1.1. For example, assuming that the instance of code version V-1.1.1 contains property branches 1-2 and the instance of code version V-1.1.3 contains property branches 1-4, then the code update procedure corresponds to stripping property branches 3-4 from the instance of code version V-1.1.3, i.e., stripping property branch codes 3-4 corresponding to property branches 3-4 from the release branch code of the instance of code version V-1.1.3, thereby updating to the instance of code version V-1.1.1.

FIG. 10 is a flowchart providing a method for sharing issue branches among a plurality of issue pipelines in accordance with an exemplary embodiment. As shown in fig. 10, the process of sharing an issue branch among a plurality of issue pipelines may include the steps of:

At step 1002, a release branch is created.

Step 1004, merging the backbone code with the issue branch.

In one embodiment, steps 1002-1004 are the same as steps 306-308 in the embodiment shown in FIG. 3, and are not described in detail herein.

At step 1006, a publication branch of an instance of the associated publication pipeline is imported.

In an embodiment, when an instance is generated on a certain release pipeline, characteristic branches included in the release branches of the instance are combined, the characteristic branches are respectively checked and have no code conflict, and when another release pipeline also needs to use the characteristic branches, the release branches can be shared, so that operations of checking the characteristic branches, checking the code conflict, combining the characteristic branch codes and the like do not need to be repeatedly implemented, and release efficiency can be improved.

For example, FIG. 11 is a schematic diagram of a sharing of issue branches among multiple issue pipelines provided by an example embodiment. Assume that one release pipeline corresponding to the application X includes release stages of branch integration, construction, daily, formal, and the like, corresponding to the icons 1100 to 1103 shown in fig. 11, respectively. In the characteristic branch management interface 111 corresponding to the branch integration operation, an integration area 1111 and a to-be-issued area 1112 are included. In one case, the user may add the feature branches provided by the developer to the to-be-published area 1112 by triggering an add option in the to-be-published area 1112 and transferring the required feature branches to the integration area 1111, respectively, to complete the merging of the feature branches. In another case, assume that there is an association relationship between the issue pipeline shown in fig. 11 and the issue pipeline shown in fig. 4C; after the issue pipeline shown in fig. 4C has created the instance with the code version V-1.1.1, if the issue pipeline shown in fig. 11 also wants to use the characteristic branches 1-2, the issue branches of the instance with the code version V-1.1.1 can be directly imported into the integration zone 1111 by triggering the import option in the integration zone 1111, so that the corresponding issue branch codes are combined with the trunk codes on the issue pipeline shown in fig. 11, without sequentially combining the characteristic branch code 1 and the characteristic branch code 2, and without considering the problems of code collision and the like.

In step 1008, an instance is created, generating a code version.

In one embodiment, assume that there is an association between the issue pipeline shown in FIG. 4C and the issue pipeline shown in FIG. 11: in one case, after the release pipeline shown in fig. 4C generates an instance, release branches can be shared to the release pipeline shown in fig. 11 at any time, so that two release pipelines can at least partially process in parallel, and release efficiency is improved; in another case, the issue branches may be shared to the issue pipeline shown in FIG. 11 after the issue pipeline shown in FIG. 4C is running.

Fig. 12 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 12, at a hardware level, the apparatus includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a nonvolatile memory 1210, although other hardware may be included as needed for other services. The processor 1202 reads the corresponding computer program from the nonvolatile memory 1210 into the memory 1208 and then runs, forming an application issuing device on a logical level. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.

Referring to fig. 13, in a software implementation, the application publishing device may include:

a stage display unit 1301 that displays a plurality of release stages of an application;

the version display unit 1302 displays the code version of the instance in the information display area corresponding to the corresponding release stage according to the instance of the application running in each release stage.

Optionally, the method further comprises:

the characteristic display unit 1303 displays the characteristic branches included in the publishing branches of the instance in the information display areas corresponding to the corresponding publishing stages.

Optionally, the example includes a trunk code of the application and a release branch code corresponding to the release branch, where the release branch code is obtained by combining characteristic branch codes corresponding to the characteristic branches.

Optionally, the method further comprises:

an interface display unit 1304 for displaying a characteristic branch management interface of the issuing branch, where the characteristic branch management interface includes an integration area and a to-be-issued area, the integration area is used for displaying the selected characteristic branch, and the to-be-issued area is used for displaying the alternative characteristic branch; the issuing branch codes are obtained by combining characteristic branch codes corresponding to the selected characteristic branches;

And a characteristic branch selection unit 1305, according to the received characteristic branch selection instruction, transferring the selected alternative characteristic branch to the integration area to display the alternative characteristic branch as the selected characteristic branch in the integration area.

Optionally, the method further comprises:

and a characteristic branch removing unit 1306, configured to transfer at least one selected characteristic branch of the integrated area to the area to be distributed according to the received characteristic branch removing instruction, so as to display the selected characteristic branch as an alternative characteristic branch in the area to be distributed.

Optionally, at least one of the following is further included:

a characteristic branch adding unit 1307 for adding at least one alternative characteristic branch to the characteristic branch management interface according to the received characteristic branch adding instruction;

a characteristic branch deletion unit 1308 deletes at least one alternative characteristic branch from the characteristic branch management interface according to the received characteristic branch deletion instruction.

Optionally, the method further comprises:

and a first generating unit 1309 for generating a new instance according to the changed selected characteristic branch when the selected characteristic branch in the integrated area is changed, wherein the code version of the new instance is different from the history code version of the history instance.

Optionally, the method further comprises:

the issue branch adjustment unit 1310 performs at least one of the following adjustment operations according to the received issue branch adjustment instruction: and merging the characteristic branch codes corresponding to the at least one characteristic branch into the release branch code, and stripping the characteristic branch code corresponding to the at least one characteristic branch from the release branch code.

Optionally, the method further comprises:

an acquisition unit 1311 that acquires an adjusted issue branch code obtained based on the issue branch adjustment instruction;

the second generating unit 1312 generates a corresponding new instance according to the post-adjustment release branch code, where the code version of the new instance is different from the history code version of the history instance.

Optionally, the method further comprises:

a collision detection unit 1313 that detects whether or not a code collision occurs when merging a characteristic branch code of any characteristic branch into the issue branch code;

and a conflict processing unit 1314, configured to strip the characteristic branch code of any characteristic branch from the release branch code when a code conflict occurs, and generate a corresponding conflict prompt to a preset user.

Optionally, the method further comprises:

an information holding unit 1315 that holds release record information of the respective code version corresponding examples;

the information searching unit 1316 searches, after the first instance of the first code version is released to the online environment, release record information corresponding to the second instance of the second code version according to a received rollback instruction from the first code version to the second code version;

a difference determining unit 1317 that determines a difference between the characteristic branches included in the second instance and the first instance, based on the found distribution record information;

the code adjustment unit 1318 adjusts the release branch code in the first instance according to the difference to automatically roll back to the second instance.

Optionally, the method further comprises:

pipeline determining unit 1319, configured to determine at least one associated issue pipeline corresponding to the issue pipelines to which the plurality of issue stages belong;

a providing unit 1320 provides the issue branches of the instances to the associated issue pipeline to form and run the corresponding instances on the associated issue pipeline.

Optionally, the method further comprises:

an audit result recording unit 1321 that acquires an audit result of the characteristic branch and records it into snapshot data corresponding to the characteristic branch;

And a condition determining unit 1322, configured to determine, when the characteristic branch is unchanged, an audit condition of the characteristic branch according to an audit result recorded in the corresponding snapshot data.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims

1. An application publishing method, comprising:

exposing a plurality of release phases of an application, comprising: sequentially displaying the visual node icons corresponding to each release stage according to the operation sequence of each release stage, and sequentially connecting each visual node icon;

according to the examples of the application respectively operated in each release stage, the code version of the example is displayed in the information display area corresponding to the corresponding release stage;

displaying characteristic branches contained in the release branches of the examples in information display areas corresponding to the corresponding release phases; the instance comprises a trunk code of the application and a release branch code corresponding to the release branch, wherein the release branch code is obtained by combining characteristic branch codes corresponding to the characteristic branches;

The characteristic branch management interface of the release branch is displayed, the characteristic branch management interface comprises an integration area and a to-be-released area, the integration area is used for displaying the selected characteristic branch, and the to-be-released area is used for displaying the alternative characteristic branch; the issuing branch codes are obtained by combining characteristic branch codes corresponding to the selected characteristic branches;

and transferring the selected alternative characteristic branches to the integration area according to the received characteristic branch selection instruction so as to display the selected characteristic branches in the integration area.

2. The method as recited in claim 1, further comprising:

and transferring at least one selected characteristic branch of the integrated area to the area to be distributed according to the received characteristic branch removing instruction so as to be displayed as an alternative characteristic branch in the area to be distributed.

3. The method of claim 2, further comprising at least one of:

adding at least one alternative characteristic branch into the characteristic branch management interface according to the received characteristic branch adding instruction;

and deleting at least one alternative characteristic branch from the characteristic branch management interface according to the received characteristic branch deleting instruction.

4. The method as recited in claim 2, further comprising:

when the selected characteristic branch in the integrated area changes, generating a new instance according to the changed selected characteristic branch, wherein the code version of the new instance is different from the historical code version of the historical instance.

5. The method as recited in claim 1, further comprising:

according to the received issued branch adjusting instruction, at least one of the following adjusting operations is implemented: and merging the characteristic branch codes corresponding to the at least one characteristic branch into the release branch code, and stripping the characteristic branch code corresponding to the at least one characteristic branch from the release branch code.

6. The method as recited in claim 5, further comprising:

acquiring an adjusted issued branch code obtained based on the issued branch adjustment instruction;

And generating a corresponding new instance according to the regulated release branch code, wherein the code version of the new instance is different from the historical code version of the historical instance.

7. The method as recited in claim 1, further comprising:

detecting whether code conflict occurs when merging the characteristic branch code of any characteristic branch into the release branch code;

and when code conflict occurs, stripping the characteristic branch code of any characteristic branch from the release branch code, and generating a corresponding conflict prompt for a preset user.

8. The method as recited in claim 1, further comprising:

respectively storing release record information of corresponding examples of each code version;

after a first instance of a first code version is released to an online environment, according to a received rollback instruction from the first code version to a second code version, release record information corresponding to the second instance of the second code version is searched;

according to the searched release record information, determining the difference between the characteristic branches contained in the second instance and the first instance;

and adjusting the release branch codes in the first instance according to the difference to automatically roll back to the second instance.

9. The method as recited in claim 1, further comprising:

determining at least one associated release pipeline corresponding to the release pipelines to which the release phases belong;

the issue branches of the instances are provided to the associated issue pipeline to form and run corresponding instances on the associated issue pipeline.

10. The method as recited in claim 1, further comprising:

obtaining an auditing result of the characteristic branch and recording the auditing result into snapshot data corresponding to the characteristic branch;

and when the characteristic branch is unchanged, determining the auditing condition of the characteristic branch according to the auditing result recorded in the corresponding snapshot data.

11. An application publishing device, comprising:

the stage display unit displays a plurality of release stages of the application, including: sequentially displaying the visual node icons corresponding to each release stage according to the operation sequence of each release stage, and sequentially connecting each visual node icon;

the version display unit displays the code version of the instance in the information display area corresponding to the corresponding release stage according to the instance of the application respectively operated in each release stage; wherein different instances of the application running in the plurality of release phases have different code versions;

The characteristic display unit displays characteristic branches contained in the release branches of the examples in the information display areas corresponding to the corresponding release stages; the instance comprises a trunk code of the application and a release branch code corresponding to the release branch, wherein the release branch code is obtained by combining characteristic branch codes corresponding to the characteristic branches;

the interface display unit displays a characteristic branch management interface of the release branch, wherein the characteristic branch management interface comprises an integration area and a to-be-released area, the integration area is used for displaying the selected characteristic branch, and the to-be-released area is used for displaying the alternative characteristic branch; the issuing branch codes are obtained by combining characteristic branch codes corresponding to the selected characteristic branches;

and the characteristic branch selection unit is used for transferring the selected alternative characteristic branches to the integration area according to the received characteristic branch selection instruction so as to display the selected alternative characteristic branches as the selected characteristic branches in the integration area.

12. The apparatus as recited in claim 11, further comprising:

And the characteristic branch removing unit transfers at least one selected characteristic branch of the integrated area to the area to be distributed according to the received characteristic branch removing instruction so as to display the characteristic branch as an alternative characteristic branch in the area to be distributed.

13. The apparatus of claim 12, further comprising at least one of:

a characteristic branch adding unit for adding at least one alternative characteristic branch to the characteristic branch management interface according to the received characteristic branch adding instruction;

and the characteristic branch deleting unit deletes at least one alternative characteristic branch from the characteristic branch management interface according to the received characteristic branch deleting instruction.

14. The apparatus as recited in claim 12, further comprising:

and the first generation unit is used for generating a new instance according to the changed selected characteristic branch when the selected characteristic branch in the integrated area is changed, wherein the code version of the new instance is different from the history code version of the history instance.

15. The apparatus as recited in claim 11, further comprising:

the issuing branch adjusting unit is used for executing at least one of the following adjusting operations according to the received issuing branch adjusting instruction: and merging the characteristic branch codes corresponding to the at least one characteristic branch into the release branch code, and stripping the characteristic branch code corresponding to the at least one characteristic branch from the release branch code.

16. The apparatus as recited in claim 15, further comprising:

the acquisition unit acquires the adjusted release branch code obtained based on the release branch adjustment instruction;

and the second generation unit generates a corresponding new instance according to the adjusted release branch code, wherein the code version of the new instance is different from the history code version of the history instance.

17. The apparatus as recited in claim 11, further comprising:

a conflict detection unit configured to detect whether or not a code conflict occurs when merging a characteristic branch code of any one characteristic branch into the issue branch code;

and the conflict processing unit is used for stripping the characteristic branch code of any characteristic branch from the release branch code when code conflict occurs, and generating a corresponding conflict prompt for a preset user.

18. The apparatus as recited in claim 11, further comprising:

the information storage unit is used for respectively storing the release record information of the corresponding examples of each code version;

the information searching unit searches the release record information corresponding to the second instance of the second code version according to the received rollback instruction from the first code version to the second code version after the first instance of the first code version is released to the online environment;

A difference determining unit for determining a difference between the characteristic branches included in the second instance and the first instance according to the searched release record information;

and the code adjusting unit is used for adjusting the release branch codes in the first instance according to the difference so as to automatically roll back to be the second instance.

19. The apparatus as recited in claim 11, further comprising:

a pipeline determining unit for determining at least one associated issuing pipeline corresponding to the issuing pipelines to which the plurality of issuing stages belong;

and the providing unit is used for providing the release branch of the instance to the associated release pipeline so as to form and run the corresponding instance on the associated release pipeline.

20. The apparatus as recited in claim 11, further comprising:

an auditing result recording unit for acquiring auditing results of the characteristic branches and recording the auditing results into snapshot data corresponding to the characteristic branches;

and the condition determining unit is used for determining the auditing condition of the characteristic branch according to the auditing result recorded in the corresponding snapshot data when the characteristic branch is unchanged.