Version synchronization method and device on version assembly line and electronic equipment

Abstract

The invention discloses a version synchronization method and device on a version assembly line and electronic equipment, and relates to the field of financial science and technology or other related technical fields, and the method comprises the steps: scanning a target version on the version assembly line in an adaptive test environment, and obtaining the program library information of the target version; determining a production version in a production environment corresponding to the target version, and detecting program library information of the production version; comparing a first modification timestamp in the program library information of the target version with a second modification timestamp in the program library information of the production version to obtain a comparison result; under the condition that the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, the modification operation corresponding to the second modification timestamp is synchronized to the target version. According to the method and the device, the technical problems of low efficiency and high probability of patch omission due to manual synchronization of modification operation of a plurality of versions when the versions of the application program are developed based on a version assembly line in related technologies are solved.

Description

Technical Field

[0001] The present invention relates to the field of financial technology or other related technical fields, and in particular, to a version synchronization method on a version pipeline, a device thereof, and an electronic device. Background Art

[0002] With the evolution of financial institutions' business system architecture and the transformation of software development models, traditional waterfall development has been gradually replaced by agile development, especially in the project management of distributed platform systems. The agile development model emphasizes rapid iteration and continuous delivery to adapt to the ever-changing business needs and market environment. In this context, the concept of pipeline development and its related pipeline technology have been widely used to promote the efficiency of software development, testing and deployment, shorten the delivery cycle, and improve software quality.

[0003] However, when the software system enters the rapid iteration stage, especially for projects with monthly version updates, multi-version parallel development becomes the norm, that is, multiple version pipelines are created at the same time, and multiple monthly versions are developed at the same time. For example, at the current time point, the versions of March, April, and May are developed in parallel. This means that one version may be undergoing comprehensive testing in an adaptive test environment, while another version may still be in the development and testing stage, and even the development of the next version has been started. In such a development environment, after the patch of the lower version is released, it needs to be synchronized in the higher version to ensure that all versions contain the latest fixes and optimizations.

[0004] Although the pipeline-based version development mechanism provides powerful version control and automated testing capabilities, there are still challenges in version synchronization and patch management. When the configuration administrator packages and releases the version at the planned time, he needs to manually determine whether there are unsynchronized patches and whether the patches in the lower version need to be synchronized to the higher version. The process of manually synchronizing patches is not only time-consuming and labor-intensive, but also may cause the configuration administrator to miss the synchronization of certain key patches due to factors such as multiple business needs, major technical transformations, and rapid version iterations, and then release the unupdated version to the adaptive test or production environment, which may cause serious production problems.

[0005] In actual operations, as the number of versions increases and overlaps, the risk of missing patch synchronization also increases, which not only affects the stability and reliability of the software, but may also cause user data risks and business interruptions, posing a threat to the normal operation of financial institutions' systems.

[0006] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0007] The embodiment of the present invention provides a version synchronization method on a version pipeline and its device and electronic device, so as to at least solve the technical problems in the related art that when developing the version of an application based on a version pipeline, the modification operation of multiple versions is manually synchronized, which is inefficient and prone to patch omissions.

[0008] According to one aspect of an embodiment of the present invention, a version synchronization method on a version pipeline is provided, comprising: scanning a target version on the version pipeline in an adaptive test environment to obtain program library information of the target version, wherein the version pipeline is used to synchronously develop multiple versions; determining that the target version corresponds to a production version in a production environment, and detecting program library information of the production version; comparing a first modification timestamp in the program library information of the target version with a second modification timestamp in the program library information of the production version to obtain a comparison result; if the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, synchronizing a modification operation corresponding to the second modification timestamp to the target version, wherein the modification operation at least includes: a patch release operation.

[0009] Optionally, before scanning the target version on the version pipeline in the adaptive testing environment, it also includes: receiving a version submission request from the development terminal, and configuring program library information for the version on the version pipeline based on the version submission request, wherein the program library information includes at least one of the following: modification timestamp, file identifier of the file storing the version code, version identifier, version baseline identifier, information of the person who performs the modification operation, and administrator information; and storing the program library information in a database.

[0010] Optionally, after storing the program library information in the database, it also includes: submitting the version on the version pipeline to a functional testing environment and performing functional testing in the functional testing environment; if the version on the version pipeline passes the functional test, submitting the version on the version pipeline to an adaptive testing environment.

[0011] Optionally, when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, it also includes: determining that there is an anomaly in the target version; for the target version with the anomaly, generating anomaly warning information based on the second modification timestamp; and sending the anomaly warning information to the modification business terminal and / or management terminal based on the modifier information and the administrator information in the program library information.

[0012] Optionally, before scanning the target version on the version pipeline in the adaptive test environment, it also includes: monitoring the production version in the production environment, and after monitoring that the production version performs a modification operation, reading the timestamp of executing the modification operation; calling the program library information of the production version, and updating the modification timestamp in the program library information of the production version based on the timestamp of executing the modification operation.

