Resource deployment method and related device

Abstract

The invention discloses a resource deployment method and a related device, and relates to the technical field of software, the method comprises the steps that a static resource file of a new version of a target application is obtained, and the file name of the static resource file comprises information calculated and determined based on the file content of the static resource file; in the release process of the new version of the target application, uploading a static resource file in a non-coverage mode; and after uploading of the static resource file is completed, uploading page resources corresponding to the static resource file in a coverage mode. According to the scheme, the new file name is calculated and determined through the file content of the new-version static resource file, and after the new-version static resource file is uploaded, the page resource corresponding to the static resource file is uploaded in a coverage mode; in this way, after the front-end browser accesses the new-version static resource file with the new file name based on the newest page resource, the new-version static resource file can be loaded in time, and the consistency of the static resource and the dynamic page of the front-end browser is guaranteed.

Description

Technical Field

[0001] The present application relates to the field of software technology, and more specifically, to a resource deployment method and related devices. Background Art

[0002] In traditional front-end deployment solutions, in order to further improve website performance, static resources and dynamic web pages are deployed in clusters. The purpose of deploying static resources and dynamic web pages in clusters is to improve website performance and flexibility. However, when deploying a new version, since the synchronization between different clusters is not instantaneous, there may be situations where the static resource page has been updated but the corresponding version of the page structure has not been updated, or the page structure has been updated but the corresponding version of the static resource has not been updated. This will cause users to encounter inconsistent resources and pages during access, causing a series of problems. For example, when users access the new page structure and load old resources, the style becomes messy, or the old version page loads the new version of resources, resulting in page execution errors. Summary of the invention

[0003] In view of this, this application provides the following technical solutions:

[0004] The first aspect of the present application provides a resource deployment method, which is executed on an application server, comprising:

[0005] Obtaining a static resource file of a new version of a target application, wherein a file name of the static resource file includes information calculated and determined based on file content of the static resource file;

[0006] In the process of publishing the new version of the target application, the static resource file is uploaded to the managed storage object in a non-overwriting manner, wherein the non-overwriting manner means that the historical version of the static resource file previously stored in the managed storage object is retained when uploading the static resource file;

[0007] After the static resource file is uploaded, the page resource corresponding to the static resource file is uploaded to the managed storage object in an overwriting manner. The overwriting manner indicates that the historical version of the page resource previously stored in the managed storage object is overwritten when the page resource is uploaded.

[0008] In a possible implementation, after obtaining the static resource file of the new version of the target application, the following is further included:

[0009] Performing a hash operation on the file content of the static resource file to generate a content summary corresponding to the static resource file;

[0010] The content summary is added to the original name of the static resource file to obtain the file name of the static resource file.

[0011] In a possible implementation, in a process of publishing a new version of a target application corresponding to the static resource file, uploading the static resource file in a non-overwriting manner includes:

[0012] During the release of the new version of the target application, the static resource files are uploaded to the managed storage object in an additive manner, and the managed storage object also retains the static resource files of the historical version of the target application.

[0013] In a possible implementation, after the static resource file is uploaded, the page resource corresponding to the static resource file is uploaded in an overwriting manner, including:

[0014] After the static resource file is uploaded, the page resource corresponding to the static resource file is uploaded to the managed storage object in an overwriting and replacement manner;

[0015] After the page resource is uploaded, the managed storage object does not include the historical page resource.

[0016] In a possible implementation manner, the managed storage object is any one of the following: an object storage system, a content distribution network.

[0017] In a possible implementation, after uploading the page resource corresponding to the static resource file in an overwriting manner, the method further includes:

[0018] Controlling access rights to the new version of the target application includes at least one of the following:

[0019] Configuring a gateway server for hosting the storage object, wherein the configuration of the gateway server is used to control access to some users among all users accessing the target application;

[0020] An access policy for a managed storage object storing the static resource files and the page resources is configured, wherein the access policy is used to control access to only some of all the users accessing the target application.

[0021] In a possible implementation, it also includes:

[0022] If no abnormality report of the new version of the target application is obtained within a first period after the access permission of the new version of the target application is controlled, the access permission of the new version of the target application is released.

[0023] A second aspect of the present application provides a resource deployment device, which is executed on an application server and includes:

[0024] A resource acquisition module, used to obtain a static resource file of a new version of a target application, wherein the file name of the static resource file includes information calculated and determined based on the file content of the static resource file;

