WO2019170018A1

WO2019170018A1 - Application publishing method and apparatus

Info

Publication number: WO2019170018A1
Application number: PCT/CN2019/076248
Authority: WO
Inventors: 潘亮; 钱琨
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2018-03-09
Filing date: 2019-02-27
Publication date: 2019-09-12
Also published as: CN110244951B; CN110244951A

Abstract

An application publishing method and apparatus. Said method may comprise: displaying a plurality of publishing stages of an application (202); and displaying, in an information presentation region corresponding to the corresponding publishing stage, a code version of the example according to an example of the application respectively running in each publishing stage (204).

Description

Application publishing method and device

The present application claims priority to Chinese Patent Application No. 20110119347, the entire disclosure of which is hereby incorporated by reference.

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 apparatus.

Background technique

In the related art, a processing idea of a publishing pipeline is proposed. By creating a publishing pipeline corresponding to an application, the application publishing process can be divided into several publishing phases in series, so that the application is organized and deployed in an orderly manner by each publishing phase. Processing, testing, and other processing operations help to quickly and securely deploy applications to production environments.

Summary of the invention

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

To achieve the above object, one or more embodiments of the present specification provide the following technical solutions:

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

Show multiple release phases of the app;

The code version of the instance is displayed in the information display area corresponding to the corresponding release stage according to the instance of the application that is respectively run in each release stage.

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

A stage display unit that displays multiple release phases of the application;

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 running in each release stage.

DRAWINGS

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

FIG. 2 is a flowchart of an application publishing method provided by an exemplary embodiment.

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

FIG. 4A is a schematic diagram of implementing feature branch management through a feature branch management interface according to an exemplary embodiment.

FIG. 4B is a schematic diagram of implementing feature branch management through a feature branch management interface according to an exemplary embodiment.

FIG. 4C is a schematic diagram of implementing feature branch management through a feature branch management interface according to an exemplary embodiment.

FIG. 5 is a schematic diagram showing information related to an example of running a release phase provided by an exemplary embodiment.

FIG. 6 is a schematic diagram of creating a new instance according to an exemplary embodiment.

FIG. 7 is a schematic diagram of related information respectively showing an example of running a plurality of publishing stages, according to an exemplary embodiment.

FIG. 8 is a schematic diagram of information related to an example of running a selected release phase provided by an exemplary embodiment.

FIG. 9 is a flowchart of an implementation of a rollback operation provided by an exemplary embodiment.

FIG. 10 is a flowchart of sharing a publishing branch between multiple publishing pipelines according to an exemplary embodiment.

FIG. 11 is a schematic diagram of sharing a publishing branch between multiple publishing pipelines according to an exemplary embodiment.

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

FIG. 13 is a block diagram of an application publishing apparatus according to an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. The following description refers to the same or similar elements in the different figures unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of the specification. Instead, they are merely examples of devices and methods consistent with aspects of one or more embodiments of the present specification as detailed in the appended claims.

It should be noted that the steps of the corresponding method are not necessarily performed in the order shown and described in the specification in other embodiments. In some other embodiments, the method may include more or fewer steps than those described herein. In addition, the individual steps described in this specification may be decomposed into multiple steps for description in other embodiments; while the multiple steps described in this specification may be combined into a single step in other embodiments. description.