[0013] Optionally, when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, the step of synchronizing the modification operation corresponding to the second modification timestamp to the target version includes: when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, determining the modification operation corresponding to the second modification timestamp; obtaining the importance level of the modification operation, and ignoring the modification operation when the importance level of the modification operation is less than a preset level threshold; or, when the importance level of the modification operation is greater than or equal to the preset level threshold, synchronizing the modification operation to the target version.

[0014] Optionally, after synchronizing the modification operation corresponding to the second modification timestamp to the target version, the method further includes: recording the synchronization timestamp of synchronizing the modification operation to the target version; and updating the program library information of the target version based on the synchronization timestamp.

[0015] According to another aspect of an embodiment of the present invention, a version synchronization device on a version pipeline is also provided, including: an acquisition unit, used to scan the target version on the version pipeline in an adaptive test environment, and obtain the program library information of the target version, wherein the version pipeline is used to develop multiple versions synchronously; a detection unit, used to determine that the target version corresponds to the production version in the production environment, and detect the program library information of the production version; a comparison unit, used to compare the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version to obtain a comparison result; a synchronization unit, used to synchronize the modification operation corresponding to the second modification timestamp to the target version when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, wherein the modification operation at least includes: a patch release operation.

[0016] Optionally, the version synchronization device on the version pipeline also includes: a first configuration module, used to receive a version submission request from a development terminal, and configure program library information for the version on the version pipeline based on the version submission request, wherein the program library information includes at least one of the following: modification timestamp, file identifier of a file storing version code, version identifier, version baseline identifier, information of a modifier who performs modification operations, and administrator information; a first storage module, used to store the program library information in a database.

[0017] Optionally, the version synchronization device on the version pipeline also includes: a first submission module, used to submit the version on the version pipeline to a functional testing environment and perform functional testing in the functional testing environment; a second submission module, used to submit the version on the version pipeline to an adaptive testing environment if the version on the version pipeline passes the functional test.

[0018] Optionally, the version synchronization device on the version pipeline also includes: a first determination module, used to determine whether there is an anomaly in the target version; a first generation module, used to generate anomaly warning information for the target version with the anomaly based on the second modification timestamp; a first sending module, used to send the anomaly warning information to the modification business terminal and / or management terminal based on the modifier information and the administrator information in the program library information.

[0019] Optionally, the version synchronization device on the version pipeline also includes: a first reading module, used to monitor the production version in the production environment, and after monitoring the production version to perform a modification operation, read the timestamp of executing the modification operation; a first update module, used to call the program library information of the production version, and update the modification timestamp in the program library information of the production version based on the timestamp of executing the modification operation.

[0020] Optionally, the synchronization unit includes: a second determination module, used to determine the modification operation corresponding to the second modification timestamp when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp; a first acquisition module, used to obtain the importance level of the modification operation, and ignore the modification operation when the importance level of the modification operation is less than a preset level threshold; and a first synchronization module, used to synchronize the modification operation to the target version when the importance level of the modification operation is greater than or equal to the preset level threshold.

[0021] Optionally, the version synchronization device on the version pipeline further includes: a first recording module, used to record a synchronization timestamp of synchronizing the modification operation to the target version; and a second updating module, used to update the program library information of the target version based on the synchronization timestamp.

[0022] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned version synchronization methods on the version pipeline.

[0023] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the above-mentioned version synchronization methods on the version pipeline.

[0024] In the present application, the following steps are performed: scanning the target version on the version pipeline in the adaptive test environment to obtain the program library information of the target version, wherein the version pipeline is used to develop multiple versions synchronously, and determining that the target version corresponds to the production version in the production environment, and detecting the program library information of the production version, and then comparing the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version to obtain a comparison result, and finally, when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, synchronizing the modification operation corresponding to the second modification timestamp to the target version, wherein the modification operation at least includes: a patch release operation.

[0025] In this application, the development information of each version pipeline is recorded through the library information, and before the version on the version pipeline is released, the library information of the target version is automatically scanned and compared with the library information of the current production version, and the modification timestamp difference between the two versions is detected. Based on the difference information, the modification operation of the production version is automatically synchronized to the version, realizing the automatic detection and patch synchronization of the target version, achieving the purpose of ensuring that all versions contain necessary patches before production, and achieving the technical effect of improving the patch synchronization efficiency of the version and reducing the patch omission failure. This solves the technical problem in the related technology that when developing the version of the application based on the version pipeline, the modification operations of multiple versions are manually synchronized, which is inefficient and prone to patch omissions. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0027] Figure 1A hardware structure block diagram of a computer terminal (or mobile device) for implementing a version synchronization method on a version pipeline is shown;

