CN116225521A

CN116225521A - Record delivery method, apparatus, device, medium, and program product

Info

Publication number: CN116225521A
Application number: CN202310220814.5A
Authority: CN
Inventors: 侯锦坚; 吴利华; 赵培桐
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2023-03-09
Filing date: 2023-03-09
Publication date: 2023-06-06

Abstract

The disclosure provides a record delivery method, which can be applied to the technical field of information security. The record delivery method comprises the following steps: receiving first package information, wherein the first package information comprises a production date; performing first matching based on the production date to obtain a plurality of script records under the production date, wherein the script records comprise a first version identifier and a second version identifier; acquiring second packaging information based on the first version identifier and the second version identifier; matching and packaging script records in a plurality of script records through preset packaging rules based on the production date, the second packaging information, the first version identification and the second version identification, wherein the preset packaging rules comprise a plurality of delivery sub-rules, and the selection of the delivery sub-rules is determined based on the first version identification and the second version identification; and sending the script record. The present disclosure also provides a record delivery apparatus, device, storage medium, and program product.

Description

Record delivery method, apparatus, device, medium, and program product

Technical Field

The present disclosure relates to the field of information security technology, and in particular, to a record delivery method, apparatus, device, medium, and program product.

Background

The metadata table structure management platform (or data table structure management platform) is used for recording change, packaging and delivery information of a table structure. When using the platform change table structure, a developer automatically generates a script (e.g., DDL) executable in the database according to the change content. When the user starts the packing and/or delivering process, the user can call the corresponding script to realize packing and delivering.

With the advancement of platform strategy under large host data, more and more applications use open platform database technology, which causes the scene demand of packaging and delivery to increase, while in the prior art, at the beginning of designing an application version number (which can be used for matching of packaging and delivery), these effects are not considered, but only by designing with other related data through delivery date, which causes problems of poor compatibility, offset delivery efficiency, etc. when coping with packaging and delivery scenes with the demand increase, these problems will cause delivery failure.

Disclosure of Invention

In view of the above, the present disclosure provides a record delivery method, apparatus, device, medium, and program product that improve record delivery compatibility and delivery efficiency.

According to a first aspect of the present disclosure, there is provided a record delivery method including: receiving first package information, wherein the first package information comprises a production date; performing first matching based on the production date to obtain a plurality of script records under the production date, wherein the script records comprise a first version identifier and a second version identifier; receiving second packaging information, wherein the second packaging information is distinguished based on the first version identification and the second version identification; matching and packaging script records in the script records through preset packaging rules based on the production date, the second packaging information, the first version identifier and the second version identifier, wherein the preset packaging rules comprise a plurality of delivery sub-rules, and the selection of the delivery sub-rules is determined based on the first version identifier and the second version identifier; and transmitting the script record.

According to an embodiment of the present disclosure, the first version identification includes: a seal board version and a patch version, the second version identification including a process version and a delivery version, the seal board version and the patch version being differentiated based on a day of delivery, the process version and the delivery version being differentiated based on whether delivery conditions are met, the receiving second packaging information being differentiated based on the first version identification and the second version identification, comprising: in the case that the first version is identified as a shrouding version and the second version is identified as a process version, the received second package information is empty; in the case that the first version is identified as a seal board version and the second version is identified as a delivery version, the received second package information is a delivery date; in the case that the first version is identified as a patch version and the second version is identified as a process version, the received second packaging information is a question number; and in the case that the first version is identified as a patch version and the second version is identified as a delivery version, the received second packaging information is a delivery date and a problem number.

According to an embodiment of the present disclosure, the process version and the delivery version correspond to different version states, the version states include to-be-integrated, to-be-issued, and the matching and packaging script records in the plurality of script records through a preset packaging rule based on the production date, the second packaging information, the first version identifier, and the second version identifier includes: under the condition that the first version is identified as a closing plate version and the second version is identified as a process version, matching and packaging the script records based on the production date and the version state to be integrated; matching and packaging the script records based on the date of production, the date of delivery, and the status of the integrated and/or to-be-published version, if the first version is identified as a shrouded version and the second version is identified as a delivered version; matching and packaging the script records based on the production date, the problem number and the version state to be integrated under the condition that the first version is identified as a patch version and the second version is identified as a process version; and matching and packaging the script records based on the date of production, the problem number, the date of delivery, and the integrated and/or to-be-released version status, in the case that the first version is identified as a patch version and the second version is identified as a delivery version.

According to an embodiment of the present disclosure, after the matching and packaging script records in the plurality of script records by a preset packaging rule based on the production date, the second packaging information, the first version identifier and the second version identifier, the method further includes: converting the version state from the to-be-integrated to the integrated if the second version is identified as the process version; and converting the version state from the integrated version to the to-be-issued or keeping the version state unchanged by the to-be-issued if the second version is identified as the delivery version.

According to an embodiment of the present disclosure, after sending the script record, the method further includes: modifying the version status to published if the second version is identified as the process version; and modifying the version status to published if the second version is identified as the delivered version.

According to a second aspect of the present disclosure, there is provided a record delivery method including: transmitting first package information, wherein the first package information comprises a production date; transmitting second package information from the user input; and receiving script records from the data table structure management platform to complete delivery.

