Deploying package to a different region takes long time

[Ge]

Hello,

In our project, we have a “deploy package” step that deploys package across multiple regions nation wide.

It usually takes about 20 seconds when deploying locally, and 20+ minutes when deploying to a different region. For instance, Chicago.

We would like to get some suggestions from Octopus. What is the best practice to shorten the deployment time when we need to deploy package to a different region?

Thanks,

Ge

[Alex.Rolley]

Hi Ge,

Thanks for getting in touch!

I suspect that transferring the package to the targets is what is taking up the bulk of the time (reviewing the logs should confirm), so based on that I have a suggestion. What we have seen work well here is configuring Octopus to use an external [to Octopus] package feed, which you can then place replica’s of at all sites.

This can be a hard concept to explain with words alone, so hopefully some diagrams help. The first diagram is a rough outline of how you would have everything configured currently.

What we want to do is break out the package feed so there is a copy at each site so package transfers are local to each site. I’m modelling using a simple network share as our package store, which replicates to the package stores at each site. We then use DNS to redirect each sites Tentacle so that it redirects to the local feed rather than the main feed

So with the blue lines representing file replication, what we want to occur in this scenario is your DNS servers for each site returning the local address for that site. So if a Tentacle queries packagefeed.company.com from the primary site it would get that sites address (e.g. 10.10.1.5), yet if a Tentacle at your secondary site went for the same entry (packagefeed.company.com) it would receive a different address (192.168.1.5) that corresponds with the feed closest to itself.

I hope this all makes sense, please let me know if I’ve skipped over anything or if you have any other questions!

Regards,

Alex

[Ge]

Hi Alex,

Thanks for the detailed explanation!

We don’t have Tentacle on the secondary site. What we do is using local Tentacle to deploy (copy) package to the filer on the secondary site.

In our case, are you suggesting that we should have a Tentacle set up on the secondary site? or we can simply use something like OctopusBypassDeploymentMutex=true to speed up the deployment process?

Thanks,

Ge

[Alex.Rolley]

Hi Ge,

OK, that’s a slightly different scenario. If you have multiple targets in the same region it might be worth installing Tentacle on one of them to handle the deployment to the others, as that will cut down your network traffic to the site (only transferring packages once for example).

Bypassing the deployment mutex may help as that allows multiple steps to run in parallel, however I think you are more bandwidth limited than processing/task speed limited. Feel free to experiment here as it may provide more gain than I expect. Before turning this on you’ll just need to make sure that none of your steps are attempting to access the same files as they will collide and overwrite each others changes.

At this point I can’t think of anything else that may assist, if I do I’ll be sure to let you know!

Regards
Alex