[0028] Figure 2 is a flowchart of an optional version synchronization method on a version pipeline according to an embodiment of the present invention;

[0029] Figure 3 is an architecture diagram of an optional version synchronization system on a version pipeline according to an embodiment of the present invention;

[0030] Figure 4 is a schematic diagram of an optional version synchronization process on a version pipeline according to an embodiment of the present invention;

[0031] Figure 5 is a schematic diagram of an optional version synchronization device on a version pipeline according to an embodiment of the present invention;

[0032] Figure 6 The hardware structure block diagram of an electronic device (or mobile device) for optionally executing a version synchronization method on a version pipeline according to an embodiment of the present invention. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0034] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0035] It should be noted that the version synchronization method and device on the version pipeline in the present application can be used in the financial technology field when synchronizing versions on the version pipeline, and can also be used in any field other than the financial technology field when synchronizing versions on the version pipeline. The application does not limit the application field of the version synchronization method and device on the version pipeline.

[0036] It should be noted that the collected information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data are in compliance with relevant laws, regulations and standards, necessary confidentiality measures are taken, and public order and good customs are not violated, and corresponding operation entrances are provided for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions to provide users with corresponding operation entrances for users to choose to agree or refuse the results of automated decision-making; if the user chooses to refuse, the expert decision-making process will be entered.

[0037] The following embodiments of the present invention can be applied to version synchronization systems / applications / devices on various version pipelines. The present invention proposes a multi-version automatic detection strategy, which automatically detects and compares program codes, configuration files, etc. in the version library at a key node before the new version is put into production. When the modification timestamp of the lower version code in the production environment is greater than the modification timestamp of the target code, the patch of the current production version is automatically synchronized to the target version, thereby improving the efficiency of multi-version patch synchronization and avoiding patch omissions.

[0038] The present invention is described in detail below in conjunction with various embodiments.

[0039] Embodiment 1

[0040] According to an embodiment of the present invention, an embodiment of a version synchronization method on a version pipeline is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0041] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal (or mobile device) for implementing a version synchronization method on a version pipeline is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more (102a, 102b, ..., 102n are used to illustrate) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0042] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0043] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the version synchronization method on the version pipeline in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, the version synchronization method on the version pipeline described above is implemented. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0044] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0045] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0046] Under the above operating environment, this application provides Figure 2 The version synchronization method on the version pipeline shown in the figure is implemented by a version synchronization system on the version pipeline, which can be applied to software development scenarios such as systems or applications.

[0047] Figure 2 is a flowchart of an optional version synchronization method on a version pipeline according to an embodiment of the present invention, such as Figure 2 As shown, the method comprises the following steps:

[0048] Step S201 , scanning the target version on the version pipeline in the adaptive test environment to obtain program library information of the target version.

[0049] It should be noted that in the process of software development and maintenance, based on user feedback and demand changes, the software is improved and optimized through multiple small-scale updates and improvements, namely version iterations. Each iteration is a correction and enhancement of the previous version. As the demand for version iterations increases and the speed increases, the parallel development of multiple versions is achieved through version pipelines. The version pipeline is used to develop multiple versions simultaneously, which can improve the efficiency of version development, but it also brings challenges to the synchronization of multiple versions. In the traditional waterfall development process, software versions are developed sequentially, and the new target version is developed after the old version is put into production. There will be no problem of patch asynchrony. However, in the process of version synchronization development based on the pipeline, the current production version may be developed synchronously with other higher versions. The patches and other modification operations of the production version from the production stage to the production stage cannot be synchronized to the higher version, so there will be version asynchrony, which can easily lead to large-scale production failures.

[0050] It should be noted that during the development process, the version will go through three stages: development testing, adaptability testing, and production operation. The embodiment of the present invention performs automated detection and version synchronization operations on the target version that is about to be put into production, thereby avoiding production problems caused by patch omissions caused by synchronous development, ensuring the stability and security of the software before entering the production environment, and providing important guarantees for the continuous and stable operation of the system and applications.

[0051] It should be noted that the target version to be monitored is selected based on a key time point before the version goes into production, such as the version 5 days before production, to ensure that there is enough time to handle any detected anomalies. At this time, the target version is in the adaptive test environment, and the target version on the version pipeline in the adaptive test environment is scanned to obtain the program library information of the target version. The purpose of starting the scan is to promptly discover the differences between the target version and the current production version, especially the modification operations involving patch releases, so as to perform necessary synchronization before the version goes into production to avoid patch omissions in the newly released version, which in turn causes major production accidents.

[0052] Optionally, before scanning the target version on the version pipeline in the adaptive test environment, it also includes: receiving a version submission request from the development terminal, and configuring program library information for the version on the version pipeline based on the version submission request, wherein the program library information includes at least one of the following: modification timestamp, file identifier of the file that stores the version code, version identifier, version baseline identifier, information of the person who performs the modification operation, and administrator information; and storing the program library information in a database.

