We’re using TeamCity and Octopus and are currently in the process of upgrading DevExpress versions. When we create a build in TC and deploy to our DEV environment in Octopus both the prior and current versions of the DevExpress components are being deployed to the DEV environment, which causes issues.
Is there a way to delete, or not copy, the prior version of the DLLs? For example, if we push build 2016.0 then it should deploy DevExpress v15.2, but if we push build 2015.3 then it should deploy DevExpress v14.3.
Should this be done in TC or Octopus? If Octopus can determine which build we are pushing then remove those DLLs that would work for me, but I am not sure how to do that.
Thanks for reaching out. As a golden rule, Octopus will always deploy exactly what’s inside of the nuget package that it was told to deploy. So if you tell Octopus to deploy the contents of package 2016.0 into c:\MyApp, It’ll do exactly that.
With the above idea in mind, we always recommend the following practices when using Octopus:
Always have all the files your app needs to run inside of your nuget package. If all that changed between V1 and V2 of your package was a simple dll, don’t put only that dll in your V2 package and then deploy it to the directory where V1 is currently running. Put all the files on the V2 package, then delete the contents of the directory where V1 is running (or create a new directory), and deploy the entire app from the V2 package.
Try to (A) Always deploy to a new directory with an “_[version]” suffix and then point your service to consume your app from that new path or (B) If you want to always run your app from the same dir, purge the directory to delete all the files from the current version first, and then deploy the full new version to it.
If you follow those 2 practices, you wont have to care about any special logic for the bin folder when you update a special DLL. Octopus will either always delete the current/old bin folder and then put the new one, or it will deploy the new bin folder to a new dir and re-point your service to that path.
Would we purge the c:\websites\dev folder or only the c:\websites\dev\bin folder?
Should be do this via TeamCity or Octopus? We have a “Deploy to Dev” step in Octopus and I saw a “Purge” option for our c:\websites\dev folder, but it didn’t see to do anything. Or if it did purge it, then the DLLs for both versions of DevExpress were copied back.
I added a new step just above my “Deploy to Dev” step to run a PowerShell script to delete a file in the BIN folder, but it doesn’t appear to be running.
I’ve attached a screenshot of this step.
When I run that command via PS manually it does delete the file. Also, when I run it via the Script Console it works.
Any thoughts on why it doesn’t work as an Octopus step?
Yesterday I tried adding the OctopusPurgePackageDirectoryBeforeCopy variable and ever since then I get the warning shown in the attached screenshot.
Does this mean that I need to rename my current “Deploy to Dev” build process and then create a new version from the backup so that it can run the Powershell script?
If so, would this impact my TeamCity settings if I name the new build process the same as the prior process?
Don’t worry about the multiple posts. There’s no limmit for those here
1. Would we purge the c:\websites\dev folder or only the c:\websites\dev\bin folder?
You would purge C:\Websites\Dev\. I’m assuming that the \bin folder is inside of the Nuget package, so It’ll get recreated once Octopus copies the content extracted from the package to C:\Websites\Dev\.
2. Should be do this via TeamCity or Octopus? We have a “Deploy to Dev” step in Octopus and I saw a “Purge” option for our c:\websites\dev folder, but it didn’t see to do anything. Or if it did purge it, then the DLLs for both versions of DevExpress were copied back
Through Octopus using that “Purge” option you mentioned. But checking that box it should delete everything from the directory set in the “Install to” field.
About that new PS step you added and the warning in your screenshot
That screenshot is telling you that you updated either a variable or a step in your deployment process, but you are still trying to deploy a release that was created prior to those changes. That new variable, the PS script and the “Purge” option won’t take effect in your deployment if you keep re-deploying the same release. You need to create a new release and deploy that one if you want those changes to take effect.
Try doing the following:
Remove the extra PS script your added.
Remove the variable OctopusPurgePackageDirectoryBeforeCopy you added.
Create a new release (so the new variables take effect) and deploy it. If possible skip as many steps as you can and only leave step we are troubleshooting in order to avoid the noise in the log.
Looks like I was right. It was the snapshot causing the issue. I have it all resolved now.
I ended up leaving the PS script for each environment, but probably could have just ticked the “Purge” box on each “Deploy to…” environment step instead.
Glad to hear its working now. Try to use the “Purge” option instead of the step. If you ever change the deploy path, that “Purge” option will always point to it, which is a lot less error prone than having to update your PS script manually. Also having less steps always makes the troubleshooting easier the next time something goes wrong.
Turns out the Purge option wasn’t right for me, since it ended up deleting some things that shouldn’t have been because we don’t keep them in version control.
I went back to the original PS scripts. Hopefully we won’t move the target folder anytime soon.
