I’m looking into using Octopus to automate installing applications that are currently being deployed with VS2010 setup projects manually. So far I have my solution generating Nuget packages and those are getting built and published to the octopus server nugget feed and automatically deployed to my dev environment. What I’m missing at this point is some of the things the installer previously handled like creating a start menu program group, desktop shortcut etc. There is also no entry in add/remove programs so I can’t use some other tools we have like Dell Kace to see that my application is installed.
Is there a better way to handle those things than generating a bunch of PowerShell scripts to manage them? When a new version is deployed I don’t want shortcuts to older versions left behind confusing things. Can files outside of the primary application directory be managed with retention policies?
Would it be better to run the installer initially then deploy to that folder using the custom directory option?
Thanks for getting in touch! I am going to have to make a few guesses and assumptions here so I’ll start with those, let me know if anything here is wrong.
You are deploying application/application updates to either desktop machines or servers. Previously you would do this manually by creating and running an MSI which would also have functionality to create desktop shortcuts and start menu program groups etc. You wanted to automate this process so are looking at your options.
Octopus mostly supports deploying websites or web applications. But we can also support installing MSI’s on our deployment targets which I think will be your best option, as I assume you were successfully creating MSI’s before. We have a blog post that explains how to install MSIs using Octopus: https://octopus.com/blog/install-msi-with-octopus
Otherwise your option will be to do as you described, with a bunch of PowerShell steps. Or run the installer and deploy other files to your custom directory.
I do know of customers doing what I described above using the Step Template and MSIs to deploy test applications to testers machines, so I know it can be done and automated.
To really help you get and idea of the best way to use Octopus to deploy your projects, having an understanding of what they are, how you manually deploy them and what you are trying to achieve in both an overall goal and individually would help me get a better understanding and idea to give you guidance.
This Project consists of 4 windows services, a database, 2 end user wpf applications and a wpf based administration app that is run by IT. I’d like to be able to go all the way to production with octopus deploy if possible, but one of the end user apps may need to stay an MSI that’s installed manually in production. The other is installed on shared workstations out in the warehouse so they are treated more like servers than workstations.
I found a step template for creating shortcuts, files, and folders. Along with the config file substitutions I now have most of what the msi installers were doing automated. I need to play around with it a bit more I think to be comfortable with how the templates work, but it sounds like it will work for me. At this point, the only thing “missing” is the entry in add/remove programs. I’m not too concerned with that, but at some point I’m sure we’ll want a way to uninstall easily as well. Is there anywhere to put code/PowerShell that would get executed when a version is removed by the retention policy? Is there a way to remove a version from a tentacle? It looks like just removing the machine from the environment doesn’t do anything to the tentacle.
Next step is figuring out the database. We use redgate currently so hopefully that simplifies things a bit.
It sounds like you have a nice solution in the making. To answer your questions:
No, the retention policies run as the very last step and can not be a trigger for any action
We do not run cleanup when Tentacles are deleted. There could be many reasons a Tentacle is removed as a deployment target but the files remaining are still valid and contain live websites/webapps or applications. We don’t make those kinds of assumptions.
2.a. Even just uninstall becomes complicated and messy - how do we know the last deployment process will have a reverse function and hasn’t changed over time, it would also require every custom PowerShell or step template to have a reverse feature.