[0025] A first uploading module is used to upload the static resource file to the managed storage object in a non-overwriting manner during the release of the new version of the target application, wherein the non-overwriting manner means that the historical version of the static resource file stored previously is retained when uploading the static resource file;

[0026] The second uploading module is used to upload the page resources corresponding to the static resource file to the managed storage object in an overwriting manner after the static resource file is uploaded. The overwriting manner means that the historical version of the page resources stored in the managed storage object is overwritten when uploading the page resources.

[0027] A third aspect of the present application provides a server, comprising at least one processor and a memory connected to the processor, wherein:

[0028] The memory is used to store computer programs;

[0029] The processor is used to execute the computer program so that the server can implement any one of the above resource deployment methods.

[0030] The fourth aspect of the present application provides a computer storage medium, characterized in that the storage medium carries one or more computer programs, and when the one or more computer programs are executed by a server, the server can implement any of the above-mentioned resource deployment methods.

[0031] After the new version of the static resource file is successfully uploaded, the above scheme updates the page resources in an overwriting manner. Since the name of the new version of the static resource file contains a part calculated based on the file content, it is different from the name of the historical version of the static resource file. Therefore, when the front-end browser accesses the hosted storage object based on the updated page resources, it can discover the existence of the new version of the static resource file through the file name and load it, so that the historical version of the resources cached in the front-end will no longer be used. This ensures that when the browser can access the page resources corresponding to the new version, it can also promptly discover and load the new version of the static resource file, thereby ensuring the consistency of the static resources and dynamic pages of the front-end browser, and avoiding style confusion and page execution errors caused by the mismatch between the static resources and the corresponding page resource versions. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0033] Figure 1 A flowchart of a resource deployment method disclosed in an embodiment of the present application;

[0034] Figure 2 A flowchart of determining the file name of a static resource file disclosed in an embodiment of the present application;

[0035] Figure 3 A schematic diagram of the full path accessed by the target application disclosed in the embodiment of the present application;

[0036] Figure 4 A schematic diagram of the structure of a resource deployment device disclosed in an embodiment of the present application;

[0037] Figure 5 A schematic diagram of the structure of a server disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0039] Figure 1 This is a flowchart of a resource deployment method disclosed in an embodiment of the present application. Figure 1 The method shown is executed on the application server. Figure 1 As shown, the resource deployment method may include:

[0040] Step 101: Obtain a static resource file of a new version of a target application, wherein the file name of the static resource file includes information calculated and determined based on the file content of the static resource file.

[0041] The target application may be any type of application, such as any of the following applications: video applications, reading applications, communication and interaction applications, education applications, asset management applications, etc. After the target application is put into use, various functions of the application will be continuously adjusted and optimized based on user feedback and user needs, so updated application versions will be released frequently to better serve users.

[0042] The new version of the target application described in this article can be understood as the latest, to-be-released version of the application, before which an old version already exists and is in use. The technical solution of this application is intended to solve the problem that the static resources and web resources of the new and old versions of the target application may not be updated synchronously during the deployment process, which may lead to the front-end page style disorder or page execution error.

[0043] In this embodiment, before the relevant content of the new version of the target application is deployed, the static resource file of the new version of the target application is first obtained. The static resource file may include but is not limited to CSS cascading style sheets, JS script files, pictures, etc. The file name of the static resource file is different from the traditional static resource name. The file name is a name obtained by a certain calculation based on the file content of the static resource file. The specific implementation of calculating and determining the file name of the static resource will be described in detail in the following embodiment content, and will not be described in detail here.

[0044] Step 102: During the release of the new version of the target application, the static resource file is uploaded to the managed storage object in a non-overwriting manner, wherein the non-overwriting manner means that the historical version of the static resource file previously stored in the managed storage object is retained when uploading the static resource file.

[0045] After the file name of the static resource file of the new version of the target application is determined, the static resource file (including its file name) can be uploaded to a managed storage object that can be called and loaded by the front-end page, so that the subsequent front-end browser can obtain and load the new version of the static resource file from the managed storage object. The managed storage object can be other objects outside the server that can store data.

[0046] In the embodiment of the present application, the static resource file is uploaded in a non-overwriting manner. The storage in the non-overwriting manner is additional storage, that is, adding new data on the basis of the originally stored data. The added stored data will not affect the originally stored data in the storage object, that is, uploading the new version of the static resource file will not affect the historical version of the static resource file. The front-end old version page can still call and load the corresponding old version of the static resource file, ensuring that no page execution errors occur. In other words, the static resource file is uploaded to the storage object in a non-overwriting manner to ensure that the existing resources are not replaced during the upload of the new resources, and to ensure that the current user's access is not disturbed.

