A method for Ansible script version control and rollback based on file metadata

Abstract

The present invention relates to the technical field of version control and rollback, and discloses a method for performing Ansible script version control and rollback based on file metadata; the method for performing Ansible script version control and rollback based on file metadata comprises the following steps: establishing a version library root directory; establishing a master version control system; establishing a branch version control system; and establishing a rapid modification system; in the present invention, a company-level configuration library administrator manages the permissions of the public control files and sub-version libraries of the version control server, thereby eliminating the need to establish or maintain control files within each version library, thereby improving system operation efficiency, and at the beginning of the project, all project-related configuration items are included in the version control library for management, and the status of each stage and each configuration item of the project is clarified by version marking and file metadata classification storage, thereby ensuring the orderliness and rollability of the versions, and quickly resolving the same problems existing in all versions.

Description

Technical Field

[0001] The present invention belongs to the technical field of version control and rollback, and specifically provides a method for performing Ansible script version control and rollback based on file metadata. Background Art

[0002] Ansible scripts are primarily used to automate operations and maintenance tasks, greatly assisting the software development process. However, it is difficult to control personnel allocation during the software development process. This lack of control can lead to conflicts between the work of different people on the same project when software version issues arise, resulting in the following problems:

[0003] When two or more programmers independently develop the same software, changes made by the last person can easily undermine the work of others. When a bug in copied code is fixed, it's often not made known to everyone who shares the code. In large systems, when common software functionality is modified, it's essential that everyone using the common code is informed. However, without effective code management, it's impossible to ensure that everyone is informed. Many large-scale software releases are developed using an incremental release process. While one release is being delivered to users, another is still under testing, and perhaps a third is in development. Bug fixes must be carefully considered across all of these releases. In large systems, multiple active releases may occur simultaneously, and many people are involved in bug fixes and software enhancements, which can easily lead to conflicts. Summary of the Invention

[0004] In view of the above situation, in order to overcome the defects of the prior art, the present invention provides a method for Ansible script version control and rollback based on file metadata, which effectively solves the problem that when two or more programmers independently develop the same software, the changes made by the last person can easily damage the work of others. When an error in the copied code is fixed, it is often not possible to let all the people who share the code know. In large systems, when modifying common software functions, it is necessary for all people who use the public code to know, but if there is a lack of effective code management, it is impossible to guarantee that each user can be found and reminded. Many large-scale software releases are developed in a progressive release manner. While one release version is delivered to users for use, another version is still under testing, and a third version may be in the development stage. The repair of errors must carefully consider all these versions. In large systems, multiple active versions may be released at the same time, and there are many people involved in error repair and software enhancement, which can easily lead to conflicts.

[0005] To achieve the above object, the present invention provides the following technical solution: a method for Ansible script version control and rollback based on file metadata, characterized in that it includes the following steps:

[0006] Step 1: Create a repository root directory. Create a root directory for all repository versions on the Ansible version control server. Create multiple sub-repositories within the repository root directory. Create trunk, branch, tag, and document directories within the sub-repositories. The public control files of the version control server are located in the repository root directory and are managed uniformly by the company-level configuration library administrator, who also controls the permission settings of the sub-repositories.

[0007] Step 2: Establish a master version control system. Create a new version library through the administrator of the Ansible server and initialize the version library. Programmers will develop the software. After the software development is completed, the first-level version will be marked, and the file metadata of the software script will be classified and stored in the directory of the sub-version library. Then, internal testing will be carried out. If the internal test fails, the version will be rolled back according to the first-level version mark and redeveloped. If the internal test passes, the second-level version will be marked and the file metadata will be classified and stored, and then field testing will be carried out. If the field test passes, the third-level version will be marked and the file metadata will be classified and stored, and the version will be released online. If the field test fails, the version will be rolled back according to the second-level version mark, and modifications will be made, and the modified content will be merged with the file metadata of the second-level version.

[0008] Step 3: Establish a branch version control system. The administrator of the Ansible server establishes a branch version library based on the third-level version. Since programmers develop branch versions, when the branch version development is completed, the branch version is marked with a sub-first-level version and stored in file metadata classification. Then the branch version is merged with the third-level version, and marked with a sub-second-level version and stored in file metadata classification. Then internal testing is carried out. When the internal test fails, the version is rolled back according to the sub-second-level version mark and re-developed. When the internal test passes, the sub-third-level version is marked and the file metadata is classified and stored, and then field testing is carried out. When the field test passes, the sub-fourth-level version is marked and the file metadata is classified and stored, and the version is released online. When the field test fails, the version is rolled back according to the sub-third-level version mark, and modifications are made, and the modified content is merged with the file metadata of the sub-third-level version.