[0053] It should be noted that the library information is an information library created for each new development version during version development. After the developer completes the code modification and passes the self-test, the system receives a version submission request from the development terminal. This request contains detailed information about the code or configuration to be submitted to the version pipeline, such as file identification, modification personnel information, etc. It is the basis for subsequent configuration of library information. Based on the received version submission request, the system automatically creates library information for the version. Library information is the core of version control, including modification timestamp, file identification, version identification, version baseline identification, modification personnel information and administrator information, and stores the library information in the database for subsequent calls and queries. The purpose of configuring library information is to accurately record the details of each version submission for subsequent version synchronization detection and patch management.

[0054] It should be noted that the library information is continuously updated as the version changes. When the version is modified after the code modification operation, the modification timestamp in the library information needs to be updated to ensure that the modification timestamp in each version of the library information is the latest and record the information of the person who performed the modification operation.

[0055] The recording and real-time update of program library information based on versions ensures that the key information of each version submission can be recorded in time, providing a solid data foundation for the subsequent automatic detection of version synchronization. By automatically collecting and storing program library information, it reduces errors and delays in manual operations, speeds up the entire process from software development to testing and deployment, and enhances the transparency and traceability of version changes, which is helpful for preventing and solving production problems caused by missing patch synchronization.

[0056] Optionally, after storing the program library information in the database, it also includes: submitting the version on the version pipeline to the functional testing environment and performing functional testing in the functional testing environment; if the version on the version pipeline passes the functional test, submitting the version on the version pipeline to the adaptive testing environment.

[0057] It should be noted that after the version pipeline is developed and submitted to the system, the system will submit the created new version to the test environment, and perform functional testing in the test environment. The functional test environment is a test platform that simulates the actual use environment, which is mainly used to verify whether the basic functions of the software version meet expectations. The purpose of this step is to ensure the correctness of its basic functions before the software enters more complex adaptability testing, so as to discover and fix possible functional defects in advance. After the software version passes the functional test, the system will automatically submit it to the adaptability test environment. The adaptability test environment is used to verify the performance and stability of the software in specific hardware, network, operating system and other environments, and ensure that the software can adapt to various actual operating conditions. After passing the adaptability test, you can enter the preparation for production.

[0058] Optionally, before scanning the target version on the version pipeline in the adaptive test environment, it also includes: monitoring the production version in the production environment, and after monitoring that the production version performs a modification operation, reading the timestamp of executing the modification operation; calling the program library information of the production version, and updating the modification timestamp in the program library information of the production version based on the timestamp of executing the modification operation.

[0059] It should be noted that the production version in the production environment is monitored, and after the production version is monitored for modification, the modification timestamp in its program library information is updated. This ensures that any changes to the production version can be recorded in a timely manner, providing accurate data support for the synchronization detection of subsequent versions.

[0060] Step S202, determining that the target version corresponds to the production version in the production environment, and detecting the program library information of the production version.

[0061] It should be noted that after detecting the target version that is about to be put into production, the production version of the application software corresponding to the target version that is currently in production and in the production environment is determined, the program library information of the production version is detected, and the latest modification timestamp is extracted from the program library information of the production version to obtain the second modification timestamp.

[0062] Step S203, comparing the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version to obtain a comparison result.

[0063] The first modification timestamp is extracted from the program library information of the target version, and the first timestamp is compared with the second timestamp corresponding to the production version to obtain the comparison result. The purpose of the comparison is to confirm whether the target version contains all patches released in the production version, that is, to check whether the modification of the target version is earlier than or equal to the modification time of the production version. If the modification time of the target version is earlier than the modification time of the production version, this means that the target version may not synchronize some patches released by the production version. Through automated timestamp comparison, the patch synchronization status between the target version and the production version can be effectively detected, avoiding production problems that may be caused by omissions in manual operations. This process not only improves the accuracy and efficiency of version management, but also reduces the operational risks caused by incomplete version synchronization in software projects.

[0064] Step S204: When the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, the modification operation corresponding to the second modification timestamp is synchronized to the target version.

[0065] It should be noted that when it is identified that the first modification timestamp of the target version is earlier than the second modification timestamp of the production version, it means that the target version does not yet contain the patch or other modification operation corresponding to the update in the production version. Based on the comparison results, the system extracts the modification operation corresponding to the second modification timestamp from the library information of the production version. These modification operations include at least: patch release operations, which may involve dimensions such as software function enhancement, bug fixes, or configuration changes. For modification operations that have not been synchronized in the target version, they are synchronized based on the importance of the modification operations to ensure that the target version contains the latest fixes and optimizations when it is put into production. Through automated synchronization of modification operations, the problem of missing patches or modifications between the target version and the production version is effectively solved.

