Method for performing Ansible script version control and rollback based on file metadata

Abstract

The invention relates to the technical field of version control and rollback, and discloses an Ansible script version control and rollback method 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 main version control system; establishing a branch version control system; establishing a rapid modification system; according to the invention, the company-level configuration library administrator manages the public control file of the version control server and the authority of the sub-version library, so that the control file does not need to be established or maintained in each version library, and the operation efficiency of the system is improved; at the beginning of a project, all configuration items related to the project are stored in a version control library for management, the states of all the stages and all the configuration items of the project are clarified in a version marking and file metadata classified storage mode, the orderliness and rollback performance of versions are ensured, and the same problems existing in all the versions can be rapidly solved.

Description

Technical Field

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

[0002] Ansible scripts are mainly used for automated operation and maintenance tasks, which can greatly assist the software development process. However, it is difficult to control the personnel configuration during the software development process. Without this control, when problems occur in the software version content, conflicts will occur in the work of different personnel in the same project, resulting in the following problems:

[0003] When two or more programmers independently develop the same software, the changes made by the last person are likely to damage the work of others. When a bug in the copied code is fixed, it is often not possible to let everyone who shares the code know. In a large system, when a common software function is modified, it is necessary for everyone who uses the common code to know. However, without effective code management, it is impossible to ensure that every user can be found and reminded. Many large software releases are developed in an incremental release manner. While one release version is delivered to users for use, another version is still under testing, and perhaps a third version is in the development stage. Bug fixes must be carefully considered for all these versions. In a large system, multiple active versions may be released simultaneously, and there are many people involved in bug fixing and software enhancement, which is likely to cause conflicts. Summary of the Invention

[0004] In view of the above situation, 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 problems that when two or more programmers independently develop the same software, the changes made by the last person are likely to damage the work of others. When a bug in the copied code is fixed, it is often not possible to let everyone who shares the code know. In a large system, when a common software function is modified, it is necessary for everyone who uses the common code to know. However, without effective code management, it is impossible to ensure that every user can be found and reminded. Many large software releases are developed in an incremental release manner. While one release version is delivered to users for use, another version is still under testing, and perhaps a third version is in the development stage. Bug fixes must be carefully considered for all these versions. In a large system, multiple active versions may be released simultaneously, and there are many people involved in bug fixing and software enhancement, which is likely to cause 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: Establish the root directory of the repository. Create a root directory for all repositories on the Ansible version control server. Create multiple sub-repositories within the root directory of the repository. Create a main trunk, branches, tags, and documentation directories within the sub-repositories. The common control files of the version control server are located under the root directory of the repository and are uniformly managed by the company-level configuration library administrator, who also controls the permission settings of the sub-repositories.

[0007] Step 2: Establish the main version control system. The administrator of the Ansible server creates a repository and initializes it. Software development is carried out by programmers. After the software development is completed, a first-level version tag is added, and the file metadata of the software script is classified and stored in the directory of the sub-repository. Then, internal testing is conducted. When the internal testing fails, version rollback is performed based on the first-level version tag, and development is restarted. When the internal testing passes, a second-level version tag is added and the file metadata is classified and stored, after which field testing is conducted. When the field testing passes, a third-level version tag is added and the file metadata is classified and stored, after which the version is released and put online. When the field testing fails, version rollback is performed based on the second-level version tag, and modifications are made. The modified content is merged with the file metadata of the second-level version.

[0008] Step 3: Establish the branch version control system. The administrator of the Ansible server creates a branch repository based on the third-level version. Programmers carry out branch version development. After the branch version development is completed, a sub-first-level version tag is added to the branch version and the file metadata is classified and stored. Then, the branch version is merged with the third-level version, and a sub-second-level version tag is added and the file metadata is classified and stored. Then, internal testing is conducted. When the internal testing fails, version rollback is performed based on the sub-second-level version tag, and development is restarted. When the internal testing passes, a sub-third-level version tag is added and the file metadata is classified and stored, after which field testing is conducted. When the field testing passes, a sub-fourth-level version tag is added and the file metadata is classified and stored, after which the version is released and put online. When the field testing fails, version rollback is performed based on the sub-third-level version tag, and modifications are made. The modified content is merged with the file metadata of the sub-third-level version.

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

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

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

