Feature Request: Hierarchical variables

Legacy Uncategorised
1

I was just reading some of the questions posted here about having to declare variables for every package. This got me to thinking that there should be a better way to manage that sort of thing. One possible solution would be a hierarchical key/value store for variables. For instance, a variable declared at the server level would be available for use by all projects, packages, etc… and could be overwritten per project or per package as necessary with the overridden value applying to everything below it in the hierarchy.

See below for a fairly contrived example.

Server (ex. Company name specified here?)
|->Project 1 (ex. Project name specified here to apply for all environments)
|     |->Environment 1 (ex. connection strings by name here to apply for all packages)
|     |     |->Package 1
|     |     |->Package 2
|     |->Environment 2 (ex. connection strings by name here to apply for all packages)
|           |->Package 1
|           |->Package 2
|->Project 2 (ex. Project name specified here to apply for all environments)
|     |->Environment 1 (ex. connection strings by name here to apply for all packages)
|     |     |->Package 1
|     |     |->Package 2
|     |->Environment 2 (ex. connection strings by name here to apply for all packages)
|           |->Package 1
|           |->Package 2
2

Guess i should have previewed before submitting…
use the |'s as tree connection indicators

3

Thanks a lot for the suggestion Matthew (I edited your post to get the formatting back).

I like the idea of server-level variables and environment-level variables. It might be a better way to manage the current override system that I have now.

One of the features I’m implementing soon is variable substitutions - for example, you could have these 3 variables:

Server = "localhost"
Database = "MyDB"
ConnectionString = "Server=@{Server};Database=@{Database}"

That, plus your idea of hierarchical variables, would change the dynamics around how variables are managed.

There are some competing issues that have to be worked out though. For example, when you create a release, it’s important for a “snapshot” of the variables to be created so that you always have a record of the configuration. Currently variables only exist at a project level so that’s no problem, but it would be harder if they existed at an environment level.

I’ll add this to the backlog and give it some though. It’s certainly a nice way to think about variables. Thanks for the suggestion.

Paul