Methods, apparatus, and electronic devices for generating deployment documents

Abstract

This invention discloses a method, apparatus, and electronic device for generating deployment documents, relating to the fintech field or other related fields. The method includes: receiving a middleware deployment request; querying a preset service address table based on a middleware identifier to obtain a target service address table; deploying the middleware indicated by the middleware identifier on each server using a preset deployment script based on deployment parameters; converting the deployment commands in the preset deployment script during middleware deployment into preset commands to obtain a preset command set; and generating a deployment document based on the preset command set and command comments corresponding to each preset command in the preset command set. This invention solves the technical problem in related technologies where manual maintenance of deployment documents easily leads to a decrease in the accuracy of the deployment documents.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and more specifically, to a method, apparatus, and electronic device for generating deployment documents. Background Technology

[0002] In related technologies, middleware deployment documentation often requires manual writing and revision using files (such as Word documents), with the revision time and content recorded at the beginning of each file. However, manually maintaining deployment documentation can easily lead to missed modifications, and manual backups are required before each change, potentially reducing the accuracy of the deployment documentation.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a method, apparatus, and electronic device for generating deployment documents, to at least solve the technical problem in related technologies where manual maintenance of deployment documents easily leads to a decrease in the accuracy of deployment documents.

[0005] According to one aspect of the present invention, a method for generating a deployment document is provided, comprising: receiving a middleware deployment request, wherein the middleware deployment request includes at least: a middleware identifier and deployment parameters; querying a preset service address table based on the middleware identifier to obtain a target service address table, wherein each service address in the target service address table corresponds to a server; deploying the middleware indicated by the middleware identifier on each of the servers using a preset deployment script based on the deployment parameters; converting the deployment commands in the preset deployment script when deploying the middleware into preset commands to obtain a preset command set, and generating a deployment document based on the preset command set and command comments corresponding to each preset command in the preset command set.

[0006] Optionally, before receiving a middleware deployment request, the method further includes: creating a corresponding inspection script, deployment script, and uninstallation script for each middleware based on a preset script format, wherein the inspection script is used to check the deployment status of the middleware, the deployment script is used to deploy the middleware, and the uninstallation script is used to uninstall the middleware; and recording each middleware and the corresponding inspection script, deployment script, and uninstallation script in a preset routing table.

[0007] Optionally, the step of querying a preset service address table based on the middleware identifier to obtain a target service address table includes: querying the preset service address table to obtain a query result, wherein the query result records the deployment status of the middleware deployed on each of the servers; filtering the servers in the query result whose deployment status is not deployed to obtain a target server set; and generating the target service address table based on the target server set.

[0008] Optionally, before deploying the middleware indicated by the middleware identifier on each of the servers using a preset deployment script based on the deployment parameters, the method further includes: responding to the middleware deployment request and generating a target task, wherein the target task is used to deploy the middleware indicated by the middleware identifier to each of the servers indicated by the service address; adding the target task to a task table and displaying the task information associated with the target task in the task table on the front-end page, wherein the task information includes: task number, task type, applicant, task progress, task log, execution details, and number of service addresses.

[0009] Optionally, after generating the target task in response to the middleware deployment request, the method further includes: invoking the inspection script corresponding to the target task; using the inspection script to sequentially check whether the middleware has been deployed on the server indicated by each service address in the target task, obtaining multiple inspection results, wherein the inspection results include at least: task number, service address, and inspection status; when the inspection results are converted into first interface parameters and the first interface parameters are passed to a first preset backend interface, the first interface parameters are inserted into a preset installation status table, and a task record corresponding to the task number is created; querying the preset installation status table, and when the number of task records associated with the task number is equal to the number of service addresses, and the inspection status indicated by each task record is "check passed", the deployment script corresponding to the target task is invoked.

[0010] Optionally, after invoking the deployment script corresponding to the target task, the method further includes: using the deployment script to deploy the middleware sequentially for each server indicated by each service address in the target task, obtaining multiple deployment results, wherein the deployment results include at least: task number, service address, and installation status; when the deployment results are converted into second interface parameters and the second interface parameters are passed to a second preset backend interface, the installation status field of the task record associated with the task number in the preset installation status table is updated based on the second interface parameters; if none of the installation status fields are empty, it is determined that each server indicated by each service address in the target task has been deployed successfully; if all installation status fields indicate successful installation, it is determined that each server indicated by each service address in the target task has been deployed successfully.

[0011] Optionally, after generating the deployment document based on the preset command set and the command comments corresponding to each preset command in the preset command set, the method further includes: if the middleware is updated, updating the check script, deployment script, and uninstallation script corresponding to the middleware based on the update parameters of the middleware; determining the updated target deployment command in the check script, deployment script, and uninstallation script; and modifying the preset command corresponding to the target deployment command and the command comments corresponding to the preset command based on the target deployment command to obtain the updated deployment document.

[0012] Optionally, after modifying the preset command corresponding to the target deployment command and the command comments corresponding to the preset command based on the target deployment command to obtain an updated deployment document, the method further includes: extracting the preset command set from the deployment document; executing the preset command set in a preset test environment to deploy the middleware on a preset server to obtain a parameter file set; if the middleware is successfully deployed on the preset server, replacing the service address of the preset server in each parameter file of the parameter file set with the service address in the pre-production environment to obtain a target file set; packaging the target file set after deleting log files to obtain target files, and generating target string values ​​based on the target files; obtaining the standard file set in the pre-production environment and deleting log files in the standard file set to obtain a target standard file set; packaging the target standard file set to obtain standard files, and generating standard string values ​​based on the standard files; if the target string value is consistent with the standard string value, determining that the deployment document has passed verification.