[0012] Preferably, the marked directory is used to store program versions in different marked states, and the document directory is used to store document materials related to the entire project. The document materials include requirement documents, design documents, test documents, database creation script files, development plans, weekly reports, and meeting minutes of software development.

[0013] Preferably, the file metadata refers to the data used to describe various attribute information of the file, which is data about data, used to describe the content, structure, background, and its 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 a certain future moment. Through initialization, version management of the 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 as follows: 1. In the present invention, the company-level configuration library administrator uniformly manages the public control files of the version control server and the permissions of the sub-version libraries, so that there is no need to establish or maintain control files inside each version library, thereby improving the system operation efficiency. All configuration items related to the project are incorporated into the version control library for management at the beginning of the project. The status of each stage and each configuration item of the project is clarified through the method of version marking and classified storage of file metadata, ensuring the orderliness and rollback ability of the versions.

[0016] 2. In the present invention, by comparing and detecting the code in all versions and marking the found duplicate code content, when a certain duplicate code content is modified, the other same codes can be updated synchronously. The programmer 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 existing in all versions, thereby reducing the time cost and labor cost required for version repair. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] In the accompanying drawings:

[0019] Figure 1 It 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 It is a framework diagram of step one in the method for Ansible script version control and rollback based on file metadata of the present invention;

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

[0022] Figure 4 It 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 implementation manners

[0023] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a 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 those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0024] Please refer to Figures 1 - 4 , a method for Ansible script version control and rollback based on file metadata of the present invention includes the following steps:

[0025] Step one: Establish a root directory for the repository. Create a root directory for all repositories on the Ansible version control server. Create multiple sub-repositories within the root directory for the repository. Create a main trunk, branches, tags, and documentation directories within the sub-repositories. The common control files of the version control server are located under the root directory for the repository and are uniformly managed by the company-level configuration library administrator, and at the same time, the permission settings of the sub-repositories are controlled;

[0026] Step 2: Establish the main version control system. The administrator of the Ansible server creates a repository and initializes it. Programmers carry out software development. After the software development is completed, a first-level version tag is applied, and the file metadata of the software script is classified and stored in the directory of the sub-repository. Then, internal testing is conducted. When the internal testing fails, version rollback is performed according to the first-level version tag, and development is restarted. When the internal testing passes, a second-level version tag is applied and the file metadata is classified and stored. Then, on-site testing is carried out. When the on-site testing passes, a third-level version tag is applied and the file metadata is classified and stored. Then, the version is released and put online. When the on-site testing fails, version rollback is performed according to the second-level version tag, and modifications are made. The modified content is merged with the file metadata of the second-level version.

[0027] Step 3: Establish the branch version control system. The administrator of the Ansible server creates a branch repository based on the third-level version. Programmers carry out branch version development. After the branch version development is completed, a sub-first-level version tag is applied to the branch version and the file metadata is classified and stored. Then, the branch version is merged with the third-level version, and a sub-second-level version tag is applied and the file metadata is classified and stored. Then, internal testing is conducted. When the internal testing fails, version rollback is performed according to the sub-second-level version tag, and development is restarted. When the internal testing passes, a sub-third-level version tag is applied and the file metadata is classified and stored. Then, on-site testing is carried out. When the on-site testing passes, a sub-fourth-level version tag is applied and the file metadata is classified and stored. Then, the version is released and put online. When the on-site testing fails, version rollback is performed according to the sub-third-level version tag, and modifications are made. The modified content is merged with the file metadata of the sub-third-level version.