In a third aspect of the present disclosure, there is provided a record delivery device including: the first package information receiving module is used for receiving first package information, wherein the first package information comprises a production date; the first matching module is used for carrying out first matching based on the production date to obtain a plurality of script records under the production date, wherein the script records comprise a first version identifier and a second version identifier; the second package information receiving module is used for receiving second package information, and the second package information is distinguished based on the first version identification and the second version identification; the second matching module is used for matching and packaging script records in the script records through a preset packaging rule based on the production date, the second packaging information, the first version identifier and the second version identifier, wherein the preset packaging rule comprises a plurality of delivery sub-rules, and the selection of the delivery sub-rules is determined based on the first version identifier and the second version identifier; and the script record sending module is used for sending the script record.

According to an embodiment of the present disclosure, the first version identification includes: the second version identification comprises a process version and a delivery version, the process version and the delivery version are distinguished based on the front and the rear of the delivery date, the process version and the delivery version are distinguished based on whether the delivery condition is met, and the second package information receiving module is used for receiving the second package information which is empty when the first version identification is the process version and the second version identification is the process version; in the case that the first version is identified as a seal board version and the second version is identified as a delivery version, the received second package information is a delivery date; in the case that the first version is identified as a patch version and the second version is identified as a process version, the received second packaging information is a question number; and in the case that the first version is identified as a patch version and the second version is identified as a delivery version, the received second packaging information is a delivery date and a problem number.

According to an embodiment of the disclosure, the process version and the delivery version correspond to different version states, the version states include to-be-integrated, to-be-issued, and the second matching module is configured to match and package the script record based on the production date and the version state to-be-integrated, if the first version is identified as a closing plate version and the second version is identified as a process version; matching and packaging the script records based on the date of production, the date of delivery, and the status of the integrated and/or to-be-published version, if the first version is identified as a shrouded version and the second version is identified as a delivered version; matching and packaging the script records based on the production date, the problem number and the version state to be integrated under the condition that the first version is identified as a patch version and the second version is identified as a process version; and matching and packaging the script records based on the date of production, the problem number, the date of delivery, and the integrated and/or to-be-released version status, in the case that the first version is identified as a patch version and the second version is identified as a delivery version.

According to an embodiment of the disclosure, the apparatus further comprises: a state modification module, configured to convert the version state from the to-be-integrated to the integrated version if the second version is identified as the process version; and converting the version state from the integrated version to the to-be-issued or keeping the version state unchanged by the to-be-issued if the second version is identified as the delivery version.

According to an embodiment of the disclosure, the state modifying module is further configured to modify the version state to published if the second version is identified as the process version; and modifying the version status to published if the second version is identified as the delivered version.

In a fourth aspect of the present disclosure, there is provided a record delivery device including: the first package information sending module is used for sending first package information, wherein the first package information comprises a production date; the second packaging information sending module is used for sending second packaging information input by a user; and the script record receiving module is used for receiving script records from the data table structure management platform to finish delivery.

In a fifth aspect of the present disclosure, there is provided an electronic device, including: one or more processors; and a memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the record delivery method described above.

In a sixth aspect of the present disclosure, there is also provided a computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the above-described record delivery method.

In a seventh aspect of the present disclosure, there is also provided a computer program product comprising a computer program which, when executed by a processor, implements the above-described record delivery method.

In the embodiment of the disclosure, matching is performed based on the date of production rather than the date of delivery, and the actual date of delivery is prevented from being disordered when packaging, so that the matching of record delivery is prevented from being influenced. And the matching method of the record delivery is suitable for a plurality of scenes by adopting staged acquisition on the basis of the matching record of the production date, and particularly can be compatible with massive packaging delivery scenes when meeting the increasing record delivery demands.

Drawings

The foregoing and other objects, features and advantages of the disclosure will be more apparent from the following description of embodiments of the disclosure with reference to the accompanying drawings, in which:

FIG. 1 schematically illustrates an application scenario diagram of a record delivery method according to an embodiment of the present disclosure;

FIG. 2A schematically illustrates a schematic diagram of a matching script DDL rule, according to an embodiment of the present disclosure;

FIG. 2B schematically illustrates a schematic diagram of a DDL status update process, according to an embodiment of the present disclosure;

FIG. 3 schematically illustrates a flow chart of a record delivery method according to an embodiment of the present disclosure;

FIG. 4 schematically illustrates a flow chart of a method of distinguishing a second packed data according to an embodiment of the disclosure;

FIG. 5A schematically illustrates a flow diagram of a script record packing method in accordance with an embodiment of the present disclosure;

FIG. 5B schematically illustrates a schematic diagram of another matching script DDL rule, according to an embodiment of the present disclosure;

FIG. 6 schematically illustrates a flow chart of a record delivery method according to an embodiment of the present disclosure;

FIG. 7 schematically illustrates a flow chart of a record delivery method according to an embodiment of the present disclosure;

FIG. 8 schematically illustrates a schematic diagram of another DDL status update process, according to an embodiment of the present disclosure;

FIG. 9 schematically illustrates a flow chart of another record delivery method according to an embodiment of the present disclosure;

FIG. 10 schematically illustrates a schematic diagram of an information interaction flow between a persistent delivery pipeline side and a SEAS side according to an embodiment of the present disclosure;

FIG. 11 schematically illustrates a schematic diagram of a DDL packing mode, according to an embodiment of the present disclosure;

FIG. 12 schematically illustrates a block diagram of a record delivery device according to an embodiment of the present disclosure;

