CN114840429A

CN114840429A - Method, apparatus, device, medium and program product for identifying version conflicts

Info

Publication number: CN114840429A
Application number: CN202210532707.1A
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: 2022-05-16
Filing date: 2022-05-16
Publication date: 2022-08-02

Abstract

The present disclosure provides a method for identifying version conflicts, which can be applied to financial or other technical fields. The method comprises the following steps: acquiring all version packages of an application and target files in all the version packages, wherein all the version packages comprise a version package to be tested and a historical version package, and the target files comprise a first target file and/or a second target file; extracting feature data of the target files in all the version packages; comparing the characteristic data of the target file in the version package to be tested with the characteristic data of the corresponding target file in the historical version package to obtain a comparison result; and determining whether conflicts exist between the version packages to be tested and the historical version packages according to the comparison result, wherein the conflict determination modes are different when all the version packages comprise the first target file and/or the second target file. The present disclosure also provides an apparatus, device, medium, and program product for identifying version conflicts.

Description

Method, apparatus, device, medium and program product for identifying version conflicts

Technical Field

The present disclosure relates to the field of parallel version testing of independent test environments, which may be applied to the financial field or other technical fields, and in particular, to a method, apparatus, device, medium, and program product for identifying version conflicts.

Background

In the prior art, a general process of software application is that a developer performs coding development and debugging, then compiles the software into an application version package to release, and then a special test operation and maintenance person performs a functional adaptability test on the version package under an independent test environment. With the enrichment and the accelerated iteration of banking business functions, the online frequency of business products is higher and higher. In order to ensure that business requirements fall to the ground as soon as possible to improve market share, different application modules based on projects generally adopt platform type research and development, and versions of different application modules are independently packaged and delivered in parallel, so that time extension caused by different development progress and different production time points among different application modules is avoided, and efficiency is improved. However, at the same time, there are also the following problems:

(1) the version package to be tested received by the testing operation and maintenance personnel is a packaged compiled program, and the version package is isolated from the development environment and the source code, so that the testing operation and maintenance personnel cannot identify whether the received version package to be tested is different from the historical version package;

(2) the platform development relates to different development teams, and because the development progress of each application module is different and the management of the development teams is different, the version manager has the situation of insufficient understanding and/or untimely synchronization on the modification of different versions of one application module;

(3) the resources of the test environment are limited, the test environment cannot be arranged for each version package independently, and if the version packages fed back by developers at different production time points are not conflicted, the version packages of different application modules of a project are generally applied to be deployed in the same environment for parallel verification. However, since developers have limited knowledge about the modification of different application modules of a project, feedback is often inaccurate, and the correctness of a test environment can only depend on the synchronization and inheritance of a version manager to a parallel version. If errors occur in the feedback of developers and the synchronization of version managers, the environment foundation of the adaptability test is completely wrong, and great production risk is introduced.

Disclosure of Invention

In view of the foregoing, the present disclosure provides methods, apparatuses, devices, media and program products for identifying version conflicts.

According to a first aspect of the present disclosure, there is provided a method of identifying version conflicts, comprising:

acquiring all version packages of an application and target files in all the version packages, wherein all the version packages comprise a version package to be tested and a historical version package, and the target files comprise a first target file and/or a second target file;

extracting feature data of the target file in all the version packages;

comparing the characteristic data of the target file in the version package to be tested with the characteristic data of the corresponding target file in the historical version package to obtain a comparison result;

and determining whether conflicts exist between the version packages to be tested and the historical version packages according to the comparison result, wherein the conflict determination modes are different when all the version packages comprise the first target file and/or the second target file.

According to an embodiment of the present disclosure, the object file includes a first object file including a compiled file and a text file and/or a second object file including a database script.

According to the embodiment of the disclosure, when the target files in all the version packages include the first target file, determining whether a conflict exists between the version package to be tested and the historical version package according to the comparison result includes:

and under the condition that the characteristic data of the first target file in the version package to be tested is different from the characteristic data of the first target file in the historical version package, determining that a conflict exists between the version package to be tested and the historical version package.

According to the embodiment of the disclosure, when the target files in all the version packs include the second target file, determining whether a conflict exists between the version pack to be tested and the historical version pack according to the comparison result includes:

and under the condition that the characteristic data of the second target file in the version package to be tested and the characteristic data of the second target file in the historical version package have repeated parts, determining that a conflict exists between the version package to be tested and the historical version package.

According to an embodiment of the present disclosure, when the target file includes a first target file, extracting feature data of the target file in all the version packages includes:

and extracting hash values of the compiled files and the text files in all the version packages through an MD5 algorithm, wherein the hash values are characteristic data.

According to an embodiment of the present disclosure, when the target file includes a second target file, extracting feature data of the target file in all the version packs includes:

analyzing database scripts in all the version packages;

and extracting a database object operated by the database script, wherein the database object is characteristic data.

According to an embodiment of the present disclosure, the database object includes at least one of a table, an index, a stored procedure, an object name of a view, and an operation manner of the database.

According to an embodiment of the disclosure, the method further comprises:

and acquiring version information of all the version packages of the application, wherein the version information comprises an application name, a version number, a delivery date and a delivery date, the delivery date is the date when each version package is delivered to the test environment, and the delivery date is the date when each version package is scheduled to be deployed on line in the production environment.

According to an embodiment of the present disclosure, in a case where the target files in all the version packages include the first target file, the method further includes:

and sending an alarm under the condition that the delivery date of the edition packet to be tested is later than that of the historical edition packet or is the same as that of the historical edition packet, and the commissioning date of the edition packet to be tested is earlier than that of the historical edition packet.

According to the embodiment of the disclosure, after the alarm is sent out, the method further comprises:

and re-determining the delivery date of the edition packet to be tested and updating the edition packet to be tested.

According to an embodiment of the present disclosure, when the target files in all the version packs include the second target file, the method further includes:

acquiring the operation mode of the repeated part;

and sending an alarm when the operation mode of the repeated part belongs to the data definition language mode.

A second aspect of the present disclosure provides an apparatus for identifying version conflicts, comprising:

the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring all version packages of an application and target files in all version packages, all version packages comprise a version package to be tested and a historical version package, and the target files comprise a first target file and/or a second target file;

the extraction module is used for extracting the characteristic data of the target file in all the version packages;

the comparison module is used for comparing the characteristic data of the target file in the version package to be tested with the characteristic data of the corresponding target file in the historical version package to obtain a comparison result;

and the determining module is used for determining whether conflicts exist between the version packages to be tested and the historical version packages according to the comparison result, wherein the conflict determining modes are different when all the version packages comprise the first target file and/or the second target file.

A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; 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 above-described method of identifying version conflicts.

A fourth aspect of the present disclosure also provides a computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the above-described method of identifying version conflicts.

A fifth aspect of the present disclosure also provides a computer program product comprising a computer program which, when executed by a processor, implements the above-described method of identifying version conflicts.

According to the method, the device, the equipment, the medium and the program product for identifying the version conflict, whether the conflict exists between the version package to be tested and the historical version package can be known by comparing the characteristic data of the target file in the version package to be tested with the characteristic data of the target file in the historical version package, a version manager can identify whether the version package to be tested is different from the historical version package through the characteristic data, and timely discover whether the version package to be tested is modified, so that synchronization can be performed, the condition of the version package to be tested can be known through the feedback of developers, the error rate of the version package to be tested is reduced, and the production risk is reduced.

Drawings

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

FIG. 1 schematically illustrates an application scenario diagram of a method, apparatus, device, medium, and program product for identifying version conflicts according to embodiments of the present disclosure;

FIG. 2 schematically illustrates a flow chart of a method of identifying version conflicts in accordance with an embodiment of the present disclosure;