[0028] Step 4: Establish a quick modification system. The Ansible server compares and detects the script code content and corresponding file metadata of each version stored in Step 2 and Step 3, searches for duplicate code content, and marks it. When a piece of duplicate code content is modified, the other identical codes can be updated synchronously. Programmers can unmark one or more marked codes to cancel the synchronous content update for that code content.

[0029] Among them, the main directory is used to store the program files of the main trunk, including the daily development activities and management materials of the software. The daily development activities include coding, testing, and documentation writing. The branch directory is used to store the branch versions of software development. The branch versions can be developed and tested independently without affecting the progress of the main development line. The tag directory is used to store the program versions in different tag states. The document directory is used to store the document materials related to the entire project. The document materials include the requirement documents, design documents, test documents, database creation script files, development plans, weekly reports, and meeting minutes of software development. File metadata refers to the 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 data, and provides detailed information about the files. 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 a certain time in the future. Through initialization, version management of the files in the project can be started to ensure the security and traceability of the code.

[0030] Embodiment 1

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

[0032] Step 1: Establish the root directory of the version library. Create a root directory for all version libraries on the Ansible version control server. Create multiple sub-version libraries within the root directory of the version library. Create main trunk, branch, tag, and document directories within the sub-version libraries. The common control files of the version control server are located under the root directory of the version library and are uniformly managed by the company-level configuration library administrator, and at the same time, the permission settings of the sub-version libraries are controlled;

[0033] Step 2: Establish the main version control system. The administrator of the Ansible server creates a version library and initializes the version library. The programming personnel carry out software development. After the software development is completed, a first-level version tag is made, and the file metadata of the software script is classified and stored in the directory of the sub-version library. Then, internal testing is carried out. When the internal testing fails, version rollback is performed according to the first-level version tag, and re-development is carried out. When the internal testing passes, after making a second-level version tag and classifying and storing the file metadata, on-site testing is carried out. When the on-site testing passes, after making a third-level version tag and classifying and storing the file metadata, the version is released online. When the on-site testing fails, version rollback is performed according to the second-level version tag, and modifications are made. The modified content is merged with the file metadata of the second-level version.

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

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

[0036] Embodiment 2

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

[0038] Step 1: Establish the root directory of the version library. A root directory for all version libraries is established on the Ansible version control server. Multiple sub-version libraries are established within the root directory of the version library. The main trunk, branches, tags, and documentation directories are established within the sub-version libraries. The public control files of the version control server are located under the root directory of the version library and are uniformly managed by the company-level configuration library administrator, and the permission settings of the sub-version libraries are controlled simultaneously;

[0039] Step 2: Establish the main version control system. The administrator of the Ansible server creates a new version library and initializes it. Programmers carry out software development. After the software development is completed, a first-level version mark is made, and the file metadata of the software script is classified and stored in the directory of the sub-version library. Then, internal testing is carried out. When the internal testing fails, version rollback is performed according to the first-level version mark and re-development is carried out. When the internal testing passes, after making a second-level version mark and classifying and storing the file metadata, on-site testing is carried out. When the on-site testing passes, after making a third-level version mark and classifying and storing the file metadata, the version is released and put online. When the on-site testing fails, version rollback is performed according to the second-level version mark, and modifications are made. The modified content is 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 creates a branch version repository based on the tertiary version. Since programmers develop branch versions, after the branch version development is completed, a sub-primary version tag and file metadata classification storage are performed on the branch version. Then, the branch version is merged with the tertiary version, and a sub-secondary version tag and file metadata classification storage are performed. Then, internal testing is carried out. When the internal testing fails, version rollback is performed according to the sub-secondary version tag and re-development is carried out. When the internal testing passes, after a sub-tertiary version tag and file metadata classification storage are performed, on-site testing is carried out. When the on-site testing passes, after a sub-quaternary version tag and file metadata classification storage are performed, the version is released and put online. When the on-site testing fails, version rollback is performed according to the sub-tertiary version tag and modifications are made, and the modified content is merged with the file metadata of the sub-tertiary version.