FIG. 13 schematically illustrates a block diagram of another record delivery device according to an embodiment of the present disclosure; and

fig. 14 schematically illustrates a block diagram of an electronic device adapted to implement a record delivery method according to an embodiment of the present disclosure.

Detailed Description

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is only exemplary and is not intended to limit the scope of the present disclosure. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. In addition, in the following description, descriptions of well-known structures and techniques are omitted so as not to unnecessarily obscure the concepts of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The terms "comprises," "comprising," and/or the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It should be noted that the terms used herein should be construed to have meanings consistent with the context of the present specification and should not be construed in an idealized or overly formal manner.

Where expressions like at least one of "A, B and C, etc. are used, the expressions should generally be interpreted in accordance with the meaning as commonly understood by those skilled in the art (e.g.," a system having at least one of A, B and C "shall include, but not be limited to, a system having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).

Before the embodiments of the present disclosure are disclosed in detail, key technical terms related to the embodiments of the present disclosure are described one by one as follows:

Data definition language: (Data Definition Language, referred to as DDL for short) some objects in the database are managed, such as Create and Drop.

Continuous delivery pipeline: in order to quickly realize the service value, a set of version continuous delivery system suitable for version management flow and automation is developed by referring to the DevOps concept in the industry, the state from source code management to the whole production process is displayed, and a visual function is provided. The current persistent delivery pipeline supports the packaging and delivery of versions.

A data table structure management platform: or metadata table structure management platform, abbreviated as SEAS, records the change, package and delivery information of the table structure. When a developer uses the platform change table structure, a script (for example, DDL) executable in the database is automatically generated according to the change content. And the user starts the packing flow through the continuous delivery flow line, and the continuous delivery flow line can call SEAS to acquire the corresponding script executed in the database, so that packing and delivery are realized.

Defect problem management system: or DCM, is used to support management of various defects and changes in the lifecycle of the software product.

The demand item: as a minimum range of demands which are consistent in communication between business and science and technology, can be independently put into production and have business value, each demand item comprises attributes such as application, delivery date, put into production date and the like.

Application version number: and grouping the required items which meet the same condition and need to be delivered according to some specific conditions, and assigning an identifier to each group, namely the application version number.

Process version: and (5) a packaged version in the development process is used for testing by a tester.

Delivery version: and packaging the version of the content to be delivered after the deliverable condition is met according to the test result so as to put into production and deploy in the production environment.

Seal DDL: DDL change records submitted on sea prior to the date of delivery of the demand item.

Patch DDL: DDL change records submitted on sea after the demand item delivery date.

To solve the technical problems existing in the prior art, an embodiment of the present disclosure provides a record delivery method, including: receiving first package information, wherein the first package information comprises a production date; performing first matching based on the production date to obtain a plurality of script records under the production date, wherein the script records comprise a first version identifier and a second version identifier; receiving second packaging information, wherein the second packaging information is distinguished based on the first version identification and the second version identification; matching and packaging script records in the script records through preset packaging rules based on the production date, the second packaging information, the first version identifier and the second version identifier, wherein the preset packaging rules comprise a plurality of delivery sub-rules, and the selection of the delivery sub-rules is determined based on the first version identifier and the second version identifier; and transmitting the script record.

Fig. 1 schematically illustrates an application scenario diagram of a record delivery method according to an embodiment of the present disclosure.

As shown in fig. 1, an application scenario 100 according to this embodiment may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the

terminal devices

101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user may interact with the server 105 via the network 104 using the

terminal devices

101, 102, 103 to receive or send messages or the like. Various communication client applications, such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only) may be installed on the

terminal devices

101, 102, 103.

The

terminal devices

101, 102, 103 may be a variety of electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.

The server 105 may be a server providing various services, such as a background management server (by way of example only) providing support for websites browsed by users using the

terminal devices

101, 102, 103. The background management server may analyze and process the received data such as the user request, and feed back the processing result (e.g., the web page, information, or data obtained or generated according to the user request) to the terminal device.

It should be noted that, the record delivery method provided by the embodiment of the present disclosure may be generally performed by the server 105. Accordingly, the record delivery device provided by the embodiments of the present disclosure may be generally provided in the server 105. The record delivery method provided by the embodiments of the present disclosure may also be performed by a server or a server cluster that is different from the server 105 and is capable of communicating with the

terminal devices

101, 102, 103 and/or the server 105. Accordingly, the record delivery device provided by the embodiments of the present disclosure may also be provided in a server or a server cluster that is different from the server 105 and is capable of communicating with the

terminal devices

101, 102, 103 and/or the server 105.

It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

The record delivery method of the disclosed embodiment will be described in detail below with reference to fig. 2A to 11 based on the scenario described in fig. 1.

Fig. 2A schematically illustrates a schematic diagram of matching script DDL rules according to an embodiment of the disclosure.

As shown in fig. 2A, in general, the matching script rule is: (1) The application version number is generated by an application+month version+delivery date; (2) The seal version is matched with the DDL state according to the application version number; (3) The patch version matches the DDL record according to the application version number + DCM problem number.

Specifically, when the process versions in the seal version are matched, the SEAS side information is sent on the continuous delivery pipeline side as follows: the SEAS side DDL record matching rule is as follows: the application version number+ddl state is "to be integrated"; when the delivery versions in the seal version are matched, the SEAS side information is sent on the continuous delivery pipeline side as follows: the matching rule of the SEAS side is as follows: the application version number + DDL state is "integrated".

