We recently started to use Octopus deploy. Now we have configured approx 30 projects in Octopus. All our deployments steps are pretty quick.
But our DB deployments are taking extra time (3-6 mins). This add a toll on our end to end deployment time whenever we deploy all (or most)applications at the same time.
Is there anyway to use a pool of resources in Octopus deploy where I can say to use any available machines from a pool of machine for a particular task.
We thought of using “workers” but we cannot use this because we need application packages to run DB deployment (please correct if this assumption is wrong). As far as I know workers are only for steps that can be executed in Octopus Server (Not on nodes) without application packages.
Hi there @Falcon_Francis
Thanks for reaching out and asking about offloading long running tasks like database deployment. Are you using the ‘run a script step’ here, or some other one.
You can use packages on workers, and you can configure the ‘run a script step’ to run on a worker on behalf of each deployment target of a particular role (e.g. ‘db-server’)
In addition, you can also require the step to bring in other packages with this setting.
Please let us know if you think of any other questions about this, we’re happy to get you more answers!
We are not using “Run Script” steps.
We are using some Readily available templates in Octopus for which we are not seeing the option to run on workers.
But we can see the option to run on workers when we create a copy of the template which we are using or when we use “Run Script” step.
Any idea how we can enable the default steps to run on workers?
Normally we use this template for our DB deployment.
Thanks for the additional detail there, unfortunately there isn’t currently a way you can enable this step to run on a worker, however the workaround you describe using the contents of that step in your own custom template should work.
Related to your question is the answer to this question, that describes some current limitations when using workers.
Hope this helps,
One option we are going to try is to
Download the packages on a shared location (definitely with unique folder name) for each release
Then update the default template for DB deployment to use the files from this shared location.
I hope this will work