[0047] Step 103: After the static resource file is uploaded, the page resource corresponding to the static resource file is uploaded to the managed storage object in an overwriting manner. The overwriting manner means that the historical version of the page resource previously stored in the managed storage object is overwritten when the page resource is uploaded.

[0048] In this application, after the static resource files are uploaded, the corresponding page resources are uploaded. The page resources are uploaded in an overwrite manner. The overwrite storage is a replacement storage, and the originally stored data will be deleted while the new data is stored, that is, the uploaded page resources will overwrite the historical version of the page resources. In this way, after the page resources of the new version of the target application, that is, the page resources corresponding to the static resource files are loaded, when the user accesses the application on the front end, the latest page resources can be directly presented, and the static resource files of the new version of the target application can be loaded, ensuring the consistency of the page resources and the static resources.

[0049] In this application, the automated non-overwrite upload and overwrite upload processes improve the overall deployment efficiency, reduce the possibility of human error, improve the reliability of deployment, and are suitable for large-scale distributed systems.

[0050] After the new version of the static resource file is successfully uploaded, the resource deployment method described in this embodiment updates the page resources in an overwriting manner. Since the name of the new version of the static resource file contains a part determined based on the file content, it is different from the name of the historical version of the static resource file. Therefore, when the front-end browser accesses the hosted storage object based on the updated page resources, it can find the existence of the new version of the static resource file through the file name and load it, so that the historical version of the resources cached in the front-end will no longer be used. This ensures that when the browser can access the page resources corresponding to the new version, it can also promptly find and load the new version of the static resource file, thereby ensuring the consistency of the static resources and dynamic pages of the front-end browser, avoiding style confusion and page execution errors caused by the mismatch between the static resources and the corresponding page resource versions, and contributing to the continuity and stability of browser access.

[0051] Figure 2 This is a flowchart of determining the file name of a static resource file disclosed in an embodiment of the present application. Figure 2 As shown, the determination of the file name of the static resource file in the above embodiment may include:

[0052] Step 201: Perform a hash operation on the file content of a static resource file to generate a content summary corresponding to the static resource file.

[0053] Step 202: Add the content summary to the original name of the static resource file to obtain the file name of the static resource file.

[0054] In this embodiment, the content summary of the static resource file can be obtained by performing a hash operation on the file content of the static resource file, and the content summary is unique. Then, the calculated content summary can be added to the original name of the static resource file to obtain a new file name.

[0055] In this application, the content summary is used as the basis for cache update. Each time a static resource file is constructed, a hash operation can be performed on the file content of the static resource file to generate a corresponding content summary. For example, the file content of a CSS file styles.css (original name) is hashed by the hash function SHA256 (a function that can map a message of any length into a hash value with a length of 256 bits) to obtain 123abc (here 123abc is a hypothetical hash value corresponding to the content summary described above), which is added to the original name to obtain a new file name styles.123abc.css. The file name of the static resource file contains the content summary generated from the file content, so when the content of the static resource file changes, the content summary will also change.

[0056] Based on the above, when the front-end browser accesses the target application, it first obtains the page resources, and then accesses the managed storage object storing the static resource files based on the page resources, and finds a new file name (for example, styles.456def.css). It thinks that the corresponding static resource file is a brand new resource, so it will not use the cached old version of the static resource file, but reload the new version of the static resource file from the server. With this strategy, when a new version is released, there is no need to worry about the front-end browser not loading the new version of the static resource in time and still using the cached old version of the static resource, thus avoiding the problem of inconsistent versions of static resources and page resources.

[0057] In the aforementioned embodiment, during the release process of a new version of a target application corresponding to the static resource file, uploading the static resource file in a non-overwriting manner may include: during the release process of a new version of a target application corresponding to the static resource file, uploading the static resource file in an appended manner to a managed storage object, wherein the managed storage object also includes static resource files of historical versions of the target application.

[0058] The managed storage object can be an object storage system, a content distribution network, etc. By uploading static resource files to the managed storage object, the static resource files will not occupy server resources, reducing the dependence on server storage and bandwidth, and effectively reducing the server resources required for front-end deployment.

[0059] When a new version of the target application is released, the generated new version of the static resource file (file name with content summary) is uploaded to the object storage or content distribution network in a non-overwrite manner. This ensures that when users visit the old version of the page, they can still load the old version of the static resource file and will not be affected by the upload of the new static resource file.

