CN108874409B

CN108874409B - Information updating method, device, server and system

Info

Publication number: CN108874409B
Application number: CN201710321989.XA
Authority: CN
Inventors: 武建芳
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2017-05-09
Filing date: 2017-05-09
Publication date: 2021-08-13
Anticipated expiration: 2037-05-09
Also published as: CN108874409A

Abstract

The application provides an information updating method, an information updating device, a server and an information updating system, wherein the server can feed back a current directory structure of a target service to a client for output when determining to perform incremental publishing on a publishing packet by analyzing the file type of the publishing packet of the current publishing version of the target service uploaded by the client, so that a developer can import the publishing packet into a corresponding folder of the current directory structure according to a target uploading path after specifically determining the target uploading path of the publishing packet, and the imported publishing packet is used for updating a full file of a last successful publishing version of the target service to obtain the full file of the current publishing version. Therefore, developers can directly upload and publish the publishing packet of the functional part of the target service in charge of the developers without matching with other developers of the target service, so that the method is very convenient, the uploading data volume is reduced, the network time consumption is reduced, and the information updating efficiency is greatly improved.

Description

Information updating method, device, server and system

Technical Field

The present application relates to the field of internet technologies, and in particular, to an information updating method, apparatus, server and system.

Background

Nowadays, with the rapid development of computer network technology, various application software, such as various office software, audio and video software, browsers, shopping software, navigation software and the like, appear on the market, and great convenience is brought to the work and life of people. In practical applications, application software usually needs to be upgraded continuously due to improvement of functions and repair of bugs, which requires a software publisher to release a new version.

In contrast, when the prior art upgrades the original version software, the software release package of the new version is usually released once again, and this method is time-consuming because the complete release package of the new version needs to be generated each time, then uploaded to the release machine, and then released to the online machine by the release machine. Moreover, because the development system of the application software is usually divided into a plurality of modules, the development and maintenance of each module are often assigned to a plurality of technicians for taking charge, when a new version is released, the modification part in charge of the development system and the parts of other responsible persons need to be combined to obtain the release package of the new version, so that the release of the new version is completed, and the process is complicated.

In conclusion, how to improve the portability of new release and reduce the time consumption of the network becomes an important research direction for technicians.

Disclosure of Invention

In view of this, the present application provides an information updating method, apparatus, server and system, which can directly complete the release of the release package of the functional part of the target service that is responsible for the information updating method without being matched with other developers of the target service, and is very convenient, and reduces the amount of uploaded data, reduces the time consumed by the network, and greatly improves the information updating efficiency.

In order to achieve the above object, the present application provides the following technical solutions:

the embodiment of the application also provides a file updating method, which is used for receiving the release packet which is uploaded by the client and aims at the current release version of the target service;

detecting the file type of the publishing packet, and determining to perform incremental publishing on the publishing packet;

feeding back the current directory structure of the target service to the client for outputting so that the client determines a target uploading path of the publishing packet based on the current directory structure;

importing the publishing packet into a corresponding folder of the current directory structure according to the target uploading path;

and updating the full file of the last successfully released version of the target service by using the imported release packet to obtain the full file of the current released version.

An embodiment of the present application further provides a device, where the device includes:

the data transmission module is used for receiving a release packet which is uploaded by a client and aims at the current release version of the target service;

the first data processing module is used for analyzing the file type of the distribution package, determining incremental distribution of the distribution package, and triggering the data transmission module to feed back the current directory structure of the target service to the client for output, so that the client determines the target uploading path of the distribution package based on the current directory structure;

the first data import module is used for importing the publishing packet into a corresponding folder of the current directory structure according to the target uploading path;

and the file updating module is used for updating the full file of the last successfully released version of the target service by using the imported release packet to obtain the full file of the current released version.

An embodiment of the present application further provides a server, where the server includes:

the communication interface is used for receiving a release packet which is uploaded by a client and aims at the current release version of the target service;

a memory for holding a plurality of instructions;

a processor to load and execute the plurality of instructions, comprising:

An embodiment of the present application further provides an information updating system, where the system includes: server and at least one client, wherein:

the client is used for uploading a release packet aiming at the current release version of the target service to the server according to a preset path; outputting the current directory structure of the target service fed back by the server, and determining a target uploading path of the publishing packet based on the current directory structure;

the server is configured to analyze the file type of the publishing packet, determine to perform incremental publishing on the publishing packet, feed back the current directory structure of the target service to the client, import the publishing packet into a corresponding folder of the current directory structure according to the target upload path sent by the client, and update the full-amount file of the last successfully published version of the target service by using the imported publishing packet to obtain the full-amount file of the current published version.

Based on the technical scheme, the embodiment of the application provides an information updating method, device, server and system, a client uploads a publishing package aiming at a current publishing version of a target service to the server, and the server determines that the publishing package is subjected to incremental publishing by analyzing the file type of the publishing package, so that a current directory structure of the target service can be fed back to the client for outputting, developers can flexibly and self-help determine a target uploading path of the publishing package according to needs, the server can directly import the publishing package into a corresponding folder of the current directory structure according to the target uploading path, and the imported publishing package is used for updating a full file of a last successfully published version of the target service to obtain the full file of the current publishing version. Therefore, in the method and the device, developers can flexibly select the specific uploading path of the distribution package according to the functional part of the target service which is in charge of the developers, the incremental distribution of the distribution package can be realized without matching with the distribution packages developed by other developers of the target service, the full files of the current distribution version are obtained, the method and the device are very convenient, the uploading data volume is greatly reduced, the time consumption of a network is reduced, and the file updating efficiency is greatly improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.

Fig. 1 is a block diagram of an information updating system according to an embodiment of the present disclosure;

fig. 2 is a timing diagram of an information updating method according to an embodiment of the present disclosure;

FIG. 3 is a diagram of a directory architecture provided by an embodiment of the present application;

fig. 4 is a directory structure output interface of an RBU service according to an embodiment of the present application;

FIG. 5 is a timing diagram illustrating another information updating method according to an embodiment of the present disclosure;

fig. 6 is a schematic view of a publishing interface provided in an embodiment of the present application;

fig. 7 is a flowchart of another information updating method provided in the embodiment of the present application;

fig. 8 is a block diagram illustrating an information updating apparatus according to an embodiment of the present disclosure;

fig. 9 is a block diagram of another information updating apparatus according to an embodiment of the present application;

fig. 10 is a block diagram illustrating a structure of another information updating apparatus according to an embodiment of the present application;

fig. 11 is a hardware configuration diagram of a server according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In order to make the aforementioned objects, features and advantages of the present application more comprehensible, the present application is described in further detail with reference to the accompanying drawings and the detailed description.

Fig. 1 is a block diagram of an information updating system provided in the embodiment of the present application, and the information updating system shown in the diagram can be used to implement the information updating method provided in the embodiment of the present application. Referring to fig. 1, the system may include: a server 10 and at least one client 20;

in this embodiment, the server 10 is mainly used to implement release of new versions of products such as drivers and application programs, and for a release process of a new version of a product, reference may be made to the following description of the corresponding embodiments.

The client 20 may be installed on a user device such as a mobile phone, a tablet computer, a notebook computer, or other industrial devices such as an industrial personal computer. In practical applications of the present application, a user can access the server 10 through the client 20 by establishing a communication connection with the server 10, so as to implement various functions of the client 20.

Optionally, the client 20 may be an application installed on the device as described above, and after a new version developer of a product completes a new version compiling test, the release package to be released may be uploaded to the server 10 through the client 20, so that the server 10 realizes the release of the release package according to the method described in the following embodiment.

When an application program, a driver or an operating system and other products on the terminal need to be upgraded, corresponding new version information can be downloaded from the server 10 through the internet to complete upgrading, so that the improvement of functions of the original version product and the repair of bugs are realized.

In practical application, the information updating scheme provided by the application can be implemented in an information publishing system, wherein the information publishing system is composed of a server, a network, a terminal and the like, and for application development technicians, the information publishing system can log in the information publishing system to publish an application new version or maintain the work of an application of an original version and the like.

The application platform usually comprises an Internet Data Center (IDC), and provides services such as large-scale, high-quality, safe and reliable professional server hosting, space renting, network wholesale bandwidth, ASP and EC for Internet Content Providers (ICP), enterprises, media and various websites. The method can be used as a module deployment place.

Therefore, when a developer develops software, the corresponding application function modules in the internet data center of the application platform are usually developed and maintained, and each application function module is usually given responsibility to a different developer, so as to improve the development and maintenance efficiency of the whole application.

Based on the information updating system shown in fig. 1, as shown in fig. 2, a timing chart of a file updating method provided in an embodiment of the present application may include the following steps:

in step S21, the client sends a version update request for the target service to the server, where the version update request may be used to update the full file of the last successfully released version of the target service stored in the preset path.

In the method and the device, in order to facilitate that each developer of the product can update the functional part responsible for the developer at any time, the publishing flexibility is improved, the functional part responsible for the developer in the target service can be updated in an incremental publishing mode, time consumption of a network for uploading the publishing packet is reduced, and the publishing efficiency is improved.

Therefore, in practical application, when a developer needs to update a functional part in charge of the developer, compile and test the functional part to obtain a required release package, a version update request can be initiated to a server.

Of course, when the developer needs to release the initial release version of the target service, the developer may also initiate a version update request to the server, the present application does not limit the trigger condition of the version update request, and the current release version requested to be released may be the initial release version or the upgrade release version.

Step S22, the client receives the response message fed back by the server, and sends the release packet of the current release version aiming at the target service to the server according to the preset path;

in practical application, a fixed uploading path, that is, a preset path, is usually allocated to each service of a product, and a directory structure and a release package of a corresponding service are stored in the preset path, so that after a developer develops a release package of an initial version or an upgraded version for a certain service, the release package can be uploaded to a server according to the preset path allocated to the developer.

For example, the server may give a preset path of the distribution package of the RBU service, such as, but not limited to,/data/release _ pkg/BSI98747124/BSI98732084/BSI 98750294/. At this time, the server detects a release packet of the current release version of the RBU service sent by the client, may import the release packet into a corresponding position according to the preset path, and generates a directory structure of the RBU service under the preset path.

In addition, in the present application, the distribution package of the current distribution version of the target service may be a single file, or a compressed file compressed by a folder composed of a plurality of files, and the present application does not limit the specific file format of the single file, the file format of each file included in the folder, and the compressed file format compressed by the folder, and may be determined according to the actual situation.

Step S23, the server detects the file type of the distribution package;

