0

I'm using DevOps to deploy Azure Data Factory ARM template

I'm using a deployment pipeline to take artifacts from a prior build pipeline and deploy to various environments (TEST, PROD)

I've created two variable groups: TEST and PROD. I've created two deployment "stages" TEST and PROD

Within the TEST variable group I've created a bunch of variables reflecting the TEST specific configuration.

As far as I understand, I now have to manually recreate all of these identically named variables in my PROD variable group.

Not only that I have to make a copy of my TEST stage

So I basically have two duplicate configs and two duplicate stages

It would make more sense if I had a single stage definition that could be run against different variable groups rather than repeating code and variable group definitions.

It seems strange and redundant to have to do this. I also find it strange that the concept of environments is not specifically called out in doco anywhere

So the specific question is: Is it the correct approach to define a variable group per environment then manually create identical variables in both variable groups?

and a more general question: am I missing something fundamental here or is the product not mature enough yet.

I have not used any other deployment tool in any detail before this and I'm not using YAML (just the UI) so maybe that's the piece I'm missing.

Another "What Am I missing" thing:

In the Resource Group deployment task in the override template parameters field I used the UI to assign variables to parameter values. I had to type the variables in and had to make sure I got the magic notation right. $(myVariable) Then I read another stack overflow that indicated if your variable value has a space in it you need to surround it by quotes. This is the second "you need quotes for spaces" issue I have found.

  • LOL this question got a tumbleweed badge. Thanks guys! Is it echoing in here? – Nick.McDermaid Jun 20 at 0:07
0

My understanding of the variable groups is that you would create this to leverage the same variables across multiple pipelines. If you needed to update the value, you'd only have to update it on the library instead of updating it on dozens of pipelines. If you are only going to use the variable group on a single pipeline definition, variables groups appear to be overkill.

If you have concerns about duplicating code and maintaining the exact same deployment steps across your stages, I would recommend you group them into a task group. That way you can manage versioned updates and will also have it reflected across all pipelines and stages where it is referenced.

I think you would have some name resolution issues if you tried to use the different variable groups that have the same name on a single pipeline. Instead, you should probably leverage the variable scope on the pipeline. It will grab the appropriate value staged to the scope you are executing.

enter image description here

  • Thanks for your response. Since then I've discovered task groups and they look good. Now my only (minor) concern is that I have to recreate the same named variables across variable groups. Like if I have four logging servers across four environments, I have to create a variable in each variable group called MyLoggingServer. I guess I'm looking for some kind of variable template or something. – Nick.McDermaid Jul 3 at 6:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.