This was originally raised at https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6186352-version-control-of-deployment-scripts and closed as completed with a solution of scripting the import/export tool.

Raising as a new suggestion as this has come up as few times in support calls and some people have suggested on the original thread that the import/export tool doesn't meet their needs. (Didn't want to reopen the original thread as some people are happy with the provided solution in that thread.)

"In the Continuous Delivery book, Jez wrote that your deployment scripts should be in source control. After creating some pretty elaborate powershell scripts for Octopus, I have to agree. Losing those scripts or having them damaged would be pretty painful.
I understand Octopus has backups, but it would be better to be able to get back to a previous version or see where the script had changed. Since we use GIT, I would be completely satisfied if GIT integration was all that you supported. :) I hope this is helpful. Thanks."

I cannot not use /p:OctoPackEnforceAddingFiles=True with MSBuild. This parameter is absolutely indispensable. It is not even an option.

However I do not want all the files in the build to be included in the package.

The nuspec file and the exclusions ability therein does not allow to exclude files that were added by OctoPackEnforceAddingFiles.

The effect of this is that I can’t use one of the best features of Octo : deploying to IIS.

Because of a few files that I can’t exclude from the build, I need to deploy to a folder, remove the files that I want, and then copy that modified folder to the folder that the IIS site is pointing to.

I completely lose the ability to have IIS setup of a site safely in a system, backed up , effectively documented as it is the single source of everything – all because there is a file in a nupkg that I can’t get rid of.

Please consider allowing an option to remove specific files that OctoPackEnforceAddingFiles added. Even if this is in the nuspec file. This is incredibly important.

Currently retention policies will only run on a Tentacle during a deployment and only for the project currently deploying. There are cases where you delete a project, channel or tenant meaning even if a deployment is run on the Tentacle those previous releases will never be deleted.

The idea being raises will give the ability for a cleanup process to be run on an environment for all active machines. It will compare existing projects, tenants (etc where relevant) against the deployment journal and if there are records in the deployment journal that cannot be matched to the triggering instance those deployments will be cleaned up.

It cannot account for anything not found in the deployment journal. There will be no directory searching inside known Octopus folders. This will work as the retention policy now does and clean up packages, package cache, and package extract folders.

There are sets of common steps that we very often want to "bookend" all of our deployments with. One concrete example would be: sending out a Manual Intervention to confirm when all servers are confirmed live before stamping a new deployment in NewRelic.

Right now, everyone has to bake these steps into their own projects by adding the Manual Intervention step followed by the NewRelic Deployment Stamp step. If it were possible to create what I would call "Composite Step Templates" then I could define a reusable step template that was made up of other step templates. That way, instead of everyone having to repeat all of the possible steps in their own projects, they would simply include this one composite step and they'd be done.

Now, my composite example was only two steps to keep it simple, but you can imagine maybe a composite is made up of more than that. Or even imagine a change in policy where the Manual Intervention email has to include more information. Everyone has to repeat this stuff in all their projects and having the ability to put it into a composite step would alleviate all of that.