[0066] Optionally, when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, it also includes: determining that there is an anomaly in the target version; for the target version with the anomaly, generating anomaly warning information based on the second modification timestamp; and sending the anomaly warning information to the modification business end and / or management terminal based on the modification personnel information and administrator information in the program library information.

[0067] It should be noted that if the first modification timestamp is earlier than the second modification timestamp, the target version is marked as an abnormal version, an abnormal warning message is generated for the abnormal version, the program library information of the abnormal version is called, the modification personnel information and the administrator information in the program library information are read, and the abnormal warning message is sent to the modification business end and / or the management terminal indicated by the modification personnel information and / or the administrator information. Therefore, when performing version synchronization, synchronization can be performed based on the importance level of the modification operation, or based on the response instructions of the modification business end and / or the management terminal.

[0068] Optionally, when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, the step of synchronizing the modification operation corresponding to the second modification timestamp to the target version includes: when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, determining the modification operation corresponding to the second modification timestamp; obtaining the importance level of the modification operation, and ignoring the modification operation when the importance level of the modification operation is less than a preset level threshold; or, when the importance level of the modification operation is greater than or equal to a preset level threshold, synchronizing the modification operation to the target version.

[0069] It should be noted that when performing version synchronization, an importance level determination strategy is added. If the first modification timestamp of the target version is earlier than the second modification timestamp of the production version, the modification operation to be synchronized is determined, and whether synchronization is required is determined based on the importance level of the modification operation. If the importance level of the modification operation is less than the preset level threshold, the modification operation can be ignored and not synchronized. On the contrary, if the importance level of the modification operation is greater than or equal to the preset level threshold, the modification operation will be synchronized to the target version. By introducing the importance level evaluation of modification operations and the synchronization decision mechanism based on the level threshold, intelligent and refined management of version synchronization is achieved. This process not only avoids wasting resources due to synchronization of non-critical updates, but also ensures that all important updates are processed in a timely manner.

[0070] Optionally, after synchronizing the modification operation corresponding to the second modification timestamp to the target version, the method further includes: recording the synchronization timestamp of synchronizing the modification operation to the target version; and updating the program library information of the target version based on the synchronization timestamp.

[0071] It should be noted that after the modification operation is synchronized to the target version, the synchronization timestamp of the synchronization operation is recorded in time, and the program library information of the target version is updated according to the synchronization timestamp, so as to facilitate the synchronization of subsequent modification operations of higher versions and avoid repeated synchronization of the target version. By recording the synchronization timestamp of the modification operation and updating the program library information of the target version, the transparency and traceability of version control are significantly enhanced.

[0072] Through the above steps, the target version on the version pipeline in the adaptive test environment is scanned to obtain the program library information of the target version, wherein the version pipeline is used to develop multiple versions synchronously, and determine that the target version corresponds to the production version in the production environment, and detect the program library information of the production version, and then compare the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version to obtain a comparison result, and finally, when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, synchronize the modification operation corresponding to the second modification timestamp to the target version, wherein the modification operation at least includes: a patch release operation.

[0073] In this embodiment, the development information of each version pipeline is recorded through the program library information, and before the version on the version pipeline is released, the program library information of the target version is automatically scanned and compared with the program library information of the current production version, the modification timestamp difference between the two versions is detected, and the modification operation of the production version is automatically synchronized to the version based on the difference information, so as to realize the automatic detection and patch synchronization of the target version, achieve the purpose of ensuring that all versions contain necessary patches before production, and achieve the technical effect of improving the patch synchronization efficiency of the version and reducing the patch omission failure. This solves the technical problem in the related technology that when the version of the application is developed based on the version pipeline, the modification operations of multiple versions are manually synchronized, which is inefficient and prone to patch omission.

[0074] Another optional specific implementation is described in detail below.

[0075] Figure 3 is an architecture diagram of a version synchronization system on an optional version pipeline according to an embodiment of the present invention, such as Figure 3 As shown, the version synchronization system on the version pipeline includes: a storage module, a version synchronization module, a notification module and a confirmation and feedback module. Specifically,

[0076] The storage module is used to store the library information of the version on the version pipeline. The library information is shown in the following table:

[0077] Table 1 Library information table

[0078]

[0079] As shown in Table 1, the program library information may specifically include: modification timestamp, file identifier of the file storing the version code, version identifier, version baseline identifier, information of the person who performs the modification operation, administrator information, etc.

[0080] The workflow of the storage module is:

[0081] Developers develop based on a certain version pipeline and submit the code base after self-testing.

[0082] The assembly line version is automatically submitted to the functional testing environment for functional testing;

[0083] At the release node (if it is a patch, at the patch release point), configure the administrator to package and release the pipeline and release it to the adaptive test environment;

[0084] When the configuration administrator releases a version, the storage module automatically collects version information and stores it.

