Triggering to release the latest version without a source environment

I am very new to octopus so forgive me for this very basic question. I use Team City to create a new release within Octopus Deploy. But it does not auto deploy to any environments at the time the release is created. I may create several “releases” throughout the day.

Then every night, I want the latest release to be deployed to a given environment. I set up a trigger as in this screenshot.

I do not know what source environment to use. This release has not been deployed to any other environments. It will not let me leave the source environment blank. For now I just put in the same source environment as destination environment.

The trigger does not do anything. No release is deployed even though this environment shows new releases available.

I am obviously missing some important octopus concept. Could you point me in the right direction?

Hi @bsmeyers,

Thanks for getting in touch, and great question! Some unfortunate news here is that the scheduled triggers feature only currently supports a redeploy/promotion of the latest successful release, so if the release in question hasn’t yet been successfully deployed, the scheduled trigger won’t pick it up to deploy to the first environment in your lifecycle. This has been suggested in the past as an enhancement that you can refer to at the following GitHub link.

In the original suggestion thread we mention our recommended workaround be to “setup a scheduled build in TeamCity that deploys the latest release for the project at your preferred time.”

Sorry it’s not the news you were after, but please let us know if you have any further questions or concerns. :slight_smile:

Best regards,

Kenny

Thank you. I appreciate you quick response. It does answer my question. I will have to rethink my approach.

Hi,

Originally I wanted this feature but have since changed how we work with deployments and as it happens it came with a way around this issue. Since the related issue Kenneth linked cause this to pop up in my inbox I figured I’d share my 2 solutions to this problem in the event it can help you out.

Solution 1 - Our Current Setup

Basically in our setup we have a scheduled trigger in Teamcity that builds our project during the night and pushes the build to Octopus. Then in Octopus we have a project that is responsible for deploying our project suit - our ‘orchestration’ project. Each step in this project triggers the deployment of another project, for example:

  • Step 1: Deploy Services Project
  • Step 2: Deploy Website Project

There is built in functionality to support this in Octopus with the ‘Deploy a Release’ step template. When you create a release in the orchestration project and deploy it to an environment it will trigger a deployment of other projects to the same environment using the highest available version. So what you can do is set the trigger on this project and when it runs overnight it will deploy the latest version of your project to the desired environment. You can further use channels to deploy the latest version of a specific release instead. I won’t go into a full explanation of each step since Octopus has some fantastic documentation, the following links should get you started:

Solution 2 - Jank… but it works

This was my original solution to the problem, it’s not amazing but technically works without much overhead. The basic idea is that with the trigger you’re forced to promote from one environment to another and so it expects that the release has been deployed somewhere. But what does ‘deployed’ actually mean, only that all valid steps for an environment have been run. So what we do is create a ‘Staging’ environment and when Teamcity pushes a build to Octopus it is also deployed to this environment. What this allows you to do is promote from the staging environment to anywhere else using the trigger and the same as above you can make use of channels to promote the latest version of a specific release to a target environment.

The important part to this solution is that when you deploy to the staging environment you don’t actually do anything. You create a step in the project you want to deploy that is scoped to the staging environment and you make sure that none of your other steps are valid to run in the staging environment. I suggest a step that runs some basic PowerShell like

Get-Date

This doesn’t do anything, but it will cause Octopus to think that all valid steps for deploying to this environment have been run, allowing you to promote from staging to another environment. Key reading for this solution would be:

  • Understanding Roles
  • Understanding Scope - I couldn’t find an exact page for this but the idea is the same, restrict a step to only be valid in the staging environment. For the normal steps, make sure the machine in staging does not have any other roles assigned to it.

Hope that helps

Tom

Hi Tom,

I just wanted to jump in again to offer a huge thank you for your sharing and great detailing of the solutions you’ve come up with! They sound great, and I want to call them workarounds since I’d consider this a limitation in the scheduled triggers feature. I’m hoping at some point we can offer this enhancement to make it an easier built-in solution.

Best regards,

Kenny

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.