FIG. 3 is a block diagram schematically illustrating an apparatus for identifying version conflicts according to an embodiment of the present disclosure; and

FIG. 4 schematically illustrates a block diagram of an electronic device adapted to implement a method of identifying version conflicts in accordance with 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 illustrative only 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 disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not 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 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 is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense.

Where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have 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.).

In the process of implementing the technical scheme, the inventor finds that in the related technology, the bank system test generally adopts an independent test environment and is isolated from a development code environment, so that the independent test environment is beneficial to finding bugs which cannot be reproduced by the development environment, the production, installation and deployment process of a software package can be simulated, and whether the installation and deployment and documents thereof have problems or not can be found in advance. However, the version package to be tested received by the testing operation and maintenance personnel is a packaged compiled program, and the version package is isolated from the development environment and the source code, so that the testing operation and maintenance personnel cannot read the program content of the version package, and therefore cannot identify whether the received version package to be tested is different from the historical version package; the platform development relates to different development teams, and because the progress of each application module and the management capability of the development teams are different, the situation that a version manager cannot fully know and cannot synchronize with the modification of project modules of different versions is caused; meanwhile, the resources of the test environment are limited, the test environment cannot be arranged for each version package independently, and if the version packages fed back by developers at different production time points are not conflicted, the version packages of different application modules of a project are generally applied to be deployed in the same environment for parallel verification. However, since developers have limited knowledge about the modification of different application modules of a project, feedback is often inaccurate, and the correctness of a test environment can only depend on the synchronization and inheritance of a version manager for parallel versions. If errors occur in the feedback of developers and the synchronization of version managers, the environment foundation of the adaptability test is completely wrong, and great production risk is introduced.

To solve the technical problems in the related art, embodiments of the present disclosure provide a method, apparatus, device, medium, and program product for identifying version conflicts. According to the embodiment of the disclosure, firstly, all version packages of an application and target files in all version packages are obtained, wherein all version packages comprise a version package to be tested and a historical version package, and the target files comprise a first target file and/or a second target file; then, extracting feature data of the target file in all the version packages; next, under the condition that the target files in all the version packages comprise the first target file, judging whether the feature data of the first target file in the version package to be tested is the same as the feature data of the first target file in the historical version package; under the condition that the target files in all the version packages comprise second target files, judging whether repeated parts exist in the feature data of the second target files in the version packages to be tested and the feature data of the second target files in the historical version packages or not; and if the feature data of the first target file in the version package to be tested is different from the feature data of the first target file in the historical version package, and/or the feature data of the second target file in the version package to be tested and the feature data of the second target file in the historical version package have repeated parts, determining that a conflict exists between the version package to be tested and the historical version package.

Fig. 1 schematically illustrates an application scenario for identifying version conflicts according to an embodiment of the present disclosure.

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

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

A user may use

terminal devices

101, 102, 103 to interact with a server 105 over a network 104 to receive or send messages or the like. The

terminal devices

101, 102, 103 may have installed thereon various communication client applications, such as shopping-like applications, web browser applications, search-like applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only).

The

terminal devices

101, 102, 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

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

terminal devices

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

It should be noted that the method for identifying version conflicts provided by the embodiments of the present disclosure may be generally performed by the server 105. Accordingly, the means for identifying version conflicts provided by the embodiments of the present disclosure may be generally disposed in the server 105. The method for identifying version conflicts provided by the embodiments of the present disclosure may also be performed by a server or a server cluster different from the server 105 and capable of communicating with the

terminal devices

101, 102, 103 and/or the server 105. Accordingly, the device for identifying version conflicts provided by the embodiment of the present disclosure may also be disposed in a server or a server cluster different from the server 105 and 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.

It should be noted that the method and apparatus for identifying version conflicts disclosed in the present disclosure may be used in project testing in the financial field, and may also be used in any field other than the financial field.