[0085] The version synchronization module can be set to start at a critical time before the version goes into production (usually one week before production), and automatically detect every day. If problems are found due to missed synchronization patches, an early warning list can be generated in time and patches can be automatically synchronized. The workflow is as follows: Figure 4 As shown, Figure 4 FIG. 1 is a schematic diagram of an optional version synchronization process on a version pipeline according to an embodiment of the present invention. The specific version synchronization process includes:

[0086] Step 1: The system periodically triggers automatic version detection;

[0087] Step 2: Automatically scan and obtain the program library information of the target version, and read the first modification timestamp;

[0088] Step 3, obtaining the program library information of the production version corresponding to the target version, and reading the second modification timestamp;

[0089] Step 4: determine whether the first modification timestamp is earlier than the second modification timestamp. If yes, proceed to step 5. If no, skip step 5 and proceed to step 6.

[0090] Step 5: Generate warning information and synchronize the target version;

[0091] Step 6: End the scan.

[0092] The notification module is used to automatically send the warning list generated by the version synchronization automatic detection module to relevant personnel, including program modifiers and version configuration administrators, for two-way confirmation.

[0093] The confirmation and feedback module is used to receive feedback information from the modifier and / or administrator, and is also used to feed back the synchronization timestamp of the synchronization operation to the storage module.

[0094] The embodiment of the present invention automatically detects and compares program codes, configuration files, etc. in the version library at key nodes before the new version is put into production. When there is a lower version code modification timestamp in the production environment that is greater than the modification timestamp of the target code, the patch of the current production version is automatically synchronized to the target version, thereby improving the efficiency of multi-version patch synchronization and avoiding patch omissions.

[0095] The following is a detailed description in conjunction with another embodiment.

[0096] Embodiment 2

[0097] The version synchronization device on a version pipeline provided in this embodiment includes multiple implementation units, each of which corresponds to each implementation step in the above-mentioned embodiment 1. Its specific implementation methods and beneficial effects can refer to the above-mentioned method embodiments and will not be repeated here.

[0098] Figure 5 is a schematic diagram of an optional version synchronization device on a version pipeline according to an embodiment of the present invention, such as Figure 5 As shown, the version synchronization device on the version pipeline may include: an acquisition unit 51, a detection unit 52, a comparison unit 53, and a synchronization unit 54, wherein:

[0099] An acquisition unit 51 is used to scan a target version on a version pipeline in an adaptive test environment to acquire program library information of the target version, wherein the version pipeline is used to develop multiple versions synchronously;

[0100] A detection unit 52, used to determine that the target version corresponds to the production version in the production environment, and detect the program library information of the production version;

[0101] A comparison unit 53, used to compare the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version to obtain a comparison result;

[0102] The synchronization unit 54 is used to synchronize the modification operation corresponding to the second modification timestamp to the target version when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, wherein the modification operation at least includes: a patch release operation.

[0103] The version synchronization device on the above-mentioned version pipeline scans the target version on the version pipeline in the adaptive test environment through the acquisition unit 51 to obtain the program library information of the target version, wherein the version pipeline is used to develop multiple versions synchronously; determines through the detection unit 52 that the target version corresponds to the production version in the production environment, and detects the program library information of the production version; compares the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version through the comparison unit 53 to obtain a comparison result; and synchronizes the modification operation corresponding to the second modification timestamp to the target version through the synchronization unit 54 when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, wherein the modification operation at least includes: a patch release operation.

[0104] In this embodiment, the development information of each version pipeline is recorded through the program library information, and before the version on the version pipeline is released, the program library information of the target version is automatically scanned and compared with the program library information of the current production version, the modification timestamp difference between the two versions is detected, and the modification operation of the production version is automatically synchronized to the version based on the difference information, so as to realize the automatic detection and patch synchronization of the target version, achieve the purpose of ensuring that all versions contain necessary patches before production, and achieve the technical effect of improving the patch synchronization efficiency of the version and reducing the patch omission failure. This solves the technical problem in the related technology that when the version of the application is developed based on the version pipeline, the modification operations of multiple versions are manually synchronized, which is inefficient and prone to patch omission.

[0105] Optionally, the version synchronization device on the version pipeline also includes: a first configuration module, used to receive a version submission request from a development terminal, and configure program library information for the version on the version pipeline based on the version submission request, wherein the program library information includes at least one of the following: modification timestamp, file identifier of a file storing version code, version identifier, version baseline identifier, information of a modifier who performs modification operations, and administrator information; a first storage module, used to store the program library information in a database.

[0106] Optionally, the version synchronization device on the version pipeline also includes: a first submission module, used to submit the version on the version pipeline to a functional testing environment and perform functional testing in the functional testing environment; a second submission module, used to submit the version on the version pipeline to an adaptive testing environment if the version on the version pipeline passes the functional test.

