A method for synchronous changes of components

Abstract

This invention discloses a method for synchronizing component changes, relating to the field of internet technology. The method includes the following steps: prompting the user to input a file path and business name; extracting the file name and synchronization type based on the user input; recombining the extracted information and inserting a unique identifier at the beginning of the file; using a keyword retrieval algorithm to search line by line for references to other files within the file; recursively executing the above process until the last line of the file is reached; using the same method to identify files in other projects; and synchronizing the identified changed files to other projects. This invention automates both the file marking process and the code synchronization process by reusing file reuse. Users only need to input a few parameters to automatically implement the above processes using a script. Whether it's an existing project or a newly created project, as long as certain conditions are met, this invention can be used to implement the code synchronization process. Furthermore, script parameters can be flexibly configured according to project characteristics, making it widely applicable.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, specifically to a method for synchronously changing components. Background Technology

[0002] With the growth of cloud computing business volume and changes in usage patterns, scenarios such as public cloud, private cloud, domestically developed cloud, hyper-converged infrastructure, and all-in-one machines exist. Elastic storage management systems have developed multiple products for different usage scenarios. To maintain overall system consistency, the page design style of each product is basically the same. At the code implementation level, each product's front-end implementation corresponds to a separate front-end project. However, due to various reasons, these front-end projects are currently developed and maintained independently. When developing or modifying similar page components, the same code logic has to be written multiple times for different projects. This not only leads to low development efficiency but also significantly increases labor and maintenance costs, and makes it difficult to guarantee code quality.

[0003] Currently, there are multiple similar front-end projects in the elastic storage management system. Many front-end components in these projects can be reused. However, the current development approach requires that the same component be developed independently in each project. Modifying a component also requires modifying multiple places at the same time, resulting in a lot of repetitive work and low development efficiency. Moreover, in order to ensure product consistency, it is often necessary to manually synchronize changes to other projects. This is not only inefficient, but also makes it difficult to guarantee product quality. As the number of projects and changes increases in the later stages, this drawback becomes more and more obvious. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a component synchronization change method, which solves the problem that when a common page component in an elastic storage management system needs to be changed, in order to ensure product consistency, it is often necessary to manually synchronize the change to other projects, which is not only inefficient but also makes it difficult to guarantee product quality.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for synchronous change of components, comprising the following steps:

[0006] S1: Prompt the user to enter the file path and service name, extract the file name and synchronization type based on the user input, recombine them and insert a unique identifier at the beginning of the file;

[0007] S2: Use a keyword search algorithm to search line by line within the file to see if it references other files, and recursively execute the above process until the last line of the file is found;

[0008] S3: Use the same method to identify files in other projects, achieved by running cstor_sync_id.sh;

[0009] S4: Synchronize the marked change files to other projects. This can be done using the cstor_sync_file.sh script or the cstor_sync_file_new.sh script.

[0010] Furthermore, in S1, for existing projects, it is determined that the target file needs to be synchronized to other projects when the code is changed. The target file has a unique copy in other projects, and then a unique identifier is injected into each file.

[0011] Furthermore, the method for injecting a unique identifier in S1 is as follows: add a comment to the first line of the file, the comment content is "synchronous file type / business name / file name", where the synchronous file type is separated by a hyphen, the word before the hyphen is fixed as 'sync', the name after the hyphen is a custom name according to the current file type, the business name is the business module to which the file belongs, and the last part is the name of the current file, which must be the same as the file name.

[0012] Furthermore, in the method of injecting unique identifiers, if the file references other files, all files referenced in the file are identified as multi-project synchronization files. The referenced files must have a unique copy in each project. If there are still referenced files in the referenced files, recursive identification is required.

[0013] Furthermore, the unmarked files in S3 are not reusable files for multiple projects, and the unmarked files do not need to be synchronized.

[0014] Furthermore, for existing projects, the change synchronization process is implemented using the cstor_sync_file.sh script. The specific execution method includes the following steps:

[0015] 1) Use the system-integrated code hosting tool to retrieve all locally changed files;

[0016] 2) Read the first line of the file to remove unmarked files, obtain the unique identifier of each file, match the file unique identifier with the file to obtain the list of files to be synchronized, and store it in the local cache;

