Variable Scoping Precendence

mpeterson · 12 February 2015 21:03

Hi,

We are in the process of switching servers over from 2008 to 2012. As such and with our test team wanting to validate the differences between them, I have two different hostnames for the sites. However they are both in the same environment.

So for scoping the variable, I left the one that had previously been scoped to the environment as is. Example: Environment: Dev
For the new one, I scoped it as follows: Environment: Dev, Machines: MySecondDevServer

Now obviously since I’m being specific to a machine I wouldn’t need “dev” for environment on the this item, however at some point, I would prefer just to remove the machine specific item since that is likely to be the one I keep and it seems to help somewhat in sorting and it doesn’t seem as though it should hurt anything other than being redundant.

However, what is ending up happening is that my config is picking up the Environment specific setting only. I’m wondering if it is an issue of precedence, and if
A) There is a listing of order of precedence in evaluating variables (Didn’t see anything specific on the documentation page although it seems to be hinted at)
B) There is a way to do what I’m trying to do without having to switch to listing by individual machines.

Vanessa_Love · 17 February 2015 05:06

Hi Mike,

Thanks for getting in touch! Sorry about the delay in getting back to you.
My suggestion would be to create a second Dev environment (such as Dev2012) and as you switch each server move it into the new environment. With Lifecycles you can now deploy to both at once so it would assure that the variables are being correctly evaluated. It might also help to know at a glace what has been moved and what hasn’t.

Seems slightly easier than scoping per machine. What do you think?
Vanessa

mpeterson · 17 February 2015 15:13

As for whether it’s easier, that’s only part of the question (additionally web transforms would have to change to reference the new environment).

If I have a whole dev environment and I have one machine I find that I need to change the variables on, does that mean I need to move that machine out of the dev environment OR individually include all machines (rather than specify “Dev” for an environment and then for the variable I want different, also specify machine?)

Example: Machines 1-5
Environment: Dev
Binding: mycodedev.mydomain.com

Environment: Dev
Machine: MyPOCBox
Binding: mycode.dev.mydomain.com

In that example from what I’ve seen “Dev” seems to be what evaluates last which seems faulty, both based on what I would expect and what the documentation seems to suggest. I’m not sure how “Role” and “Step” fit into the pyramid of precedence (more or less specific), but a machine would definitely seem more specific than an enviroment.

Past that even if I then do this, it doesn’t make anything better because it will still fall into dev above:

Environment:
Machine: MyPOCBox
DirectoryToInstall: C:\inetpub\mycode\subcode

Vanessa_Love · 19 February 2015 06:33

Hi Mike,

Yeah, you are totally right about the environment for configs.
So how about a role instead? if say those machines have a web-server role you could make a new web-server2012 role for the new machines. Then you just need to add the role to the corresponding steps and make 1 new variable without continually scoping a new machine.

This is the precedence (from our documentation):

Since variables can be scoped in many different ways, there needs to be a predictable, deterministic order in which they are resolved. The list below is the priority in which variable scopes take precedence - the top items are considered higher priority than the bottom ones:
The current step/action (most specific)
The current machine
Roles applied to the current machine and targeted by the current step
Roles applied to the current machine
The target environment
No scope (least specific)

So I will test the scenario you described because the machine should have overwritten that variable.

Vanessa

mpeterson · 2 March 2015 19:40

OK, I can definitely confirm that this was happening. I’m going to have to try to reproduce because I needed to fix it when it happened. And to be honest I’m not sure the best way to pass this information on to you.

The scenario I had was similar to this:
variable1, value: 1st value, scope: environment: Dev, QA, Performanance
variable2, value: 2nd value, scope: environment: Dev, QA, machines: 2012DevServer, 2012QAServer

I’m wondering if it’s a case where adding the environment in the second case messes things up. Because technically what I’m trying to do is override it for that specific machine, not all of Dev or QA (but I initially added those because that is where those boxes are and it seemed to make sense to scope them), and because Octopus sees Dev/QA again listed it says “Hey we’ve already got one of these” and dumps the second occurrence.

-Mike

Vanessa_Love · 3 March 2015 03:41

Hi Mike,

I’ll try my hardest to replicate this and see what I can find. What specific version are you running?

Vanessa

mpeterson · 3 March 2015 16:47

I created a test project, created a “ThisIsATest” variable and web.config app setting. Set it to “DefaultValue” in the web.config. In the variables section, I made 2 line entries for “ThisIsATest”, set one to “Value1” and the other to “Value2”. Uploaded a package with just the web.config and then tried switching the scopes as such.

ThisIsATest – Value1 – Machine: Server1, Environment: Dev
ThisIsATest – Value2 – Machine: Server2, Environment: Dev

On machine 1, the value was transformed to Value1 and on machine 2, the value was transformed to Value2.*

ThisIsATest – Value1 – Machine: Server1, Environment: Dev
ThisIsATest – Value2 – Environment: Dev

On machine 1, the value was transformed to Value1 and on machine 2, the value was transformed to Value2.*

ThisIsATest – Value1 – Environment: Dev
ThisIsATest – Value2 – Machine: Server2, Environment: Dev

On machine 1, the value was transformed to Value1 and on machine 2, the value was transformed to Value2.*

ThisIsATest – Value1 – Machine: Server2, Environment: Dev
ThisIsATest – Value2 – Environment: Dev

On machine 1, the value was transformed to Value2 and on machine 2, the value was transformed to Value1.*

ThisIsATest – Value1 – Environment: Dev
ThisIsATest – Value2 – Machine: Server1, Environment: Dev

On machine 1, the value was transformed to Value2 and on machine 2, the value was transformed to Value1.*

So the theory below doesn’t seem to be right and none of the iterations seem to cause issues. I’ll have to figure out what was different from what I initially had on the actual project.

- This is checking both the output from Octo and the actual values on the server

mpeterson · 3 March 2015 17:29

Realized I forgot to include version 2.6.2.845