Silent update on the job
I develop and support a single corporate tool. In short, a rather complicated automated monitoring system, the client runs under Windows. Actually, the problem was how to update the program. Main obstacles:
The program is running on multiple computers, and running all the time.
Unplanned program launch is a very undesirable thing. The restart takes a couple of minutes, but during this time an important event can slip through which will not be tracked.
The program is launched from a shared network resource via a link (this is more convenient for everyone), respectively, until all workstations run the program, the binary file cannot be replaced - it is used.
Until some time, the update happened like this: I asked everyone to close the program, and replaced the old binary with an updated one. Often you had to wait - someone was always busy, or could not close the monitoring, or something else like that.
How did I solve the problem of updating on the job?
As is usually the case, at first difficult and ineffective ways of solving the problem came to mind. For example, the forced self-copying of the program on the launching screw, and the launch from there. Or launch not the program itself, but its copies in RAM. In general, at first I was repelled by the fact that after launching the binary it should not have been occupied by the program, and could be replaced.
')
But the final solution was very simple and much more efficient.
I replaced the main exe-file of the program with a program that searches for and launches the latest version of monitoring. The launched “update” looks in its directory for all exe-files with names matching the specified mask, checks the version of the file and runs the file whose version is older. I decided to build on the version of the file, but, let's say, not on the name or the update date - this is safer.
For users, everything remains as before, I did not even have to edit the links. After the update is posted to the network, it will be launched at the first restart of monitoring, which is performed when possible, and not when it is required. Old versions of binaries are manually removed after the update has been tested during the work. In case of anything - rolling back to the old version is also simplified as much as possible, it is enough to remove the update (albeit in the old way).
Already half a year the method works like a clock. Of course, I did not come up with anything new and original - but, perhaps, this note will help someone solve a similar problem.
The program is running on multiple computers, and running all the time.
Unplanned program launch is a very undesirable thing. The restart takes a couple of minutes, but during this time an important event can slip through which will not be tracked.
The program is launched from a shared network resource via a link (this is more convenient for everyone), respectively, until all workstations run the program, the binary file cannot be replaced - it is used.
Until some time, the update happened like this: I asked everyone to close the program, and replaced the old binary with an updated one. Often you had to wait - someone was always busy, or could not close the monitoring, or something else like that.
How did I solve the problem of updating on the job?
As is usually the case, at first difficult and ineffective ways of solving the problem came to mind. For example, the forced self-copying of the program on the launching screw, and the launch from there. Or launch not the program itself, but its copies in RAM. In general, at first I was repelled by the fact that after launching the binary it should not have been occupied by the program, and could be replaced.
')
But the final solution was very simple and much more efficient.
I replaced the main exe-file of the program with a program that searches for and launches the latest version of monitoring. The launched “update” looks in its directory for all exe-files with names matching the specified mask, checks the version of the file and runs the file whose version is older. I decided to build on the version of the file, but, let's say, not on the name or the update date - this is safer.
For users, everything remains as before, I did not even have to edit the links. After the update is posted to the network, it will be launched at the first restart of monitoring, which is performed when possible, and not when it is required. Old versions of binaries are manually removed after the update has been tested during the work. In case of anything - rolling back to the old version is also simplified as much as possible, it is enough to remove the update (albeit in the old way).
Already half a year the method works like a clock. Of course, I did not come up with anything new and original - but, perhaps, this note will help someone solve a similar problem.
Source: https://habr.com/ru/post/21624/
All Articles