Comments by KevinAG (Top 5 by date)

At another place I worked, this is the way we did it as well. At that job, we had four environments, development, functional test, beta, and production. Each environment typically had two "NCC" servers, two web servers, and a clustered database server. Our suite of applications used things like MSMQ and every custom service had to be redundant and work well with load balancing.

We then had a naming convention that we used for each server in each environment. dev-ncc1, dev-ncc2, dev-web1, dev-web2, ft-ncc1, ft-ncc2, ft-web1, ft-web2, beta-ncc1, etc...

This would allow for us to create appSettings keys like:

<add key="RefreshCacheIntervalSeconds" value="60"/>
<add key="[dev-web*]RefreshCacheIntervalSeconds" value="10"/>

So while developing, the RefreshCacheIntervalSeconds would have a value of 10, but everywhere else, it would have a value of 60.

This would also allow you to take things a step further and have:

<add key="[dev-web1]RefreshCacheIntervalSeconds" value="10"/>
<add key="[dev-web2]RefreshCacheIntervalSeconds" value="20"/>
<add key="[ft-web1]RefreshCacheIntervalSeconds" value="30"/>
<add key="[ft-web2]RefreshCacheIntervalSeconds" value="40"/>

if there was a setting that needed that kind of fine grained control.