In an embodiment, the application publishing solution of the present specification may be applied to an electronic device, such as a mobile phone, a PC, a tablet device, a notebook computer, a PDA (Personal Digital Assistants), and a wearable device (eg, Smart glasses, smart watches, etc., etc., one or more embodiments of the present specification are not limited thereto. During operation, the electronic device can run an application publishing system to implement the application publishing scheme of the present specification. Wherein, the application of the application publishing system can be pre-installed on the electronic device, so that the application publishing system can be started and run on the electronic device; of course, when adopting technologies such as HTML5, it is not necessary to install the corresponding device on the electronic device. The application can get and run the app publishing system.

In an embodiment, FIG. 1 is a schematic structural diagram of an application publishing system provided by an exemplary embodiment. The application publishing system may include the server 11, the network 12, and several electronic devices as shown in FIG. 1, for example, the electronic device may include the PC 13, the PC 14. The server 11 can run the program on the server side of the application publishing system to implement related processing functions, and the PC 13 and the PC 14 can run the client side program of the application publishing system during the running process. In order to implement related functions such as display and human-computer interaction, the application publishing system is implemented between the server 11 and the PC 13 and the PC 14.

The server 11 may be a physical server including a separate host, or the server 11 may be a virtual server hosted by the host cluster. In addition to the PC13 and PC14 described above, the electronic device may include other types of devices as follows: mobile phones, tablet devices, notebook computers, personal digital assistants (PDAs), and wearable devices (such as smart glasses, smart watches, etc.). And the like, one or more embodiments of the present specification are not limited thereto. For the network 12 that interacts between the PC 13, the PC 14 and the server 11, various types of wired or wireless networks may be included. In an embodiment, the network 12 may include a Public Switched Telephone Network (PSTN) and the Internet. It should be noted that the client application of the application publishing system can be pre-installed on the electronic device so that the client can be launched and run on the electronic device; of course, when adopting an online "client" such as HTML5 technology. The client can be obtained and run without having to install the appropriate application on the electronic device.

FIG. 2 is a flowchart of an application publishing method provided by an exemplary embodiment. As shown in FIG. 2, the method may include the following steps:

Step 202, showing multiple release phases of the application.

In an embodiment, multiple release phases of the application belong to a certain release pipeline corresponding to the application.

In an embodiment, the corresponding release pipeline of the application may be provided with a corresponding pipeline administrator, and the pipeline administrator is responsible for configuring the release phase included in the release pipeline. In other embodiments, the release phase of the release pipeline can be configured by users of other identities, and this specification does not limit this.

In an embodiment, the visualization node icons corresponding to the respective release stages may be respectively displayed, and the visualization node icons are sequentially arranged according to the running sequence between the respective release stages, and the icons of the respective visualization nodes are sequentially performed by icons such as arrows. The connection enables a visual representation of the release phase contained in the release pipeline, enabling users of each role (such as pipeline administrators, application developers, etc.) to clearly and clearly understand the health of the release pipeline.

In an embodiment, the instances of the application do not necessarily run in all the release phases from beginning to end, in some cases from the release phase of an intermediate location, or in some cases alone. The release phase runs; the pipeline administrator or other users can adjust according to the actual situation, this specification does not limit this.

In step 204, the code version of the instance is displayed in the information display area corresponding to the corresponding release stage according to the instance of the application that is respectively run in each release stage.

In an embodiment, when the application is loaded into the release pipeline, a corresponding instance (or a running instance) is generated based on the current situation of the application at the loading time, so that the instance runs on the publishing pipeline, and the running result is It is used to reflect the application at the above loading moment. When the application is loaded to the release pipeline at another time, if the code content of the application or the like is different from the current situation of the loading moment, another instance needs to be generated, and the other instance is run on the release pipeline; Even if the code content of the application does not differ from the current situation of the loading moment described above, such as only for the re-run of the application, it may still be necessary to regenerate the instance and run the regenerated instance on the publishing pipeline.

In an embodiment, different instances of the application have different code versions for accurately distinguishing between different instances. Since the instances of the application are sequentially run in the various release phases of the release pipeline, different release phases can run instances of different code versions; for example, when the release pipeline includes "first phase→second phase→third phase", at first After the phase completes the operation of instance 1, the instance 1 can continue to be run by the second phase, and the first phase can run the subsequently loaded instance 2. Therefore, by displaying the code version of the running instance in the information display area corresponding to the release phase, the user can clearly understand the instances running in each release phase, and clarify the operation of each instance.

In an embodiment, the feature branches included in the publishing branch of the instance may be displayed in the information display area corresponding to the corresponding publishing stage. When an application contains one or more new features that are required to be published, these new features are represented by the feature branches contained in the release branch of the instance. By presenting the feature branches contained in the running instance in the information display area corresponding to the release phase, and combining the code versions shown in the information display area, the user can clearly understand the new features included in the instances of each code version, so as to facilitate The operation of the instance is processed or adjusted in time to help improve the efficiency of application publishing.

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

In an embodiment, an instance may include a trunk code of the application, and a release branch code corresponding to the release branch. The trunk code corresponds to the main function of the application, and the release branch is composed of the feature branches of the application; correspondingly, the release branch code is obtained by combining the feature branch codes corresponding to the feature branches.

In an embodiment, the application may include one or more new features, and the instance of the application may include a corresponding one or more feature branches, and the feature branch code of the feature branches may be provided by one or more developers. This is not a limitation.

In an embodiment, when the instance includes multiple feature branches, the initial release branch code may be formed by the feature branch code of the first feature branch, and then the feature branch code of the other feature branches is merged into the release branch code. The final release branch code is finally obtained. Wherein, when merging the feature branch code of each feature branch, it is possible to detect whether a code conflict occurs; when a code conflict occurs, the corresponding feature branch code can be automatically stripped from the release branch code and forwarded to a preset user (such as a pipeline) The administrator, the corresponding developer, etc.) generate corresponding conflict prompts, so that the relevant personnel can adjust the feature branch code and solve the conflict problem.

In an embodiment, when a user wishes to add a feature branch to an application, an audit operation for the feature branch may be implemented to restrict the addition of a feature branch that has not passed the audit; of course, in some cases, the addition may fail to be approved. The feature branch depends on the management strategy actually adopted, and this specification does not limit this. The audit operation can be an automatic audit or a manual audit performed by the auditor. This manual does not limit this. The audit operation may include at least one of a plurality of types such as code review and security audit, and this specification does not limit this. The auditing operation may be implemented for the feature branch code of the feature branch, or may be implemented for other information such as the submitter of the feature branch, and this specification does not limit this.

In an embodiment, the audit result of the feature branch may be obtained and recorded in the snapshot data corresponding to the feature branch; then, when the feature branch does not change, it may be recorded according to the corresponding snapshot data. The result of the audit determines the audit status of the feature branch. For example, when the snapshot data is recorded as the audit pass, and the subsequent view is that the feature branch has passed the audit without re-reviewing, and the snapshot data is recorded as the audit fails, the subsequent considers that The feature branch failed the approval. When the feature branch changes, for example, the editing operation for the corresponding feature branch code is detected, the original corresponding snapshot data may be deleted or the original corresponding snapshot data may be marked as untrusted, so that the audit must be re-implemented for the changed feature branch. .

In an embodiment, the feature branch management interface of the publishing branch may be displayed, where the feature branch management interface includes an integrated area and a to-be-released area, where the integrated area is used to display the selected feature branch, and the to-be-released area is used for displaying An optional feature branch; wherein the release branch code is merged by the feature branch code corresponding to the selected feature branch; according to the received feature branch selection instruction, the selected candidate feature branch may be transferred to the integration The zone is shown as a selected feature branch within the integration zone. In other words, by presenting the feature branch management interface to the user, the user can quickly and accurately determine the available feature branches (ie, the candidate feature branches) and the selected feature branches (ie, the selected feature branches) based on the visualized content, and pass the characteristics. The branch selection instruction quickly selects the feature branch that you want to add from the area to be released, so as to quickly add the feature branch. Accordingly, when any of the alternate feature branches are transferred to the integration zone, the corresponding feature branch code can be automatically merged to the release branch code without the user having to manually process it.