optionally, the present application may divide a common file formed by a single file (e.g., a file in a format of so, a, etc.) and a folder formed by a plurality of files into a first type of file by compressing a compressed file ending with a tgz. A second compressed file, which is a compressed file of another format compressed from a folder containing a plurality of files, is divided into files of a second type. In this embodiment, it may be preset that the first type of file is distributed in an incremental distribution manner, and the second type of file is distributed in a full distribution manner.

Optionally, in this embodiment, a corresponding relationship between the file type of the publishing packet and the publishing mode may be pre-established, so that after the file type of the publishing packet is detected, the publishing mode of the publishing packet of the current publishing version may be determined according to the corresponding relationship.

It should be noted that, in the present application, neither a representation manner nor a storage manner of the correspondence is limited, and the correspondence between the file type of the distribution package and the corresponding distribution manner may be determined by a manner of a correspondence table, or by setting a unique identifier, and the like, which is not listed herein.

As another embodiment of the present application, for a developer, a file type included in a release package of a current release version uploaded by the developer is known, so that the developer can also carry an identifier representing a release manner of the release package when uploading the release package of the current release version, so that a server determines the release manner of the release package of the current release version, that is, full release or incremental release, according to the received identifier.

Therefore, the process of how to determine the publishing mode of the publishing packet is not limited in the present application, and which publishing mode is adopted for the publishing of the current version is related to the file format of the publishing packet, which is specifically described in the corresponding section above.

Step S24, the server determines to carry out increment release to the release packet, and backups the full file of the last successful release version of the target service;

in practical applications, the directory structure of each service of the product is clear to developers of the product, and the primary directory of the directory structure is generally the same for different services, as shown in fig. 3, the primary directory may include folders of real _ body, rub, release, and the like. However, the second level of the directory structure and the following directories are usually different according to different services, and may be determined according to the functions of the services, and the detailed description of the embodiment is omitted here.

It should be noted that names of folders in the primary directory are not limited to those shown in fig. 3, and other names may be given according to functions of the folders, and in the architecture of the directory architecture shown in fig. 3, the secondary and following directories, such as bin, conf, op, l4rank, mcp, and the like, may represent files or folders contained in the service file itself, fig. 3 only illustrates the RBU service file as an example, and contents of the secondary and following directories may be different for other service files, and may be determined according to specific situations, and this application is not described in detail herein.

In order to more clearly understand the directory architecture shown in fig. 3, the following description will be made on the types of folder storage information of the directories in fig. 3 or the functions of the directory folders, particularly the functions of folders that are common to the businesses.

Specifically, the real _ body folder may be used to store the full amount of files of the last successfully released version; the body folder can be used for temporarily storing the full files of the current release version, and after the release is successful, the contents in the body folder are replaced by the contents in the real _ body folder, namely the full files of the current release version are used for replacing the full files of the last release version; RBU folder (which corresponds to RBU service, for other services, this folder can be the folder of the corresponding service) can be used to store the directory structure of the release package of the current release version of the target service; the release folder can be used for storing full files and incremental files of the publishing packages of all the publishing versions of the business files, v1 and v2 can represent two different publishing versions, the changed folder can be used for storing the incremental files, and the total folder can be used for storing the full files.

In practical applications, the obtained information may be imported into the corresponding folder corresponding to the function of each folder in the directory architecture. In this embodiment, after receiving the distribution package of the current release version of the RBU service, the RBU service is determined to be incrementally released in the manner described above, and in this case, it may be considered that the service already has a directory structure of a release version, that is, a directory structure of a full file of a last successfully released version.

Therefore, when incremental publishing is performed, the directory architecture of the target service to be updated is completely consistent with the directory architecture obtained by the last full publishing. Therefore, the current directory structure of the target service obtained in step S14 may be the directory structure generated when the target service was last released in full.

In combination with the above-mentioned functional description of the directory structure of each service file of the product, if the merging of the full amount of files is directly performed in the primary directory real _ body folder of the directory structure, after the files are released to the online machine, i.e., after the gray scale release is performed, it is found that the release packet uploaded by the developer is wrong, and at this time, the uploaded wrong files are already merged with the full amount of files, and the rollback of the previous version cannot be realized, thereby causing the failure of the release.

In order to solve the problem caused by the uploading error of the publishing package, in this embodiment, after determining that the publishing package of the current publishing version is issued in an incremental manner, the full-amount file of the last successfully published version stored in the current directory architecture is backed up, that is, the server has a rollback function by a way of backing up the full-amount file in the real _ body folder, so that when a developer or a publisher finds that the uploaded publishing package is in an error, the developer or the publisher can reacquire the full-amount file of the last successfully published version in the real _ body folder and then perform incremental publishing, and the integrity of the full-amount file of the last successfully published version of the target service is not affected.

Based on this, the server determines to perform incremental release on the release packet of the current release version, and may determine, in the directory architecture where the target service is located, a folder for temporarily storing the full amount of files of the current release version as a backup folder, and delete the contents in the backup folder, thereby copying the folder contents for storing the full amount of files of the last successful release version to the backup folder.

Specifically, referring to the directory architecture shown in fig. 3, the server determines to perform incremental publishing on the publishing package of the currently published version, and may use the body folder as a backup folder, delete all contents under the body folder, and copy the contents in the real _ body folder into the body folder, so that the contents of the body/directory are consistent with the contents of the real _ body/directory, and thus, in the incremental publishing process, the full files under the body/body may be merged, and the full files under the real _ body/directory are still the full publishing package of the last successfully published version, and even if the currently uploaded files are incorrect, the contents in the real _ body folder may be copied again to perform incremental publishing in the manner described above, thereby ensuring reliability of successful publishing.