Specifically, when the process versions in the patch versions are matched, the continuous delivery pipeline side sends SEAS side information as follows: applying version number + DCM problem number, the SEAS side DDL record matching rule is: the application version number + DCM problem number + DDL status is "to be integrated"; when the delivery versions in the patch versions are matched, the SEAS side information is sent on the continuous delivery pipeline side as follows: applying version number + DCM problem number, DDL record matching rules at sea side are: the application version number + DCM problem number + DDL status is "integrated".

Fig. 2B schematically illustrates a schematic diagram of a DDL status update process according to an embodiment of the disclosure.

As shown in FIG. 2B, the conditions that the status is updated from "to integrate" to "integrated" and the status is updated from "integrated" to "delivered" are that the packaging and version updating are successful. Under the condition that the process version is packed and updated successfully, updating the state to be integrated into the state integrated; in the event that the delivery version package and update is successful, the status "integrated" update is changed to status "delivered".

The developers found that, in conjunction with fig. 2A and 2B, script DDL packing and delivery in a partial scenario could be implemented, but in the solution shown in fig. 2A and 2B, the following drawbacks still exist, as follows:

(1) Since the application version numbers are generated according to the delivery date of the demand item, which causes different delivery dates to generate different application version numbers, and the versions (seal version and/or patch version) are packaged according to the application version numbers, the DDL script of which each version intelligently packages one delivery date is limited. In an actual development scenario, when a developer simultaneously develops multiple delivery date requirements on the same production date, all of the requirements need to be submitted together to a test scenario. In the current mode, only a plurality of version packages can be updated to the test environment, so that the actual development and test requirements are not met.

(2) In the delayed delivery scenario, the seal DDL and the patch DDL need to be packaged together, but in the modes of fig. 2A and 2B, the seal DDL or the patch DDL on one delivery day cannot be packaged together by intelligent packaging of one version, and the seal DDL records need to be manually invalidated and then submitted again in the form of the patch DDL, so that the seal DDL and the patch DDL can be packaged together, and the operation flow is complex.

(3) Under the scene that the delivery insurance book needs to be repackaged, a developer needs to rollback the state (from delivered rollback to integrated), the operation flow is complex and depends on manual operation, and the version packing cost is increased under the condition of missing rollback.

(4) When the DDL is successfully updated in the functional environment, the state is updated from 'integrated' to 'delivered', and the DDL is not hooked with the actual delivery step, so that the risk of delivery omission exists.

Fig. 3 schematically illustrates a flowchart of a record delivery method according to an embodiment of the present disclosure.

As shown in fig. 3, the record delivery method of this embodiment includes operations S310 to S350, and the record delivery method may be performed by the server 105.

In operation S310, first package information including a date of production is received.

Since the delivery process is performed interactively on the data table structure management platform side and the persistent delivery pipeline side, operations S310 to S350 are performed on the data table structure management platform side.

Specifically, the delivery date is different from the delivery date, the delivery date and the delivery date belong to two concepts, the delivery date generally comprises an expected delivery date and an actual delivery date, only one delivery date is adopted, the delivery date is adopted to replace the delivery date, one of the matching elements used for matching script records is adopted, and the problem that the adopted delivery date is easy to be confused is avoided.

In operation S320, a first matching is performed based on the production date, so as to obtain a plurality of script records under the production date, where the script records include a first version identifier and a second version identifier.

It will be appreciated that all script records are matched at a particular day of production. Script records that want to be packaged can then be extracted further from these script records.

In operation S330, second packing information is received, the second packing information being distinguished based on the first version identification and the second version identification.

Specifically, the second package information under the different first version identification and the different second version identification is different. That is, the script records under specific first and second version identifications can be purposefully obtained, and the data required for matching by the script records under the first and second version identifications is different.

According to an embodiment of the present disclosure, the first version identification includes: and the second version identifier comprises a process version and a delivery version, the seal plate version and the patch version are distinguished based on the front and the back of the delivery date, and the process version and the delivery version are distinguished based on whether the delivery condition is met or not.

Specifically, the process version is a version packaged in the development process for testing by a tester, and the delivery version is a version packaged with contents to be delivered after meeting the deliverable condition according to the test result so as to put into production and deploy in the production environment.

Fig. 4 schematically illustrates a flow chart of a method of distinguishing a second packed data according to an embodiment of the disclosure.

As shown in fig. 4, the second packed data distinguishing method of this embodiment includes operations S410 to S440, and operations S410 to S440 of this embodiment may at least partially perform operation S330 described above.

In operation S410, in a case where the first version is identified as a sealing board version and the second version is identified as a process version, the received second packing information is empty.

Namely, under the condition of being both the shrouding version and the process version, more packaging information does not need to be further acquired.

In operation S420, in case that the first version is identified as a closing board version and the second version is identified as a delivery version, the received second packing information is a delivery date.

I.e. in case of both the closure plate version and the delivery version, the delivery date also needs to be received. In particular, since the delivery version is an already delivered version, there is no concern that the expected delivery date is confused with the actual delivery date.

In operation S430, in case that the first version is identified as a patch version and the second version is identified as a process version, the received second packing information is a question number.