In an embodiment, a feature branch management interface of the publishing branch may be displayed, where the feature branch management interface includes an integrated area and a to-be-released area, where the integrated area is used to display the selected feature branch, and the to-be-released area is used And displaying the candidate feature branch; wherein the release branch code is obtained by combining the feature branch code corresponding to the selected feature branch; according to the received feature branch removal instruction, at least one selected feature of the integrated region may be selected The branch is transferred to the to-be-released area to be displayed as an alternate feature branch in the to-be-released area. In other words, by presenting the feature branch management interface to the user, the user can quickly and accurately determine the available feature branches (ie, the candidate feature branches) and the selected feature branches (ie, the selected feature branches) based on the visualized content, and pass the characteristics. The branch removal instruction quickly selects the feature branch that is desired to be removed from the integration area to achieve rapid removal of the feature branch. Accordingly, when any of the selected feature branches are transferred to the to-be-released zone, the corresponding feature branch code can be automatically stripped from the release branch code without the user having to manually process it.

In an embodiment, at least one candidate feature branch may be added to the feature branch management interface according to the received feature branch adding instruction to implement fast management of the area to be released. At the same time, it is convenient to further transfer the candidate feature branch into the selected feature branch in the integration region by using a feature branch selection instruction such as the above.

In an embodiment, at least one candidate feature branch may be deleted from the feature branch management interface according to the received feature branch deletion instruction to implement fast management of the area to be released.

In an embodiment, when the selected feature branch in the integrated area changes, for example, an increase or decrease of the selected feature branch occurs, the corresponding release branch code changes, and may be selected according to the change. The feature branch generates a new instance whose code version is different from the historical code version of the historical instance. In one case, "release branch code has changed" can be understood as the "change" operation of the release branch code, and whether there is a substantial difference between the release branch codes before and after the change, it is necessary to regenerate the new instance and its New code versions to ensure that all changes are traceable. In another case, "release branch code has changed" can be understood as a substantial difference between the release branch code before and after the change; for example, after the user removes a feature branch from the integration area, it is added again to The integration area, as long as the feature branch itself has not changed, it can be considered that the release branch code does not have a substantial difference before and after the change.

In an embodiment, at least one of the following adjustment operations may be implemented according to the received release branch adjustment instruction: combining the feature branch code corresponding to the at least one feature branch to the release branch code, and corresponding to the at least one feature branch The feature branch code is stripped from the release branch code. In one case, the issuing branch adjustment instruction may be combined with the feature branch management interface described above, and then the issuing branch adjustment instruction may be equivalent to the foregoing characteristic branch selection instruction, the characteristic branch removal instruction, etc., and may be used for the integration area, The feature branch of the release area is managed to add or remove feature branches included in the release branch to implement fast management of the release branch. In another case, regardless of the feature branch management interface described above, the user may issue a release branch adjustment instruction through non-visualization or other forms to implement quick management of the release branch.

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

In an embodiment, the release record information of the corresponding instance of each code version may be separately saved; after the first instance of the first code version is released to the online environment, if the first code version is received according to the received version a rollback instruction of the code version, which may search for the release record information corresponding to the second instance of the second code version; and then, according to the found release record information, determine that the second instance and the first instance are included The difference between the feature branches, and the release branch code in the first instance is adjusted according to the difference to automatically roll back to the second instance. Therefore, by generating a corresponding code version for each instance and saving the corresponding release record information for each code version instance, the corresponding release record information can be obtained by specifying the code version, and the instance can be quickly and conveniently based on the release record information. Automatic rollback, avoiding manual intervention and preventing the release of error codes into the online environment.

In an embodiment, at least one associated release pipeline corresponding to the issue pipeline may be determined, and a release branch of the instance is provided to the associated release pipeline to form and run a corresponding instance on the associated release pipeline Thus, sharing of the publishing branches is implemented between multiple publishing pipelines without repeating the merge operation of the corresponding feature branches. After the publishing branch of the publishing pipeline is merged, it can be shared to the associated publishing pipeline. Alternatively, the publishing branch can be shared to the associated publishing pipeline after the instance runs normally on the publishing pipeline and confirms that there is no problem with the publishing branch. .

For ease of understanding, the technical solution of one or more embodiments of the present specification will be described below by taking a process of publishing a new feature for an application as an example. Assuming that the application is application X, in the process of update development and product iteration of the application X, new features that need to be expanded may occur, and corresponding feature branches may be developed by the corresponding developers to implement the update of the application X. After the updated application X is obtained, it can be processed through the corresponding release pipeline to achieve continuous delivery of the application.

When the application X is published by the release pipeline, an instance of the application X is specifically generated by the release pipeline, and the instance is run by the release pipeline. For example, FIG. 3 is a flowchart of a creation example provided by an exemplary embodiment; as shown in FIG. 3, the process of creating an instance may include the following steps:

In step 302, branch integration is initiated.

In an embodiment, the process of creating an instance can be understood as a branch integration operation, and the corresponding feature branch can be integrated within the release branch according to the new features that need to be added in the application X.

In an embodiment, the branch integration operation can be used as a release phase of the release pipeline. For example, as shown in FIG. 4A, the publishing pipeline as an embodiment may include multiple publishing stages such as branch integration, construction, daily, formal, etc., corresponding to the visualized icon 40, the icon 41, the icon 42 and the icon 43 respectively. The branch integration is in the first release stage in the embodiment shown in FIG. 4A according to the arrangement order between the icons 40-43; of course, the branch integration may also be located anywhere in the release pipeline, and is not limited to the first one. Release stage. In other embodiments, the branch integration operation may be an independent operation other than the release pipeline, and is different from the construction, daily, formal, and other release phases, but does not affect the implementation of the technical solution of the present specification; for ease of understanding, in this specification, For example, the branch integration operation is a release pipeline.