[0009] Step 4: Establish a rapid modification system. Use the Ansible server to compare and detect the script code content of each version stored in steps 2 and 3 and the corresponding file metadata, find the copied code content, and mark it. When a copied code content is modified, other identical codes can be updated synchronously. Programmers can unmark one or more marked codes to cancel the synchronous content update of the code content.

[0010] Preferably, the trunk directory is used to store trunk program files, including daily software development activities and management materials, and the daily development activities include coding, testing, and document writing.

[0011] Preferably, the branch directory is used to store branch versions of software development, and the branch versions can be independently developed and tested without affecting the progress of the main development line.

[0012] Preferably, the mark directory is used to store program versions with different mark states, and the document directory is used to store document materials related to the entire project, including software development requirement documents, design documents, test documents, library construction script files, development plans, weekly reports and meeting minutes.

[0013] Preferably, the file metadata refers to data used to describe various attribute information of a file, which is data about the data and is used to describe the content, structure, background and management process of the data, and provides detailed information about the file.

[0014] Preferably, the version library initialization refers to the process of creating and setting the initial state of a local version library. In the initialized version library, the modification and deletion of each file can be tracked so that the history can be traced at any time or restored at some point in the future. Through initialization, version management of files in the project can be started to ensure the security and traceability of the code.

[0015] Compared with the prior art, the beneficial effects of the present invention are: 1. In the present invention, the company-level configuration library administrator uniformly manages the permissions of the public control files and sub-version libraries of the version control server, so that there is no need to establish or maintain control files within each version library, thereby improving the system operation efficiency. At the beginning of the project, all configuration items related to the project are included in the version control library for management. The status of each stage and configuration item of the project is clarified through version tags and file metadata classification storage, ensuring the orderliness and rollback of the version.

[0016] 2. The present invention compares and detects the codes in all versions and marks the duplicate code contents found. When a duplicate code content is modified, other identical codes can be updated synchronously. Programmers can unmark one or more marked codes and cancel the synchronous content update of the code content, thereby quickly solving the same problems in all versions and reducing the time and manpower costs of version repair. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are used to provide further understanding of the present invention and constitute a part of the specification. They are used to explain the present invention together with the embodiments of the present invention and do not constitute a limitation of the present invention.

[0018] In the attached figure:

[0019] Figure 1 This is a framework diagram of the method for Ansible script version control and rollback based on file metadata of the present invention;

[0020] Figure 2 This is a framework diagram of step 1 in the method for Ansible script version control and rollback based on file metadata of the present invention;

[0021] Figure 3 This is a framework diagram of step 2 in the method for Ansible script version control and rollback based on file metadata of the present invention;

[0022] Figure 4 This is a framework diagram of step three in the method for Ansible script version control and rollback based on file metadata of the present invention. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments; based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0024] See also Figure 1-Figure 4 The present invention provides a method for Ansible script version control and rollback based on file metadata, comprising the following steps:

[0025] Step 1: Create a repository root directory. Create a root directory for all repository versions on the Ansible version control server. Create multiple sub-repositories within the repository root directory. Create trunk, branch, tag, and document directories within the sub-repositories. The public control files of the version control server are located in the repository root directory and are managed uniformly by the company-level configuration library administrator, who also controls the permission settings of the sub-repositories.

[0026] Step 2: Establish a master version control system. Create a new version library through the administrator of the Ansible server and initialize the version library. Programmers will develop the software. After the software development is completed, the first-level version will be marked, and the file metadata of the software script will be classified and stored in the directory of the sub-version library. Then, internal testing will be carried out. If the internal test fails, the version will be rolled back according to the first-level version mark and redeveloped. If the internal test passes, the second-level version will be marked and the file metadata will be classified and stored, and then field testing will be carried out. If the field test passes, the third-level version will be marked and the file metadata will be classified and stored, and the version will be released online. If the field test fails, the version will be rolled back according to the second-level version mark, and modifications will be made, and the modified content will be merged with the file metadata of the second-level version.

[0027] Step 3: Establish a branch version control system. The administrator of the Ansible server establishes a branch version library based on the third-level version. Since programmers develop branch versions, when the branch version development is completed, the branch version is marked with a sub-first-level version and stored in file metadata classification. Then the branch version is merged with the third-level version, and marked with a sub-second-level version and stored in file metadata classification. Then internal testing is carried out. When the internal test fails, the version is rolled back according to the sub-second-level version mark and re-developed. When the internal test passes, the sub-third-level version is marked and the file metadata is classified and stored, and then field testing is carried out. When the field test passes, the sub-fourth-level version is marked and the file metadata is classified and stored, and the version is released online. When the field test fails, the version is rolled back according to the sub-third-level version mark, and modifications are made, and the modified content is merged with the file metadata of the sub-third-level version.

