I have a question regarding the scoping of variables. I searched the forum but could find anything that solves my problem.
So we have a pretty large project containing several environments, every environment has multiple servers (6-10) and containing over a thousand variables. The enviroment is physically splitted in a backoffice (LOB) and a frontoffice (CONS) and both contain the same applications which are deployed based on role.
Situation:
We have 1 application (login site) which in installed on 2 machines LOB01 and SVC01 and depending on which machine only the variables differ. The codebase is exactly the same so i created 1 step and depending on te roles per machine i hope te fetch the correct variable.
Machines:
LOB01 -> SVC and LOB role
WFE01 -> SVC and CONS role
1 Step:
Creating the Website in IIS and deploy the nuget package
Role -> SVC
This variable is being used as a HTTP-Binding in IIS . So i expect this to show up as a binding to the created website in IIS.
Result:
Now the result is that both servers are configured using the LOB-URL(login-lob.site.nl) and this is not what i expect. I expect them to differ because the CONS variable is more specific because it matches on both CONS and SVC and the LOB-URL should be more specific because of LOB and SVC.
When i add the variables “OctopusPrintEvaluatedVariables” and “OctopusPrintVariables” is can see that only the LOB-URL.
I suspect that the variable only matches on 1 Scope defined on the Machine instead of both is my assumption correct. In that case i have to create Scopes (SVC-CONS and SVC-LOB) but that sounds redundant.
Maybe usefull to add, it is not only SVC we use. There are multiple applications which are added to a “ROLE”. For example SVC, WEB, MOBILE, MGT and both are being deployen on both ends (frontnet and backnet).
For example the Login_URL are different but for example the location are shared:
Thanks for getting in touch. Just to check, which version of Octopus are you using?
When given two variables to pick from, we match by the role that the deployment targets (“SVC” in this case) first, before matching by whatever other roles the machine might happen to have.
So in this case we only match on SVC and ignore the other roles. Then we pick one of those two matches.
I’d agree that if we get multiple matches, we should then go to the next level of trying to see if the machine has any other roles that make it more specific. I have a feeling we may have done this already, but I’m not sure how recently it was.
I got only 1 obvious question. In which version should it be fixed so i can determine to change all the scopes to SVC-CONS and SVC-LOB or wait untill that version is being released.
I did some thinking about the scenarios, and started down the path of tweaking Octopus to work for your scenario. But along the way, I found a few other scenarios that would break if we make variable scoping work the way you need. I wrote a blog post to try and explain:
I’d agree that the examples you gave are pretty intuitive, which is why I originally treated it as a bug report. But when combined with other levels of scoping I think it makes other scenarios much less intuitive.
I hope there’s perhaps a simpler way you can model this; maybe by defining values for the URL’s at environment level, or creating a new role and letting the step target it?
Thanks for your reply. I’ve read your blog and understand it is difficult to implement. I indeed can imagine that simpler is easier especially with this kind of complex features, keeping a matrix will be hard to maintain and also to understand so we will keep it simple and stupid :).