I.e. in case of both patch and process version, the question number needs to be received, which of course is an option or not. Specifically, the problem number is a problem number in DCM (defect management system) and is associated with a patch version.

In operation S440, in case that the first version is identified as a patch version and the second version is identified as a delivery version, the received second package information is a delivery date and a problem number.

That is, in the case of both the patch version and the delivery version, the delivery date and the question number need to be received, and of course, the delivery date and the question number are optional and may not be received.

In the embodiment of the disclosure, different matching means are adopted for different first version identifiers and second version identifiers, corresponding second packaging information is obtained before matching, and the packaging information is obtained in stages, so that the information obtaining cost can be reduced, and the method is applicable to more scenes.

In operation S340, the script records are matched and packaged in the plurality of script records through a preset packaging rule based on the date of production, the second packaging information, the first version identifier and the second version identifier, wherein the preset packaging rule includes a plurality of delivery sub-rules, and the selection of the delivery sub-rules is determined based on the first version identifier and the second version identifier.

Corresponding to the first version identifier and the second version identifier, the first version identifier comprises two versions, the second version identifier comprises two versions, four combinations exist (the above operations S410-S440), and four corresponding matched rules exist, namely four delivery sub-rules. Of course, when the first version identifier and the second version identifier are each greater than two, the combined number is the number of delivery sub-rules.

According to an embodiment of the present disclosure, the process version and the delivery version correspond to different version states, including to-be-integrated, to-be-issued, and issued.

Unlike the version state in fig. 2B, a version state "to be released" is added thereto.

Fig. 5A schematically illustrates a flowchart of a script record packing method in accordance with an embodiment of the present disclosure.

As shown in fig. 5A, the script recording packing method of this embodiment includes operations S510 to S540, and operations S510 to S540 of this embodiment may at least partially perform operation S340 described above.

In operation S510, in a case where the first version is identified as a closed-board version and the second version is identified as a process version, the script records are matched and packaged based on the date of production and the version status to be integrated.

The script record may be, for example, a script DDL record.

In operation S520, in case the first version is identified as a closing version and the second version is identified as a delivery version, the script records are matched and packaged based on the date of production, the date of delivery, and the status of the integrated and/or the version to be released.

In operation S530, in case that the first version is identified as a patch version and the second version is identified as a process version, the script records are matched and packaged based on the production date, the problem number, and the version status to be integrated.

In operation S540, in the case where the first version is identified as a patch version and the second version is identified as a delivery version, the script records are matched and packaged based on the date of production, the question number, the date of delivery, and the status of the integrated and/or the version to be released.

Specifically, each demand item has a delivery date, but there are cases where the demand is completed in advance or delayed in completion at the time of actual development work.

Packaging of process versions: for the same production date, the demand item codes of a plurality of delivery dates are simultaneously developed, and the demand item codes need to be simultaneously updated into the environment for testing by testers.

For packaging of delivery versions, developers and testers need to evaluate which DDLs can be packaged and delivered according to test results, and a requirement for supporting various packaging combinations exists in combination with evaluation results; packing DDL records for multiple delivery days simultaneously or packing DDL records for both the closure and patch simultaneously.

Fig. 5B schematically illustrates a schematic diagram of another matching script DDL rule according to an embodiment of the disclosure.

As shown in fig. 5B, in general, the matching script rule is: (1) the application version number is generated according to the production date instead; (2) When a process version of the package version is marked, acquiring DDL records to be integrated of all demand items under the production date according to the production date; (3) When packaging the delivery version of the envelope version, the corresponding DDL record is obtained from the date of production + date of delivery + integrated/to-be-delivered, where the date(s) of delivery require the user to provide.

Specifically, when the process versions in the seal version are matched, the SEAS side information is sent on the continuous delivery pipeline side as follows: the date of production, SEAS side DDL record matching rule is: the date of production+DDL state is "to be integrated"; when the delivery versions in the seal version are matched, the SEAS side information is sent on the continuous delivery pipeline side as follows: the matching rules of the SEAS side are as follows: the date of production + date of delivery + DDL status is "integrated/ready to be published".

Specifically, when the process versions in the patch versions are matched, the continuous delivery pipeline side sends SEAS side information as follows: the date of production+DCM problem number, SEAS side DDL record matching rule is: the application version number + DCM problem number + DDL status is "to be integrated"; when the delivery versions in the patch versions are matched, the SEAS side information is sent on the continuous delivery pipeline side as follows: the date of production, date of delivery and DCM problem number, and the DDL record matching rule at SEAS side is: the date of production, date of delivery, DCM issue number, DDL status is "integrated/ready to issue".

In the embodiment of the disclosure, for the delivered version, under the condition of delivering the version and packing work, the state is updated from 'integrated' to 'delivered', but when the delivery is not performed after packing, the state is 'delivered', which causes confusion, especially in the process of repacking the delivered version, the state is required to be changed first and then packed again, which increases the time consumption for use, and ensures correct flow by newly adding the 'to-be-distributed' state on the original basis, and the state does not need to be returned in the repacking process.

Fig. 6 schematically illustrates a flowchart of a record delivery method according to an embodiment of the present disclosure.

As shown in fig. 6, the record delivery method of this embodiment includes operations S610 to S620 in addition to operations S310 to S350 described above, and operations S610 to S620 are performed after operation S340 and before operation S350.

In operation S610, the version status is converted from the to-be-integrated into the integrated version in case the second version is identified as the process version.