Step S25, the server detects the release packet of the current release version and determines the type of the release packet;

as can be seen from the above description, the publishing package adopting the incremental publishing method may include a single file and the first compressed file. In the application, if the purpose of the incremental release is to update a certain currently stored file, the incremental release can be directly realized by adopting a file replacement mode, referring to fig. 4, when the exam.so file needs to be updated, a developer can redevelop the exam.so file and replace the original exam.so file with the file, and in this case, a release package uploaded by the developer is usually a single file.

However, if the file included in the release package of the release version does not exist in the last release version, and a certain file of the last release version is not used in the release version, that is, the file is a waste file, for this situation, because the two files are different, incremental release cannot be realized by using a file replacement method, the incremental release is realized by using a folder where the file is located, that is, the release package uploaded by the developer in this situation will be the first compressed file.

Therefore, for different types of incremental publishing packages, the specifically adopted incremental publishing modes are different, and in this embodiment, after determining that the incremental publishing mode is adopted for the received publishing package of the current publishing version, the server needs to further determine the type of the publishing package, that is, whether the publishing package is a single file or a compressed file in a specific format.

Step S26, the server determines that the distribution package of the current distribution version is a single file, determines the file to be updated in the backup folder, replaces the file to be updated with the distribution package, and enters step S211;

in combination with the above analysis, after determining that the distribution package uploaded this time needs to be incrementally distributed, the server generally sends the directory structure of the target service to the client for output, as shown in fig. 4, which facilitates developers to flexibly select a path to be uploaded of the distribution package according to a functional part that needs to be updated by the developers themselves according to actual needs, and feeds back the upload path of the distribution package to the server, so that the server sends the received distribution package to a corresponding position of the directory structure of the target service according to the upload path.

Based on this, when a developer uploads and releases a single file at this time, the storage position of the file in the current directory structure can be directly determined, so that the server determines the file to be updated to be replaced in the backup file according to the storage position or the formed uploading path, and replaces the file to be updated by using the received single file, the process is simple and convenient, the influence of function modification of other developers of the target service is avoided, and the flexibility and the efficiency of file release are greatly improved.

For example, with reference to the directory structure of a service file shown in fig. 4, if a developer needs to upload a single file in an exam.so format, the developer may determine, according to the directory frame structure of an RBU service file output by a client, where the publishing packet should be uploaded to the directory structure of the target service, that is, determine an uploading path of an incremental publishing packet, so that the server introduces the incremental publishing packet into a corresponding position of the directory structure of the RBU service file according to the uploading path, and completes incremental publishing of the single file.

It should be noted that, in the present application, a manner of determining an upload path of a single file is not limited, and correspondingly, a manner of determining a file to be updated in a backup file is not limited, and the above description may be adopted, and a developer directly selects and determines from a directory structure of a target service displayed by a client, and may also directly input an upload path of a single file, and the like, which is not described in detail herein.

Step S27, the server determines that the distribution package of the current distribution version is a first compressed file, creates a storage folder, and introduces the first compressed file into the storage folder for decompression to obtain a first decompressed folder;

as analyzed above, in incremental release, for a certain file in a version successfully released last time, if the file is no longer needed in the version successfully released this time, the file is usually deleted as a waste file, so as to ensure that the service successfully released by the version released this time can work normally.

For example, referring to fig. 3, if there is an a.conf file when a version is distributed at v1 under the conf/folder, and if the version is distributed at v2, the a.conf file is not needed any more, but is replaced with a b.conf file, the a.conf file needs to be deleted and only the b.conf file remains. For this case, the present application may replace the conf/folder of the v2 release version in its entirety with the conf/folder of the v1 release version. Therefore, the method and the device have the advantages that the update of the files is upgraded to the replacement of the folders, and the problem of deleting the abandoned files is solved.

In practical application, during the process of publishing the folder, the compressed file is usually transmitted by using a compressed file method, but the specific compressed method of the folder is not limited, and the compressed file to be published by using an incremental publishing method in this embodiment may be the first compressed file in the tgz place format.

In this embodiment, when the server determines that the first compressed file is received, a new directory folder, i.e., a storage folder, may be created to complete the decompression of the compressed file. As shown in fig. 3, a tmp folder may be created in a directory structure under a preset path of the target service to temporarily store the release packet uploaded this time, and decompress to obtain a folder included in the release packet, that is, a folder in the tgz place format. After the server determines that the release version is successfully released, the release packet and the decompressed file thereof are not needed any more, and the storage folder such as a tmp folder can be directly deleted, so that the obtained directory architecture is simplified, and the storage space is saved.

Step S28, the server determines the folder with the same name and the same path level as the first decompression folder as the folder to be updated in the backup folder and the service folder;

