On face value the (new-ish) Lifecycle and Release Blocking features of Octopus Deploy are very exciting, however there is a slight bugbear that makes them impractical for my workplace.
We use continuous integration practices and as a result, all commits to shared source control repositories are automatically built and (if that build is successful) an automatic release is created / deployed to our development environment. Once the developers are happy with that release (in the development environment) it is then manually promoted to the staging environment for user access testing, after which it can be manually promoted to production.
The current Lifecycle / Release Blocking features limit the scale of the block to a specific release, which in the above workflow is inadequate as every commit to source control creates a new release and automatically deploys it to the development environment. This new release doesn’t have a block and can be promoted to any environment without limitation.
An example: let’s say person A creates a breaking change in r1000 that they want to prevent from going live until it can be resolved or is user tested so they block the release whilst it’s deployed in both development and staging. If person B commits unrelated changes to source control creating release r1001. This can then be manually pushed to both staging and production despite person A’s change not being fixed / tested correctly.
Ideally, we would be able to block all new releases to production for a project until a human presses a button confirming that releases may go ahead again. Hence other people cannot accidentally promote releases that contain person A’s change / bug / whatever.
I suppose that practically, for me at least, there is no preferable difference between allowing you to block all releases to production, or a feature whereby a release block would be inherited by all subsequently created releases until the block is removed. I.e. r1000 is blocked at staging. Releases r1001 - r1010 are created and are all blocked from being promoted passed staging. Release r1010 is the fix we were looking for, so a human removes the block and it can then be promoted to production, however; releases r1000 - r1009 still cannot be promoted passed staging. Also as an aside; it’s important to us that we can promote blocked releases to environments other than production (i.e. from development to staging).
I understand that ours might not be the typical workflow, so this request might be quite subjective, however it would be incredibly useful for our team and I’m willing to bet (and am hoping) other users out there would use this if implemented.
Thanks,
Liam