[0017] 3) Connect remotely to the host of the project to be synchronized in sequence, locate the root directory of the project, loop through the file list in the local cache, and retrieve the file to be synchronized in the remote project according to the file name and unique identifier;

[0018] 4) Transfer the local file to the retrieved file path, and overwrite the file.

[0019] Furthermore, in S1, for newly created projects, a directory structure is planned for files that can be reused by multiple projects. The file types that may be used now and in the future are distinguished in combination with the actual project architecture, and a separate file directory is created for each file type. After creation, all projects must be built according to the same directory structure.

[0020] Furthermore, for the construction rules of the reusable file directory structure in newly created projects, the directory is also constructed according to the unique identification rules in S1, namely: "synchronous file type / business name / file name". The reusable file directory should be placed directly under the project root path, while ensuring that the relative path of the same file is consistent in all projects.

[0021] Furthermore, after the directory structure of a newly created project is built, when the contents of files within the directory are changed, the changes will be synchronized to other projects using the cstor_sync_file_new.sh script.

[0022] Furthermore, the specific execution method of the cstor_sync_file_new.sh script includes the following steps:

[0023] 1) Use the system-integrated code hosting tool to retrieve all locally changed files;

[0024] 2) Remove files that do not need to be synchronized based on their file paths, extract the relative path of each file, match the relative paths with the files one by one, obtain the list of files to be synchronized, and store it in the local cache.

[0025] 3) Connect remotely to the host of the project to be synchronized in sequence, locate the root directory of the project, loop through the file list in the local cache, and retrieve the files to be synchronized in the remote project according to the file relative path;

[0026] 4) Transfer the local file to the retrieved file path, and overwrite the file.

[0027] The present invention has the following advantages: the component synchronization change method automates both the reusable file marking process and the code synchronization process. Users only need to input a few parameters to automatically implement the above process using a script, resulting in a high degree of automation. Whether it is an existing project or a new project, as long as certain conditions are met, the present invention can be used to implement the code synchronization process. Furthermore, the script parameters can be flexibly configured according to the characteristics of the project, resulting in high flexibility and wide applicability.

[0028] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0029] Figure 1This is a flowchart of the method of the present invention;

[0030] Figure 2 This describes the execution flow of the cstor_sync_id.sh script in this invention.

[0031] Figure 3 This describes the execution flow of the cstor_sync_file.sh script in this invention.

[0032] Figure 4 This is a diagram showing the relationship between the annotations in this invention;

[0033] Figure 5 This describes the execution flow of the cstor_sync_file_new.sh script in this invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] In the description of this invention, it should be understood that the terms "opening", "upper", "lower", "thickness", "top", "middle", "length", "inner", "around", etc., which indicate orientation or positional relationship, are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the components or elements referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as limiting this invention.

[0036] Example 1: Please refer to Figures 1-4 This invention provides a technical solution: a method for synchronously changing components, such as... Figure 1 As shown, the method includes the following steps:

[0037] S1: Prompt the user to enter the file path and service name. If the file exists, extract the file name and synchronization type based on the user's input information, recombine them, and insert a unique identifier at the beginning of the file.

[0038] S2: Use a keyword search algorithm to search line by line within the file to see if it references other files, and recursively execute the above process until the last line of the file is found;

[0039] S3: Use the same method to identify files in other projects, achieved by running cstor_sync_id.sh, such as... Figure 2 As shown;

[0040] S4: Synchronize the marked change files to other projects. Unmarked files do not need to be synchronized because they are not reusable across multiple projects. This process can be achieved using the cstor_sync_file.sh script or the cstor_sync_file_new.sh script.

[0041] In this embodiment, in step S1), for existing projects, it is determined that the target file needs to be synchronized to other projects when the code is changed. The target file has a unique copy in other projects, which is a prerequisite for code synchronization. Then, a unique identifier is injected into each file to ensure its uniqueness.

[0042] In this embodiment, the method for injecting the unique identifier in S1) is as follows: add a comment to the first line of the file, the comment content of which is "synchronization file type / service name / file name", such as Figure 4 As shown, synchronous file types are separated by hyphens. The name before the hyphen is always 'sync', and the name after the hyphen is a custom name based on the current file type. For example, in the above example, if the current file is a vue file, the synchronous file type name is 'sync_vue'. Similarly, if the current file is a js file, the synchronous file type name is 'sync_js'. The corresponding relationship is shown below:

[0043] File type Synchronized file type name Vue sync_vue js sync_js CSS sync_css html sync_html png sync_png

[0044] The business name is the business module to which the file belongs. If the file is a general component that does not depend on any business, it can be named "common". The last part is the name of the current file, which must be the same as the file name.

[0045] In this embodiment, if a file references other files in the method of injecting unique identifiers, all files referenced in the file are identified as multi-project synchronization files. Each project must have a unique copy of the referenced file. If there are still referenced files in the referenced file, recursive identification is required.

[0046] In this embodiment, for existing projects, the change synchronization process is implemented using the cstor_sync_file.sh script, such as... Figure 3 As shown, the specific operation method includes the following steps:

[0047] 1) Use the system-integrated code hosting tool to retrieve all locally modified files. Currently, it supports both git and svn. The script will automatically match the system.

[0048] 2) Read the first line of the file to remove unmarked files, obtain the unique identifier of each file, match the file unique identifier with the file to obtain the list of files to be synchronized, and store it in the local cache;

[0049] 3) Connect remotely to the host of the project to be synchronized in sequence, locate the root directory of the project, loop through the file list in the local cache, and retrieve the file to be synchronized in the remote project according to the file name and unique identifier;

[0050] 4) Transfer the local file to the retrieved file path and overwrite the file, thus completing the code synchronization process.

[0051] Example 2: Please refer to Figure 1 , Figure 2 and Figure 5 This invention provides a technical solution: a method for synchronously changing components, such as... Figure 1 As shown, the method includes the following steps:

[0052] S1: Prompt the user to enter the file path and service name. If the file exists, extract the file name and synchronization type based on the user's input information, recombine them, and insert a unique identifier at the beginning of the file.

[0053] S2: Use a keyword search algorithm to search line by line within the file to see if it references other files, and recursively execute the above process until the last line of the file is found;

[0054] S3: Use the same method to identify files in other projects, achieved by running cstor_sync_id.sh, such as... Figure 2 As shown;

[0055] S4: Synchronize the marked change files to other projects. Unmarked files do not need to be synchronized because they are not reusable across multiple projects. This process is achieved using the cstor_sync_file_new.sh script.

[0056] In this embodiment, in S1), for newly created projects, the directory structure is planned for files that can be reused by multiple projects. The file types that may be used now and in the future are distinguished in combination with the actual project architecture, and a separate file directory is created for each file type. After creation, all projects must be built according to the same directory structure.

[0057] In this embodiment, the reusable file directory structure construction rules for newly created projects are also constructed according to the unique identification rules in S1), namely: "synchronous file type / business name / file name", for example: / sync_vue / osd / table.vue. The reusable file directory should be placed directly under the project root path, and at the same time, it should be ensured that the relative path of the same file is consistent in all projects. For example, the relative path of the table.vue file in the above example should also be / sync_vue / osd / table.vue in other projects.

[0058] In this embodiment, after the directory structure of a newly created project is built, when the content of files within the directory changes, the changes are synchronized to other projects. This synchronization process is achieved using the `cstor_sync_file_new.sh` script. Figure 5 As shown, the specific operation method includes the following steps:

[0059] 1) Use the system-integrated code hosting tool to retrieve all locally modified files. Currently, it supports both git and svn. The script will automatically match the system.

[0060] 2) Remove files that do not need to be synchronized based on their file paths, and extract the relative path of each file. For example, if the absolute path of a file is / home / project_name / sync_vue / osd / table.vue, the relative path of the file is / sync_vue / osd / table.vue. Match the relative paths of the files with the files one by one to obtain a list of files to be synchronized and store it in the local cache.

[0061] 3) Connect remotely to the host of the project to be synchronized in sequence, locate the root directory of the project, loop through the file list in the local cache, and retrieve the files to be synchronized in the remote project according to the file relative path;

[0062] 4) Transfer the local file to the retrieved file path, and overwrite the file.