[0028] Step 4: Establish a rapid modification system. Use the Ansible server to compare and detect the script code content of each version stored in steps 2 and 3 and the corresponding file metadata, find the copied code content, and mark it. When a copied code content is modified, other identical codes can be updated synchronously. Programmers can unmark one or more marked codes to cancel the synchronous content update of the code content.

[0029] Among them, the trunk directory is used to store trunk program files, including daily software development activities and management materials. The daily development activities include coding, testing, and document writing. The branch directory is used to store branch versions of software development. The branch versions can be independently developed and tested without affecting the progress of the main development line. The mark directory is used to store program versions with different markup states. The document directory is used to store document materials related to the entire project, including software development requirements documents, design documents, test documents, library construction script files, development plans, weekly reports, and meeting minutes. File metadata refers to data used to describe various attribute information of files. It is data about data, used to describe the content, structure, background, and management process of the data, and provides detailed information about the file. Version library initialization refers to the process of creating and setting the initial state of a local version library. In the initialized version library, the modification and deletion of each file can be tracked so that the history can be traced at any time or restored at some point in the future. Through initialization, you can start version management of files in the project to ensure the security and traceability of the code.

[0030] Example 1

[0031] A method for Ansible script version control and rollback based on file metadata includes the following steps:

[0032] Step 1: Create a repository root directory. Create a root directory for all repository versions on the Ansible version control server. Create multiple sub-repositories within the repository root directory. Create trunk, branch, tag, and document directories within the sub-repositories. The public control files of the version control server are located in the repository root directory and are managed uniformly by the company-level configuration library administrator, who also controls the permission settings of the sub-repositories.

[0033] Step 2: Establish a master version control system. Create a new version library through the administrator of the Ansible server and initialize the version library. Programmers will develop the software. After the software development is completed, the first-level version will be marked, and the file metadata of the software script will be classified and stored in the directory of the sub-version library. Then, internal testing will be carried out. If the internal test fails, the version will be rolled back according to the first-level version mark and re-developed. If the internal test passes, the second-level version will be marked and the file metadata will be classified and stored, and then field testing will be carried out. If the field test passes, the third-level version will be marked and the file metadata will be classified and stored, and the version will be released online. If the field test fails, the version will be rolled back according to the second-level version mark, and modifications will be made, and the modified content will be merged with the file metadata of the second-level version.

[0034] Step 3: Establish a rapid modification system. Use the Ansible server to compare and detect the script code content of each version stored in step 2 and the corresponding file metadata, find the copied code content, and mark it. When a copied code content is modified, other identical codes can be updated synchronously. Programmers can unmark one or more marked codes to cancel the synchronous content update of the code content.

[0035] Through the above method, the company-level configuration library administrator will uniformly manage the permissions of the public control files and sub-version libraries of the version control server, so that there is no need to establish or maintain control files within each version library, thereby improving the efficiency of system operation. At the beginning of the project, all project-related configuration items are included in the version control library for management. The status of each stage and configuration item of the project is clarified through version tags and file metadata classification storage, ensuring the orderliness and rollback of the version.

[0036] Example 2

[0037] A method for Ansible script version control and rollback based on file metadata includes the following steps:

[0038] Step 1: Create a repository root directory. Create a root directory for all repository versions on the Ansible version control server. Create multiple sub-repositories within the repository root directory. Create trunk, branch, tag, and document directories within the sub-repositories. The public control files of the version control server are located in the repository root directory and are managed uniformly by the company-level configuration library administrator, who also controls the permission settings of the sub-repositories.

[0039] Step 2: Establish a master version control system. Create a new version library through the administrator of the Ansible server and initialize the version library. Programmers will develop the software. After the software development is completed, the first-level version will be marked, and the file metadata of the software script will be classified and stored in the directory of the sub-version library. Then, internal testing will be carried out. If the internal test fails, the version will be rolled back according to the first-level version mark and redeveloped. If the internal test passes, the second-level version will be marked and the file metadata will be classified and stored, and then field testing will be carried out. If the field test passes, the third-level version will be marked and the file metadata will be classified and stored, and the version will be released online. If the field test fails, the version will be rolled back according to the second-level version mark, and modifications will be made, and the modified content will be merged with the file metadata of the second-level version.

