Triggers, gates and bad releases
These features combine to make it possible to build a better deployment pipeline without requiring external tools (like a build server) to make the pipeline work.
First, we'll implement different kinds of "triggers" that create a deployment:
- When a new package is pushed ("Deploy to DEV when a new package is ready")
- When a deployment finishes ("If DEV completed successfully, deploy to UAT")
- Time ("Promote DEV to UAT every Monday at 9AM")
- Script trigger (runs every half hour, can use variables and logic to decide what to do)
Second, make it possible to define gates to allow for a more controlled workflow:
- You can't deploy to UAT unless you deploy to DEV
- You can't deploy to Staging unless you deploy to INT1 or INT2, but people in team XYZ can override with a justification
Third, make it possible to look at a deployment and decide that it is "bad". For example, after deploying to staging, we might discover a bug that deletes customers. Make it possible to flag the release as bad - now no one will be allowed to deploy it to Production.
Paul Stovell
shared this idea
This is completed as part of the Lifecycles work in 2.6
-
Tim Walker
commented
I don't see how Lifecycles solve the triggers issue. You cannot use Lifecycles to trigger a script every half hour as is mentioned in the original request.
-
Jesse Beard
commented
+1 for everything about this. Looking forward to it.
-
borislav.traikov
commented
Having the triggers is something I'm very much looking forward to and it may be the essential feature that I'll need in order to persuade my colleagues to use OctopusDeploy for the entire company.
Can you give me an ETA as when will this feature will be available?
Since this feature is slated for Octopus 2.6 so the ETA question is about that version :) -
Adam Bezverkov
commented
In the same spirit of marking a deploy as bad, which seems like it would be a type of (locked) gate, it would also be nice to gate the opposite. A standard workflow for deploy is being able to mark something as good (i.e. QA Approved), and block any deployments (ex: to production) that didn't meet that criteria.
I only call that out specifically because all the examples of gates given were based on something a deployment and not an attribute. -
Scott McFadden
commented
Would the proposed Octopus trigger allow us to write powershell script to handle a given deployment event? For instance, it might be nice to write a powershell script that notifies when a given app is successfully deployed to a given environment.
-
Andrea Maruccia commented
I would have a suggestion for gates:
Let's say you've project A (WEBSITE) that has a dependency to Project B (API)
If someone is deploying project A you should be able to block the deploy of Project B because it could have a negative impact on the whole system.
Taking it further it would be nice to be able to setup a whole set of deploy rules that define what deploys are allowed, or/and how many of these deploys can run in concurency.
Instead of blocking a deploy it could be queued.
Sadly it isn't fantasy :) we would need something like this ;)
-
-
Thanks for the update Daniel. I think your suggestion would be a nice way to implement support promotion triggers generally:
I.e., your step would allow you to select not just the project, but the environment.
These are pretty similar use cases:
"When project A is deployed to DEV, deploy project B to DEV"
"When project A is deployed to DEV, promote it to UAT"