The method of identifying version conflicts of the disclosed embodiments will be described in detail below with respect to fig. 2 based on the scenario described in fig. 1.

FIG. 2 schematically shows a flow chart of a method of identifying version conflicts according to an embodiment of the present disclosure.

As shown in fig. 2, identifying version conflicts in this embodiment includes operations S210 to S240.

In operation S210, all version packages of an application and target files in all version packages are obtained, where all version packages include a version package to be tested and a history version package, and a target file includes a first target file and/or a second target file;

in this embodiment, the first object file includes a compiled file and a text file, and the second object file includes a database script. Wherein, files such as class, pictures, jar packets, etc. are compiled; text files, such as jsp, xml, txt, etc.; database scripts, such as sql, and the like. The different types of target files may have different methods for comparing the feature data with the feature data. In this embodiment, the version package to be tested is a newly received version package, and the historical version package is a version package that belongs to the same application as the version package to be tested but is received before the version package to be tested.

In operation S220, extracting feature data of the target file in all the version packs;

in this embodiment, the operation S220 specifically includes, when the target file includes the first target file, that is, includes the compiled file and/or the text file, and extracting the feature data of the target file in all the version packages includes: and extracting hash values of the compiled files and the text files in all the version packages through an MD5 algorithm, wherein the hash values are characteristic data. When the target file comprises a second target file, namely the database script is included, extracting the feature data of the target file in all the version packages comprises: analyzing database scripts in all the version packages; and extracting a database object operated by the database script, wherein the database object is characteristic data. The database object includes at least one of a table, an index, a stored procedure of the database, an object name of the view, and an operation manner, such as a data definition language of create, drop, alter, etc., or a DML of delete, update, insert, etc. The present disclosure can identify the difference between the version package to be tested and the historical version package based on these characteristic data by extracting hash values of the compiled file and the text file and the database object operated by the database script. In order to render the feature data of the compiled file, the text file and the database script more clearly, as shown in table 1, table 1 shows an embodiment of the correspondence relationship between the feature data of the compiled file, the text file and the database script.

TABLE 1

Name of application	Version number	Object document	Target file type	Characteristic data
					Applications A	V1.1.1	a.class	Compiling files	Hash value
Applications A	V1.1.1	b.jsp	Text file	Hash value
					Applications A	V1.2.1	a.class	Compiling files	Hash value
Applications A	V1.2.1	c_0801.sql	Database script	Related database object

It should be noted that, the hash value is also called: a Hash Function (or Hash algorithm, also known as Hash Function, english: Hash Function) is a method of creating a small digital "fingerprint" from any kind of data. The hash function compresses a message or data into a digest so that the amount of data becomes small, fixing the format of the data. This function mixes the data in a hash, recreating a fingerprint called a hash value (hash sums, or hashes). MD5, Message-Digest Algorithm 5, is used to ensure that the information transfer is complete and consistent. Is one of the hash algorithms (also known as digest algorithm and hash algorithm) widely used by computers, and the mainstream programming language is generally realized by MD 5. The operation of data (such as Chinese characters) into another fixed length value is the basic principle of the hash algorithm. The MD5 algorithm has the following characteristics: 1. compressibility: for any length of data, the calculated length of the MD5 value is fixed. 2. Easy to calculate: it is easy to calculate the MD5 value from the raw data. 3. Resistance to modification: any change to the original data, even if only 1 byte is modified, can result in a great difference in the value of MD 5. 4. Strong collision resistance: knowing the original data and its MD5 value, it is very difficult to find a data with the same MD5 value (i.e., counterfeit data). MD5 functions to allow large volumes of information to be "compressed" into a secure format (i.e., to convert a byte string of any length into a fixed-length hexadecimal digital string) before the private key is signed by digital signature software. Component of the SQL language (structured query language), which includes four main categories of programming language statements: data Definition Language (DDL), Data Manipulation Language (DML), Data Control Language (DCL) and Transaction Control Language (TCL).

