we have a separation between our dev and production servers, so unfortunately we can’t use the same octopus instance for both dev and prod. Therefore the way that we’ve been looking to promote between environments is to publish the package to a file share that is accessible from both sides - and then set up a feed from the prod side that looks at that server
i’ve looked at this page, but this doesn’t seem to help
my current plan is to set up a tentacle that will be used to push packages to the file share using powershell, but i can’t seem to get the package onto the tentacle without unpacking it - and therefore i have nothing to copy
also, i can’t see how any of the other deployment steps are going to be transferred across (IIS, services etc), but i think thats going to be a separate issue:)
Thanks for reaching out. The feature mentioned by Paul on that post was not implemented, and its not on our current plans either unfortunatelly.
Before getting deep into the fileshare approach, have you thought on using a 3rd party NuGet feed that both Octopus instances can consume? That would make things a lot easier. If Prod-Only Passwords/Configs worry you, you could have those on the Production Octopus instance and then add those values to your app at deployment time.
If you need to stick with the fileshare approach, i’d recommend you to set up a Tentacle on the Octopus Server itself and run the Package-Pushing from there. On the Octopus Server you can find the physical NuGet packages under C:\Octopus\OctopusServer\Repository\Packages in 2.X and C:\Octopus\Packages in 3.0.
If that approach doesnt work either, you can use the variable #{Octopus.Tentacle.CurrentDeployment.PackageFilePath} during your deployment to get the path of the package. This wont stop it from being extracted, so you might wanna add another step to delete the extracted contents at the end of the deployment.
For the deployment process transfer, you can export/import the full project using Octo.exe
hi Dalmiro - thanks for the quick reply - very impressed!
unfortunately, the file share is the only way for us to transfer the packages - all sorts of firewall and security issues!
from the looks of it, i’ll use the C:\Octopus\Packages method - i’ve already installed the tentacle on the octopus server for this reason, but i was using #{Octopus.Tentacle.CurrentDeployment.PackageFilePath} which was null - as i hadn’t deployed it i’m guessing.
The variable #{Octopus.Tentacle.CurrentDeployment.PackageFilePath} will only work while you are deploying the package. I guess it was my mistake to have proposed using it.
The C:\Octopus\Packages approach will have to do in such a restricted environment
my final solution for this was to pick up the package from the c:\Octopus\Packages folder on the tentacle server as suggested. For this to work, I had to switch from using the team city nuget feed to the internal octopus one (which with hindsight is better anyway) otherwise the packages are not uploaded to the server
After that i used a powershell script as below. The main thing here is that the credentials are passed in so i can authenticate the share using credentials from the other domain