[0060] After the static resource file is uploaded, the page resources corresponding to the static resource file are uploaded in an overwriting manner, which may include: after the static resource file is uploaded, the page resources corresponding to the static resource file are uploaded to the managed storage object in an overwriting replacement manner; after the page resources are uploaded, the managed storage object does not include historical page resources.

[0061] The page resource may be an HTML file, which includes the storage address of the corresponding static resource file. After the static resource file is uploaded, the page resource is overwritten and uploaded, so that when the user accesses the target application page, the static resource file of the new version of the target application is loaded based on the updated page resource, ensuring the consistency of the browser dynamic page and the static resource version.

[0062] Static resource files need to be verified by the managed storage object when they are uploaded. The verification here can verify whether the server uploading the data is legal, whether the uploaded data is safe, etc., to prevent some unsafe data from being uploaded to the managed storage object.

[0063] In the specific implementation, during the resource file upload stage, the generated static resource file (file name with content summary) of the new version of the target application can be uploaded to the object storage system in a non-overwriting manner. After all static resource files are uploaded, the pipeline notification interface is called to overwrite and upload the page resources of the new version of the target application to the object storage system.

[0064] After the new version of the page resource is overwritten and uploaded to the object storage system, the browser obtains the new version of the page resource by accessing it, and accesses the static resource file based on the page resource; because the file name of the static resource file contains a content summary, whenever the content of the static resource file changes, the file name also changes accordingly, so that when the front-end browser accesses these resources, it can timely discover and load the new version of the static resource file, effectively avoiding the problem that the new version of the static resource file cannot be cached in the browser in time. The page resource takes effect immediately after uploading. Through the overwriting upload function of the object storage, it is ensured that the effective page resource is consistent with the version of the referenced static resource file, ensuring that the user reads the latest page resource. In implementation, the managed storage object can be deployed on a virtual machine. After the new version of the static resource file and the page resource are uploaded to the managed storage object, the virtual machine can obtain a user access request, which comes from the browser. The browser obtains the page resource on the virtual machine through the user access request, and then accesses the address of the static resource file recorded in the page resource to view the static resource file; if a new version of the static resource file is found, the new version of the static resource file is loaded to the front-end cache. In other implementations, uploading the page resource corresponding to the static resource file in an overwriting manner may also include: controlling access rights of the new version of the target application.

[0065] Figure 3 This is a schematic diagram of the full path of the target application access disclosed in the embodiment of this application. Figure 3 As shown, from Figure 3 Starting from the left side of the figure, the user initiates an access request through the terminal device, and then the DNS resolves the domain name carried in the access request. The gateway server sends the user request to the corresponding distribution load server based on the domain name, and the distribution load server accesses the hosted storage object based on the domain name. There are multiple storage buckets in the hosted storage object, including storage buckets for storing static resource files and page resources.

[0066] Combination Figure 3 Specifically, controlling the access rights of the new version of the target application may include any of the following: configuring the gateway server of the hosted storage object, and the configuration of the gateway server is used to control access to some of all access users of the target application; configuring the access policy of the hosted storage object storing the static resource files and the page resources, and the access policy is used to control access to some of all access users of the target application.

[0067] The hosted storage object is deployed on a virtual machine, and the gateway server for configuring the hosted storage object is also the gateway server for configuring the virtual machine. User access to the target application needs to go through the gateway server. These user accesses carry user identifiers, and the corresponding user information can be matched based on the user identifier, such as user age, gender, region, whether or not a member, etc. The target user characteristics can be configured on the gateway server, so that the configured gateway server allows users who meet the target user characteristics to access, and intercepts access to users who do not meet the target user characteristics. The target user characteristics may include a combination of different user feature information. In the example, the configuration for the gateway server can be used to limit access to users with set user portraits, such as member users are allowed to access, male users are allowed to access, etc.; or user access in area A is allowed, and user access in other areas outside area A is not allowed.

[0068] The access policy may be configured to allow a fixed ratio of users to access, such as allowing 20% ​​of users to access and not allowing 80% of users to access.

[0069] In the implementation, if no abnormal report of the new version of the target application is obtained within the first period after the access rights of the new version of the target application are controlled, the access rights of the new version of the target application will be released. That is, in the grayscale testing phase, if there are no problems with the operation of the new version of the target application, there will be no restrictions on the access to the new version of the target application, and all front-end browsers that access the target application can use the new version of the static resource files, allowing users to experience the new version of the target application.