In operation S230, comparing the feature data of the target file in the version package to be tested with the feature data of the corresponding target file in the historical version package to obtain a comparison result;

in this embodiment, it is required to limit that the target files in all the version packages include the first target file or the second target file, for example, because the version package to be tested includes the a.class file, if there is no a.class file in the history version package, the a.class file in the version package to be tested will not intersect or synchronize with the file in the history version package, and therefore, in this case, there is no need to perform the next identification.

In operation S240, it is determined whether a conflict exists between the version package to be tested and the historical version package according to the comparison result, where the conflict is determined in different manners when all the version packages include the first target file and/or the second target file.

In this embodiment, when the target files in all the version packs include the first target file, if the feature data of the first target file in the version pack to be tested is the same as the feature data of the first target file in the history version pack, it indicates that the content of the first target file is synchronized, and the first target file in the current version pack to be tested has no problem, and if the feature data of the first target file in the version pack to be tested is different from the feature data of the first target file in the history version pack, it indicates that the version pack to be tested and the history version pack are in conflict. When the target files in all the version packages comprise second target files, the judging modes are different due to different file types, if the feature data of the second target files in the version packages to be tested and the feature data of the second target files in the historical version packages do not have repeated parts, it is indicated that the second target files have no cross influence on the version packages to be tested and the historical version packages, and if the feature data of the second target files in the version packages to be tested and the feature data of the second target files in the historical version packages have repeated parts, it is indicated that conflicts exist between the version packages to be tested and the historical version packages, and the size and the risk of the specific conflicts need to be further judged.

The method for identifying version conflicts disclosed by the embodiment obtains the characteristic data corresponding to different target files by dividing the target files into two types, and then compares the characteristic data of the target files in the version package to be tested with the characteristic data of the target files corresponding to the historical version package, wherein the first target file and the second target file have different corresponding modes, so that whether conflicts exist between the version package to be tested and the historical version package can be quickly obtained, source codes do not need to be relied on, and feedback of a development team and developers does not need to be relied on, a version manager can autonomously identify and synchronize the version package to be tested, the error rate of the version package to be tested is reduced, and the safety of putting the version package into production is improved.

As an optional embodiment, the method for identifying version conflicts disclosed in this embodiment further includes acquiring version information of all version packs of the application, where the version information includes an application name, a version number, a delivery date, and a delivery date. The version number is a unique name for a specific package, and corresponds to a specific version of an application, the delivery date is a date when each package is delivered to the test environment, and the commissioning date is a date when each package is scheduled to be deployed online in the production environment, as shown in table 2, where table 2 shows an embodiment of contents included in the version information.

TABLE 2

Name of application	Version number	Day of delivery	Day of delivery
				Applications A	V1.1.1	2021-08-01	2021-08-10
Applications A	V1.2.1	2021-08-01	2021-08-15
				Applications A	V1.2.2	2021-08-02	2021-08-15
Applications A	V1.1.2	2021-08-03	2021-08-10
				Applications A	V1.2.3	2021-08-03	2021-08-15
Applications A	V1.1.3	2021-08-04	2021-08-10

Because the historical version package is the version package received before the version package to be tested, the delivery date of the historical version package is earlier than or the same as the delivery date of the version package to be tested, and it should be noted that, in general, the version package received on the same day is tested on the same day.

