[Theme QT 13th] Implementation of Automatic System software deployment

This article is a supplement to the article on the dynamic upgrade of the plug-in version based on the CTK plugin framework, in the previous article, we focused on how to update the local running program after the new plug-in version has been downloaded to the Plugins directory. This is the second half of the implementation of the entire plug-in upgrade. This article describes the First Half of automatic software deployment (including plug-in upgrades, of course.

We must understand that our programs run on user machines, and plug-in updates are not manually put in, there must be a mechanism for the client to detect the need to upgrade the plug-in, then download the plug-in automatically, and finally install or update the plug-in.

The basic architecture of automatic system software deployment is as follows:

In the composition, the [application] and [Update Service] sections run on the client, the [database] and [File Server] run on the server, and the [server (webserver)] is responsible for communications between the client and the server. The basic process is as follows:

1> The [Update Service] on the client uses the qtimer: singleshot () logic to regularly trigger Version Detection.

2> In the Version Detection logic, the webserver request is used to access the Version Detection Service of the server (implemented through PHP). The server returns to access the [database] and checks whether there is a higher version of plug-in/upgrade package.

3> check information returned to the [Update Service] of the client. When [Update Service] identifies a newer plug-in/installation package based on the returned results, access File Server and perform the download operation. You can use ftp to download the updated files on the file server, or download the updated files from the file server to a local directory.

4> the last part is the most troublesome part for system software deployment/plug-in upgrade. The [Update Service] of the client determines whether the [application] module is running a job or providing external services. If the [application] module does not provide external services, you can directly upgrade or install the module if prompted by the user. If the [application] module is providing external services, you need to use the idle time update policy to update the service after the external service is complete.

Basically, the logic architecture of automatic system software deployment is shown above, but some important issues need to be considered for implementation in actual code.

1. to be compatible with various files in the installation package/upgrade package, the downloaded files include EXE, DLL, and zip packages. You must be able to differentiate the extension names of the downloaded files and then use different suffixes, use different installation or upgrade policies.

2. compatible with various platforms, such as Windows, Linux, and Mac OS. There are various installation packages under different platforms, such as exe1_dll1_zipzipand rpm1_tar.gz under windows.

3. when the [application] module is providing external services, such as network operations and opened ports, the original occupied ports must be stopped before plug-in updates or upgrade packages are installed, after the plug-in is updated, open the port again to restore the previous task. This process is not very well controlled and there is no experience in dealing with this issue.

Finally, because the client needs to communicate with the server, the same data structure or communication protocol must be defined. At this time, Google protobuf provides great flexibility. It is not only easy to use, but also more efficient (usually compared with XML). It also supports many language versions, such as PHP, C ++, and Java, we strongly recommend that you use Google protobuf to define the network protocol when it comes to network communication in future projects. It will surprise you with your inintention.

Keep learning and accumulating every day. Come on!