We have a license in the company and I I have what I think is a common business case, which as far as I know can not be resolved by Octopus? Let me know what you think:
We have multiple projects, APIs, UI, etc. As is common in a multi distributed system, each of them will follow a different channel, and will be deployed to different production servers, once they go through the “common” test and staging servers.
Now what I want is to create a big “Master Release” Project that will promote all these projects to Staging, and then to their subsequent production server.
So I created this “Master Release” project, but as soon as its created, a Life cycle has to be defined. So here is the problem. If I add “Deploy Release Steps”, they have to be deployed to one of the environments of the current Project’s life cycle.
Having into account each of these projects have different Life cycles, how can I surpass this limitation?
Not sure if I am missing something here, but glad if you could help out.
Thanks for getting in touch! Currently the project containing the deploy release step must have a Lifecycle compatible with the releases it is deploying. There is a small section on this in our documentation:
The Lifecycles of project’s being deployed by a Deploy Release step must be compatible with the coordinating project.
For example, if you have two projects,
Project A and
Project B which are referenced by Deploy Release steps in another project Project
Alphabet. When deploying Project
Alphabet to the
Test environment, the release versions chosen for
Project A and
Project B must also be eligible to be deployed to the
Test environment according to the Lifecycles of those projects.
This means you will not be able to use different Lifecycles between your Master Release project and the projects it is deploying a release for. You are still able to use the Channels feature here to automatically define versions for the releases you are deploying, but the Lifecycles must match.
Let me know if you have any further thoughts or questions around this.
Thanks for your reply. That’s exactly what I thought when I read this article: https://octopus.com/docs/deployment-process/projects/coordinating-multiple-projects/deploy-release-step
Now, I’m sure our scenario is a common one. Having into account the concept of a multi distributed architecture model, there is a really low chance that all of the components will be deployed to the same physical servers. That could possibly even mean a really bad design in most of the scenarios. And based on this, it is why this “feature” does not really add any value to the concept of “Coordinating Multiple Projects”.
Could be possible to add a feature for Coordinating Multiple Projects with Different Channels? I think that would really represent a closer version to the reality, where most of the times there is a relationship between projects but that does not necessarily mean there is as well between “Servers”,and you still need to coordinate a multiple release.
It would be something as “As a Release Manager, I want to Orchestrate a Release of multiple Projects that use different Channels” . Obviously there may need to be some restrictions, such as the same number of deployment steps, that’s why It may be a tricky one, but i bet there is a lot of users/companies looking for this feature, as it responds to a common architecture design.
Another “patch” option would be to add a Step: “Promote Project Release to next Project Channel Server” where a release would be promoted to the next server of the “original” Project’s lifecycle.
Let me know if there is a better place to add this feature suggestion.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.