Deploy Release Step variable management

[critchley.sj]

Hello,

I’m breaking up my monolith into into different independent deployments. I’m trying to create a parent project that will deploy n of these releases with some overhead management in the parent project. Currently all my variables are in library variable sets, split up by env. What I wanted/thought I would be able to do was just add those same library variable sets to the parent project and that they would be passed into the deploy release target but they are not.

Instead it seems to want me to manually retype all the variable names and reference them via interpolation in the value. In my case that is a total show stopper. First it adds an entire other list of variables i have to maintain, second its broken as soon as the master list is updated, thirdly i have dozens and dozens of these things!! Some dont exist in certain envs.

I’m sure there are some scenarios were this is just fine… but really in any case I can think of where I want to share common values from the parent to several sub-project this just feels like pain/more work.

Could we get an option to just import and forward every (non system) parameter to the target project? Either just a import all checkbox, or a variable name mask and/or clicking library variable sets to include (that have already been added to the project).

Alternatively is there a way I can do the same thing from a step script (without resorting to calling octo.exe and triggering a deploy via rest).

[critchley.sj]

I noticed that when i turn on output variable printing Deploy Release steps have none of the variables they contextually should (apart from the system ones).

[Michael_Richardson]

Hi Sam,

The idea of passing all variables into the triggered deployment is an option. We just want to make sure we’ve exhausted other approaches first.

Currently all my variables are in library variable sets, split up by env.

Can I ask why you split your variable sets up by environment. Why not have a single variable-set, and have the values within it scoped to the environment.

For example, you have:

Variable Set: Env-A
Variable Name: AzurePassword
Variable Value: s23fl23#45f!

Variable Set: Env-B
Variable Name: AzurePassword
Variable Value: dg4g43$^fgasdf

Instead, why not:

Variable Set: Azure

Variable Name: AzurePassword
Variable Value: s23fl23#45f!
Variable Scope: Env-A

Variable Name: AzurePassword
Variable Value: dg4g43$^fgasdf
Variable Scope: Env-B

This way you could just link the one variable set to your child projects. Would this work?

I don’t believe you will be able to achieve this from a script step.

[critchley.sj]

Hi Michael,

the reason for the split was simply that (at the time) I couldn’t filter the view by env and it was really hard on the eyes managing a list containing every value at once.

I see I can now filter the list by scope.