In operation S620, in case the second version is identified as the delivered version, the version status is converted from the integrated version to the to-be-distributed or the version status is kept unchanged by the to-be-distributed.

In operation S350, the script record is transmitted.

Specifically, the script records are sent to a persistent delivery pipeline.

Fig. 7 schematically illustrates a flowchart of a record delivery method according to an embodiment of the present disclosure.

As shown in fig. 7, the record delivery method of this embodiment includes operations S710 to S720 in addition to operations S310 to S350 and operations S610 to S620 described above, and operations S710 to S720 are performed after operation S350.

In operation S710, in the case where the second version is identified as the process version, the version status is modified to published.

In operation S720, in the case where the second version is identified as the delivered version, the version status is modified to published.

Fig. 8 schematically illustrates a schematic diagram of another DDL status update process according to an embodiment of the disclosure.

As shown in fig. 6, fig. 7 and fig. 8, compared with fig. 2B, when the version is packaged and delivered and updated successfully, the DDL state on the sea is changed to be released, and when the actual delivery is successful, the DDL state on the sea is updated to be released.

Under the condition that the process version packaging and updating are successful, updating the state 'to be integrated' into the state 'integrated'; under the condition that the delivery version packaging and updating are successful, updating the state integrated into the state to be distributed; in the case of successful delivery, the state "to issue" is updated to the state "issued".

Fig. 9 schematically illustrates a flowchart of another record delivery method according to an embodiment of the present disclosure.

It is understood that operations S910 to S930 are performed on the persistent delivery pipeline side.

In operation S910, first package information including a date of production is transmitted;

in operation S920, transmitting second packing information from the user input; and

in operation S930, a script record from the data table structure management platform is received to complete delivery.

Specifically, the continuous delivery pipeline may be understood as a user directly contacting the side, and by operating on the continuous delivery pipeline, the packaged script DDL record from the sea side may be obtained.

Fig. 10 schematically illustrates a schematic diagram of an information interaction flow between a persistent delivery pipeline side and a sea side according to an embodiment of the present disclosure.

As shown in fig. 10, on the persistent delivery pipeline side, the user initiates the package information (the package information may be transmitted in multiple rounds) to the sea side; packaging the matched DDL script at the SEAS side, and transmitting the corresponding packaged version to the continuous delivery pipeline side; updating the environment for testing by a tester at the continuous delivery pipeline side, and updating success information of the testing environment to the SEAS side under the condition of successful testing; the delivery status is changed on the SEA side by updating the test environment success information.

Fig. 11 schematically illustrates a schematic diagram of a DDL packing pattern according to an embodiment of the present disclosure.

As shown in fig. 11, when there are demand items of delivery date 10 and 20, there are 1 seal DDL and patch DDL, respectively, and there are 13 types of package scenes of the delivery version: 4 (only one of the records was packed) +4 (only 2 of the records were packed, any combination) +4 (only 3 of the records were packed, any combination) +1 (all were packed together) =13 scenes. Of these, fig. 6 shows only 5 packing modes. In the scenario of fig. 6, where only 4 DDL records are illustrated ("only one of the records", "only 2 of the records are packaged in any combination", "3 of the records are packaged in any combination", and "all together packaged"), more DDLs are to be delivered in the actual usage scenario, and therefore, more packaging combinations need to be supported.

Based on the record delivery method, the disclosure also provides a record delivery device. The device will be described in detail below in connection with fig. 12 and 13.

Fig. 12 schematically shows a block diagram of a record delivery device according to an embodiment of the present disclosure.

As shown in fig. 12, the record delivery device 1200 of this embodiment includes a first package information receiving module 1210, a first matching module 1220, a second package information receiving module 1230, a second matching module 1240, and a script record transmitting module 1250.

The first package information receiving module 1210 is configured to receive first package information, where the first package information includes a date of production. In an embodiment, the first packet information receiving module 1210 may be configured to perform the operation S310 described above, which is not described herein.

The first matching module 1220 is configured to perform a first matching based on the production date, and obtain a plurality of script records under the production date, where the script records include a first version identifier and a second version identifier. In an embodiment, the first matching module 1220 may be used to perform the operation S320 described above, which is not described herein.

The second package information receiving module 1230 is configured to receive second package information, where the second package information is distinguished based on the first version identification and the second version identification. In an embodiment, the second package information receiving module 1230 may be used to perform the operation S330 described above, which is not described herein.

The second matching module 1240 is configured to match and package script records in the plurality of script records according to a preset packaging rule based on the date of production, the second packaging information, the first version identifier and the second version identifier, where the preset packaging rule includes a plurality of delivery sub-rules, and the selection of the delivery sub-rules is determined based on the first version identifier and the second version identifier. In an embodiment, the second matching module 1240 may be configured to perform the operation S340 described above, which is not described herein.

Script record transmitting module 1250 script record transmitting module for transmitting the script record. In an embodiment, the script record sending module 1250 may be used to perform the operation S350 described above, which is not described herein.

It is understood that the record delivery device 1200 is applied to a data table structure management platform.

