CN116931963A - Method for rollback release and deployment of server multi-component software - Google Patents
Method for rollback release and deployment of server multi-component software Download PDFInfo
- Publication number
- CN116931963A CN116931963A CN202310965636.9A CN202310965636A CN116931963A CN 116931963 A CN116931963 A CN 116931963A CN 202310965636 A CN202310965636 A CN 202310965636A CN 116931963 A CN116931963 A CN 116931963A
- Authority
- CN
- China
- Prior art keywords
- deployed
- soft component
- deployment
- soft
- component
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 32
- 230000001360 synchronised effect Effects 0.000 claims description 3
- 238000011084 recovery Methods 0.000 abstract description 3
- 238000010586 diagram Methods 0.000 description 6
- 238000004422 calculation algorithm Methods 0.000 description 4
- 238000004883 computer application Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/142—Reconfiguring to eliminate the error
- G06F11/143—Reconfiguring to eliminate the error with loss of software functionality
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a server-side multi-component software rollback release deployment method, which specifically comprises the following steps: forming a soft component to be deployed and a version information table, called DEPLOY LIST for short, by filling information and uploading files by a user; generating an automatic script, namely PLAYBOOK, starting an active to execute PLAYBOOK, and deploying a soft component file to a target server; after deployment is completed, the deployed soft component is restored to a certain historical version through a quick rollback mechanism during the running period of the deployed soft component on the target server; after deployment is completed, the deployed soft component is retrieved and aligned during operation on the target server. The deployment method provided by the invention can be suitable for high-reliability and multi-component complex system software release deployment application scenes, does not need to install proxy software on a managed server, and can automatically complete frequent software copying, version comparison query and fault recovery.
Description
Technical Field
The invention belongs to the technical field of computer application control, and particularly relates to a server-side multi-component software rollback release deployment method.
Background
The conventional is an open source automatic operation and maintenance tool, and the managed machine is remotely operated through an SSH protocol to provide more than 1000 function modules such as file copy, software package installation, file search, system configuration and the like. An automation script (hereinafter referred to as "play") is created by a user, and an executable script calls a specific module to perform file copying, searching and peer-to-peer operations.
MD5 (Message-Digest algorism 5) is a widely used information Digest (hash) Algorithm for computers. A unique MD5 code value is obtained from a file by this algorithm. The MD5 code is used to identify the version of the file (software) as a "digital fingerprint" of the file, typically for software version verification. The Jinja is a quick, easy-to-understand and expandable template engine, codes similar to Python grammar are written by adopting special placeholders, namely, the Jinja template is compiled by the Jinja engine, data and the template are collected, and a final document is generated.
Server software product release deployment refers to: a process of installing/deploying "B/S", "C/S" architecture Server ("S": server) side soft components to specific locations. For complex business system software, it is typically composed of a large number of software components. The one-time release deployment process typically requires that files to be updated (executable programs, dynamic link libraries, etc.) be deployed to different locations. The process has the following two characteristics: 1) The reliability requirement is high: individual file deployment errors or version confusion can cause interruption of a business process, and serious loss is caused; 2) Non-graphical man-machine interaction environment: the server version operating system often does not run graphic interface applications such as KDE, GNOME, etc., and the software is usually run in a background process (Daemon) manner.
Disclosure of Invention
The invention aims to provide a server-side multi-component software rollback release deployment method, which realizes rapid release and deployment of soft components of a complex service system and version rollback and automatic detection.
The technical scheme adopted by the invention is that the server-side multi-component software rollback release deployment method is implemented according to the following steps:
step 1, forming a soft component to be deployed and a version information table, called DEPLOY LIST for short, by filling information and uploading files by a user;
step 2, generating an automatic script, namely PLAYBOOK, starting an active to execute PLAYBOOK, and deploying a soft component file to a target server;
step 3, after deployment, restoring the deployed soft component to a certain historical version through a quick rollback mechanism during the operation of the deployed soft component on the target server;
and 4, searching and comparing the deployed soft components during the operation of the deployed soft components on the target server after the deployment is completed.
The present invention is also characterized in that,
in step 1, specifically:
step 1.1, obtaining a logic composition structure of a soft component to be deployed by filling information by a user, establishing a data structure of a subsystem-configuration item-soft component, and storing the data structure in a database table form;
and 1.2, uploading files by a user to obtain a physical entity file set of the soft component to be deployed, and calculating MD5 codes of the files to be used as version information. And (3) adding version information on the basis of the subsystem-configuration item-soft component structure of the step 1.1, so as to form a DEPLOY LIST.
In step 1.1, the subsystem-configuration item-soft component is specifically designed as follows: the structure is described through a database table, the name of the soft component is taken as a primary key, the name of the subsystem to which the soft component belongs and the name of the configuration item are taken as attributes, namely, each soft component is in a row, and the name of the soft component, the subsystem to which the soft component belongs and the information of the configuration item to which the soft component belongs are recorded.
In step 2, specifically:
step 2.1, writing a Jinja template according to an format supported by an active, wherein the template does not relate to specific soft component information to be deployed, and fields of a file name and a deployment position are replaced by special placeholders;
the template provides two deployment modes: one is a synchronous mode, the 'stable.pos.synchonize' module is appointed to be used, and the whole folder on the target server is replaced by the folder to be deployed; the other mode is a copying mode, namely an allowable.copy module is appointed to be used, files to be deployed are copied to a target server, and if the files with the same names exist, the files are replaced;
step 2.2, selecting a soft component to be deployed according to the requirement of a deployment task to obtain a soft component name LIST to be deployed, combining the LIST with a DEPLOY LIST, and extracting each piece of soft component information from the DEPLOY LIST to obtain a soft component information set to be deployed in the deployment task, which is simply called as TASKITEM;
step 2.3, selecting the deployment mode of each soft component according to the requirement in the two deployment modes in step 2.1, and recording the deployment modes in a TASKITEM;
step 2.4, combining the TASKITEM with the Jinja template in the step 2.1, and replacing a special placeholder in Jinja by using soft component information in the TASKITEM to obtain PLAYBOOK deployed for a certain time;
and 2.5, operating the active read and executing PLAYBOOK, and deploying each soft component to be deployed to the appointed position of each target server.
In step 4, specifically:
step 4.1, reading TASKITEM, and obtaining soft component information of deployed software, wherein the soft component information comprises names, MD5 codes and deployment positions;
and 4.2, according to the information of the soft components to be deployed, searching the soft components which are actually deployed on the target server item by item, confirming whether the soft components are correctly deployed, and reminding a user if the version error condition occurs.
In step 4.2, if the deployed soft component is not in the TASKITEM, the soft component redundant deployment is proved; if the deployed soft component is in the TASKITEM, but the MD5 codes are inconsistent in comparison, proving that the deployed version is wrong; if the deployed soft component is in TASKITEM and the MD5 codes are consistent in comparison, the soft component is proved to be deployed correctly; if the file expected to be deployed in the TASKITEM is not on the server, the soft component is proved to be omitted from deployment.
The server-side multi-component software rollback release deployment method has the advantages that the method is applicable to high-reliability multi-component complex system software release deployment application scenes, proxy software is not required to be installed on a managed server, and frequent software copying, version comparison query and fault recovery can be automatically completed.
Drawings
FIG. 1 is a diagram showing the structure of a part and version information table according to the present invention
FIG. 2 is a schematic diagram of the generation of PLAYBOOK from DEPLOY LIST according to the present invention
FIG. 3 is a schematic diagram of a rollback algorithm data record of the present invention.
Detailed Description
The invention will be described in detail below with reference to the drawings and the detailed description.
Example 1
The invention provides a server-side multi-component software rollback release deployment method, which is implemented according to the following steps:
step 1, forming a soft component to be deployed and a version information table, called DEPLOY LIST for short, by filling information and uploading files by a user; the method comprises the following steps:
step 1.1, obtaining a logic composition structure of a soft component to be deployed by filling information by a user, establishing a data structure of a subsystem-configuration item-soft component, and storing the data structure in a database table form;
complex business system software is typically composed of multiple subsystems, which are composed of multiple configuration items, which in turn contain multiple soft components. "subsystem-configuration item-soft component" describes a complex business system software hierarchy. The "subsystem-configuration item-soft component" is specifically designed to: the structure is described by a database table, the name of the soft component is taken as a main key, and the name of the subsystem and the name of the configuration item which the soft component belongs to are taken as the attributes of the soft component. Namely, each soft component is a row, and the information such as the name of the soft component, the subsystem to which the soft component belongs, the configuration item to which the soft component belongs and the like is recorded;
step 1.2, uploading files by a user to obtain a physical entity file set of the soft component to be deployed, wherein the physical entity file set comprises a plurality of executable programs, dynamic link libraries and other files, and MD5 codes of the files are calculated and used as version information. Adding version information on the basis of the subsystem-configuration item-soft component structure of the step 1.1, so as to form a DEPLOY LIST;
the "part and version information table" is specifically designed as follows: and (3) taking the MD5 code value of each file as a main key, taking information such as deployment position, deployment mode and the like as attributes, and associating with a subsystem-configuration item-soft component table in an external key association mode. One MD5 code value corresponds to one soft component information, because there may be multiple versions of one soft component, there may be multiple MD5 codes corresponding to the same soft component information;
step 2, generating an automatic script, namely PLAYBOOK, starting an active to execute PLAYBOOK, and deploying a soft component file to a target server; the method comprises the following steps:
step 2.1, writing a Jinja template according to an format supported by an active, wherein the template does not relate to specific soft component information to be deployed, and fields of a file name and a deployment position are replaced by special placeholders;
the template provides two deployment modes: one is a synchronous mode, the 'stable.pos.synchonize' module is appointed to be used, and the whole folder on the target server is replaced by the folder to be deployed; the other mode is a copying mode, namely an allowable.copy module is appointed to be used, files to be deployed are copied to a target server, and if the files with the same names exist, the files are replaced;
and 2.2, selecting the soft components to be deployed according to the requirements of the deployment task, and obtaining a name list of the soft components to be deployed. Combining the LIST with the DEPLOY LIST, and extracting each piece of soft component information (comprising a soft component name, a storage position and a to-be-deployed position) from the DEPLOY LIST to obtain a soft component information set of software to be deployed in the deployment task, which is simply called as TASKITEM;
step 2.3, selecting the deployment mode of each soft component according to the requirement in the two deployment modes in step 2.1, and recording the deployment modes in a TASKITEM;
step 2.4, combining the TASKITEM with the Jinja template in the step 2.1, and replacing a special placeholder in Jinja by using soft component information in the TASKITEM to obtain PLAYBOOK deployed for a certain time;
step 2.5, operating an active read and executing PLAYBOOK, and deploying each soft component to be deployed to a designated position of each target server;
step 3, after deployment is completed, during the operation of the deployed soft component on the target server, restoring to a certain historical version through a quick rollback mechanism, searching TASKITEM through information such as deployment time when rollback is needed, finding out each soft component version deployed for a certain time, namely recording in the DEPLOY LIST, and repeatedly executing the step 2 to perform deployment to realize quick restoration;
step 4, searching and comparing the deployed soft components when the deployed soft components run on the target server after the deployment is completed, and timely finding version error conditions caused by error copying, misoperation and other reasons;
example 2
Unlike example 1, in step 4, specifically:
step 4.1, reading TASKITEM, and obtaining deployment soft component information, wherein the deployment soft component information comprises a name, an MD5 code and a deployment position;
step 4.2, according to the information of the soft components to be deployed, searching the soft components which are actually deployed on the target server item by item, confirming whether each soft component is correctly deployed, and reminding a user if a version error condition occurs;
if the deployed soft component is not in the TASKITEM, the soft component redundant deployment is proved;
if the deployed soft component is in the TASKITEM, but the MD5 codes are inconsistent in comparison, proving that the deployed version is wrong;
if the deployed soft component is in TASKITEM and the MD5 codes are consistent in comparison, the soft component is proved to be deployed correctly;
if the file expected to be deployed in the TASKITEM is not on the server, the soft component is proved to be omitted from deployment.
Fig. 1 is a schematic structural diagram of a configuration LIST of the present invention, and as shown in fig. 1, a software product has a structure of "product-subsystem-configuration item-soft component", wherein soft component information includes: name, function, category, type, etc. The version information includes: MD5 code, development time, developer, version description, deployment location, etc. There may be multiple versions of a soft component, each version corresponding to an executable program file or a dynamically linked library file, a single file being the basic unit of product release deployment.
Soft component information is entered by an operator, including the subsystem to which it belongs, configuration items, soft component names, developers, etc. The soft part version file can be obtained by uploading the file or extracting the code warehouse and the like. And calculating MD5 codes, defining the deployment position, and recording the information into the DEPLOY LIST as a record.
Fig. 2 is a schematic structural diagram of play of the present invention, where Jinja templates are written in format supported by an active, and are an abstract summary of a deployment flow. The method comprises two deployment methods: and firstly, the original folder is deleted, and the soft components to be deployed are integrally upgraded. The method can prevent residual redundancy during redeployment; and secondly, overlaying Copy (Copy), copying if the files with the same names are not available, and overlaying, namely deleting the original files and copying and updating if the files with the same names are available. The method realizes accurate updating and has smaller influence domain. The method can be selected by an operator according to deployment requirements, and different deployment strategies can be adopted according to the characteristics of soft components at different deployment positions.
The Jinja template does not relate to specific file content to be deployed, wherein fields such as file name, deployment position and the like are replaced by special placeholders. When the PLAYBOOK is generated, TASKITEM is taken as input, and the soft component version data (soft component and version information) is compiled by combining with the Jinja template, so that the PLAYBOOK deployed at a certain time is obtained. And reading and executing PLAYBOOK by the active, and deploying each soft component file to a designated position of each target server according to a designated deployment method to complete the release deployment process.
Example 3
FIG. 3 shows a schematic diagram of the rollback algorithm data record of the present invention. The recording information includes: "task", "deployment object" and "software component" are in a "one-to-many" relationship with each other, i.e. a "task" comprises a plurality of "deployments", and a "deployment" comprises a plurality of "deployment objects", which are specifically software components. By the above data relation combination, it is equivalent to marking different "tags" (deployment information) in the plan LIST (shown in the lower left corner of fig. 3). And associating the task-task deployment-deployment details.
The user can retrieve the soft component set of each deployment through the tag. When rollback is needed, the software component set is searched out by taking deployment time or other deployment information as an index, and deployment is carried out once, so that state rollback to a specific version is realized.
The method can effectively implement the release and deployment process of the server-side multi-component software system, can reduce 95% of manual copying and comparison checking work, can complete the release and deployment work of a complex system consisting of thousands of software components within a few minutes, automatically complete the comparison checking to ensure the stable operation of the server for 7X 24 hours, and improve the system fault recovery time to the order of minutes from the day.
Claims (6)
1. The server-side multi-component software rollback release deployment method is characterized by comprising the following steps of:
step 1, forming a soft component to be deployed and a version information table, called DEPLOY LIST for short, by filling information and uploading files by a user;
step 2, generating an automatic script, namely PLAYBOOK, starting an active to execute PLAYBOOK, and deploying a soft component file to a target server;
step 3, after deployment, restoring the deployed soft component to a certain historical version through a quick rollback mechanism during the operation of the deployed soft component on the target server;
and 4, searching and comparing the deployed soft components during the operation of the deployed soft components on the target server after the deployment is completed.
2. The server-side multi-component software rollback release deployment method according to claim 1, wherein in step 1, specifically:
step 1.1, obtaining a logic composition structure of a soft component to be deployed by filling information by a user, establishing a data structure of a subsystem-configuration item-soft component, and storing the data structure in a database table form;
step 1.2, uploading files by a user to obtain a physical entity file set of the soft component to be deployed, calculating MD5 codes of the files, and adding version information on the basis of the subsystem-configuration item-soft component structure of step 1.1 to form a DEPLOY LIST.
3. The server-side multi-component software rollback release deployment method according to claim 2, wherein in step 1.1, the subsystem-configuration item-soft component is specifically designed to: the structure is described through a database table, the name of the soft component is taken as a primary key, the name of the subsystem to which the soft component belongs and the name of the configuration item are taken as attributes, namely, each soft component is in a row, and the name of the soft component, the subsystem to which the soft component belongs and the information of the configuration item to which the soft component belongs are recorded.
4. The server-side multi-component software rollback release deployment method according to claim 2, wherein in step 2, specifically:
step 2.1, writing a Jinja template according to an format supported by an active, wherein the template does not relate to specific soft component information to be deployed, and fields of a file name and a deployment position are replaced by special placeholders;
the template provides two deployment modes: one is a synchronous mode, the 'stable.pos.synchonize' module is appointed to be used, and the whole folder on the target server is replaced by the folder to be deployed; the other mode is a copying mode, namely an allowable.copy module is appointed to be used, files to be deployed are copied to a target server, and if the files with the same names exist, the files are replaced;
step 2.2, selecting a soft component to be deployed according to the requirement of a deployment task to obtain a soft component name LIST to be deployed, combining the LIST with a DEPLOY LIST, and extracting each piece of soft component information from the DEPLOY LIST to obtain a soft component information set to be deployed in the deployment task, which is simply called as TASKITEM;
step 2.3, selecting the deployment mode of each soft component according to the requirement in the two deployment modes in step 2.1, and recording the deployment modes in a TASKITEM;
step 2.4, combining the TASKITEM with the Jinja template in the step 2.1, and replacing a special placeholder in Jinja by using soft component information in the TASKITEM to obtain PLAYBOOK deployed for a certain time;
and 2.5, operating the active read and executing PLAYBOOK, and deploying each soft component to be deployed to the appointed position of each target server.
5. The server-side multi-component software rollback release deployment method according to claim 4, wherein in step 4, specifically:
step 4.1, reading TASKITEM, and obtaining soft component information of deployed software, wherein the soft component information comprises names, MD5 codes and deployment positions;
and 4.2, according to the information of the soft components to be deployed, searching the soft components which are actually deployed on the target server item by item, confirming whether the soft components are correctly deployed, and reminding a user if the version error condition occurs.
6. The method for rollback release deployment of server-side multi-component software according to claim 5, wherein in step 4.2, if the deployed soft component is not in the TASKITEM, the soft component redundancy deployment is proved; if the deployed soft component is in the TASKITEM, but the MD5 codes are inconsistent in comparison, proving that the deployed version is wrong; if the deployed soft component is in TASKITEM and the MD5 codes are consistent in comparison, the soft component is proved to be deployed correctly; if the file expected to be deployed in the TASKITEM is not on the server, the soft component is proved to be omitted from deployment.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310965636.9A CN116931963A (en) | 2023-08-02 | 2023-08-02 | Method for rollback release and deployment of server multi-component software |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310965636.9A CN116931963A (en) | 2023-08-02 | 2023-08-02 | Method for rollback release and deployment of server multi-component software |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116931963A true CN116931963A (en) | 2023-10-24 |
Family
ID=88377114
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310965636.9A Pending CN116931963A (en) | 2023-08-02 | 2023-08-02 | Method for rollback release and deployment of server multi-component software |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116931963A (en) |
-
2023
- 2023-08-02 CN CN202310965636.9A patent/CN116931963A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7739547B2 (en) | Failure recovery and error correction techniques for data loading in information warehouses | |
| KR100655124B1 (en) | Software installation and testing system for a built-to-order computer system | |
| KR100394195B1 (en) | Software Installation and Testing for a Build-To-Order Computer System | |
| EP2194467A1 (en) | Extend CRUD to support lifecycle management and business continuity | |
| JP6238983B2 (en) | Browsing open file history | |
| CN111142899B (en) | Database script execution method and device, storage medium and electronic equipment | |
| CN102567140A (en) | Bile system backup using change journal | |
| CN115039084A (en) | Unit testing of components of a dataflow graph | |
| CN111694612A (en) | Configuration checking method, device, computer system and storage medium | |
| US11537570B2 (en) | Systems and/or methods for migrating live database schemas to support zero downtime deployments with zero data losses | |
| CN112100194A (en) | Database version management method and system | |
| JPH11134235A (en) | Method for supporting recovery from fault of external storage device | |
| CN102193841B (en) | Backup method and device of Subversion configuration database | |
| CN110825546A (en) | Recovery method, system and equipment terminal for high-availability database cluster | |
| US11099837B2 (en) | Providing build avoidance without requiring local source code | |
| JP2011013792A (en) | Device, method and program for control of database in program model inspection | |
| US9665367B2 (en) | Uniform references | |
| CN116931963A (en) | Method for rollback release and deployment of server multi-component software | |
| US20190065168A1 (en) | Apparatus and method to shorten software installation time based on a history of file installation | |
| CN114490570A (en) | Production data synchronization method and device, data synchronization system and server | |
| CN112241370A (en) | Verification method, system and device for API (application program interface) interface class | |
| CN117573564B (en) | Method for automatically identifying differences based on gitlab code submitted log | |
| CN116700763B (en) | Version upgrading method and device for Clickhouse database | |
| CN113296816B (en) | Method for improving reliability and performance of SVN storage | |
| JPH1091405A (en) | Software maintenance method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |