Interesting idea. Just confirming, this is to create safety, so you don't accidentally deploy 2.x into any machine(s) that are designated 1.x?
Our current design, like you mentioned, is to create a new Environment and Lifecycle to provide that safety. One reason for this is there is an existing mapping from Machine -> Environment -> Lifecycle -> Project -> Channel, because Channels "belong" to a Project.
So when you want to restrict a Machine to one (or more?) specific Channels, we would need to map Machine -> Project -> Channel, which could leave room for confusion with the other potential mappings, like Roles.
I like the idea, that when you're creating a new machine, you know the purpose you intend for that Machine, and it's a good idea to stamp that Machine with its "purpose". (We are allowing something similar for multi-tenancy - see https://octopus.com/blog/rfc-multitenancy-take-two#deployment-targets-and-accounts)
Could you have a think about your situation and let me know how you would expect this to work, perhaps with a mockup which would really help illustrate!
5 votesMichael Noonan shared this idea ·
We have recently made good progress on getting Tentacle running on Linux via netcore and expect it to be available in the next couple months. https://github.com/OctopusDeploy/Issues/issues/3596
As for Octopus Server on Linux, we have also started working on this effort however the current focus is for internal use for running Hosted Octopus. There are some additional complications that come with running Octopus on Linux particularly in the context of “run on the server” and s a result I wouldn’t expect a version of this to be available until mid-year at the earliest.
Most of our other additional tooling and libraries like Calamari are now available to be run on netcore and run on Linux.
Porting Tentacle/Calamari to .NET Core would enable deployments on Windows Nano Server also.