According to an embodiment of the present disclosure, any of the first package information receiving module 1210, the first matching module 1220, the second package information receiving module 1230, the second matching module 1240, and the script record transmitting module 1250 may be combined in one module to be implemented, or any of the modules may be split into a plurality of modules. Alternatively, at least some of the functionality of one or more of the modules may be combined with at least some of the functionality of other modules and implemented in one module. According to embodiments of the present disclosure, at least one of the first packet information receiving module 1210, the first matching module 1220, the second packet information receiving module 1230, the second matching module 1240, and the script record transmitting module 1250 may be implemented at least in part as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system-on-chip, a system-on-substrate, a system-on-package, an Application Specific Integrated Circuit (ASIC), or may be implemented in hardware or firmware in any other reasonable manner of integrating or packaging the circuitry, or in any one of or a suitable combination of three of software, hardware, and firmware. Alternatively, at least one of the first package information receiving module 1210, the first matching module 1220, the second package information receiving module 1230, the second matching module 1240, and the script record transmitting module 1250 may be at least partially implemented as a computer program module, which may perform corresponding functions when being executed.

Fig. 13 schematically illustrates a block diagram of another record delivery device according to an embodiment of the present disclosure.

As shown in fig. 13, the record delivery device 1300 of this embodiment includes a first package information transmitting module 1310, a second package information transmitting module 1320, and a script record receiving module 1330.

The first packet information sending module 1310 is configured to send first packet information, where the first packet information includes a date of production. In an embodiment, the first packet information sending module 1310 may be configured to perform the operation S910 described above, which is not described herein.

The second package information transmitting module 1320 is for transmitting the second package information from the user input. In an embodiment, the second package information sending module 1320 may be configured to perform the operation S920 described above, which is not described herein.

The script record receiving module 1330 is configured to receive a script record from the data table structure management platform to complete delivery. In an embodiment, the script record receiving module 1330 may be configured to perform the operation S930 described above, which is not described herein.

It is understood that the record delivery device 1300 is applied to a continuous delivery pipeline.

According to an embodiment of the present disclosure, any of the first package information transmitting module 1310, the second package information transmitting module 1320, and the script recording receiving module 1330 may be combined in one module to be implemented, or any of the modules may be split into a plurality of modules. Alternatively, at least some of the functionality of one or more of the modules may be combined with at least some of the functionality of other modules and implemented in one module. According to embodiments of the present disclosure, at least one of the first package information sending module 1310, the second package information sending module 1320, and the script record receiving module 1330 may be implemented, at least in part, as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system on a chip, a system on a substrate, a system on a package, an Application Specific Integrated Circuit (ASIC), or may be implemented in hardware or firmware in any other reasonable manner of integrating or packaging circuitry, or in any one of or a suitable combination of three of software, hardware, and firmware. Alternatively, at least one of the first package information transmitting module 1310, the second package information transmitting module 1320, and the script record receiving module 1330 may be at least partially implemented as a computer program module, which may perform corresponding functions when being executed.

As shown in fig. 14, an electronic device 1400 according to an embodiment of the present disclosure includes a processor 1401 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1402 or a program loaded from a storage section 1408 into a Random Access Memory (RAM) 1403. The processor 1401 may include, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and/or an associated chipset and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), or the like. The processor 1401 may also include on-board memory for caching purposes. The processor 1401 may include a single processing unit or a plurality of processing units for performing different actions of the method flows according to embodiments of the present disclosure.

In the RAM 1403, various programs and data necessary for the operation of the electronic device 1400 are stored. The processor 1401, ROM 1402, and RAM 1403 are connected to each other through a bus 1404. The processor 1401 performs various operations of the method flow according to the embodiment of the present disclosure by executing programs in the ROM 1402 and/or the RAM 1403. Note that the program may be stored in one or more memories other than the ROM 1402 and the RAM 1403. The processor 1401 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in the one or more memories.

According to an embodiment of the disclosure, the electronic device 1400 may also include an input/output (I/O) interface 1405, the input/output (I/O) interface 1405 also being connected to the bus 1404. Electronic device 1400 may also include one or more of the following components connected to I/O interface 1405: an input section 1406 including a keyboard, a mouse, and the like; an output portion 1407 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like; a storage section 1408 including a hard disk or the like; and a communication section 1409 including a network interface card such as a LAN card, a modem, and the like. The communication section 1409 performs communication processing via a network such as the internet. The drive 1410 is also connected to the I/O interface 1405 as needed. Removable media 1411, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memory, and the like, is installed as needed on drive 1410 so that a computer program read therefrom is installed as needed into storage portion 1408.

The present disclosure also provides a computer-readable storage medium that may be embodied in the apparatus/device/system described in the above embodiments; or may exist alone without being assembled into the apparatus/device/system. The computer-readable storage medium carries one or more programs which, when executed, implement methods in accordance with embodiments of the present disclosure.

According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example, but is not limited to: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this disclosure, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the present disclosure, the computer-readable storage medium may include ROM 1402 and/or RAM 1403 described above and/or one or more memories other than ROM 1402 and RAM 1403.

Embodiments of the present disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowcharts. The program code, when executed in a computer system, causes the computer system to perform the methods provided by embodiments of the present disclosure.

The above-described functions defined in the system/apparatus of the embodiments of the present disclosure are performed when the computer program is executed by the processor 1401. The systems, apparatus, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the disclosure.

In one embodiment, the computer program may be based on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program can also be transmitted, distributed over a network medium in the form of signals, and downloaded and installed via the communication portion 1409, and/or installed from the removable medium 1411. The computer program may include program code that may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1409 and/or installed from the removable medium 1411. The above-described functions defined in the system of the embodiments of the present disclosure are performed when the computer program is executed by the processor 1401. The systems, devices, apparatus, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the disclosure.