[0063] This invention provides a method for synchronous component changes, enabling the same code developed in one place to be used multiple times within the same project, and achieving cross-project reuse. This significantly reduces development costs and improves code quality and development efficiency. Compared with existing technologies, the advantages of this invention are:

[0064] 1. High degree of automation: The process of marking reusable files and synchronizing code are both automated. Users only need to input a few parameters to automatically complete the above processes using scripts.

[0065] 2. High flexibility and wide applicability: Whether it is an existing project or a new project, as long as certain conditions are met, the code synchronization process can be achieved using this invention; script parameters can also be flexibly configured according to the characteristics of the project.

[0066] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0067] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for synchronously changing components, characterized in that: The following steps are included: S1: Prompt the user to enter the file path and business name. Extract the file name and synchronization type based on the user's input information, recombine them, and inject a unique identifier into the first line of the file. The file being identified is a file that can be reused in multiple projects. S2: Use a keyword search algorithm to search line by line within the file to see if it references other files, and recursively execute the above process until the last line of the file is found; S3: Use the same method to identify files in other projects, achieved by running cstor_sync_id.sh; S4: Synchronize the marked change files to other projects. This can be done using the cstor_sync_file.sh script or the cstor_sync_file_new.sh script. The method of injecting a unique identifier in S1 is as follows: add a comment to the first line of the file, the comment content is "synchronous file type / business name / file name", where the synchronous file type is separated by a hyphen, the word before the hyphen is fixed as 'sync', the name after the hyphen is a custom name according to the current file type, the business name is the business module to which the file belongs, and the last part is the name of the current file, which must be the same as the file name; In the method of injecting unique identifiers, if the file references other files, all the files referenced in the file will be marked as files that can be reused in multiple projects. The referenced files will necessarily have a unique copy in each project. If there are still referenced files in the referenced files, the marking needs to be done recursively. For existing projects, the change synchronization process is implemented using the cstor_sync_file.sh script. The specific steps are as follows: 1) Use the system-integrated code hosting tool to retrieve all locally changed files; 2) Read the first line of the file to remove unmarked files, obtain the unique identifier of each file, match the unique identifier of each file with the file to obtain the list of files to be synchronized, and store it in the local cache; 3) Connect remotely to the host of the project to be synchronized in sequence, locate the root directory of the project, loop through the file list in the local cache, and retrieve the files to be synchronized in the remote project according to the file name and unique identifier; 4) Transfer the local file to the retrieved file path, and overwrite the file.

2. The component synchronization change method according to claim 1, characterized in that: In S1, for existing projects, it is determined that the target file needs to be synchronized to other projects when the code is changed. The target file has a unique copy in other projects, and then a unique identifier is injected into each file.

3. The component synchronization change method according to claim 1, characterized in that: In S3, files that are not marked are not reusable files for multiple projects, and files that are not marked do not need to be synchronized.

4. The component synchronization change method according to claim 1, characterized in that: In S1, for newly created projects, a directory structure is planned for files that can be reused in multiple projects. The file types that may be used now and in the future are distinguished in combination with the actual project architecture, and a separate file directory is created for each file type. After creation, all projects must be built according to the same directory structure.

5. The component synchronization change method according to claim 4, characterized in that: For the construction rules of reusable file directory structure in newly created projects, the directory is also constructed according to the unique identification rules in S1, namely: "synchronous file type / business name / file name". The reusable file directory should be placed directly under the project root path, and at the same time, ensure that the relative path of the same file is consistent in all projects.

6. A component synchronization change method according to claim 5, characterized in that: After a newly created project has built its directory structure, when the contents of files within that directory change, the changes are synchronized to other projects using the cstor_sync_file_new.sh script.

7. A component synchronization change method according to claim 6, characterized in that: The specific execution method of the cstor_sync_file_new.sh script includes the following steps: 1) Use the system-integrated code hosting tool to retrieve all locally changed files; 2) Remove files that do not need to be synchronized based on their file paths, extract the relative path of each file, match the relative paths with the files one by one, obtain the list of files to be synchronized, and store it in the local cache. 3) Connect remotely to the host of the project to be synchronized in sequence, locate the root directory of the project, loop through the file list in the local cache, and retrieve the files to be synchronized in the remote project according to the file relative path; 4) Transfer the local file to the retrieved file path, and overwrite the file.

Images