[0041] Step 4: Establish a quick modification system. The Ansible server compares and detects the script code content and corresponding file metadata of each version stored in Steps 2 and 3 to find duplicate code content and mark it. When a certain duplicate 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 for that code content.

[0042] Through the above method, by comparing and detecting the codes in all versions and marking the found duplicate code content, when a certain duplicate 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 for that code content, so as to quickly solve the same problems existing in all versions, thereby reducing the time cost and labor cost required for version repair.

[0043] It should be noted that in this article, relational terms such as first and second are only used 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 term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device.

[0044] Although embodiments of the present invention have been shown and described, those of ordinary skill in the art will appreciate that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present 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 in that: It includes the following steps: Step 1: Establish the root directory of the repository. Create a root directory for all repositories on the Ansible version control server. Create multiple sub-repositories within the root directory of the repository. Create a main trunk, branches, tags, and documentation directories within the sub-repositories. The common control files of the version control server are located under the root directory of the repository and are uniformly managed by the company-level configuration library administrator, and at the same time, the permission settings of the sub-repositories are controlled; Step 2: Establish the main version control system. The administrator of the Ansible server creates a new repository and initializes the repository. Software development is carried out by programmers. After the software development is completed, a first-level version tag is made, and the file metadata of the software script is classified and stored in the directory of the sub-repository. Then, internal testing is carried out. When the internal testing fails, version rollback is performed according to the first-level version tag, and development is restarted. When the internal testing passes, after making a second-level version tag and classifying and storing the file metadata, field testing is carried out. When the field testing passes, after making a third-level version tag and classifying and storing the file metadata, the version is released and put online. When the field testing fails, version rollback is performed according to the second-level version tag, and modifications are made. The modified content is merged with the file metadata of the second-level version; Step 3: Establish the branch version control system. The administrator of the Ansible server creates a branch repository based on the third-level version. Programmers carry out branch version development. After the branch version development is completed, a sub-first-level version tag and file metadata classification are made for the branch version. Then, the branch version is merged with the third-level version, and a sub-second-level version tag and file metadata classification are made. Then, internal testing is carried out. When the internal testing fails, version rollback is performed according to the sub-second-level version tag, and development is restarted. When the internal testing passes, after making a sub-third-level version tag and classifying and storing the file metadata, field testing is carried out. When the field testing passes, after making a sub-fourth-level version tag and classifying and storing the file metadata, the version is released and put online. When the field testing fails, version rollback is performed according to the sub-third-level version tag, and modifications are made. The modified content is merged with the file metadata of the sub-third-level version. Step 4: Establish a quick modification system. The Ansible server compares and detects the script code content and corresponding file metadata of each version stored in Steps 2 and 3 to find duplicate code content and mark it. When a certain duplicate code content is modified, the same code in other places 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, wherein: The main trunk directory is used to store the program files of the main trunk, including the daily development activities and management materials of the software. The daily development activities include coding, testing, and documentation writing.

3. A 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 the branch versions of software development. The branch versions can be developed and tested independently without affecting the progress of the main development line.

4. A method for Ansible script version control and rollback based on file metadata according to claim 2, characterized in that: The said tag directory is used to store program versions in different tag states, and the said document directory is used to store document materials related to the entire project. The said document materials include requirement documents, design documents, test documents, database creation script files, development plans, weekly reports, and meeting minutes for software development.

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

6. A method for Ansible script version control and rollback based on file metadata according to claim 1, characterized in that: The said version library initialization refers to the process of creating and setting the initial state of a local version library. In the initialized version library, modifications and deletions of each file can be tracked so that the history can be traced at any time or restored at a certain future moment. Through initialization, version management of the files in the project can be started to ensure the security and traceability of the code.

Images