Hi,
One of our users has found a flaw with the deployment lifecycles which i would like to try and prevent.
Our situation is a multi step deployment whereby the 1st step is non distructive.
Our lifecycle states a deployment to “DEV” before “QAT” to prevent our QA team getting a bad build.
However, a developer has discovered they can deploy 1 step to “DEV” which unlocks deployments to "QAT"
They are then able to deploy all steps to “QAT” essentially bypassing the Octopus lifecycle requirements.
Is there a way to only allow steps which have been deployed to “DEV” to be promoted to “QAT”?
Hi Chris, thanks for reaching out.
I’ve run this question past the team, and I wanted to give you some information as to why steps are not able to be locked down as you described.
Octopus Deploy has been developed to give developers the flexibility to run steps as needed. Examples we have seen used by customers are skipping steps that, while still defined to make them repeatable, are run only once or very infrequently, such as a database setup script. Developers may also choose to skip long running steps like backups in development environments, rerun individual steps after a successful deployment, or skip steps that are known to be already done in a development environment but still need to be done in production.
You could use a manual intervention step which could be used to verify that all steps from the previous environment were executed. However these manual intervention steps can also be skipped, so they can’t be relied on as a means of enforcement. The deployment process is designed to be repeatable, but also to trust those doing the deployments.
If this is a feature that would benefit your team, please feel free to create a user voice idea at https://octopusdeploy.uservoice.com/.
Regards
Matt C
Whilst i understand where your comming from, i fail to understand the perpose of the forced deploy to an environment in these scenarios.
I agree that trust is important whilst doing deploys, this issue can also cause problems when triggered accidently. - i.e. i thought i deployed that step to the previous environment but didn’t.
Coupled with the fact that when promoting the default behaviour is a full deployment, we have seen sitations (and luckily stopped prior to any serious issues) whereby a deploy of a single step was done to 1 environment and a full deployment was done to another (completely by accident).
I would love to add this to your user voice, but i am currently maxed out on votes so cannot raise a new request.
Hi,
Many thanks, i’ll keep an eye on that user voice and hopefully it will get enough votes 