I am deploying a nuget package that comes to Octopus Deploy from TeamCity. What I need to do is to apply config transforms and deploy the zip archive of that package content (Windows Application binaries) to a specific folder of the tentacle. I even don't need to publish the package itself. Is there a way to achieve that?
0
votes
Can you tell me if the nuget package contains the zip and the config files, or the zip file contains the config files - Any chance you can provide a screenshot of the .nupkg contents from TeamCity?
– Evolve Software Ltd
@DevOps, My package doesn't contain zip. It contains binaries and configs for transform. So what I need is to apply the config transform (as usual in Octopus Deploy) but then deploy binaries in the zipped form (while typically they are deployed as just a folder)
– SiberianGuy
2 Answers
0
votes
If I understand you correctly, you should be able to achieve this fairly easily.
Have a standard step type of Deploy NuGet Package to install the nuget package onto the tentacle for the correct environment and role, ensuring that Configuration Variables and Xml Transforms are enabled - This will ensure your configs are transformed OOTB with no effort.
In order to then deploy the binaries I would use some custom powershell as this doesn't appear to be an "application type" that Octopus treats as a first class citizen. You could write the powershell inline as a second step by adding a step type of Run a PowerShell script and writing the code in the Octopus UI. Not knowing if the are going over a network share or any specifics I've not attempted to write any code.
My personal preference would be to write this as a powershell script that is included in the .nuget package. Octopus Deploy supports a naming convention on certain PowerShell files it finds in the .nuget package (PreDeploy.ps1, Deploy.ps1, PostDeploy.ps1). I'd write a PostDeploy.ps1 and package that up. I'd then have that script under source control and could easily make changes to it.
The caveat with this if you aren't careful is that you then start to move deployment implementations away from Octopus. However, written carefully and generically you could bootstrap the script with Variables (such as path to directory / network share etc) which makes it reusable should the need arise, and you can have it work differently in different environments.
Please pardon my ignorance if I've still not understood what you mean by the binaries "being in zipped form"
Further details on the Octopus Deploy PowerShell Scripts
Hope this help.
