Assign machines to a channel
We have a situation in which we need to restrict the deployment of version N+1 builds from deploying to version N environments. It would be very useful if we could use channels to restrict which machines get deployed to from a given channel. Currently, we have to create a new environment group (future.stack, hotfix.dev, etc), add deployment targets to the new env. group, create a lifecycle to reflect and then assign it to the channel.
Will Metcalf
shared this idea
-
This behaviour could perhaps be achieved using the new Multi-Tenancy feature provided in Octopus Deploy 3.4 (http://docs.octopusdeploy.com/display/OD/Multi-tenant+deployments)
In this scenario you can create a seperate Tenant for each of your hotfix builds, which specific machines scoped to each Tenant. Using Channels also scoped to each Tenant, you can then create and deploy releases with confidence that specific builds, as defined by the version range or tag information, only go to specific machines. In this approach you can keep your list of environments to a minimum.
Using tenants and scoping machines to tenants, means that only deployments for that tenant will be able to go to that machine.
Is there anything with this approach that you think wouldn't achieve the goals proposed by this suggestion?
-
Will Metcalf
commented
Your understanding of my ask is correct. We develop an enterprise system with a server web app being the center point. We operate on a System Release basis in that the version of the server directly correlates to the version of the clients with limited backwards compatibility between system releases. Good or bad, that's the current model. Channels was a great feature for us working under this model. However, by being able to assign specific machines to channels, it will create the safety you spoke of much and make SR based deployments much easier than creating the environments/lifecycle in the current design. I read on the multi tenancy feature and will take a look when it's released. It may provide us with what we need.
-
Michael Noonan
commented
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!