still by way of example, after the conf folder is replaced with the above-mentioned conf folder, the publishing package is decompressed in the created storage folder to obtain the conf folder, and then, in combination with the current directory architecture shown in fig. 3, the body/(i.e., backup folder) and RBU/(i.e., service folder of the RBU service may be determined, and for other services, the name of the service folder may change the folder belonging to the same directory as the decompressed conf folder in the same path in the directory, for example, the body/conf and RBU/conf are determined as the folders to be updated.

The service folder may include the directory structure of the distribution package and the distribution package (i.e., the incremental distribution package) as shown in rbu/folder in fig. 3, so that when a developer needs to determine a specific uploading path of the distribution package, the directory structure in the rbu folder may be fed back to the client for output, as shown in fig. 4.

Step S29, the server replaces the folder to be updated with a first decompression folder to obtain the full file and the incremental file of the current release version;

as described above, the first decompressed folder, such as the conf folder, may be used to replace the conf folder under the body/directory and the conf folder under the rbu/directory, so as to enable the body/directory to re-form the full-size files for the current release version, that is, the full-size files of the last successfully released version stored in the backup folder are updated, and the delta files stored under the release package folder are also updated, so as to obtain the delta files of the current release version re-formed under rbu/directory.

Step S210, the server creates an incremental folder and a full folder of a current release version in a version folder of a directory architecture where the target service is located, and imports the obtained full file and the incremental file into the corresponding folders;

with reference to the description of the directory structure of the target service in fig. 3, for the full files and the incremental files of the same release version of the target service, the full files and the incremental files of the same release version of the target service may be stored in two different folders of the same version folder, for example, release/version number/changed and release/version number/total are generated, then the incremental files are imported into the changed folder for storage, and the full files are imported into the total folder for storage, so as to obtain the required files according to the version path in the following process.

In step S211, the server replaces the contents of the folder storing the full amount of files of the last successfully released version in the current directory structure with the contents of the current backup folder.

In this embodiment, after determining that the version is successfully published, the body folder, that is, the content in the backup folder, may be moved to the real _ body folder (that is, the folder storing the full-amount file of the version that was successfully published last time), so that the real _ body folder stores the full-amount file of the current publishing version, and the incremental publishing of the publishing package is completed.

In summary, in this embodiment, when a developer needs to upgrade a functional part responsible for a target service and determine a corresponding release package, the release of the release package may be implemented in an incremental release manner, without uploading and releasing a whole full file, and without cooperating with other developers of the target service, so that a current release version may be released simply and conveniently, time for the developer to upload the release package and time for the operation and maintenance personnel to release the release package are saved, and efficiency of releasing a new version of a product is improved.

As shown in fig. 5, a timing diagram of another file updating method provided in this embodiment of the present application is mainly used for explaining an incremental publishing manner of a new version product file, and specifically may include the following steps:

step S51, the client sends a version update request for the target service to the server, and the version update request can be used for updating the full file of the last successfully issued version of the target service stored under the preset path;

optionally, in this embodiment, the server may perform identity authentication on the client that sends the version update request, for example, verify login information or registration information of the client, and determine whether the client user has the publishing authority of the new version of the target service. It should be noted that, the present application does not limit the authentication method of the client.

Step S52, the client receives the response message fed back by the server and outputs a version release interface;

in this embodiment, after the server verifies that the identity of the client is qualified, a corresponding response message may be fed back to the client, and then the client may output a version publishing interface, as shown in fig. 6, a selection button of a version publishing mode may be set on the version publishing interface, and a developer may select a publishing mode of a publishing package of a currently published version of the target service, but is not limited to the interface content shown in fig. 6.

Step S53, the server receives the increment issuing instruction fed back by the client, backups the full file of the last successful issuing version of the target service, and sends the current directory structure of the target service to the client;

in this embodiment, when the client outputs the version publishing interface shown in fig. 6, a developer may select a publishing manner of the current publishing package according to an actual publishing requirement, and if an increment publishing manner is selected, the client generates a corresponding increment publishing instruction and sends the increment publishing instruction to the server.

For the backup process of the full-size file of the last successfully-issued version of the target service, reference may be made to the description of the corresponding part in the foregoing embodiment, and details are not described in this embodiment again.

Step S54, the client outputs the current directory structure of the target service, obtains the upload path of the release packet of the current release version, and sends the release packet of the current release version to the server according to the upload path;

in this embodiment, the current directory structure of the directory service output by the client may be as shown in fig. 4, but is not limited thereto, at this time, a developer may directly determine a file to be updated that needs to be replaced from the directory structure, so as to determine an upload path of the distribution package, and then the client may upload the distribution package of the current distribution version to a service folder in the directory architecture of the target service stored in the server according to the upload path.

Step S55, the server detects the type of the distribution package;

as described in the foregoing embodiment, in the incremental publishing process, the publishing processes of a single file and a folder are not the same, so after receiving the incremental publishing package, the server needs to detect the file type included in the publishing package first, and determine whether the publishing package includes the single file or a compressed file compressed by the folder.

Step S56, the server determines that the release package of the current release version is a single file, and replaces the file to be updated in the backup folder with the release package;

for a single file uploaded, the embodiment may adopt a direct replacement manner, that is, a file to be updated having the same name as the file in the last release version is found from the backup folder, and the file to be updated is directly replaced with the file.

Step S57, the server determines that the release package of the current release version is a first compressed file, creates a storage folder in the directory architecture where the target service is located, and introduces the first compressed file into the storage folder for decompression to obtain a first decompressed folder;

here, the first compressed file may be a compressed file that is compressed from a folder composed of a plurality of files and ends in a tgz place format.

Step S58, the server determines the folder with the same name and the same path level as the first decompression folder as the folder to be updated in the backup folder and the service folder;

step S59, the server replaces the folder to be updated with a first decompression folder to obtain the full file and the incremental file of the current release version;

step S510, the server creates an incremental folder and a full folder of a corresponding version in a version folder of a current directory architecture, and imports the obtained full files and incremental files into the corresponding folders;

in step S511, the server replaces the contents of the folder storing the full amount of files of the last successfully released version in the current directory structure with the contents of the current backup folder.

In summary, in this embodiment, when a developer needs to update a single file or folder in a target service file, the file or folder may be used as a publishing packet, and a directory structure of the target service output by a client is used to determine a target uploading path of the target service, and the publishing packet is uploaded to a corresponding location of a server, so that the server implements incremental publishing of the publishing packet by using corresponding logic.

Moreover, the method and the device for issuing the new version issuing package adopt incremental issuing to realize issuing of the new version issuing package, developers do not need to know functional parts responsible by other developers, the functional parts responsible by the developers can be directly uploaded, the server can realize issuing of the functions, and the issuing process is flexible and practical.

The following describes a process of implementing the full publishing manner of the publishing packet of the current publishing version described in the foregoing embodiment, and as shown in fig. 7, this embodiment mainly describes the full publishing process from the perspective of the server, and as to a version update request process initiated by the client to the server, reference may be made to the description of the foregoing embodiment, which is not described in detail here, so the full publishing process may include:

step S71, receiving a release packet uploaded by a client and aiming at the current release version of the target service;

in practical application, the server may allocate a fixed upload path to each service file of a product, so that all the distribution packages of the service file are uploaded to the upload path. Therefore, in this embodiment, after determining that the release package uploaded by the developer this time needs to be released in a full amount, the server may send the preset path corresponding to the target service, that is, the upload path, to the client, so that the client uploads the release package of the current release version according to the preset path.

Step S72, decompressing the distribution packet, and generating a directory structure under the rub folder by using the obtained second decompressed folder;

in conjunction with the above description, for a full volume distribution package, it is typical to compress a second compressed file composed of a folder composed of a plurality of files, and the second compressed file is not a compressed file ending in the tgz. Therefore, after receiving the incremental publishing package, it is usually necessary to decompress it and generate the directory structure under the folder of the publishing package, i.e. rbu/folder as in fig. 3.

It should be noted that, the full-volume publishing process described in this embodiment is only performed by taking the directory structure of the RBU service shown in fig. 3 as an example, for other services, the first-level directory folder in fig. 3 is not changed, but the second-level directory folder and the following directory folder components thereof will be changed accordingly, and this embodiment is not described in detail herein.

Step S73, creating the body folder and the directory structure thereof, and importing the second decompressed folder into the directory structure of the body folder;

step S74, creating a release folder and a directory structure thereof, and importing the full-amount decompressed files into the full-amount folder with the corresponding version number in the release folder;

as shown in fig. 3, the release folder may be divided into a plurality of version numbers, each version number may be divided into a full folder and an incremental folder, and for the full distribution package, after the corresponding version number is available, the decompressed file, i.e., the full file, is directly imported into the full folder under the version number.

Step S75, deleting files in non-folders in the rbu folder to obtain a directory structure of the current release version of the target service;

in step S76, the contents in the current body folder are moved to the real _ body folder.

In this embodiment, after the release of the release package of the currently released version is realized through the full-volume release manner, a developer may perform incremental release according to actual needs on the basis of the obtained directory architecture to realize the release of the new version of the service, and the process may refer to the process described in the above embodiment, which is not described in detail herein.

It should be noted that, in practical applications, the above-mentioned full-volume publishing manner is usually adopted when an initial version of a certain service is published, and for the new version that is improved on the basis of the initial version, the incremental publishing described in the above embodiment is usually adopted, but is not limited to this.

Therefore, when the release packet of the current release version of the target service is released, a full release mode or an incremental release mode can be flexibly selected according to actual conditions, and the reliable release of the release packet of the current release version is ensured.

And after the server completes the full release, the generated directory structure aiming at the release version can be fed back to the client, and the client outputs the directory structure, so that developers can intuitively know the directory structure of the current release version of the target service, and at the moment, the contents contained in each file of each level of directory can be checked by clicking. In addition, the developer can also perform incremental release on the basis, and the process can refer to the description of the corresponding embodiment.

As shown in fig. 8, a block diagram of an information updating apparatus provided in an embodiment of the present application is shown, where the information updating apparatus may include:

the data transmission module 81 is configured to receive a release packet uploaded by a client and specific to a current release version of a target service;

the first data processing module 82 is configured to analyze a file type of the distribution package, determine to perform incremental distribution on the distribution package, and trigger the data transmission module to feed back a current directory structure of the target service to the client for output, so that the client determines a target upload path of the distribution package based on the current directory structure;

the first data import module 83 is configured to import the publishing package into a corresponding folder of the current directory structure according to the target upload path;

and a file updating module 84, configured to update, by using the imported publishing packet, the full file of the version successfully published last time by the target service, so as to obtain the full file of the current publishing version.

Optionally, on the basis of the foregoing embodiment, in order to implement incremental distribution of the distribution package of the current distribution version, as shown in fig. 9, the information updating apparatus may further include:

the file backup module 85 is used for backing up the full files of the versions successfully issued by the target service last time;

accordingly, the file updating module 84 may be specifically configured to update the obtained backup folder with the imported publishing package, where the backup folder is included in the directory structure where the target service is located, and replace, with the updated content of the backup folder, the folder content in the directory structure, where the folder content is used to store the full number of files of the last successfully published version.

Wherein, when the distribution package is the first compressed file, the information updating apparatus may further include:

a first creating module 86, configured to create a storage folder in a directory architecture where the target service is located;

the file updating module 84 may be specifically configured to send the imported first compressed file to the storage folder for decompression, obtain a corresponding first decompressed folder, query the folder with the same name and the same path level as the first decompressed folder under the directory architecture, determine the queried folder as the folder to be updated, and replace the folder to be updated with the first decompressed folder, to obtain the full-size file of the current release version.

Optionally, the information updating apparatus may further include:

a first generating module 87, configured to generate an incremental file of the target service when the publishing package is imported into the corresponding folder of the current directory structure;

a second creating module 88, configured to create a full folder and an incremental folder corresponding to the current release version in the version folder of the directory architecture where the target service is located;

and a second data importing module 89, configured to import the obtained full file of the current release version into the full folder, and import the obtained incremental file into the incremental folder.

It should be noted that, for the specific process of implementing the increment issue by each server embodiment provided in the present application, reference may be made to the description of the corresponding part of the above method embodiment, and this embodiment is not described herein again.

As another embodiment of the present application, according to actual needs, the server may further perform full distribution on a distribution package of a currently distributed version of the target service, as shown in fig. 10, where the information updating apparatus may further include:

the second data processing module 810 is configured to determine to issue the distribution package in full when the distribution package is the second compressed file;

a decompression module 811 for decompressing the second compressed file;

a second generating module 812, configured to generate a directory structure of the target service and a directory structure of a folder for storing a current release version release package by using the decompressed file or folder;

the third data import module 813 is configured to import the decompressed files or folders into corresponding folders in the directory structure of the folders, so as to obtain full files of the current release version;

a third creating module 814, configured to create a full folder corresponding to the current release version in the version folder of the directory architecture where the target service is located, and import the obtained full file into the full folder.

It should be noted that, regarding the specific process of the information updating apparatus for implementing the full-scale distribution of the distribution package by using the functional module, reference may be made to the description of the corresponding part of the foregoing method embodiment, and this embodiment is not described herein again.

Therefore, the information updating device provided by the application can determine whether the issuing mode is incremental issuing or full issuing according to the type of the issuing package uploaded by the client, so that issuing of the issuing package of the current issuing version of the target service is realized according to a corresponding control strategy, developers can conveniently and flexibly select the issuing mode to complete issuing of the issuing package of the current issuing version according to actual issuing requirements, and the information updating device is very practical. Especially, only partial functions which are responsible for the method are upgraded, the method can be completed by directly adopting an incremental release mode without being matched with other developers, the method is very convenient, and the release efficiency is greatly improved.

The following description will be made from a hardware structure of a server, and referring to fig. 11, a hardware structure diagram of a server provided by an example of the present application may include: a processor 111, a communication interface 112, a memory 113, and a communication bus 114.

The processor 111, the communication interface 112 and the memory 113 complete mutual communication through the communication bus 114;

alternatively, the communication interface 112 may be an interface of a communication module, such as an interface of a GSM module;

the processor 111 may be a central processing unit CPU or an application Specific Integrated circuit asic or one or more Integrated circuits configured to implement embodiments of the present application.

The memory 113 may comprise high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory. In this embodiment, the memory 113 may store a plurality of instructions for implementing the above information updating method.

In this application, the processor 111 loads and executes a plurality of instructions in the memory, specifically for:

receiving a release packet which is uploaded by a client and aims at a current release version of a target service;

It should be noted that, as to the specific process of the processor 111 for implementing the above functions, reference may be made to the description of the corresponding parts of the above method embodiments, and the detailed description of the embodiments is omitted here.

In conjunction with fig. 1 above, the embodiment of the present application further provides an information updating system, which may include a server 10 and at least one client 20, where:

the client 20 is configured to upload a release packet of a current release version for the target service to the server according to a preset path; outputting the current directory structure of the target service fed back by the server, and determining a target uploading path of the publishing packet based on the current directory structure;

the server 10 is configured to analyze the file type of the publishing packet, determine to perform incremental publishing on the publishing packet, feed back the current directory structure of the target service to the client, import the publishing packet into a corresponding folder of the current directory structure according to the target upload path sent by the client, and update the full-size file of the last successfully published version of the target service by using the imported publishing packet to obtain the full-size file of the current published version.

For the functional implementation of the server 10 and the client 20 in the information updating process, reference may be made to the description of the corresponding parts of the above method embodiments, and the detailed description of the embodiment is not repeated here.

In summary, the information updating scheme provided by the application can flexibly select a full-scale release or incremental release package according to the release requirement, and particularly, when developers need to upgrade the functional modules in charge of the developers, the release packages developed by the developers can be directly uploaded to the server, and the server can release the received release packages with partial functions by adopting an incremental release mode without matching the release packages of other functional modules developed by other developers, so that the updating of the partial functions is completed, the convenience is high, the time consumption of an uploaded network is greatly reduced, and the release efficiency is improved.

Finally, it should be noted that, in the embodiments, relational terms such as first, second and the like may be used solely to distinguish one operation, unit or module from another operation, unit or module without necessarily requiring or implying any actual such relationship or order between such units, operations or modules. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method or system that comprises the element.

The embodiments in the present description are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other. For the server disclosed by the embodiment, the server corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the description of the method part.

Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An information updating method, characterized in that the method comprises:

detecting the file type of the publishing packet, and determining to perform incremental publishing on the publishing packet according to the corresponding relation between the file type of the publishing packet and a publishing mode;

2. The method of claim 1, wherein after the determining to incrementally publish the publishing packet, the method further comprises:

backing up the full files of the last successfully released version of the target service;

the updating the full file of the last successfully released version of the target service by using the imported release packet includes:

updating the obtained backup folder by using the imported publishing package, wherein the backup folder is contained in a directory architecture where the target service is located;

and replacing the folder contents of the full amount of files for storing the last successfully issued version in the directory architecture by using the updated backup folder contents.

3. The method of claim 1, wherein determining that the publishing package is a single file, and wherein importing the publishing package into a corresponding folder of the current directory structure according to the target upload path comprises:

according to the target uploading path, the single file is imported into a corresponding folder of the current directory structure;

and replacing the corresponding file in the full amount of files of the last successfully issued version of the target service by using the imported single file.

4. The method of claim 1, wherein it is determined that the distribution package is a first compressed file, the method further comprising:

creating a storage folder in a directory architecture where the target service is located;

sending the imported first compressed file to the storage folder for decompression to obtain a corresponding first decompressed folder;

inquiring folders with the same name and the same path level as the first decompression folder under the directory architecture, and determining the inquired folders as folders to be updated;

and replacing the folder to be updated with the first decompressed folder to obtain the full files of the current release version.

5. The method of claim 1, wherein when importing the publishing package into the corresponding folder of the current directory structure, the method further comprises:

generating an increment file of the target service;

creating a full folder and an incremental folder corresponding to the current release version in a version folder of a directory architecture where the target service is located;

and importing the obtained full file of the current release version into the full folder, and importing the obtained incremental file into the incremental folder.

6. The method of claim 1, further comprising:

when the publishing packet is a second compressed file, determining to publish the publishing packet in a full amount;

decompressing the second compressed file;

generating a directory structure of the target service and a directory structure of a folder for storing the current release version release package by utilizing the decompressed files or folders;

importing the decompressed files or folders into corresponding folders in the generated directory structure of the folders to obtain the full files of the current release version;

and creating a full folder corresponding to the current release version in the version folder of the directory architecture where the target service is located, and importing the obtained full file into the full folder.

7. The method of claim 2, wherein the backing up the full amount of files of the last successfully released version of the target service comprises:

determining a folder for temporarily storing the full amount of files of the current release version in a directory architecture where the target service is located as a backup folder;

and deleting the content in the backup folder, and copying the folder content of the full amount of files for storing the last successfully issued version to the backup folder.

8. An information updating apparatus, characterized in that the apparatus comprises:

the first data processing module is used for analyzing the file type of the distribution package, determining to perform incremental distribution on the distribution package according to the corresponding relation between the file type of the distribution package and a distribution mode, and triggering the data transmission module to feed back the current directory structure of the target service to the client for output so that the client determines the target uploading path of the distribution package based on the current directory structure;

9. The apparatus of claim 8, further comprising:

the file backup module is used for backing up the full files of the last successfully released version of the target service;

the file updating module is specifically configured to update the obtained backup folder by using the imported release package, where the backup folder is included in a directory framework where the target service is located, and replace, by using the updated content of the backup folder, the folder content in the directory framework, where the file is used to store the full amount of files of the last successfully released version.

10. The apparatus of claim 8, wherein when the data processing module determines that the distribution package is a first compressed file, the apparatus further comprises:

the first creating module is used for creating a storage folder in a directory architecture where the target service is located;

the file updating module is specifically configured to send the imported first compressed file to the storage folder for decompression to obtain a corresponding first decompressed folder, query folders with the same name and the same path level as the first decompressed folder under the directory architecture, determine the queried folders as folders to be updated, replace the folders to be updated with the first decompressed folder, and obtain a full file of a current release version.

11. The apparatus of claim 8, further comprising:

the first generation module is used for generating an incremental file of the target service when the release package is imported into the corresponding folder of the current directory structure;

the second creating module is used for creating a full folder and an incremental folder corresponding to the current release version in the version folder of the directory architecture where the target service is located;

and the second data import module is used for importing the obtained full file of the current release version into the full folder and importing the obtained incremental file into the incremental folder.

12. The apparatus of claim 8, further comprising:

the second data processing module is used for determining to fully issue the issuing package when the issuing package is a second compressed file;

the decompression module is used for decompressing the second compressed file;

the second generation module is used for generating a directory structure of the target service and a directory structure of a folder for storing the current release version release package by utilizing the file or the folder obtained by decompression;

the third data import module is used for importing the decompressed files or folders into corresponding folders in the generated directory structure of the folders to obtain the full files of the current release version;

and the third creating module is used for creating a full folder corresponding to the current release version in the version folder of the directory architecture where the target service is located, and importing the obtained full file into the full folder.

13. A server, characterized in that the server comprises:

a memory for holding a plurality of instructions;

a processor to load and execute the plurality of instructions, comprising:

14. An information updating system, characterized in that the system comprises: server and at least one client, wherein:

the server is used for analyzing the file type of the publishing packet, determining to perform incremental publishing on the publishing packet according to the corresponding relation between the file type of the publishing packet and a publishing mode, feeding back the current directory structure of the target service to the client, importing the publishing packet into a corresponding folder of the current directory structure according to the target uploading path sent by the client, and updating the full file of the last successfully published version of the target service by using the imported publishing packet to obtain the full file of the current published version.