[0040] Step 3: Establish a branch version control system. The administrator of the Ansible server establishes a branch version library based on the third-level version. Since programmers develop branch versions, when the branch version development is completed, the branch version is marked with a sub-first-level version and stored in file metadata classification. Then the branch version is merged with the third-level version, and marked with a sub-second-level version and stored in file metadata classification. Then internal testing is carried out. When the internal test fails, the version is rolled back according to the sub-second-level version mark and re-developed. When the internal test passes, the sub-third-level version is marked and the file metadata is classified and stored, and then field testing is carried out. When the field test passes, the sub-fourth-level version is marked and the file metadata is classified and stored, and the version is released online. When the field test fails, the version is rolled back according to the sub-third-level version mark, and modifications are made, and the modified content is merged with the file metadata of the sub-third-level version.

[0041] Step 4: Establish a rapid modification system. Use the Ansible server to compare and detect the script code content of each version stored in steps 2 and 3 and the corresponding file metadata, find the copied code content, and mark it. When a copied code content is modified, other identical codes can be updated synchronously. Programmers can unmark one or more marked codes to cancel the synchronous content update of the code content.

[0042] Through the above method, by comparing and detecting the codes in all versions and marking the duplicate code contents found, when a duplicate code content is modified, other identical codes can be updated synchronously. Programmers can unmark one or more marked codes and cancel the synchronous content update of the code content, so as to quickly solve the same problems in all versions, thereby reducing the time and manpower costs of version repair.

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

[0044] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A method for Ansible script version control and rollback based on file metadata, characterized by: The following steps are involved: Step 1: Create a repository root directory. Create a root directory for all repository versions on the Ansible version control server. Create multiple sub-repositories within the repository root directory. Create trunk, branch, tag, and document directories within the sub-repositories. The public control files of the version control server are located in the repository root directory and are managed uniformly by the company-level configuration library administrator, who also controls the permission settings of the sub-repositories. Step 2: Establish a master version control system. Create a new version library through the administrator of the Ansible server and initialize the version library. Programmers will develop the software. After the software development is completed, the first-level version will be marked, and the file metadata of the software script will be classified and stored in the directory of the sub-version library. Then, internal testing will be carried out. If the internal test fails, the version will be rolled back according to the first-level version mark and redeveloped. If the internal test passes, the second-level version will be marked and the file metadata will be classified and stored, and then field testing will be carried out. If the field test passes, the third-level version will be marked and the file metadata will be classified and stored, and the version will be released online. If the field test fails, the version will be rolled back according to the second-level version mark, and modifications will be made, and the modified content will be merged with the file metadata of the second-level version. Step 3: Establish a branch version control system. The administrator of the Ansible server establishes a branch version library based on the third-level version. Since programmers develop branch versions, when the branch version development is completed, the branch version is marked with a sub-first-level version and stored in file meta-classification. Then the branch version is merged with the third-level version, and marked with a sub-second-level version and stored in file meta-classification. Then, internal testing is carried out. When the internal test fails, the version is rolled back according to the sub-second-level version mark and redeveloped. When the internal test passes, the sub-third-level version is marked and stored in file meta-classification, and then field testing is carried out. When the field test passes, the sub-fourth-level version is marked and stored in file meta-classification, and the version is released online. When the field test fails, the version is rolled back according to the sub-third-level version mark, and modifications are made, and the modified content is merged with the file metadata of the sub-third-level version. Step 4: Establish a rapid modification system. Use the Ansible server to compare and detect the script code content of each version stored in steps 2 and 3 and the corresponding file metadata, find the copied code content, and mark it. When a copied code content is modified, other identical codes can be updated synchronously. Programmers can unmark one or more marked codes to cancel the synchronous content update of the code content.

2. The method for Ansible script version control and rollback based on file metadata according to claim 1, characterized in that: The trunk directory is used to store trunk program files, including daily software development activities and management information. The daily development activities include coding, testing, and document writing.

3. The method for Ansible script version control and rollback based on file metadata according to claim 2, characterized in that: The branch directory is used to store branch versions of software development, and the branch versions can be independently developed and tested without affecting the progress of the main development line.

4. The method for Ansible script version control and rollback based on file metadata according to claim 2, characterized in that: The marking directory is used to store program versions with different marking statuses, and the document directory is used to store document materials related to the entire project, including software development requirement documents, design documents, test documents, library construction script files, development plans, weekly reports and meeting minutes.

5. The method for Ansible script version control and rollback based on file metadata according to claim 1, characterized in that: The file metadata refers to data used to describe various attribute information of a file. It is data about the data and is used to describe the content, structure, background and management process of the data, providing detailed information about the file.

6. The method for Ansible script version control and rollback based on file metadata according to claim 1, characterized in that: The repository initialization is the process of creating and setting the initial state of a local repository. In the initialized repository, the modification and deletion of each file can be tracked so that the history can be traced at any time or restored at some point in the future. Through initialization, you can start version management of files in the project to ensure the security and traceability of the code.

Images