Hello I’m looking for advice.
I have application package that has inside service and desktop app.
It has 30 targets to deploy in total. 10 of them are services and 20 are desktop.
I wanted to create 2 different prd channels inside one project to organize the targets.
So one channel has one lifecycle for services and other channel has different lifecycle for desktop.
Everything was looking great till I wanted to create release.
In project settings i set that my package version = octopus deploy version.
So I created a release for services channel 1.0.0
Then I wanted to create release for desktop channel and here is the problem.
Octopus does not allow me to use same version 1.0.0 that is used in services channel it shows that I need to write for example 1.0.1
It’s the same package for both channels it should have same version.
Both services and desktop app have same variables I don’t want to create second project and duplicate it.
Is this possible to somehow set that one channel can’t have same version twice but allow same version for different channels?
Greetings @fragir, thanks for reaching out. I would like to know a little more about what you’re doing as I see there could be multiple ways of solving this. Are the lifecycles very different? Are there any steps that are the same between the service(s) and the desktop? Are they related to each other as in one cannot be deployed without the other?
Regards,
Shawn
Hello @Shawn_Sesna thank you for your message.
Lifecycle 1 for desktop, one phase with 20 different from lifecycle 2 production targets nothing more.
Lifecycle 2 for services, one phase with 10 different from lifecycle 1 production targets nothing more.
Channel 1 = Lifecycle 1
Channel 2 = Lifecycle 2
One same package for both.
Steps are different for Lifecycle 1 and Lifecycle 2 but just have them in same project because both use most of the same variables and don’t wanted to duplicate them cos there’s a lot of them and it would be hard to manage.
Now when I wrote this I’m thinking maybe I should create another project and use Library sets maybe this might just work like this.
Hey there @fragir! The phrase “great minds think alike” would apply here 
The recommendation I was leaning towards was exactly as you suggested, however, wanted to get more details first before making it 
Taking this approach will also make it more manageable should there be a need for project-specific variables down the line.
The final piece that I was going to recommend would be release orchestration. With splitting the projects up, you are now able to deploy the components individually, release orchestration provides a method of deploying everything together. Does that make sense?
Regards,
Shawn