Release Orchestration, can you restrict version by environment?

The questions are based on the example environment below. Thanks in advance for your time!

The orchestration project was created using the example here: Better release management with Octopus Deploy - Octopus Deploy

  1. When creating a new Prod Lifecycle release for the Orchestration project, is it possible to restrict the allowed versions to be the latest from the Test environment? I am aware of restricting versions by channel, but restricting by Environment is what would be desired.

ie; Create a new Prod release for Orchestration with version “1.1.14-RC1”:
Project1 version “1.1.4”
Project2 version “1.1.9”
Project3 version “1.1.14”

The default behavior is to take the latest package version for each Project, which would lead to the unintended default:
Project1 version “1.1.5”
Project2 version “1.1.10”
Project3 version “1.1.15”

  1. Is there anywhere in the UI to be able to view a dashboard for Orchestration projects to see a history view of all of the Orchestration versions and their deployed project versions?

  2. Does it make sense to restrict Staging and Prod release channels separately than Dev & Test? Should Staging & Prod be a part of the Default lifecycle? The intention is to require a separate process to promote projects to staging and then production.

Thanks again!

Example Environment

Projects: Project1, Project2, Project3, Orchestration
Each project has a Default and Prod lifecycle defined.

Orchestration project steps:

  1. Deploy Project1
  2. Deploy Project2
  3. Deploy Project3

Example project states

Default lifecycle
Dev Test
Project1 1.1.5 1.1.4
Project2 1.1.10 1.1.9
Project3 1.1.15 1.1.14
Orchestration
Prod Lifecycle
Staging Prod
Project1 1.0.0 1.0.0
Project2 1.0.0 1.0.0
Project3 1.0.0 1.0.0
Orchestration 1.0.0 1.0.0

Hi Nurrea,

Thank you for reaching out about the step template! Let’s dive into your questions.

  1. That is an interesting question, would it be helpful if the step template was updated to include a version range or exclude anything with pre-release tags?

The only thing I can think off of the top of my head is to provide the release numbers in a variable and scope that to an environment. Or, use prompted variables.

  1. Not specifically in a dashboard no. The only place to view that is on the deployment itself. This is something I wish we could show in a nice easy way.

  2. Yes, that is quite common. However, if you go down that route, you will have to create a new release in your child project (Project1, Project2, Project3, etc.) when you are ready to promote to staging. You cannot change the channel of a release once it is created.

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