Octopus Deploy does not currently enforce the completion of all steps in all environments. This leads to at least two scenarios that may not represent the desired workflow:

1. Steps skipped in previous environments are not necessarily skipped in later environments
e.g. a database script was not applied in Integration but was applied in User Acceptance Testing, when the intention was for User Acceptance Testing to have skipped the same steps that were skipped in Integration to ensure both environments are the same.

2. Promotions can take place when steps have been skipped in previous environments
e.g. a database script was not applied in Integration and the deployment was promoted to User Acceptance Testing with the database script applied, when the intention was for all steps to be completed in a previous environment before a promotion could occur.

This idea is to provide some means to enforce that either the same steps are skipped in all environments, or all steps are completed before a promotion can take place to the next environment.

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."

As of version 3.7.12 it is possible to use the "Transfer package" step and use the selected package on custom steps (e.g. push it to an s3 bucket).

However, when it comes to docker "packages" the only way to select a docker feed is by using one of the 3 default docker steps.

It would be nice to have a basic step which would allow us to select only the docker feed and have that step export the image+version (tag) to other steps.

In my case, this would allow me control the deployment of a specific image using custom templates (e.g. updating an AWS ECS service).

With the current model and permissions, there is no way for us to allow developers to be able to edit processes, but not not have the capability to skip, delete or disable manual intervention steps. The Manual Intervention is a useful tool, but it's not suitable for audited approvals of deployments.

It would be good to move approvals outside of the process itself and have a separate way to manage them, so that they cannot be skipped and can be secured so only a privileged user can amend them. They should also send notification to the person / team that is set as the approver and be easily reportable. They should sit at the deployment level as opposed to the deployment step level where they are now.

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.

Sometimes when deploying, the user receives this message:

"For consistency, this deployment will use a snapshot of the variables and deployment process that was taken when the release was created, which does not include the latest changes that have been made to the project. A changed process can only be incorporated by creating a new release (this one may be renamed if desired). Variables can be updated via the release page, clicking Show to show the variables from the snapshot, and clicking the Update variables button."

It would be great to be able to tell the user exactly what changed, so they can make a judgement on whether or not to update variables or create a new release.