As an alternative embodiment, in the case that the target files in all the version packs include the first target file, the method for identifying the version conflict further includes: in the case that the delivery date of the to-be-tested edition package is determined to be later than or the same as the delivery date of the historical edition package, and in the case that the delivery date of the to-be-tested edition package is earlier than the delivery date of the historical edition package, an alarm is given, and two embodiments are given below for detailed explanation, embodiment 1: the current day is 2021-08-04, the files a and class are delivered in V1.1.3 (delivery day: 2021-08-04, production day: 2021-08-10) and V1.2.1 (delivery day: 2021-08-01, production day: 2021-08-15), and the two characteristic data are identified to be inconsistent, and the 15 production content of the file is not delivered on the current day, which indicates that the file is not synchronized in time, if the test is continued, the test result may show to be normal, but the a and class file of the production environment in the 15 production process is covered as an old file, which will cause production problems, and then the test problem will be automatically submitted and tracked, and the information of the unsynchronized file is attached; example 2: the current day is 2021-08-04, the files b.class are delivered in V1.1.3 (delivery day: 2021-08-04, production day: 2021-08-10) and V1.2.3 (delivery day: 2021-08-04, production day: 2021-08-15), the inconsistency of the characteristic data is identified, the files are indicated to be crossed in the test environment, and the content of the current test verification base 2021-08-15 cannot guarantee the result of 10-day production, which may cause production problems. Both of these situations will send an alarm to alert the relevant personnel or system to perform further operations. And for embodiment 2, after the alarm is issued, the method for identifying version conflicts further includes: and re-determining the delivery date of the version package to be tested and updating the version package to be tested, specifically, matching two project groups of 10 days and 15 days to negotiate a test plan, if the first project test is preferentially ensured before 8 days, automatically setting the b.class file of the test environment to be V1.1.3 version, and automatically updating to be V1.2.3 version after 8 days.

According to an embodiment of the present disclosure, in a case that the target files in all the version packages include the second target file, the method for identifying the version conflict further includes: acquiring the operation mode of the repeated part; and sending an alarm under the condition that the operation mode of the repeated part belongs to the DDL mode. In the embodiment, if the operation on the same database object belongs to the DML, namely the change of the data class, other scripts are generally not influenced, the operation can be regarded as normal common operation, and an alarm does not need to be sent out; however, if the operation mode of the same database object belongs to the DDL, that is, the change of the database object itself may have a great influence on other script operations, an alarm needs to be issued to remind a technical tester of the test environment to take charge of checking, evaluating, tracking and feeding back, and the information related to the crossed database scripts is attached.

It should be noted that a Data Management Language (DML) is an instruction set in SQL Language, which is responsible for executing Data access work on a database object, and takes three instructions, namely INSERT, UPDATE, and DELETE, as cores, and represents insertion, UPDATE, and deletion, respectively, which are instructions that are certainly used for developing an application program with Data as a center, so that many developers call four major instructions of a SELECT statement of SQL "CRUD".

In the embodiment, the reasonability of the target file coverage relation between the parallel projects can be automatically judged, further identification can be carried out according to different conflict conditions, next-step measures can be provided in a targeted mode, a solution for problem tracking and testing environment can be provided, the intensive environment use efficiency is greatly improved, and the testing environment for reliable deployment and safety verification of the parallel versions is provided.

Based on the method for identifying the version conflict, the disclosure also provides a device for identifying the version conflict. The apparatus will be described in detail below with reference to fig. 3.

Fig. 3 schematically shows a block diagram of an apparatus for identifying version conflicts according to an embodiment of the present disclosure.

As shown in fig. 3, the apparatus 300 for identifying version conflicts of this embodiment includes an obtaining module 310, an extracting module 320, a comparing module 330, and a determining module 340.

The obtaining module 310 is configured to obtain all version packages of an application and a target file in all version packages, where all version packages include a version package to be tested and a history version package, and the target file includes a first target file and/or a second target file. In an embodiment, the obtaining module 310 may be configured to perform the operation S210 described above, which is not described herein again.

The extraction module 320 is used for extracting feature data of the target file in all the version packages. In an embodiment, the extracting module 320 may be configured to perform the operation S220 described above, which is not described herein again.

The comparison module 330 is configured to compare the feature data of the target file in the version package to be tested with the feature data of the corresponding target file in the historical version package to obtain a comparison result. In an embodiment, the comparing module 330 may be configured to perform the operation S230 described above, which is not described herein again.