In step 304, it is determined whether a release branch already exists; when it exists, the process proceeds to step 308, otherwise, the process proceeds to step 306.

In step 306, a release branch is created.

In an embodiment, after the release branch is created, it does not initially contain a feature branch, which is equivalent to only a "container" that adds a feature branch later; and for an existing release branch, one or more feature branches may already be included. As shown in FIG. 4A, the release branch corresponds to the feature branch management interface 400, which includes an integration area 401 and a to-be-released area 402, and the integration area 401 and the to-be-released area 402 are used to separately manage the characteristics provided by the developer. A branch; wherein the integration area 401 and the to-be-released area 402 are both empty, and the user can add an optional feature branch by triggering an add option in the to-be-released area 402. For example, as shown in FIG. 4B, it is assumed that the developer provides the feature branch 1, the feature branch 2, the feature branch 3, and the feature branch 4, respectively corresponding to the visualized icon 51, icon 52, icon 53 and icon 54 shown in FIG. 4B. The branches 1 to 4 are initially in the to-be-released area 402, and the icons 51 to 54 are all displayed in the to-be-released area 402.

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

In an embodiment, the main code is merged with the release branch, and the main code is actually merged with the release branch code corresponding to the release branch, and the release branch code is merged by the feature branch code corresponding to the feature branch included in the release branch. get. When the release branch is newly created, the release branch does not include the feature branch. After the feature branch is added, the merge branch code can be merged to form the release branch code. When the release branch already exists, the feature branch may be included. The feature branch code merges to get the release branch code.

In one scenario, a feature branch can be added to the release branch, involving steps 310A-318 described below.

Step 310A, when it is necessary to add a feature branch, go to step 312A, otherwise go to step 320.

In an embodiment, the new features that are desired to be released may be determined according to actual needs, and the feature branches corresponding to the new features are transferred from the to-be-released area 402 to the integrated area 401. For example, when the new feature that is desired to be released corresponds to the feature branches 1 to 2, the feature branches 1 to 2 can be removed from the to-be-released area by, for example, dragging the icons 51 to 52 from the to-be-released area 402 to the integrated area 401. 402 is transferred to the integration area 401 to form a state as shown in FIG. 4C.

In step 312A, the feature branch is merged into the release branch.

In an embodiment, when the feature branch 1 is transferred from the to-be-released area 402 to the integration area 401, the characteristic branch code 1 of the characteristic branch 1 is merged into the issue branch; since the release branch does not previously contain the feature branch, thus the The release branch code consists of the feature branch code 1. Further, when the feature branch 2 is transferred from the to-be-released area 402 to the integration area 401, the characteristic branch code 2 of the characteristic branch 2 is merged to the issue branch; since the issue branch code is composed of the feature branch code 1, the feature branch needs to be branched Code 1 is merged with feature branch code 2 to get the updated release branch code.

In an embodiment, the user only needs to focus on the features that need to be released, and transfer the corresponding feature branches from the to-be-released zone to the integrated zone, and the corresponding feature branch code can be automatically merged into the publishing branch without manual operation by the user. .

In step 314, it is determined whether a code conflict has occurred; if a code conflict occurs, the process proceeds to step 316, otherwise, the process proceeds to step 318.

In step 316, the user is prompted to resolve the code conflict.

In an embodiment, when the feature branch code is merged into the release branch, existing code conflicts can be monitored and prompted by the user to resolve the code conflict as quickly as possible. At the same time, the feature branch code that causes the code conflict can be automatically stripped from the release branch code; for example, if the release branch already contains the feature branch 1, if a code conflict occurs when the feature branch 2 is merged into the release branch, the user can be At the same time, the feature branch code 2 corresponding to the feature branch 2 is automatically stripped from the release branch code, and the release branch code is restored to the uncombined feature branch code 2, without manual operation by the user.

In step 318, the merge is completed.

In an embodiment, after receiving the prompt of the code conflict, the user may adjust the corresponding feature branch code and re-merge to the release branch; if there is still a code conflict, the user may continue to be prompted until there is no code conflict. , the corresponding feature branch and release branch can be smoothly merged. Of course, the user can also terminate the merging of related feature branches.

In an embodiment, the user may further add more candidate feature branches by triggering the add option in the to-be-released area 402; and the user may transfer more feature branches from the to-be-released zone to the integrated zone, and then is transferred. The feature branch to the integrated area can be merged with the advertised branch, and the process is the same as the above-mentioned feature branches 1 and 2, and details are not described herein again.

It should be noted that:

When each feature branch is added to the to-be-released area 402 or the integrated area 401, audit operations for the feature branch, such as code review, security audit, etc., may be triggered, and this specification does not limit this. After the audit is completed, the corresponding audit result can be recorded in the snapshot corresponding to the feature branch. As long as the code of the feature branch has not changed, the snapshot and the audit result it contains are valid for the feature branch; for example, assume The rule is defined as the feature branch added to the integration area 401 must pass the audit. If the audit result corresponding to the feature branch 1 is recorded in the snapshot 1 corresponding to the feature branch 1, and the audit result is approved, then the code of the feature branch 1 is used. No change can be added directly to the integration area 401 based on the audit result in the snapshot, without repeating the audit operation for the feature branch 1.

In one scenario, the feature branch can be removed from the release branch, involving steps 310B-312B described below.

Step 310B, when it is necessary to remove the feature branch, go to step 312B, otherwise go to step 320.

In step 312B, the feature branch is stripped from the publishing branch.

