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
- 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”
-
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?
-
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:
- Deploy Project1
- Deploy Project2
- 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 |