The determining module 340 is configured to determine whether a conflict exists between the version package to be tested and the historical version package according to the comparison result, where the conflict determination manners are different when all the version packages include the first target file and/or the second target file. In an embodiment, the confirmation module 330 may be configured to perform the operation S240 described above, which is not described herein again.

According to the embodiment of the present disclosure, any plurality of the obtaining module 310, the extracting module 320, the comparing module 330, and the determining module 340 may be combined and implemented in one module, or any one of the modules may be split into a plurality of modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in one module. According to an embodiment of the present disclosure, at least one of the obtaining module 310, the extracting module 320, the comparing module 330 and the determining module 340 may be implemented at least partially as a hardware circuit, 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 by hardware or firmware in any other reasonable manner of integrating or packaging a circuit, or implemented by any one of three implementations of software, hardware and firmware, or in a suitable combination of any several of them. Alternatively, at least one of the obtaining module 310, the extracting module 320, the comparing module 330 and the determining module 340 may be at least partially implemented as a computer program module, which when executed may perform a corresponding function.

It should be noted that, a device portion for identifying a version conflict in the embodiment of the present disclosure corresponds to a method portion for identifying a version conflict in the embodiment of the present disclosure, and the description of the device portion for identifying a version conflict specifically refers to the method portion for identifying a version conflict, and is not described herein again.

As shown in fig. 4, an electronic apparatus 900 according to an embodiment of the present disclosure includes a processor 901 which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)902 or a program loaded from a storage portion 908 into a Random Access Memory (RAM) 903. Processor 901 may comprise, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and/or associated chipset, and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), among others. The processor 901 may also include on-board memory for caching purposes. The processor 901 may comprise a single processing unit or a plurality of processing units for performing the different actions of the method flows according to embodiments of the present disclosure.

In the RAM 903, various programs and data necessary for the operation of the electronic apparatus 900 are stored. The processor 901, the ROM 902, and the RAM 903 are connected to each other through a bus 904. The processor 901 performs various operations of the method flows according to the embodiments of the present disclosure by executing programs in the ROM 902 and/or the RAM 903. Note that the programs may also be stored in one or more memories other than the ROM 902 and the RAM 903. The processor 901 may also perform various operations of the method flows according to embodiments of the present disclosure by executing programs stored in the one or more memories.

Electronic device 900 may also include input/output (I/O) interface 905, input/output (I/O) interface 905 also connected to bus 904, according to an embodiment of the present disclosure. The electronic device 900 may also include one or more of the following components connected to the I/O interface 905: an input portion 906 including a keyboard, a mouse, and the like; an output section 907 including components such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 908 including a hard disk and the like; and a communication section 909 including a network interface card such as a LAN card, a modem, or the like. The communication section 909 performs communication processing via a network such as the internet. The drive 910 is also connected to the I/O interface 905 as necessary. A removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 910 as necessary, so that a computer program read out therefrom is mounted into the storage section 908 as necessary.

The present disclosure also provides a computer-readable storage medium, which may be contained in the apparatus/device/system described in the above embodiments; or may exist alone without being assembled into the device/apparatus/system. The computer-readable storage medium carries one or more programs which, when executed, implement the method according to an embodiment of the 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 present 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, a computer-readable storage medium may include the ROM 902 and/or RAM 903 described above and/or one or more memories other than the ROM 902 and RAM 903.

Embodiments of the present disclosure also include a computer program product comprising a computer program containing program code for performing the method illustrated in the flow chart. When the computer program product runs in a computer system, the program code is used for causing the computer system to realize the item recommendation method provided by the embodiment of the disclosure.

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

In one embodiment, the computer program may be hosted on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program may also be transmitted, distributed in the form of a signal on a network medium, and downloaded and installed through the communication section 909 and/or installed from the removable medium 911. The computer program containing program code may be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 909, and/or installed from the removable medium 911. The computer program, when executed by the processor 901, performs the above-described functions defined in the system of the embodiment of the present disclosure. The systems, devices, apparatuses, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the present disclosure.