[0070] The purpose of configuring the gateway server of the managed storage object and / or the access policy of the managed storage object in this implementation is to implement the grayscale test of the new version of the target application. That is, a small number of users are selected to test the target application first to verify the stability and compatibility of the new version of the target application. Before the final full release, the scope of use of the new version or new function is gradually expanded to gradually cover more users to ensure that the new version can run well in the actual environment.

[0071] During the grayscale testing phase, the gateway server can be configured and the access policy of the object storage can be combined with the user feature grouping configuration of the gateway server to ensure that grayscale testing users and ordinary users obtain different versions of resources, which helps to achieve a smooth upgrade of the target application.

[0072] In summary, the present application is intended to solve the problem of style confusion or page execution errors caused by untimely resource cache updates in traditional front-end deployment solutions. At the same time, it also improves the stability and reliability of the release of new functions of the target application by supporting grayscale testing capabilities. The core idea of ​​this application is to manage the resource cache by generating a content summary through the file content of the static resource file and using it as part of the file name, using non-overwriting to upload static resources, and then overwriting to upload page resource files, so as to ensure that users can still access the application normally during the deployment process.

[0073] For the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0074] The method is described in detail in the embodiments disclosed in the above-mentioned application. The method of the application can be implemented by various forms of devices. Therefore, the application also discloses a device, and a specific embodiment is given below for detailed description.

[0075] Figure 4 A schematic diagram of the structure of a resource deployment device disclosed in an embodiment of the present application. Figure 4 The device shown is executed on an application server. Figure 4 As shown, the resource deployment device 40 may include:

[0076] The resource acquisition module 401 is used to obtain a static resource file of a new version of a target application, wherein the file name of the static resource file includes information calculated and determined based on the file content of the static resource file.

[0077] The first uploading module 402 is used to upload the static resource file to the managed storage object in a non-overwriting manner during the release of the new version of the target application. The non-overwriting manner means that the historical version of the static resource file stored previously is retained when uploading the static resource file.

[0078] The second uploading module 403 is used to upload the page resources corresponding to the static resource file to the managed storage object in an overwriting manner after the static resource file is uploaded. The overwriting manner means that the historical version of the page resources previously stored in the managed storage object is overwritten when uploading the page resources.

[0079] After the new version of the static resource file is successfully uploaded, the resource deployment device described in this embodiment updates the page resources in an overwriting manner. Since the name of the new version of the static resource file contains a part determined based on the file content, it is different from the name of the historical version of the static resource file. Therefore, when the front-end browser accesses the hosted storage object based on the updated page resources, it can find the existence of the new version of the static resource file through the file name and load it, so that the historical version of the resources cached in the front-end will no longer be used, ensuring that the browser can timely find and load the new version of the static resource file when it can access the page resources corresponding to the new version, thereby ensuring the consistency of the static resources and dynamic pages of the front-end browser, and avoiding style confusion and page execution errors caused by the mismatch between the static resources and the corresponding page resource versions.

[0080] In one implementation, the device also includes: a name determination module, which is used to perform a hash operation on the file content of the static resource file to generate a content summary corresponding to the static resource file; and add the content summary to the original name of the static resource file to obtain the file name of the static resource file.

[0081] In one implementation, the first upload module can be specifically used to: during the release of a new version of the target application corresponding to the static resource file, upload the static resource file to the managed storage object in an appended manner, and the managed storage object also includes the static resource file of the historical version of the target application.

[0082] In one implementation, the second upload module can be specifically used to: after the static resource file is uploaded, the page resources corresponding to the static resource file are uploaded to the managed storage object, and the historical page resources are deleted; after the page resources are uploaded, the historical page resources are not included in the managed storage object.

[0083] In one implementation, the managed storage object is any one of the following: an object storage system, a content distribution network.

[0084] In one implementation, the resource deployment device may further include: a grayscale testing module, which is used to control the access rights of the new version of the target application after uploading the page resources corresponding to the static resource file in the overwriting manner.

[0085] In one implementation, the grayscale testing module is specifically used for at least one of the following: configuring the gateway server of the hosted storage object, and the configuration of the gateway server is used to control access to some of all access users of the target application; configuring the access policy of the hosted storage object storing the static resource files and the page resources, and the access policy is used to control access to some of all access users of the target application.

[0086] For the specific implementation of the above resource deployment device and the modules it contains, please refer to the corresponding parts of the method embodiment, which will not be repeated here.

