Deployment Trigger promotion only when destination environment has NOT been deployed to yet?

(Matthew Douston) #1

I’d like to configure the deployment triggers so they deploy to the destination environment only if it has not been deployed to yet. I don’t want deploy triggers redeploying what’s already in a given environment in the most recent release.

I have a large number of projects with scheduled deployment triggers set to deploy from Development to QA at regular intervals. If the Development deploy has already been promoted to QA, I don’t want a subsequent scheduled trigger to redeploy to the QA environment if it’s already been deployed to. With how it is now dozens of deploys get queued up that are effectively redundant, wasting a lot of time in our task queue. My idea here is for the scheduled triggers to promote only new updates to QA, not redo things that have already been promoted from Dev to QA in the most recent release of a project.

Is this possible to configure in the UI? Does the Octopus REST api expose enough that I can create a script to do things this way? (For a project, get the default channel, check whether an environment has been deployed to or not, and if it hasn’t, trigger a deploy to it.)

(Donny Bell) #3

Hi Matthew,

Thank you for posting your issue. Would you mind telling me what version of Octopus you are running?

Just to confirm, so I can make sure I understand correctly, I assume you want to do something like this:

  • Take v1.1 that is in DEV and deploy to QA automatically if QA is v1.0, but do nothing if QA is already v1.1

We have a few options that revolve around what you are looking for. Depending on how you want to shape things, Lifecycles, Runbooks, and triggers (with “Do not re-deploy to existing deployment targets that are already up-to-date with the current deployment” selected) can all deploy new releases and avoid redundant deployments.

I apologize if I’m misunderstanding what you are going for. Feel free to provide more details if that is the case. Looking forward to hearing back from you.

Regards,
Donny

(Matthew Douston) #4

You understand me perfectly, Donny. The trigger option you mentioned would be just what I need.

We have Octopus server version 2019.6.8. Does the “do not re-deploy to existing deployment targets taht are already up-to-date with the current deployment” option exist in this version?

Update: I see that the “Deployment Target Trigger” has this option, but the “Scheduled Trigger” does not. It’s the scheduled triggers I’d like to be able to configure this on.

(Donny Bell) #5

Hi Matthew,

Thank you for getting back to me.

We added this option for Scheduled Triggers in version 2019.10.10 (example screenshot below).

This may be a good excuse to upgrade your version to something newer than 2019.10.10 while you are at it. If you end up upgrading to current. Be sure to check out our Breaking Changes section by hitting the “Show/Hide” button for each major release.

If you have any more questions or run into any trouble during your upgrade process, please let me know. :slightly_smiling_face:

Regards,
Donny

(Matthew Douston) #6

Thank you Donny, that should provide me with a convincing argument to get our instance of Octopus server upgraded!

(Tahir Mehmet) #7

Hi @donny.bell ,

Would the same apply for Octopus Cloud?

Regards,
Tahir

(Donny Bell) #8

Hi tahir.mehmet,

Yes, the same methods would apply to Octopus Cloud. If you have any specific questions, feel free to ask.

Regards,
Donny