In accordance with embodiments of the present disclosure, program code for executing computer programs provided by embodiments of the present disclosure may be written in any combination of one or more programming languages, and in particular, these computer programs may be implemented using high level procedural and/or object oriented programming languages, and/or assembly/machine languages. The programming language includes, but is not limited to, programming languages such as Java, C + +, python, the "C" language, or the like. The program code may execute entirely on the user computing device, partly on the user device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, 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., through the internet using an internet service provider).

The flowchart 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 various combinations and/or combinations of features recited in the various embodiments and/or claims of the present disclosure can be made, even if such combinations or combinations are not expressly recited in the present disclosure. In particular, various combinations and/or combinations of the features recited in the various embodiments and/or claims of the present disclosure may be made without departing from the spirit or teaching of the present disclosure. All such combinations and/or associations are within the scope of the present disclosure.

The embodiments of the present disclosure have been 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 separately above, 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 devised by those skilled in the art without departing from the scope of the present disclosure, and such alternatives and modifications are intended to be within the scope of the present disclosure.

Claims

1. A method of identifying version conflicts, comprising:

extracting feature data of the target files in all the version packages;

and determining whether a conflict exists between the version package to be tested and the historical version package according to the comparison result, wherein the conflict determination modes are different when all the version packages comprise the first target file and/or the second target file.

2. The method of claim 1, wherein the first object file comprises a compiled file and a text file, and the second object file comprises a database script.

3. The method of claim 2, wherein when the target file in all the version packs comprises the first target file, the determining whether a conflict exists between the version pack to be tested and the historical version pack according to the comparison result comprises:

4. The method of claim 2, wherein when the target file in all the version packs comprises the second target file, the determining whether a conflict exists between the version pack to be tested and the historical version pack according to the comparison result comprises:

5. The method of claim 2, wherein, when the target file comprises the first target file, the extracting feature data of the target file in the all-version package comprises:

and extracting hash values of the compiled files and the text files in all the version packages through an MD5 algorithm, wherein the hash values are the characteristic data.

6. The method of claim 4, wherein, when the target file comprises the second target file, the extracting feature data of the target file in the all-version package comprises:

analyzing the database scripts in all the version packages;

and extracting a database object operated by the database script, wherein the database object is the characteristic data.

7. The method of claim 6, wherein the database object comprises at least one of a table, an index, a stored procedure, an object name of a view, and an operation mode of a database.

8. The method of claim 2, wherein the method further comprises:

acquiring version information of all the version packages of the application, wherein the version information comprises an application name, a version number, a delivery date and a delivery date, the delivery date is the date when each version package is delivered to a test environment, and the delivery date is the date when each version package is scheduled to be deployed on line in a production environment.

9. The method of claim 8, wherein, in the case that the target file in all of the version bundles includes the first target file, the method further comprises:

and sending an alarm under the condition that the delivery date of the to-be-tested edition package is later than that of the historical edition package or is the same as that of the historical edition package, and the production date of the to-be-tested edition package is earlier than that of the historical edition package.

10. The method of claim 9, wherein after the issuing of the alert, the method further comprises:

11. The method of claim 7, wherein when the target file in all version bundles includes the second target file, the method further comprises:

acquiring the operation mode of the repeated part;

and sending an alarm under the condition that the operation mode of the repeated part belongs to the data definition language mode.

12. An apparatus for identifying version conflicts, comprising:

the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring all version packages of an application and target files in all the version packages, the all version packages comprise a version package to be tested and a historical version package, and the target files comprise a first target file and/or a second target file;

and the determining module is used for determining whether conflicts exist between the version packages to be tested and the historical version packages according to the comparison result, wherein the conflict modes are determined to be different when all the version packages comprise the first target file and/or the second target file.

13. An electronic device, comprising:

one or more processors;

a storage device 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-11.

14. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 11.

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