We are implementing a slightly unusual scenario for one of our applications where we’re not actually deploying the code for the app through Octopus, but we are deploying some XML files that the app reads.
We have 3 Nuget packages that can potentially be deployed, let’s call them P1, P2 and P3.
However, the way this works is that each release won’t necessarily contain all 3 packages - it may be P1 only, or P1 and P3, etc.
Creating the release is fine. However, when it comes to deploying the release, if a certain package isn’t available, the release fails unless the deployment step for that package has been manually skipped.
Is there any way we can implement this so that the user doesn’t have to do the manual skip, and the deployment step just won’t be executed at all if the package isn’t there?
On a slightly different subject, this application also has some environments where there are 2 servers running the app itself, but the data files live on a shared NAS. So we’ve tagged one of the servers to execute the tasks to deploy the files to the NAS, which fine. However, both servers then have to have a service restarted to pick up the new files - is there a way to ensure that the recycle task on the second server doesn’t get executed until the deployment of the files has finished? (or is this the default behaviour anyhow?)
Thanks for getting in touch! While there is no way to do exactly what you want here and tell Octopus to skip a step if it fails, there are perhaps some other options available that you could look into using.
The first thing that comes to mind is that you could use channels. More specifically, you could create a channel for each package, once the package is ready to ship, you could simply create a release for that specific channel. This will allow you to separate all 3 in case one is not needed/ready.
Here is a link to our documentation on channels: http://docs.octopus.com/display/OD/Channels
Please let me know if you run into any issues or have any questions here.
Another option is to configure the project to always choose the latest package and set it to “Skip any package step that is already installed” Though, this gives you a lot less control than the channels option.
As for your second question. This is actually a default behaviour of Octopus, we sequentially run each step of the deployment. You should be able to achieve this by separating the deployment and the recycle of the service into two different steps. If you create some more scoping for the servers.
As an example. Have one of them as a member of say NAS_deploy and have them both a member of app server for the deploy and the recycle steps respectively. This will make Octopus install the files on the NAS_deploy machine and then run the second step on both machines with the app_server role.
Thanks for the response. I think because of the bizarre way these files are deployed, we’ll just play it safe and train the users which steps they need to disable in particular circumstances.
Regarding the second point, of course you are correct - I spotted it after running the process shortly after posting my question!