Settings and activity
5 results found
-
7 votes
An error occurred while saving the comment -
11 votes
An error occurred while saving the comment 
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!
-
3 votesMichael Noonan
shared this idea
·
-
2 votes
An error occurred while saving the comment -
4 votes
An error occurred while saving the comment
Just thought I'd point you to a recent discussion on snapshots so you can add your voice to the conversation: https://octopus.com/blog/rfc-removing-snapshots Hope that helps!