[0013] According to another aspect of the present invention, a deployment document generation apparatus is also provided, comprising: a receiving unit for receiving a middleware deployment request, wherein the middleware deployment request includes at least: a middleware identifier and deployment parameters; a querying unit for querying a preset service address table based on the middleware identifier to obtain a target service address table, wherein each service address in the target service address table corresponds to a server; a deployment unit for deploying the middleware indicated by the middleware identifier on each of the servers based on the deployment parameters and using a preset deployment script; and a generation unit for converting deployment commands in the preset deployment script when deploying the middleware into preset commands to obtain a preset command set, and generating a deployment document based on the preset command set and command comments corresponding to each preset command in the preset command set.

[0014] Optionally, the generation device further includes: a first creation module, configured to create a corresponding inspection script, deployment script, and uninstallation script for each middleware based on a preset script format before receiving a middleware deployment request, wherein the inspection script is used to check the deployment status of the middleware, the deployment script is used to deploy the middleware, and the uninstallation script is used to uninstall the middleware; and a first recording module, configured to record each middleware and the corresponding inspection script, deployment script, and uninstallation script in a preset routing table.

[0015] Optionally, the query unit includes: a first query module, used to query the preset service address table to obtain query results, wherein the query results record the deployment status of the middleware deployed on each of the servers; a first filtering module, used to filter servers in the query results whose deployment status is not deployed, to obtain a target server set; and a first generation module, used to generate the target service address table based on the target server set.

[0016] Optionally, the generation device further includes: a second generation module, configured to respond to the middleware deployment request and generate a target task before deploying the middleware indicated by the middleware identifier on each of the servers based on the deployment parameters and using a preset deployment script, wherein the target task is used to deploy the middleware indicated by the middleware identifier to each of the servers indicated by the service address; and a first display module, configured to add the target task to a task table and display the task information associated with the target task in the task table on a front-end page, wherein the task information includes: task number, task type, applicant, task progress, task log, execution details, and number of service addresses.

[0017] Optionally, the generation device further includes: a first invocation module, configured to, after generating a target task in response to the middleware deployment request, invoke the inspection script corresponding to the target task; a first inspection module, configured to, using the inspection script, sequentially check whether the middleware has been deployed on the server indicated by each service address in the target task, and obtain multiple inspection results, wherein the inspection results include at least: task number, service address, and inspection status; a first insertion module, configured to, when converting the inspection results into first interface parameters and passing the first interface parameters to a first preset backend interface, insert the first interface parameters into a preset installation status table and create a task record corresponding to the task number; and a second invocation module, configured to, query the preset installation status table, and, when the number of task records associated with the task number is equal to the number of service addresses, and the inspection status indicated by each task record is "check passed", invoke the deployment script corresponding to the target task.

[0018] Optionally, the generation device further includes: a first deployment module, configured to, after calling the deployment script corresponding to the target task, use the deployment script to sequentially deploy the middleware to each server indicated by the service address in the target task, obtaining multiple deployment results, wherein the deployment results include at least: task number, service address, and installation status; a first update module, configured to, after converting the deployment results into second interface parameters and passing the second interface parameters to a second preset backend interface, update the installation status field of the task record associated with the task number in the preset installation status table based on the second interface parameters; a first determination module, configured to, if the installation status field is not empty, determine that each server indicated by the service address in the target task has been deployed successfully; and a second determination module, configured to, if the installation status field is all successfully installed, determine that each server indicated by the service address in the target task has been deployed successfully.

[0019] Optionally, the generation device further includes: a second update module, configured to, after generating a deployment document based on the preset command set and the command comments corresponding to each preset command in the preset command set, update the check script, deployment script, and uninstallation script corresponding to the middleware based on the update parameters of the middleware when the middleware is updated; a third determination module, configured to determine the updated target deployment command in the check script, the deployment script, and the uninstallation script; and a first modification module, configured to modify the preset command corresponding to the target deployment command and the command comments corresponding to the preset command based on the target deployment command, to obtain the updated deployment document.

[0020] Optionally, the generation apparatus further includes: a first extraction module, configured to extract the set of preset commands from the deployment document after modifying the preset commands corresponding to the target deployment command and the command comments corresponding to the preset commands based on the target deployment command to obtain an updated deployment document; a first execution module, configured to execute the set of preset commands in a preset test environment to deploy the middleware on a preset server to obtain a set of parameter files; and a first replacement module, configured to replace the service address of the preset server in each parameter file of the parameter file set with the service address of the server in the pre-production environment if the middleware is successfully deployed on the preset server. The service address is used to obtain a set of target files; a first packaging module is used to package the set of target files after deleting log files to obtain target files, and generate target string values ​​based on the target files; a first acquisition module is used to acquire the set of standard files in the pre-production environment, and delete log files in the set of standard files to obtain a set of target standard files; a second packaging module is used to package the set of target standard files to obtain standard files, and generate standard string values ​​based on the standard files; a fourth determination module is used to determine that the deployment document verification is passed if the target string value is consistent with the standard string value.

[0021] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the deployment document generation method described above.

[0022] In this disclosure, a middleware deployment request is received. Based on the middleware identifier, a preset service address table is queried to obtain the target service address table. Based on deployment parameters, a preset deployment script is used to deploy the middleware indicated by the middleware identifier on each server. The deployment commands in the preset deployment script during middleware deployment are converted into preset commands to obtain a set of preset commands. A deployment document is generated based on the set of preset commands and the command comments corresponding to each preset command. In this application, the server where the middleware needs to be deployed can be determined through the middleware identifier carried in the middleware deployment request. Then, the middleware is deployed on each server using a preset deployment script. At the same time, the deployment commands in the preset deployment script during middleware deployment are converted into preset commands, and a deployment document is automatically generated based on the preset commands and the command comments corresponding to the preset commands. By integrating the deployment process and the process of creating the deployment document, no manual maintenance is required, which can improve the accuracy of the deployment document. This solves the technical problem in related technologies where manual maintenance of deployment documents can easily lead to a decrease in the accuracy of the deployment document. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0024] Figure 1 This is a flowchart of an optional method for generating deployment documents according to an embodiment of the present invention;

[0025] Figure 2 This is a schematic diagram of an optional deployment document generation apparatus according to an embodiment of the present invention;

[0026] Figure 3 This is a hardware structure block diagram of an electronic device (or mobile device) for deploying a document generation method according to an embodiment of the present invention. Detailed Implementation

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

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] It should be noted that the deployment document generation method and apparatus in this disclosure can be used in the field of fintech for generating deployment documents, and can also be used in any field other than fintech for generating deployment documents. This disclosure does not limit the application field of the deployment document generation method and apparatus.

[0030] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are information and data authorized by the user or fully authorized by all parties. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving consent information from the aforementioned user or organization.

[0031] The following embodiments of the present invention can be applied to various systems / applications / devices that generate deployment documents. By integrating the deployment process and the process of creating deployment documents, the present invention can also verify the consistency between the automatically generated deployment documents and the deployment results in the production environment, ensuring the accuracy of the deployment documents. Furthermore, it effectively solves the problem of deployment documents becoming inaccurate over time, saves on deployment document maintenance costs, and improves customer satisfaction.

[0032] The present invention will now be described in detail with reference to various embodiments.

[0033] Example 1

[0034] According to an embodiment of the present invention, a method for generating deployment documents is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] Figure 1 This is a flowchart of an optional deployment document generation method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0036] Step S101: Receive middleware deployment request, wherein the middleware deployment request includes at least: middleware identifier and deployment parameters.

[0037] Step S102: Based on the middleware identifier, query the preset service address table to obtain the target service address table, wherein each service address in the target service address table corresponds to a server.

[0038] Step S103: Based on the deployment parameters, deploy the middleware indicated by the middleware identifier on each server using a preset deployment script.

[0039] Step S104: Convert the deployment commands in the preset deployment script when deploying the middleware into preset commands to obtain a preset command set, and generate a deployment document based on the preset command set and the command comments corresponding to each preset command in the preset command set.

[0040] Through the above steps, a middleware deployment request can be received. Based on the middleware identifier, a preset service address table is queried to obtain the target service address table. Based on the deployment parameters, a preset deployment script is used to deploy the middleware indicated by the middleware identifier on each server. The deployment commands in the preset deployment script when deploying the middleware are converted into preset commands to obtain a set of preset commands. Based on the set of preset commands and the command comments corresponding to each preset command, a deployment document is generated. In this embodiment of the invention, the server where the middleware needs to be deployed can be determined through the middleware identifier carried in the middleware deployment request. Then, the middleware is deployed on each server using a preset deployment script. At the same time, the deployment commands in the preset deployment script when deploying the middleware are converted into preset commands. Based on the preset commands and the command comments corresponding to the preset commands, a deployment document is automatically generated. By integrating the deployment process and the process of creating the deployment document, no manual maintenance is required, which can improve the accuracy of the deployment document. This solves the technical problem in related technologies where manual maintenance of deployment documents easily leads to a decrease in the accuracy of the deployment document.

[0041] The embodiments of the present invention will now be described in detail with reference to the steps described above.

[0042] In one embodiment of the present invention, optionally, before receiving a middleware deployment request, the method further includes: creating a corresponding inspection script, deployment script, and uninstallation script for each middleware based on a preset script format, wherein the inspection script is used to check the deployment status of the middleware, the deployment script is used to deploy the middleware, and the uninstallation script is used to uninstall the middleware; and recording each middleware and the corresponding inspection script, deployment script, and uninstallation script in a preset routing table.

[0043] In this embodiment of the invention, a corresponding check script (agent_check), deployment script (agent_install), and uninstallation script (agent_uninstall) can be created for each middleware. These three scripts can follow a preset script format (e.g., the Ansible playbook script editing format). The check script is used to check the deployment status of the corresponding middleware on the server, the deployment script is used to deploy the corresponding middleware on the server, and the uninstallation script is used to uninstall the corresponding middleware on the server. Then, each middleware and its corresponding check script, deployment script, and uninstallation script can be recorded in a preset routing table. In this way, when a middleware is selected for deployment on the front-end page, the system will automatically find the corresponding check script to check the deployment status and the deployment script to perform the deployment.

[0044] Step S101: Receive middleware deployment request, wherein the middleware deployment request includes at least: middleware identifier and deployment parameters.

[0045] In this embodiment of the invention, the front-end page can be developed using a preset language (such as Java). Users can filter the middleware to be deployed on the front-end page. After selecting the middleware, users need to input the corresponding deployment parameters (i.e., some configuration parameters of the middleware, such as installation path, access port, required memory, etc.). Clicking "Deploy" will take you to the task page. The front-end page can generate a middleware deployment request based on the middleware identifier indicated by the selected middleware and the corresponding deployment parameters, and transmit it to the back-end for execution.

[0046] Step S102: Based on the middleware identifier, query the preset service address table to obtain the target service address table, wherein each service address in the target service address table corresponds to a server.

[0047] Optionally, the step of querying a preset service address table based on the middleware identifier to obtain the target service address table includes: querying the preset service address table to obtain query results, wherein the query results record the deployment status of the middleware deployed on each server; filtering the servers in the query results whose deployment status is not deployed to obtain the target server set; and generating the target service address table based on the target server set.

[0048] In this embodiment of the invention, the backend program can access the system ledger, query the preset service address table in the system ledger according to the middleware identifier, and obtain the query results. The query will record which servers have deployed the middleware and which servers have not deployed the middleware (that is, the deployment status of the middleware in each server is recorded in the query results). Then, the servers with the deployment status of "not deployed" in the query results can be filtered to obtain the target server set. Based on the target server set, a target service address table is generated. In this way, the middleware indicated by the middleware identifier can be deployed on the server indicated by each service address in the target service address table.

[0049] In another alternative embodiment, the filtered servers that have not deployed middleware can be returned to the front-end page in a list format, at which point the user can select multiple servers for deployment on the front-end page.

[0050] Optionally, before deploying the middleware indicated by the middleware identifier on each server using a preset deployment script based on deployment parameters, the method further includes: responding to the middleware deployment request and generating a target task, wherein the target task is used to deploy the middleware indicated by the middleware identifier to the server indicated by each service address; adding the target task to a task table and displaying the task information associated with the target task in the task table on the front-end page, wherein the task information includes: task number, task type, applicant, task progress, task log, execution details, and number of service addresses.

[0051] In this embodiment of the invention, the backend program can respond to the middleware deployment request and generate a target task. The target task is used to deploy the middleware indicated by the middleware identifier to the server indicated by each service address. Then, the target task is added to the task table, and the task information associated with the target task in the task table is displayed on the front-end page (that is, when the user clicks to deploy, the backend program will create the task information of the target task, including: task number, task type, applicant, task progress, task log, execution details, number of service addresses, etc. These tasks are all executed in the background. After the user clicks to deploy, he will be redirected to the task page to display the task information of each task in the task table).

[0052] Table 1 shows the task information of a certain task in an optional task table in this embodiment, as shown in Table 1:

[0053] Table 1

[0054]

[0055] In this embodiment of the invention, task information includes task type, task status (i.e., task progress, execution details, etc.), and execution details may include check time and installation time. The latest task progress (i.e., the current task status) can be queried via the refresh button next to the task progress displayed on the task page. During the check process, the task progress can be marked as "Checking," and the check result is either "Check passed" or "Check failed." During the deployment process, the task progress can be marked as "Deploying," and the deployment result is either "Deployment failed" or "Deployment completed." The task logs in this embodiment can be downloaded, including check logs (check_task_number.log) and installation logs (install_task_number.log), mainly used for handling installation errors. Simultaneously, the check time and installation time can also be recorded in the task, which can be used as reference indicators in subsequent optimization processes.

[0056] In another optional embodiment, before deploying the middleware indicated by the middleware identifier on each server using a preset deployment script based on deployment parameters, the backend program can find the corresponding middleware check script according to the selected middleware identifier, check whether the server filtered by the system ledger has already deployed the middleware. If the check confirms that the middleware has not been installed, the installation process begins. Normally, the server information provided by the system ledger is accurate, but to avoid duplicate installations on servers not correctly marked as having deployed middleware, the backend program will call the check script to check the relevant servers sequentially. After the check is completed, the results will be uploaded to the backend program via a backend interface and displayed on the page. Since checking multiple servers takes a long time, when the user clicks "deploy," they can be redirected to a task page, which displays task information automatically created by the backend program. These tasks can be executed automatically by the backend.

[0057] Optionally, after responding to the middleware deployment request and generating the target task, the process further includes: invoking the check script corresponding to the target task; using the check script to sequentially check whether the server indicated by each service address in the target task has deployed the middleware, obtaining multiple check results, wherein the check results include at least: task number, service address, and check status; when the check results are converted into a first interface parameter and the first interface parameter is passed to a first preset backend interface, the first interface parameter is inserted into a preset installation status table, and a task record corresponding to the task number is created; querying the preset installation status table, and if the number of task records associated with the task number is equal to the number of service addresses, and the check status indicated by each task record is "check passed", the deployment script corresponding to the target task is invoked.

[0058] In this embodiment of the invention, the target task can first be inserted into the task table to obtain a task record, including: task number, task progress, etc. The initial value of the task progress field can be "checking in progress". The task number, log file name, and task details table will all use it. The ipCnt (i.e., number of service addresses) field is used to record the number of service address IPs that need to be deployed. After that, the backend can call the agent_check.yml script (i.e., call the check script corresponding to the target task). In this embodiment, in addition to the deployment parameters filled in by the front-end page, the task number tskId also needs to be added when calling the deployment command, so that a log file named check_task number.log can be created to record the entire check process so that problems can be investigated in time when an anomaly is detected. Then, the check script can be used to check whether the server indicated by each service address in the target task has deployed the middleware in turn, and obtain multiple check results. The check results include: task number, service address, check status, etc. When the check task is completed, the check script will call the backend interface (i.e., the first preset backend interface, such as checkCallBack) and pass the check results to the first preset backend interface in the following form (i.e., convert the check results into the first interface parameters):

