Hi - I have a new situation today I am not sure of how to configure regarding a post-deployment warm up. Long story short, we have a project being deployed into multiple environments and I have a script I would like to run to verify the service is logically started and ready before the deployment is considered “done.”
I have a warm up script currently configured as running via a worker pool once and the script step references a package to gain access to scoped variables for the URL, etc --this works great if we run a deployment to a single environment at a time. However, if we deploy to multiple environments at once I believe there is going to be a logical error here – I assume the variables will be “randomly” scoped and not all environments will be correctly warmed.
Some environments have multiple hosts being deployed to, others a single host but each presents only a single instance of the service. This script is hitting env1.service.domain.com or env2.service.domain.com to validate the environment being deployed into is ready vs the currently active line on the reverse proxy.
I know I can configure the script to run on a worker on behalf of each deployment target (or even each target directly) and I assume that will provide valid references for each URL based on the target’s environment membership. For the environments with multiple targets, this would run the script more than needed. For this simple warm-up, that is not exactly a problem, as the additional targets in the environment beyond the first would just redundantly ping/warm-up the service. However, I could envision other scenarios where I need something to happen only once in each environment and I am not too sure how I would go about that within my deployment process?
Has anyone encountered a similar scenario and found a viable solution?
Thanks in advance!
Hi @smontney,
Thanks for reaching out, that’s a great question!
It seems like selecting Run once on a Worker rather than Run on a worker on behalf of each deployment target should be what you are after, however it sounds like you’ve already selected this option for the warm-up script and are still seeing it run multiple times, is this correct?
if we deploy to multiple environments at once I believe there is going to be a logical error here – I assume the variables will be “randomly” scoped and not all environments will be correctly warmed.
Regarding variable scoping, our docs about scope specificity outline the order that values are chosen and it will only be random the variables are equal, where we recommend reviewing the variable name or using multiple values with a single variable name:
Our Samples instance’s HTTP - Test URL step in the Monitor Primary Website & Failover to DR if offline Runbook is an example of HTTP testing using a worker and should be similar to what you are wanting to achieve but I’d be happy to look over your Deployment Process/Script if you’d like to send them through!
Feel free to reach out with any questions at all!
Best Regards,
Good evening - Yes the “run once on a worker” is what I have selected and that is working correctly. We should probably chalk this up to “I never asked this question” 
I failed to remember that each environment deployment gets implemented as a separate task. I was over thinking the workflow within Octopus and was not able to run additional tests until much later this evening.When deploying to env1 and env2 at the same time, I had been thinking the process definition of “run once” would apply to both deployments (becouse they were running at the same time in my mind). I failed to remember that Octopus uses separate tasks for each environment during a multiple environment deployment. Each of these tasks is of course scoped correctly and everything runs swimmingly.
1 Like
