It is hard to decide how such a feature would be able to be natively implemented. The best suggestion would be for users to bundle an uninstall.ps1 script (to ensure that the uninstall process is tied to the version deployed) then use the Octopus.Tentacle.Package.PreviousInstallDirectory variable in a script before the "new" deployment step to access and invoke that script on subsequent deployments.

How would Octopus be expected to uninstall if for example roles are removed from a machine? We then no longer have any way of knowing what machines were involved in that release or if it should be our responsibility to now try and connect to something that has explicitly been changed to no longer be part of that deployment.

If you would use separate steps for the pre-package installation service removal (using Octopus.Tentacle.Package.PreviousInstallDirectory or it's equivalent in a PowerShell script) and separate package installation and post package install service "installation and activation", you could simply scope the installation and "activation" to the roles where you want that service active and leave the uninstall unscoped so it attempts to uninstall the service from any roles where it isn't explicitly called for.

This came up *again* yesterday, in a conversation with a client that's evaluating Octopus, and doesn't want to lose the ability to rollback (that they have in their current, largely manual, process).

@Jack - one workaround is to put an additional deployment step prior to the service deployment that does the uninstall, based on finding the currently registered service and using the normal TopShelf uninstall conventions. It's a wee bit messy to do this because you have to grep the service path from the output from SC.EXE since get-service doesn't give it to you, but it can be done.

This also helps in rollback situations (just intentionally saying rollback so it comes up in search). Rollback.

+1. A simple convention where an 'undeploy.ps1' script gets executed in the currently deployed package prior to the next version being deployed is all that's required. If the version number of the *new* deployment was passed to that script it'd be all the better.
Otherwise definitely risk of leaving debris behind (and I have seen this in the wild, with deployments that deployed varying numbers of TopShelf services too)

In environments where servers get new roles and sometimes loses some there appears a gap in Octopus Deploy. What happens when I remove a role? The deployment is still clearly active and the only way to remove the deployed code is either:

Create an undeployment deployment, which seems a bit silly.

Manually go into the servers and remove the released code.

A best practice solution would be much appreciated!