[0107] Optionally, the version synchronization device on the version pipeline also includes: a first determination module, used to determine whether there is an anomaly in the target version; a first generation module, used to generate anomaly warning information for the target version with the anomaly based on the second modification timestamp; a first sending module, used to send the anomaly warning information to the modification business terminal and / or management terminal based on the modifier information and administrator information in the program library information.

[0108] Optionally, the version synchronization device on the version pipeline also includes: a first reading module, used to monitor the production version in the production environment, and after monitoring the production version to perform a modification operation, read the timestamp of executing the modification operation; a first update module, used to call the program library information of the production version, and update the modification timestamp in the program library information of the production version based on the timestamp of executing the modification operation.

[0109] Optionally, the synchronization unit 54 includes: a second determination module, used to determine the modification operation corresponding to the second modification timestamp when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp; a first acquisition module, used to obtain the importance level of the modification operation, and ignore the modification operation when the importance level of the modification operation is less than a preset level threshold; a first synchronization module, used to synchronize the modification operation to the target version when the importance level of the modification operation is greater than or equal to a preset level threshold.

[0110] Optionally, the version synchronization device on the version pipeline further includes: a first recording module, used to record the synchronization timestamp of synchronizing the modification operation to the target version; and a second updating module, used to update the program library information of the target version based on the synchronization timestamp.

[0111] It should be noted that the acquisition unit 51, the detection unit 52, the comparison unit 53, and the synchronization unit 54 correspond to steps S201 to S204 in the first embodiment, and the examples and application scenarios implemented by the above units and the corresponding steps are the same, but are not limited to the contents disclosed in the first embodiment. It should be noted that the above modules or units can be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n), and the above modules or units can also be part of the device and can be run in the computer terminal 10 provided in the first embodiment.

[0112] The present invention is described below in conjunction with another optional embodiment.

[0113] Embodiment 3

[0114] An embodiment of the present invention may also provide an electronic device, Figure 6is a hardware structure block diagram of an electronic device (or mobile device) for executing a version synchronization method on a version pipeline according to an optional embodiment of the present invention, such as Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (only one is shown) processor 602, memory 604, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0115] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the methods and devices in the embodiments of the present application, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, realizing the above-mentioned method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0116] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: scan the target version on the version pipeline in the adaptive test environment to obtain the program library information of the target version, wherein the version pipeline is used to develop multiple versions synchronously; determine that the target version corresponds to the production version in the production environment, and detect the program library information of the production version; compare the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version to obtain a comparison result; when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, synchronize the modification operation corresponding to the second modification timestamp to the target version, wherein the modification operation at least includes: a patch release operation.

[0117] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: receive a version submission request from the development terminal, and configure the version library information on the version pipeline based on the version submission request, wherein the program library information includes at least one of the following: modification timestamp, file identifier of the file that stores the version code, version identifier, version baseline identifier, information of the person who performs the modification operation, and administrator information; store the program library information in a database.

[0118] The processor can call the information and application programs stored in the memory through the transmission device to perform the following steps: submit the version on the version pipeline to the functional test environment and perform functional testing in the functional test environment; if the version on the version pipeline passes the functional test, submit the version on the version pipeline to the adaptive test environment.

[0119] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: determine whether there is an abnormality in the target version; for the target version with the abnormality, generate abnormal warning information based on the second modification timestamp; send the abnormal warning information to the modification business end and / or management terminal based on the modification personnel information and administrator information in the program library information.

[0120] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: monitor the production version in the production environment, and after monitoring the production version to perform a modification operation, read the timestamp of the modification operation; call the program library information of the production version, and update the modification timestamp in the program library information of the production version based on the timestamp of the modification operation.

[0121] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, determine the modification operation corresponding to the second modification timestamp; obtain the importance level of the modification operation, and when the importance level of the modification operation is less than a preset level threshold, ignore the modification operation; or, when the importance level of the modification operation is greater than or equal to a preset level threshold, synchronize the modification operation to the target version.

[0122] The processor can call the information and application program stored in the memory through the transmission device to perform the following steps: record the synchronization timestamp of synchronizing the modification operation to the target version; and update the program library information of the target version based on the synchronization timestamp.

[0123] By adopting the embodiment of the present invention, a version synchronization scheme on a version pipeline is provided. The development information of each version pipeline is recorded through the program library information, and before the version on the version pipeline is released, the program library information of the target version is automatically scanned and compared with the program library information of the current production version, and the modification timestamp difference between the two versions is detected. Based on the difference information, the modification operation of the production version is automatically synchronized to the version, thereby realizing the automatic detection and patch synchronization of the target version, achieving the purpose of ensuring that all versions contain necessary patches before production, and achieving the technical effect of improving the patch synchronization efficiency of the version and reducing patch omission failures. This solves the technical problem in the related art that when the version of the application is developed based on the version pipeline, the modification operations of multiple versions are manually synchronized, which is inefficient and prone to patch omissions.