[0087] Any one of the resource deployment devices described in the above embodiments includes a processor and a memory. The resource acquisition module, the first upload module, the second upload module, the name determination module, the request response module, the grayscale test module, etc. in the above embodiments are all stored in the memory as program modules, and the processor executes the above program modules stored in the memory to implement corresponding functions.

[0088] The processor includes a kernel, which retrieves the corresponding program module from the memory. One or more kernels can be set, and the processing of the access data can be realized by adjusting the kernel parameters.

[0089] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0090] In an exemplary embodiment, a computer-readable storage medium is also provided, which can be directly loaded into the internal memory of a computer and contains software code. After being loaded and executed by a computer, the computer program can implement the steps shown in any embodiment of the resource deployment method described above.

[0091] In an exemplary embodiment, a computer program product is also provided, which can be directly loaded into the internal memory of a computer and contains software codes. After being loaded and executed by a computer, the computer program can implement the steps shown in any embodiment of the resource deployment method described above.

[0092] Furthermore, an embodiment of the present application provides a server. Figure 5 This is a schematic diagram of the structure of a server disclosed in an embodiment of the present application. Figure 5 As shown, the server 50 includes at least one processor 501, and at least one memory 502 and a bus 503 connected to the processor; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the above-mentioned resource deployment method.

[0093] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0094] It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0095] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0096] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A resource deployment method, characterized in that: Executed on the application server, including: Obtaining a static resource file of a new version of a target application, wherein a file name of the static resource file includes information calculated and determined based on file content of the static resource file; In the process of publishing the new version of the target application, the static resource file is uploaded to the managed storage object in a non-overwriting manner, wherein the non-overwriting manner means that the historical version of the static resource file previously stored in the managed storage object is retained when uploading the static resource file; After the static resource file is uploaded, the page resource corresponding to the static resource file is uploaded to the managed storage object in an overwriting manner. The overwriting manner indicates that the historical version of the page resource previously stored in the managed storage object is overwritten when the page resource is uploaded.

2. The resource deployment method according to claim 1, characterized in that: After obtaining the static resource files of the new version of the target application, it also includes: Performing a hash operation on the file content of the static resource file to generate a content summary corresponding to the static resource file; The content summary is added to the original name of the static resource file to obtain the file name of the static resource file.

3. The resource deployment method according to claim 1, characterized in that: In the process of publishing a new version of the target application corresponding to the static resource file, uploading the static resource file in a non-overwriting manner includes: During the release of the new version of the target application, the static resource files are uploaded to the managed storage object in an additive manner, and the managed storage object also retains the static resource files of the historical version of the target application.

4. The resource deployment method according to claim 1, characterized in that: After the static resource file is uploaded, the page resource corresponding to the static resource file is uploaded in an overwriting manner, including: After the static resource file is uploaded, the page resource corresponding to the static resource file is uploaded to the managed storage object in an overwriting and replacement manner; After the page resource is uploaded, the managed storage object does not include the historical page resource.

5. The resource deployment method according to claim 3 or 4, characterized in that: The managed storage object is any one of the following: an object storage system, a content distribution network.

6. The resource deployment method according to claim 1, characterized in that: After uploading the page resource corresponding to the static resource file in an overwriting manner, the method further includes: Controlling access rights to the new version of the target application includes at least one of the following: Configuring a gateway server for hosting the storage object, wherein the configuration of the gateway server is used to control access to some users among all users accessing the target application; An access policy for a managed storage object storing the static resource files and the page resources is configured, wherein the access policy is used to control access to only some of all the users accessing the target application.

7. The resource deployment method according to claim 6, characterized in that: Also includes: If no abnormality report of the new version of the target application is obtained within a first period after the access permission of the new version of the target application is controlled, the access permission of the new version of the target application is released.

8. A resource deployment device, characterized in that: Executed on the application server, including: A resource acquisition module, used to obtain a static resource file of a new version of a target application, wherein the file name of the static resource file includes information calculated and determined based on the file content of the static resource file; A first uploading module is used to upload the static resource file to the managed storage object in a non-overwriting manner during the release of the new version of the target application, wherein the non-overwriting manner means that the historical version of the static resource file stored previously is retained when uploading the static resource file; The second uploading module is used to upload the page resources corresponding to the static resource file to the managed storage object in an overwriting manner after the static resource file is uploaded. The overwriting manner means that the historical version of the page resources previously stored in the managed storage object is overwritten when uploading the page resources.

9. A server, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the server can implement the resource deployment method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by the server, the server can implement the resource deployment method as described in any one of claims 1 to 7.

Images