In an embodiment, in addition to adding a feature branch, the user may remove the previously added feature branch. For example, as shown in FIG. 4C, the user can drag the icons 51 to 52 from the integration area 401 to the to-be-released area 402, so that the characteristic branches 1 to 2 are removed from the distribution branch, and the corresponding characteristic branch codes 1 to 2 can also be used. It is automatically stripped from the release branch code to return to the situation as shown in FIG. 4B.

Step 320: When it is not necessary to add or remove a feature branch, create an instance according to the feature branch already included in the publishing branch, and generate a code version.

In an embodiment, after the addition or removal of the feature branch is completed, the user can trigger the completion of the branch integration operation, so that the application publishing system can generate an instance of the application X, the instance including the trunk code and the release branch code, wherein the branch is released The code is obtained by combining the feature branch codes corresponding to all the feature branches finally included in the integration area 401.

For example, assuming that the branch integration operation is completed in the state shown in FIG. 4C, since the integration area 401 includes the characteristic branches 1 to 2 as shown in FIG. 4C, the instance can be used to issue the corresponding new characteristics 1 to 2. The application publishing system can generate new instances each time the user triggers the branch integration operation; in order to distinguish different instances and perform accurate traceability or related processing for each instance, a corresponding code version can be generated for each instance. For example, the code version of the example corresponding to FIG. 4C may be V-1.1.1.

After the branch integration phase is completed, the instance generated by the application publishing system can be transferred to the subsequent release phase for processing. In order to facilitate the user to determine the instance and related information that is run in each release phase, related information of the instance running in the release phase may be displayed in the information display area corresponding to each release phase. For example, FIG. 5 is a schematic diagram showing information related to an example of running a release phase provided by an exemplary embodiment; as shown in FIG. 5, when the above code version is an instance of V-1.1.1, the instance is running in the release phase. The information presentation area corresponding to the "construction" of the release phase may include two parts: the first part is located in the icon 41, and is used to display the code version "V-1.1.1" of the running instance, and the second part includes FIG. The feature branch display area 410 is shown to show that the feature branches included in the running instance are the feature branches 1 to 2, and are specifically presented as the icons 51 to 52 displayed in the feature branch display area 410. Therefore, based on the content shown in FIG. 5, the user can quickly and accurately determine that the release phase "builds" an instance of the running code version V-1.1.1, and the instance includes the feature branches 1-2.

FIG. 6 is a schematic diagram of creating a new instance according to 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 feature branch 3 to the release branch by dragging the icon 53 from the to-be-released area 402 to the integration area 401, which is the same as the above. Steps 310A-318 are similar; further, when the user triggers the completion of the branch integration operation, the application publishing system may generate a new instance, and the release branch included in the instance is merged by the feature branches 1 to 3 finally included in the integration area 401 (ie, released) The branch code is obtained by combining the feature branch codes 1 to 3). At the same time, the application publishing system can generate a corresponding code version for the new instance, for example, the code version of the new instance can be V-1.1.2.

FIG. 7 is a schematic diagram of related information respectively showing an example of running a plurality of publishing stages, according to an exemplary embodiment. As shown in FIG. 7, after the release phase "build" completes the running of the instance with the code version V-1.1.1, the instance of the code version V-1.1.1 is transferred to the "release" phase of the subsequent release phase. The above version of the code version V-1.1.2 is transferred to the "build" run of the release phase. Then, similar to the embodiment shown in FIG. 5, the information display area corresponding to the "build" in the release stage can display related information of the instance of the code version V-1.1.2, and the information corresponding to the "daily" in the release stage. The display area shows information about instances of this code version V-1.1.1. The information display area corresponding to the "construction" of the release stage includes an icon 41 and a characteristic branch display area 410 for displaying the code version "V-1.1.2" and the icons 51 to 53 corresponding to the characteristic branches 1 to 3, respectively; The information display area corresponding to "Daily" includes an icon 42 and a characteristic branch display area 420 for respectively displaying the code versions "V-1.1.1" and the icons 51 to 52 corresponding to the characteristic branches 1 to 2.

In an embodiment, when there is a running instance in the publishing phase, the information display area corresponding to the publishing phase may be continuously displayed for the user to view; for example, in the embodiment shown in FIG. 5, the continuous display publishing phase is “built. The corresponding icon 41 and the characteristic branch display area 410, and in the embodiment shown in FIG. 7, continue to display the icon 41 corresponding to the "construction" of the release phase and the feature branch display area 410, and the icon 42 corresponding to the "daily" release stage. And feature branch display area 420. In another embodiment, the user may select a release stage of interest and display only the information display area corresponding to the selected release stage. For example, FIG. 8 is a schematic diagram showing related information of an instance running in a selected release phase provided by an exemplary embodiment; as shown in FIG. 8, it is assumed that the release phase "build" running code version is V-1.1.3. The instance, the release phase "everyday" running code version is an instance of V-1.1.2, and the release phase "official" running code version is an instance of V-1.1.1. When the user selects the publishing stage "official", the corresponding icon 43 can adopt a thick border as shown in FIG. 8 to distinguish between the icons 40 to 42 using the thin border, etc., to indicate that the publishing stage is "formally" selected by the user; The feature branch display area 430 can be shown, and the corresponding icons 51-52 are displayed in the new branch display area 430 according to the feature branches 1 to 2 included in the example of the code version V-1.1.1.

FIG. 9 is a flowchart of an implementation of a rollback operation provided by an exemplary embodiment. As shown in FIG. 9, the implementation process of the rollback operation may include the following steps:

In step 902, the release record is saved.

In an embodiment, when the instance runs on the release pipeline, the application publishing system may generate corresponding release record information for each instance and record it in the release record described above.

In step 904, the target version of the rollback is selected.