[0124] It can be understood by those skilled in the art that Figure 6 The structure shown is for illustration only, and the electronic device may also be a terminal device such as a smart phone, a tablet computer, a PDA, a mobile Internet device (Mobile Internet Devices, MID), a PAD, etc. Figure 6 The structure of the electronic device is not limited. Figure 6 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Figure 6 Different configurations are shown.

[0125] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0126] The present invention is described below in conjunction with another optional embodiment.

[0127] Embodiment 4

[0128] The embodiment of the present invention further provides a computer-readable storage medium. Optionally, in the embodiment of the present invention, the computer-readable storage medium can be used to store the program code executed by the version synchronization method on the version pipeline provided in the first embodiment.

[0129] Optionally, in an embodiment of the present invention, the above-mentioned storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0130] An embodiment of the present invention also provides a computer program product, which, when executed on a data processing device, is suitable for executing the steps of a version synchronization method on a version pipeline: scanning a target version on a version pipeline in an adaptive test environment to obtain program library information of the target version, wherein the version pipeline is used to synchronously develop multiple versions; determining that the target version corresponds to a production version in a production environment, and detecting program library information of the production version; comparing a first modification timestamp in the program library information of the target version with a second modification timestamp in the program library information of the production version to obtain a comparison result; when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, synchronizing the modification operation corresponding to the second modification timestamp to the target version, wherein the modification operation at least includes: a patch release operation.

[0131] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0132] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0133] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0134] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0135] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0136] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0137] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A version synchronization method on a version pipeline, characterized in that: include: Scanning a target version on a version pipeline in an adaptive test environment to obtain program library information of the target version, wherein the version pipeline is used to synchronously develop multiple versions; Determine that the target version corresponds to a production version in a production environment, and detect program library information of the production version; Compare the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version to obtain a comparison result; When the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, the modification operation corresponding to the second modification timestamp is synchronized to the target version, wherein the modification operation at least includes: a patch release operation.

2. The method according to claim 1, characterized in that Before scanning the target version on the version pipeline in the adaptive test environment, it also includes: Receive a version submission request from a development terminal, and configure program library information for the version on the version pipeline based on the version submission request, wherein the program library information includes at least one of the following: a modification timestamp, a file identifier of a file storing version code, a version identifier, a version baseline identifier, information of a modification person who performs the modification operation, and administrator information; The library information is stored in a database.

3. The method according to claim 2, characterized in that After storing the program library information in the database, the method further includes: Submitting the version on the version pipeline to a functional testing environment, and performing functional testing in the functional testing environment; When the version on the version pipeline passes the functional test, the version on the version pipeline is submitted to the adaptive test environment.

4. The method according to claim 2, characterized in that: When the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, the method further includes: Determining that the target version has an anomaly; For the target version with an exception, generating an exception warning information based on the second modification timestamp; The abnormal warning information is sent to the modification service terminal and / or the management terminal based on the modification personnel information and the administrator information in the program library information.

5. The method according to claim 1, characterized in that Before scanning the target version on the version pipeline in the adaptive test environment, it also includes: The production version in the production environment is monitored, and after monitoring that the production version is modified, a timestamp of the modification operation is read; The program library information of the production version is called, and the modification timestamp in the program library information of the production version is updated based on the timestamp of executing the modification operation.

6. The method according to claim 1, characterized in that When the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, the step of synchronizing the modification operation corresponding to the second modification timestamp to the target version includes: If the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, determining a modification operation corresponding to the second modification timestamp; obtaining the importance level of the modification operation, and ignoring the modification operation if the importance level of the modification operation is less than a preset level threshold; or, When the importance level of the modification operation is greater than or equal to the preset level threshold, the modification operation is synchronized to the target version.

7. The method according to claim 1, characterized in that After synchronizing the modification operation corresponding to the second modification timestamp to the target version, the method further includes: Recording a synchronization timestamp for synchronizing the modification operation to the target version; The library information of the target version is updated based on the synchronization timestamp.

8. A version synchronization device on a version pipeline, characterized in that: include: An acquisition unit, used for scanning a target version on a version pipeline in an adaptive test environment to acquire program library information of the target version, wherein the version pipeline is used for synchronously developing multiple versions; A detection unit, used to determine that the target version corresponds to a production version in a production environment, and detect program library information of the production version; A comparison unit, used for comparing the first modification timestamp in the program library information of the target version with the second modification timestamp in the program library information of the production version to obtain a comparison result; A synchronization unit is used to synchronize the modification operation corresponding to the second modification timestamp to the target version when the comparison result indicates that the first modification timestamp is earlier than the second modification timestamp, wherein the modification operation at least includes: a patch release operation.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located is controlled to execute the version synchronization method on the version pipeline according to any one of claims 1 to 7.

10. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the version synchronization method on the version pipeline described in any one of claims 1 to 7.

Images