[0059] http: / / xxx.xxx.xxx.xxx / ansible / checkCallBack?tskId=2&ip=12*.*.*.*&status=*, where ansible is the script format, checkCallBack is the backend API to be called, tskId is the task number, ip is the server's service address, and status is the check status: 1 means the middleware is installed, and 0 means the middleware is not installed.

[0060] Subsequently, when the backend checkCallBack interface receives the first interface parameter, it can first insert the interface data into the preset installation status table (such as the dops_install_status table) and create a task record corresponding to the task number. In this embodiment, multiple clients can execute the check process asynchronously, so the result of each client's execution will create a task record under the task number, recording the check result of the corresponding service address. Therefore, the preset installation status table can be queried to determine whether the number of data records under the task number is equal to the number of service addresses. If the number of data records is not equal to the number of service addresses, it indicates that there are still servers that have not been checked, and the obtained first interface parameter is inserted into the preset installation status table. If the check status is "installed", only the first interface parameter is inserted into the preset installation status table, and the task table status is updated to "check failed".

[0061] If the number of data records under the task number is equal to the number of service addresses, and the check result is that none of them are installed (i.e., if the number of task records associated with the task number is equal to the number of service addresses, and the check status indicated by each task record is "check passed"), then the agent_install.ym script is called (i.e., the deployment script corresponding to the target task is called), and the task table status is updated to "deploying".

[0062] Optionally, after calling the deployment script corresponding to the target task, the method further includes: using the deployment script to deploy middleware to the server indicated by each service address in the target task in sequence, obtaining multiple deployment results, wherein the deployment results include at least: task number, service address, and installation status; when the deployment results are converted into second interface parameters and the second interface parameters are passed to the second preset backend interface, the installation status field of the task record associated with the task number in the preset installation status table is updated based on the second interface parameters; if the installation status field is not empty, it is determined that the server indicated by each service address in the target task has been deployed successfully; if the installation status field is successful, it is determined that the server indicated by each service address in the target task has been deployed successfully.

[0063] In this embodiment of the invention, a deployment script can be used to deploy middleware to the server indicated by each service address in the target task in sequence, resulting in multiple deployment results. These deployment results include: task number, service address, installation status, etc. After the deployment is completed, a backend interface (a second preset backend interface, such as installCallBack) can be called back. The deployment results can be passed to the second preset backend interface in the following form (i.e., the deployment results are converted into second interface parameters):

[0064] http: / / xxx.xxx.xxx.xxx / ansible / installCallBack?tskId=2&ip=12*.*.*.*&status=*, where ansible is the script format, installCallBack is the backend API to be called, tskId is the task number, ip is the server's service address, and status is the installation status: 1 means the middleware is installed, and 0 means the middleware is not installed.

[0065] Subsequently, when the backend installCallBack interface receives the transmitted second interface parameter (i.e., after converting the deployment result into the second interface parameter and passing the second interface parameter to the second preset backend interface), the second interface parameter can first be updated in the dops_install_status table (i.e., based on the second interface parameter, the installation status field of the task record associated with the task number in the preset installation status table is updated). If the preset installation status table is checked and the installation status field (install_status field) of any task record is found to be empty, it indicates that not all installations have been successful; if the preset installation status table is checked and the value of the install_status field is not empty, it means that all client nodes (i.e., servers) have been installed (i.e., if the installation status field is not empty, it is determined that the server indicated by each service address in the target task has been deployed successfully). Then, the value of the installation status field in the preset installation status table can be checked to verify whether the servers have been installed successfully. If successful, the task status is updated to deployment successful (i.e., if the installation status field is successful, it is determined that the server indicated by each service address in the target task has been deployed successfully); otherwise, it is updated to deployment failed.

[0066] Optionally, you can view the detailed execution information of the task by clicking the "Details" button next to the execution details displayed on the task page.

[0067] Step S103: Based on the deployment parameters, deploy the middleware indicated by the middleware identifier on each server using a preset deployment script.

[0068] In this embodiment of the invention, middleware indicated by a middleware identifier can be deployed on each server according to deployment parameters (including: installation path, access port, required memory, etc.) through a preset deployment script.

[0069] Step S104: Convert the deployment commands in the preset deployment script when deploying the middleware into preset commands to obtain a preset command set, and generate a deployment document based on the preset command set and the command comments corresponding to each preset command in the preset command set.

[0070] In this embodiment of the invention, the syntax of deployment commands in the preset deployment script is not easy to understand, requiring a learning curve to comprehend. Since the deployment documentation is intended for operations and development personnel, to make it understandable for junior operations and development staff, as well as users unfamiliar with the syntax of deployment commands, a preset command (such as a shell command) can be appended to each deployment command in the deployment script. The result of executing this appended preset command is consistent with the deployment command, and command comments corresponding to the preset command are also appended. During deployment, the preset command and command comments are not actually executed but are appended to the deployment documentation, thus automatically generating the middleware deployment documentation.

[0071] Optionally, after generating the deployment document based on the preset command set and the command comments corresponding to each preset command in the preset command set, the method further includes: if the middleware is updated, updating the check script, deployment script, and uninstallation script corresponding to the middleware based on the update parameters of the middleware; determining the target deployment command updated in the check script, deployment script, and uninstallation script; and modifying the preset command corresponding to the target deployment command and the command comments corresponding to the preset command based on the target deployment command to obtain the updated deployment document.

[0072] In this embodiment of the invention, as the middleware is optimized, preset commands and corresponding command comments can be added or modified in the middleware scripts (i.e., the check scripts, deployment scripts, and uninstall scripts corresponding to the middleware). (That is, when the middleware is updated, the check scripts, deployment scripts, and uninstall scripts corresponding to the middleware are updated based on the update parameters of the middleware, and the target deployment command updated in the check scripts, deployment scripts, and uninstall scripts is determined. Based on the target deployment command, the preset command corresponding to the target deployment command and the command comments corresponding to the preset command are modified.) The backend will automatically update the deployment document in a preset format (such as markdown format), and archive the deployment document before modification. The task page can also display the latest deployment document.

[0073] Optionally, after modifying the preset commands and command comments corresponding to the target deployment command based on the target deployment command to obtain the updated deployment document, the process further includes: extracting the preset command set from the deployment document; executing the preset command set in a preset test environment to deploy middleware on a preset server to obtain a parameter file set; if the middleware deployment on the preset server is successful, replacing the service address of the preset server in each parameter file in the parameter file set with the service address in the pre-production environment to obtain a target file set; packaging the target file set after deleting log files to obtain target files, and generating target string values ​​based on the target files; obtaining the standard file set in the pre-production environment and deleting log files from the standard file set to obtain a target standard file set; packaging the target standard file set to obtain standard files, and generating standard string values ​​based on the standard files; if the target string value matches the standard string value, the deployment document verification is confirmed to be successful.

[0074] In this embodiment of the invention, before displaying the updated deployment document on the task page, it is necessary to verify the consistency between the deployment document and the deployment document in the production environment. Specifically, preset commands can be extracted from the deployment document sequentially and executed in a preset test environment. After execution, the middleware's check script can be used to confirm whether the installation on the preset server was successful (i.e., extracting the set of preset commands from the deployment document, executing the set of preset commands in the preset test environment to deploy the middleware on the preset server, and obtaining a set of parameter files). After verifying successful installation, the test environment will replace the service address of the preset server in each parameter file in the parameter file set with the service address in the pre-production environment. At the same time, the target file set after deleting log files will be packaged to obtain target files, and a target string value (such as an MD5 value, which is unique) will be generated based on the target files. Similarly, obtain the standard file set in the pre-production environment, delete the log files in the standard file set to obtain the target standard file set, package the target standard file set to obtain standard files, and generate standard string values ​​(such as MD5 values, which are unique) based on the standard files. If the target string value is consistent with the standard string value, the deployment document verification is confirmed to be successful (that is, the automatically updated deployment document is consistent with the deployment document in the production environment).

[0075] In this embodiment of the invention, by integrating the deployment process and the process of creating deployment documents, and by verifying the consistency between the deployment results of the automatically generated deployment documents and the deployment results in the production environment, the accuracy of the deployment documents can be ensured. Furthermore, it effectively solves the problem of deployment documents becoming inaccurate over time, saves on deployment document maintenance costs, and improves customer satisfaction.

[0076] The following is a detailed description with reference to another embodiment.

[0077] Example 2

[0078] The deployment document generation device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above.

[0079] Figure 2 This is a schematic diagram of an optional deployment document generation apparatus according to an embodiment of the present invention, such as... Figure 2 As shown, the generating apparatus may include: a receiving unit 20, a querying unit 21, a deployment unit 22, and a generating unit 23, wherein,

[0080] The receiving unit 20 is used to receive a middleware deployment request, wherein the middleware deployment request includes at least: middleware identifier and deployment parameters;

[0081] The query unit 21 is used to query a preset service address table based on the middleware identifier to obtain a target service address table, wherein each service address in the target service address table corresponds to a server;

[0082] Deployment unit 22 is used to deploy the middleware indicated by the middleware identifier on each server based on deployment parameters and using a preset deployment script;

[0083] The generation unit 23 is used to convert the deployment commands in the preset deployment script when deploying the middleware into preset commands, obtain a preset command set, and generate a deployment document based on the preset command set and the command comments corresponding to each preset command in the preset command set.

[0084] The aforementioned generation device can receive middleware deployment requests through receiving unit 20, query a preset service address table based on the middleware identifier through query unit 21 to obtain a target service address table, deploy middleware indicated by the middleware identifier on each server through deployment unit 22 based on deployment parameters and using a preset deployment script, and generate a deployment document based on the deployment command set and command comments corresponding to each preset command in the preset deployment script. In this embodiment of the invention, the server where middleware needs to be deployed can be determined through the middleware identifier carried in the middleware deployment request, and then the middleware can be deployed on each server using a preset deployment script. At the same time, the deployment commands in the preset deployment script are converted into preset commands, and a deployment document is automatically generated based on the preset commands and command comments corresponding to the preset commands. By integrating the deployment process and the process of creating the deployment document, no manual maintenance is required, which can improve the accuracy of the deployment document and solve the technical problem in related technologies where manual maintenance of deployment documents easily leads to a decrease in the accuracy of the deployment document.

[0085] Optionally, the generation device further includes: a first creation module, used to create a corresponding inspection script, deployment script, and uninstallation script for each middleware based on a preset script format before receiving a middleware deployment request, wherein the inspection script is used to check the deployment status of the middleware, the deployment script is used to deploy the middleware, and the uninstallation script is used to uninstall the middleware; and a first recording module, used to record each middleware and the corresponding inspection script, deployment script, and uninstallation script to a preset routing table.

[0086] Optionally, the query unit includes: a first query module, used to query a preset service address table to obtain query results, wherein the query results record the deployment status of the middleware deployed on each server; a first filtering module, used to filter servers in the query results whose deployment status is not deployed, to obtain a target server set; and a first generation module, used to generate a target service address table based on the target server set.

[0087] Optionally, the generation device further includes: a second generation module, used to respond to a middleware deployment request and generate a target task before deploying the middleware indicated by the middleware identifier on each server based on deployment parameters and using a preset deployment script, wherein the target task is used to deploy the middleware indicated by the middleware identifier to each server indicated by the service address; and a first display module, used to add the target task to a task table and display the task information associated with the target task in the task table on the front-end page, wherein the task information includes: task number, task type, applicant, task progress, task log, execution details, and number of service addresses.

[0088] Optionally, the generation device further includes: a first invocation module, used to invoke a check script corresponding to the target task after generating the target task in response to a middleware deployment request; a first check module, used to use the check script to sequentially check whether the server indicated by each service address in the target task has deployed middleware, and obtain multiple check results, wherein the check results include at least: task number, service address, and check status; a first insertion module, used to insert the first interface parameter into a preset installation status table and create a task record corresponding to the task number when the check result is converted into a first interface parameter and the first interface parameter is passed to a first preset backend interface; and a second invocation module, used to query the preset installation status table, and invoke the deployment script corresponding to the target task when the number of task records associated with the task number is equal to the number of service addresses and the check status indicated by each task record is "check passed".

[0089] Optionally, the generation device further includes: a first deployment module, used to deploy middleware sequentially for each server indicated by a service address in the target task after calling the deployment script corresponding to the target task, thereby obtaining multiple deployment results, wherein the deployment results include at least: task number, service address, and installation status; a first update module, used to update the installation status field of the task record associated with the task number in the preset installation status table based on the second interface parameters after converting the deployment results into second interface parameters and passing the second interface parameters to the second preset backend interface; a first determination module, used to determine that each server indicated by a service address in the target task has been deployed successfully if none of the installation status fields are empty; and a second determination module, used to determine that each server indicated by a service address in the target task has been deployed successfully if all installation status fields indicate successful installation.

[0090] Optionally, the generation device further includes: a second updating module, used to update the check script, deployment script, and uninstallation script corresponding to the middleware based on the update parameters of the middleware after generating the deployment document based on the preset command set and the command comments corresponding to each preset command in the preset command set; a third determining module, used to determine the updated target deployment command in the check script, deployment script, and uninstallation script; and a first modifying module, used to modify the preset command corresponding to the target deployment command and the command comments corresponding to the preset command based on the target deployment command, to obtain the updated deployment document.

[0091] Optionally, the generation device further includes: a first extraction module, used to extract a set of preset commands from the deployment document after modifying the preset commands corresponding to the target deployment command and the command comments corresponding to the preset commands to obtain an updated deployment document based on the target deployment command; a first execution module, used to execute the set of preset commands in a preset test environment to deploy middleware on a preset server to obtain a set of parameter files; a first replacement module, used to replace the service address of the preset server in each parameter file in the set of parameter files with the service address in the pre-production environment if the middleware is successfully deployed on the preset server to obtain a set of target files; a first packaging module, used to package the set of target files after deleting log files to obtain target files, and generate target string values ​​based on the target files; a first acquisition module, used to acquire a set of standard files in the pre-production environment and delete log files in the set of standard files to obtain a set of target standard files; a second packaging module, used to package the set of target standard files to obtain standard files, and generate standard string values ​​based on the standard files; and a fourth determination module, used to determine that the deployment document verification is passed if the target string value is consistent with the standard string value.

[0092] The aforementioned generating apparatus may also include a processor and a memory. The receiving unit 20, querying unit 21, deployment unit 22, generating unit 23, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0093] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, deployment commands in the preset deployment scripts used when deploying middleware are converted into preset commands, resulting in a set of preset commands. Based on this set of preset commands and the command comments corresponding to each preset command, a deployment document is generated.

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

[0095] This application also provides a computer program product that, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: receiving a middleware deployment request; querying a preset service address table based on a middleware identifier to obtain a target service address table; deploying the middleware indicated by the middleware identifier on each server using a preset deployment script based on deployment parameters; converting the deployment commands in the preset deployment script when deploying the middleware into preset commands to obtain a preset command set; and generating a deployment document based on the preset command set and the command comments corresponding to each preset command in the preset command set.

[0096] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the above-described deployment document generation method.

[0097] Figure 3 This is a hardware structure block diagram of an electronic device (or mobile device) for deploying a document generation method according to an embodiment of the present invention. Figure 3 As shown, the electronic device may include one or more processors 302 (shown as 302a, 302b, ..., 302n in the figure) 302 (processor 302 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 304 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 3 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device may also include components that are more... Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown.

[0098] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0099] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0100] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0101] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0102] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0103] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0104] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method of generating a deployment document, the method comprising: The method comprises the following steps: receiving a middleware deployment request, wherein the middleware deployment request comprises at least a middleware identifier and a deployment parameter; querying a preset service address table based on the middleware identifier to obtain a target service address table, wherein each service address in the target service address table corresponds to a server; deploying the middleware indicated by the middleware identifier on each server based on the deployment parameter by using a preset deployment script; converting deployment commands in the preset deployment script into preset commands to obtain a preset command set, and generating a deployment document based on the preset command set and a command annotation corresponding to each preset command in the preset command set; wherein, before receiving the middleware deployment request, the method further comprises the following steps: creating a corresponding check script, a deployment script and an uninstall script for each middleware based on a preset script format, wherein the check script is used to check the deployment status of the middleware, the deployment script is used to deploy the middleware, and the uninstall script is used to uninstall the middleware; recording each middleware and the corresponding check script, deployment script and uninstall script in a preset routing table; querying the preset service address table to obtain a query result, wherein the query result records the deployment status of the middleware in each server; filtering servers with an undeployed deployment status from the query result to obtain a target server set; generating the target service address table based on the target server set; before deploying the middleware indicated by the middleware identifier on each server based on the deployment parameter by using a preset deployment script, the method further comprises the following steps: generating a target task in response to the middleware deployment request, wherein the target task is used to deploy the middleware indicated by the middleware identifier to the server indicated by each service address; adding the target task to a task table and displaying task information associated with the target task in the task table on a front-end page, wherein the task information comprises a task number, a task type, an applicant, a task progress, a task log, an execution detail and a number of service addresses. after generating the target task in response to the middleware deployment request, the method further comprises the following steps:

2. The generation method of claim 1, wherein, calling the check script corresponding to the target task; using the check script to sequentially check whether the middleware has been deployed on each server indicated by the service address in the target task to obtain a plurality of check results, wherein the check result comprises at least a task number, a service address and a check status; in the case of converting the check result into a first interface parameter and inputting the first interface parameter into a first preset back-end interface, inserting the first interface parameter into a preset installation status table and creating a task record corresponding to the task number. ​ query the preset installation state table, and in a case where the number of task records associated with the task number is equal to the number of service addresses and each of the task records indicates that the check state is passed, call the deployment script corresponding to the target task.

3. The generation method of claim 2, wherein, After the deployment script corresponding to the target task is called, further comprising: deploying the middleware for each server indicated by the service address in the target task in sequence by using the deployment script to obtain a plurality of deployment results, wherein the deployment results at least include a task number, a service address, and an installation state; in a case where the deployment results are converted into a second interface parameter and the second interface parameter is transmitted into a second preset backend interface, updating the installation state field of the task record associated with the task number in the preset installation state table based on the second interface parameter; in a case where none of the installation state fields are empty, determining that the deployment of each server indicated by the service address in the target task is completed; in a case where all of the installation state fields are installation successes, determining that the deployment of each server indicated by the service address in the target task is successful.

4. The generation method of claim 1, wherein, After generating the deployment document based on the preset command set and the command annotation corresponding to each preset command in the preset command set, further comprising: in a case where the middleware is updated, updating the check script, the deployment script, and the uninstallation script corresponding to the middleware based on the update parameter of the middleware; determining a target deployment command updated in the check script, the deployment script, and the uninstallation script; based on the target deployment command, modifying the preset command corresponding to the target deployment command and the command annotation corresponding to the preset command to obtain an updated deployment document.

5. The generation method of claim 4, wherein, After modifying the preset command corresponding to the target deployment command and the command annotation corresponding to the preset command based on the target deployment command to obtain an updated deployment document, further comprising: extracting the preset command set in the deployment document; executing the preset command set in a preset test environment to deploy the middleware on a preset server to obtain a parameter file set; in a case where the deployment of the middleware on the preset server is successful, replacing the service address of the preset server in each parameter file in the parameter file set with a service address in a pre-production environment to obtain a target file set; packing the target file set after the log files are deleted to obtain a target file, and generating a target string value based on the target file; obtaining a standard file set in the pre-production environment, and deleting log files in the standard file set to obtain a target standard file set; packing the target standard file set to obtain a standard file, and generating a standard string value based on the standard file; in a case where the target string value is consistent with the standard string value, determining that the deployment document is verified.

6. An apparatus for generating a deployment document, the apparatus comprising: comprising: The receiving unit is configured to receive a middleware deployment request, wherein the middleware deployment request comprises at least a middleware identifier and deployment parameters; The querying unit is configured to query a preset service address table based on the middleware identifier to obtain a target service address table, wherein each service address in the target service address table corresponds to a server; The deployment unit is configured to deploy middleware indicated by the middleware identifier on each server based on the deployment parameters and using a preset deployment script. The generating unit is configured to convert deployment commands in the preset deployment script during deployment of the middleware into preset commands to obtain a preset command set, and generate a deployment document based on the preset command set and command annotations corresponding to each preset command in the preset command set. The device further comprises a first creating module configured to create, before receiving the middleware deployment request, a corresponding check script, deployment script and uninstall script for each middleware based on a preset script format, wherein the check script is used to check the deployment status of the middleware, the deployment script is used to deploy the middleware, and the uninstall script is used to uninstall the middleware; and a first recording module configured to record each middleware and the corresponding check script, deployment script and uninstall script in a preset routing table. The querying unit comprises a first querying module configured to query the preset service address table to obtain a query result, wherein the query result records the deployment status of the middleware in each server; a first screening module configured to screen servers with an undeployed deployment status in the query result to obtain a target server set; and a first generating module configured to generate the target service address table based on the target server set. The generating device further comprises a second generating module configured to generate a target task in response to the middleware deployment request before deploying the middleware indicated by the middleware identifier on each server based on the deployment parameters and using the preset deployment script, wherein the target task is used to deploy the middleware indicated by the middleware identifier to the server indicated by each service address; and a first display module configured to add the target task to a task table and display task information associated with the target task in the task table on a front-end page, wherein the task information comprises a task number, task type, applicant, task progress, task log, execution details and number of service addresses.

7. An electronic device, comprising: The device comprises one or more processors and a memory configured to store one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method for generating a deployment document according to any one of claims 1 to 5.

Images