In an embodiment, it is assumed that an instance of the code version V-1.1.3 is released to the online environment through the release pipeline, and it is found that a running exception occurs and needs to be rolled back to the instance where the exception has not occurred before. The user can select an instance of the target version that is desired to be rolled back by querying the above-mentioned release record. For example, the target version may be V-1.1.1; for example, the user may trigger the code version to correspond to the instance of V-1.1.1. The record information is published such that the release pipeline implements a rollback operation for the instance of the code version V-1.1.1.

In step 906, the deployment package is rolled back to the target version.

In an embodiment, the rollback operation may include two parts: a first part, rolling back a deployment package on the server, and rolling back the deployment package to the target version; and a second part, code update. In some cases it may only be necessary to implement deployment package rollback, while in other cases it may be necessary to implement code updates.

In step 908, when it is necessary to update the code, the process proceeds to step 910, otherwise the rollback ends.

In step 910, an instance corresponding to the target version is determined.

Step 912, implementing a code update.

In an embodiment, when it is determined that the instance corresponding to the target version is an 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 obtained to implement the code update.

In an embodiment, when it is determined that the instance corresponding to the target version is an instance of the code version V-1.1.1, it may be based on an instance of the code version V-1.1.3 and an instance of the code version V-1.1.1. Differences, implement the corresponding code update. For example, assuming that the instance of code version V-1.1.1 contains feature branches 1 to 2, and the instance of code version V-1.1.3 contains feature branches 1 to 4, the code update process is equivalent to the code version V-1.1.3. In the example of the stripping characteristic branches 3 to 4, the characteristic branch codes 3 to 4 corresponding to the characteristic branches 3 to 4 are stripped from the issuing branch code of the example of the code version V-1.1.3, thereby being updated to the code version V-1.1. An example of .1.

FIG. 10 is a flowchart of sharing a publishing branch between multiple publishing pipelines according to an exemplary embodiment. As shown in FIG. 10, the process of sharing a publishing branch between multiple publishing pipelines may include the following steps:

In step 1002, a release branch is created.

In step 1004, the trunk code is merged with the release branch.

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

Step 1006: Import the release branch of the instance of the associated release pipeline.

In an embodiment, when an instance has been generated on a release pipeline, the feature branches included in the release branch of the instance have been merged, and the feature branches have passed the audit, and there is no code conflict, then When another release pipeline also needs to use these feature branches, it can share branches by sharing, so that it is not necessary to repeatedly perform auditing of feature branches, checking for code conflicts, and merging feature branch codes, etc., to improve publishing efficiency.

For example, FIG. 11 is a schematic diagram of sharing a publishing branch between multiple publishing pipelines according to an exemplary embodiment. It is assumed that a release pipeline corresponding to the application X includes a branch integration, construction, daily, formal, and the like release phases, which respectively correspond to the icons 1100 to 1103 shown in FIG. In the feature branch management interface 111 corresponding to the branch integration operation, an integration area 1111 and a to-be-released area 1112 are included. In one case, the user can add a feature branch provided by the developer to the to-be-released area 1112 by triggering the add option in the to-be-released area 1112, and transfer the required feature branch to the integration area 1111, respectively, to complete the branch of the feature. Merger. In another case, it is assumed that there is an association relationship between the issue pipeline shown in FIG. 11 and the issue pipeline shown in FIG. 4C; the release pipeline shown in FIG. 4C has created an instance of the code version V-1.1.1. Then, if the release pipeline shown in FIG. 11 also wants to adopt the feature branches 1 to 2, the release branch of the instance whose code version is V-1.1.1 can be directly imported into the integration area by triggering the import option in the integration area 1111. 1111, the corresponding release branch code is merged with the main code of the release pipeline shown in FIG. 11, without the need to merge the feature branch code 1, the feature branch code 2, and the code conflict.

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

In an embodiment, it is assumed 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 generation example shown in FIG. 4C, the release pipeline can be released at any time. The branches are shared to the release pipeline shown in FIG. 11, so that the two release pipelines can be processed at least partially in parallel to improve the release efficiency; in another case, the branch share can be released after the release pipeline shown in FIG. 4C is completed. Go to the release pipeline shown in Figure 11.

FIG. 12 is a schematic structural diagram of an apparatus provided by an exemplary embodiment. Referring to FIG. 12, at the hardware level, the device includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a non-volatile memory 1210, and of course may also include hardware required for other services. The processor 1202 reads the corresponding computer program from the non-volatile memory 1210 into the memory 1208 and then operates to form an application publishing device at a logical level. Of course, in addition to the software implementation, one or more embodiments of the present specification do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution body of the following processing flow is not limited to each. A logical unit, which can also be a hardware or logic device.

Referring to FIG. 13, in the software implementation, the application publishing apparatus may include:

The stage display unit 1301 displays multiple release stages of the 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 that is respectively executed in each release stage.

Optionally, it also includes:

The feature display unit 1303 displays the feature branches included in the release branch of the instance in the information display area corresponding to the corresponding release stage.

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

Optionally, it also includes:

The interface display unit 1304 is configured to display a feature branch management interface of the publishing branch, where the feature branch management interface includes an integrated area and a to-be-released area, where the integrated area is used to display the selected feature branch, and the to-be-released area is used for displaying An alternative feature branch; wherein the release branch code is obtained by combining the feature branch codes corresponding to the selected feature branches;

The feature branch selecting unit 1305, according to the received feature branch selection instruction, transfers the selected candidate feature branch to the integrated area to be displayed as the selected feature branch in the integrated area.

Optionally, it also includes:

The feature branch removal unit 1306, according to the received feature branch removal instruction, transfers at least one selected feature branch of the integration zone to the to-be-released zone to be displayed as an candidate feature branch in the to-be-released zone.

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

The feature branch adding unit 1307 adds at least one candidate feature branch to the feature branch management interface according to the received feature branch adding instruction;

The feature branch deleting unit 1308 deletes at least one candidate feature branch from the feature branch management interface according to the received feature branch deletion instruction.

Optionally, it also includes:

The first generating unit 1309 generates a new instance according to the changed selected characteristic branch when the selected characteristic branch in the integrated area changes, and the code version of the new instance is different from the historical code version of the historical instance.

Optionally, it also includes:

The issue branch adjustment unit 1310 performs at least one of the following adjustment operations according to the received release branch adjustment instruction: combining the feature branch code corresponding to the at least one feature branch to the release branch code, and the feature corresponding to the at least one feature branch The branch code is stripped from the release branch code.

Optionally, it also includes:

The obtaining unit 1311 is configured to obtain an adjusted post branch code obtained based on the issuing branch adjustment instruction;

The second generating unit 1312 generates a corresponding new instance according to the adjusted post branch code, where the code version of the new instance is different from the historical code version of the historical instance.

Optionally, it also includes:

The conflict detecting unit 1313 detects whether a code conflict occurs when the feature branch code of any feature branch is merged into the issuing branch code.

The conflict processing unit 1314, when a code conflict occurs, strips the characteristic branch code of any of the feature branches from the release branch code, and generates a corresponding conflict prompt to the preset user.

Optionally, it also includes:

The information storage unit 1315 saves the release record information of the corresponding instance of each code version;

The information searching unit 1316, after the first instance of the first code version is released to the online environment, searches for the second code according to the received rollback instruction from the first code version to the second code version. Release record information for the second instance of the version;

The difference determining unit 1317 determines, according to the found release record information, a difference between the second instance and the characteristic branch included in the first instance;

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, it also includes:

The pipeline determining unit 1319 determines at least one associated publishing pipeline corresponding to the publishing pipeline to which the plurality of publishing stages belong;

A providing unit 1320 provides the publishing branch of the instance to the associated publishing pipeline to form and run a corresponding instance on the associated publishing pipeline.

Optionally, it also includes:

The audit result recording unit 1321 acquires an audit result of the feature branch, and records the snapshot data corresponding to the feature branch;

The situation determining unit 1322 determines the audit status of the feature branch according to the audit result recorded in the corresponding snapshot data when the feature branch does not change.

The system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function. A typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, and a game control. A combination of a tablet, a tablet, a wearable device, or 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 non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory. Memory is an example of a computer readable medium.

Computer readable media includes both permanent and non-persistent, removable and non-removable media. Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media 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, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic cassette tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transporting media can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.

It is also to be understood that the terms "comprises" or "comprising" or "comprising" or any other variations are intended to encompass a non-exclusive inclusion, such that a process, method, article, Other elements not explicitly listed, or elements that are inherent to such a process, method, commodity, or equipment. An element defined by the phrase "comprising a ..." does not exclude the presence of additional equivalent elements in the process, method, item, or device including the element.

The foregoing description of the specific embodiments of the specification has been described. 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 the embodiments and still achieve the desired results. In addition, the processes depicted in the figures are not necessarily in a particular order or in a sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terms used in one or more embodiments of the present specification are for the purpose of describing particular embodiments, and are not intended to limit one or more embodiments. The singular forms "a", "the", and "the" It should also be understood that the term "and/or" as used herein refers to and encompasses any and 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 to describe various information in one or more embodiments of the specification, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information may also be referred to as the second information without departing from the scope of one or more embodiments of the present disclosure. Similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to a determination."

The above is only a preferred embodiment of one or more embodiments of the present specification, and is not intended to limit one or more embodiments of the present specification, which is within the spirit and principles of one or more embodiments of the present specification, Any modifications, equivalent substitutions, improvements, etc., are intended to be included within the scope of the protection of one or more embodiments.

Claims

An application publishing method, comprising:

Show multiple release phases of the app;

The code version of the instance is displayed in the information display area corresponding to the corresponding release stage according to the instance of the application that is respectively run in each release stage.
The method of claim 1 further comprising:

The feature branches included in the publishing branch of the instance are displayed in the information display area corresponding to the corresponding publishing stage.
The method according to claim 2, wherein the instance comprises a trunk code of the application, a release branch code corresponding to the release branch, and the release branch code is merged by a feature branch code corresponding to the feature branch. get.
The method of claim 3, further comprising:

The feature branch management interface of the publishing branch is displayed, where the feature branch management interface includes an integrated area and a to-be-released area, where the integrated area is used to display the selected feature branch, and the to-be-released area is used to display the candidate feature branch; The issue branch code is obtained by combining the feature branch codes corresponding to the selected feature branches;

The selected candidate feature branch is transferred to the integration zone according to the received feature branch selection instruction to be displayed as the selected feature branch in the integration zone.
The method of claim 3, further comprising:

The feature branch management interface of the publishing branch is displayed, where the feature branch management interface includes an integrated area and a to-be-released area, where the integrated area is used to display the selected feature branch, and the to-be-released area is used to display the candidate feature branch; The issue branch code is obtained by combining the feature branch codes corresponding to the selected feature branches;

And transmitting, according to the received feature branch removal instruction, at least one selected feature branch of the integrated area to the to-be-released area to be displayed as an alternate feature branch in the to-be-released area.
The method according to claim 4 or 5, further comprising at least one of the following:

Adding at least one candidate feature branch to the feature branch management interface according to the received feature branch adding instruction;

And deleting at least one candidate feature branch from the feature branch management interface according to the received feature branch deletion instruction.
The method according to claim 4 or 5, further comprising:

When the selected feature branch in the integrated zone changes, a new instance is generated based on the changed selected feature branch, the code version of the new instance being different from the historical code version of the historical instance.
The method of claim 3, further comprising:

And performing, according to the received release branch adjustment instruction, at least one of the following adjustment operations: combining the feature branch code corresponding to the at least one feature branch with the release branch code, and the feature branch code corresponding to the at least one feature branch and the issuing The branch code is stripped.
The method of claim 8 further comprising:

Obtaining an adjusted release branch code obtained based on the release branch adjustment instruction;

A corresponding new instance is generated according to the adjusted post branch code, and the code version of the new instance is different from the historical code version of the historical instance.
The method of claim 3, further comprising:

Detecting whether a code conflict occurs when the feature branch code of any feature branch is merged into the release branch code;

When a code conflict occurs, the feature branch code of any of the feature branches is stripped from the release branch code, and a corresponding conflict prompt is generated to the preset user.
The method of claim 2, further comprising:

Separate the release record information of the corresponding instance of each code version;

After the first instance of the first code version is released to the online environment, searching for a second instance corresponding to the second code version according to the received rollback instruction from the first code version to the second code version Release record information;

Determining, according to the found release record information, a difference between the second instance and a feature branch included in the first instance;

The release branch code in the first instance is adjusted according to the difference to automatically roll back to the second instance.
The method of claim 1 further comprising:

Determining at least one associated release pipeline corresponding to the release pipeline to which the multiple release stages belong;

A publishing branch of the instance is provided to the associated publishing pipeline to form and run a corresponding instance on the associated publishing pipeline.
The method of claim 2, further comprising:

Obtaining an audit result of the feature branch, and recording the snapshot data corresponding to the feature branch;

When the feature branch does not change, the audit status of the feature branch is determined according to the audit result recorded in the corresponding snapshot data.
An application publishing device, comprising:

A stage display unit that displays multiple release phases of the application;

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 running in each release stage.
The device according to claim 14, further comprising:

The feature display unit displays the feature branches included in the release branch of the instance in the information display area corresponding to the corresponding release stage.
The apparatus according to claim 15, wherein the instance comprises a trunk code of the application, a release branch code corresponding to the release branch, and the release branch code is merged by a feature branch code corresponding to the feature branch. get.
The device according to claim 16, further comprising:

An interface display unit, where the feature branch management interface of the publishing branch is displayed, where the feature branch management interface includes an integrated area and a to-be-released area, where the integrated area is used to display the selected feature branch, and the to-be-released area is used for displaying the standby Selecting a feature branch; wherein the issue branch code is obtained by combining the feature branch codes corresponding to the selected feature branch;

The feature branch selection unit transfers the selected candidate feature branch to the integration zone according to the received feature branch selection instruction to be displayed as the selected feature branch in the integration zone.
The device according to claim 16, further comprising:

An interface display unit, where the feature branch management interface of the publishing branch is displayed, where the feature branch management interface includes an integrated area and a to-be-released area, where the integrated area is used to display the selected feature branch, and the to-be-released area is used for displaying the standby Selecting a feature branch; wherein the issue branch code is obtained by combining the feature branch codes corresponding to the selected feature branch;

The feature branch removal unit transfers the at least one selected feature branch of the integration area to the to-be-released area according to the received feature branch removal instruction to be displayed as an candidate feature branch in the to-be-released area.
The apparatus according to claim 17 or 18, further comprising at least one of the following:

The feature branch adding unit adds at least one candidate feature branch to the feature branch management interface according to the received feature branch adding instruction;

The feature branch deleting unit deletes at least one candidate feature branch from the feature branch management interface according to the received feature branch deletion instruction.
The device according to claim 17 or 18, further comprising:

The first generating unit generates a new instance according to the changed selected feature branch when the selected feature branch in the integrated area changes, and the code version of the new instance is different from the historical code version of the historical instance.
The device according to claim 16, further comprising:

And a release branch adjustment unit, configured to perform at least one of the following adjustment operations according to the received release branch adjustment instruction: merge the feature branch code corresponding to the at least one feature branch with the release branch code, and branch the feature branch corresponding to the at least one feature branch The code is stripped from the release branch code.
The device according to claim 21, further comprising:

Obtaining a unit, and obtaining an adjusted release branch code obtained based on the release branch adjustment instruction;

The second generating unit generates a corresponding new instance according to the adjusted post branch code, where the code version of the new instance is different from the historical code version of the historical instance.
The device according to claim 16, further comprising:

The conflict detection unit detects whether a code conflict occurs when the feature branch code of any feature branch is merged into the release branch code;

The conflict processing unit, when a code conflict occurs, strips the characteristic branch code of the any feature branch from the release branch code, and generates a corresponding conflict prompt to the preset user.
The device according to claim 15, further comprising:

The information saving unit separately saves the release record information of the corresponding instance of each code version;

An information searching unit, after the first instance of the first code version is released to the online environment, searching for a second code version according to the received rollback instruction from the first code version to the second code version Release record information of the second instance;

a difference determining unit, determining, according to the found release record information, a difference between the second instance and a feature branch included in the first instance;

The code adjustment unit adjusts the release branch code in the first instance according to the difference to automatically roll back to the second instance.
The device according to claim 14, further comprising:

a pipeline determining unit, configured to determine at least one associated publishing pipeline corresponding to the publishing pipeline to which the plurality of publishing stages belong;

A providing unit is provided to the publishing branch of the instance to the associated publishing pipeline to form and run a corresponding instance on the associated publishing pipeline.
The device according to claim 15, further comprising:

An audit result recording unit obtains an audit result of the feature branch and records the snapshot data corresponding to the feature branch;

The situation determining unit determines, when the feature branch does not change, the audit status of the feature branch according to the audit result recorded in the corresponding snapshot data.