According to embodiments of the present disclosure, program code for performing computer programs provided by embodiments of the present disclosure may be written in any combination of one or more programming languages, and in particular, such computer programs may be implemented in high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. Programming languages include, but are not limited to, such as Java, c++, python, "C" or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Those skilled in the art will appreciate that the features recited in the various embodiments of the disclosure and/or in the claims may be provided in a variety of combinations and/or combinations, even if such combinations or combinations are not explicitly recited in the disclosure. In particular, the features recited in the various embodiments of the present disclosure and/or the claims may be variously combined and/or combined without departing from the spirit and teachings of the present disclosure. All such combinations and/or combinations fall within the scope of the present disclosure.

The embodiments of the present disclosure are described above. However, these examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the embodiments cannot be used advantageously in combination. The scope of the disclosure is defined by the appended claims and equivalents thereof. Various alternatives and modifications can be made by those skilled in the art without departing from the scope of the disclosure, and such alternatives and modifications are intended to fall within the scope of the disclosure.

Claims

1. A record delivery method comprising:

receiving first package information, wherein the first package information comprises a production date;

Performing first matching based on the production date to obtain a plurality of script records under the production date, wherein the script records comprise a first version identifier and a second version identifier;

receiving second packaging information, wherein the second packaging information is distinguished based on the first version identification and the second version identification;

matching and packaging script records in the script records through preset packaging rules based on the production date, the second packaging information, the first version identifier and the second version identifier, wherein the preset packaging rules comprise a plurality of delivery sub-rules, and the selection of the delivery sub-rules is determined based on the first version identifier and the second version identifier; and

and sending the script record.

2. The method of claim 1, wherein the first version identification comprises: a seal plate version and a patch version, the second version identification including a process version and a delivery version, the seal plate version and the patch version being distinguished based on a date of delivery, the process version and the delivery version being distinguished based on whether delivery conditions are met,

the receiving second package information, the second package information being distinguished based on the first version identification and the second version identification, includes:

In the case that the first version is identified as a shrouding version and the second version is identified as a process version, the received second package information is empty;

in the case that the first version is identified as a seal board version and the second version is identified as a delivery version, the received second package information is a delivery date;

in the case that the first version is identified as a patch version and the second version is identified as a process version, the received second packaging information is a question number; and

in the case where the first version is identified as a patch version and the second version is identified as a delivery version, the received second packaging information is a delivery date and a problem number.

3. The method of claim 2, wherein the process version and the delivery version correspond to different version states, the version states including to-be-integrated, to-be-published, and published,

the matching and packaging script records in the plurality of script records through a preset packaging rule based on the production date, the second packaging information, the first version identifier and the second version identifier comprises the following steps:

under the condition that the first version is identified as a closing plate version and the second version is identified as a process version, matching and packaging the script records based on the production date and the version state to be integrated;

Matching and packaging the script records based on the date of production, the date of delivery, and the status of the integrated and/or to-be-published version, if the first version is identified as a shrouded version and the second version is identified as a delivered version;

matching and packaging the script records based on the production date, the problem number and the version state to be integrated under the condition that the first version is identified as a patch version and the second version is identified as a process version; and

and in the case that the first version is identified as a patch version and the second version is identified as a delivery version, matching and packaging the script records based on the date of production, the problem number, the date of delivery and the integrated and/or to-be-released version states.

4. The method of claim 3, wherein after matching and packaging script records among the plurality of script records by a preset packaging rule based on the date of production, the second packaging information, the first version identification, and the second version identification, further comprising:

converting the version state from the to-be-integrated to the integrated if the second version is identified as the process version; and

And converting the version state from the integrated version to the to-be-issued or keeping the version state unchanged by the to-be-issued under the condition that the second version is identified as the delivery version.

5. The method of claim 4, wherein after transmitting the script record, further comprising:

modifying the version status to published if the second version is identified as the process version; and

and modifying the version state to be published in the condition that the second version is identified as the delivery version.

6. A record delivery method comprising:

transmitting first package information, wherein the first package information comprises a production date;

transmitting second package information from the user input; and

and receiving script records from the data table structure management platform to finish delivery.

7. A record delivery device, comprising:

the first package information receiving module is used for receiving first package information, wherein the first package information comprises a production date;

the first matching module is used for carrying out first matching based on the production date to obtain a plurality of script records under the production date, wherein the script records comprise a first version identifier and a second version identifier;

The second package information receiving module is used for receiving second package information, and the second package information is distinguished based on the first version identification and the second version identification;

the second matching module is used for matching and packaging script records in the script records through a preset packaging rule based on the production date, the second packaging information, the first version identifier and the second version identifier, wherein the preset packaging rule comprises a plurality of delivery sub-rules, and the selection of the delivery sub-rules is determined based on the first version identifier and the second version identifier; and

and the script record sending module is used for sending the script record.

8. A record delivery device, comprising:

the first package information sending module is used for sending first package information, wherein the first package information comprises a production date;

the second packaging information sending module is used for sending second packaging information input by a user; and

and the script record receiving module is used for receiving the script record from the data table structure management platform to finish delivery.

9. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs,

Wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-6.

10. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor, cause the processor to perform the method according to any of claims 1-6.

11. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 6.