We have a small number of targets that basically run our software every five minutes as a windows scheduled task. These are bots, just churning away in the background, checking that everything is good with the world.
We have also set up Octopus to autodeploy to these machines whenever a particular condition is met.
Quite often, one or more of them will be busy running the software already, so the deployment will fail. This isn’t a big problem for us, as the bots don’t need to be totally up to date, but I’d like to fix it.
I have seen some suggestions in a similar thread from a couple of years ago. In that scenario, the software was being run from a sql server scheduled job and your advice was to install the software to a new folder, and then update the scheduled task so that next time it ran the new version of the software would be executed. Then they were advised to use retention policies to clean up old installations.
- is that still sound advice? If so, any tips on automatically updating our scheduled task?
- What about just having a script that waits for the software to stop running and then copies over it? Is that something Octopus can/should do?
Thanks for getting in touch! The solution you’ve described sounds good to me. That being said, personally I find Windows Scheduled Tasks tricky to use and try to avoid them.
This might not be possible in your case but I would move scheduling to the app itself and install it as a window service. Then you could use our Deploy a Windows Service step to deploy updates. In this way you will avoid failed deployments and the app will have a chance to shut down gracefully.
If that doesn’t work for you then:
- There is library step that you might find useful: Windows Scheduled Task - Change Path. The code is contributed by our users so we can’t provide any guarantees.
- I would avoid this approach because you are going to have long running tasks and this might exhaust your task cap.
Please let me know how you go.
Hi Pawel, thanks for your advice. Unfortunately our app can’t be changed to run as a service, so I’ll take a look at that scheduled task step. Looks handy.
These tasks are not that long running, usually 1 minute or so with an occasional timeout after 30 minutes. And deployments don’t usually occur that frequently, maybe 3 or 4 times a day on a typical day.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.