I was wondering if there is a variable that can be overridden to prevent the versioned folders from being created when a release is redeployed (e.g. e:\applications\dev\app\1.0.0_3, e:\applications\dev\app\1.0.0_4). We have a script to clean these up in another project, but I’d much rather set a variable to turn it off if possible. I’d also be interested to know if anyone has had a need to refer back to the previous folders under the same version or if there is a specific reason these folders are kept around after redeploying.
Hi Cory,
Thanks for getting in touch! The short answer is no, there is no setting to stop this from occurring.
So a couple of explanations to why.
- The reason we create these folders, is so we have a clean path to unpack, apply transforms, substitute variables etc etc all while the server still has a stable solution hooked up to IIS, then when its all completed we can point the IIS at the new folder, but even if it then goes to a custom install directory, the un-packed pre-transformed files don’t break a live site, we move it after we have done that.
- Having the old stable deployments available also means that if something goes wrong with the current release, pointing back to the previous directory can be accommodated very quickly.
- Our retention policy actually cleans those files up for us! depending on our settings and at the time of deployment it looks back and cleans up any outside of the policy.
I hope that helps clear it up a bit as to why the software works in that way.
Vanessa
So if the retention policy is set to keep three releases on the tentacle, the directories for each deployment associated with the first release (1.0.0, 1.0.0_1, 1.0.0_2, 1.0.0_3) will all remain until the fourth release is deployed - correct?
I would like to understand the recommended or commonly used workflow when the physical path of an application is set to #{Octopus.Action[StepName].Output.Package.InstallationDirectoryPath} and a single version is deployed multiple times. Without deleting the previous install directories after successful deployments, there will be several directories that essentially contain a copy of the prior deployment but aren’t being referenced by IIS. From what I can see, there’s no clean way of rolling back to a prior deployment of the same build without modifying the physical path in IIS. If that’s the case, it seems a feasible way to handle this might be to delete the previous installation directory once the current deployment is successful.
I would appreciate any thoughts or advice.