Azure devops 将变量组移动到代码存储库，并从YAML管道引用它

我们正在寻找如何将非机密变量从变量组移动到代码存储库的解决方案。 我们希望有以下可能性：

• 跟踪代码存储库中所有设置的更改
• 变量的版本值连同源代码、管道代码版本

---

问题： 我们定义了100多个变量组，这些变量组被100多个YAML管道引用。 它们在不同的管道/阶段/作业级别注入，具体取决于它们所处的环境/组件/阶段

示例问题：

• 一些变量可以更改其名称，一些变量可以删除，并且在针对PROD环境的管道中仍然引用该变量，而在部署到DEV上的管道中则不存在该变量
• 特定的管道运行在过去某个日期使用了变量的版本，最好知道它在过去部署了什么设置

---

可能的解决方案：

应该可以使用简单的yaml模板变量文件来模拟变量组，并使用以下方法将带有变量组的yaml模板包含到主yaml中：

理论上，将变量组转换为YAML模板文件并从YAML引用它们应该很容易，而不是使用对变量组的引用

# Current reference we use
variables:
- group: "Current classical variable group"

但是，即使没有实现这种方法，我们在管道中也达到了以下限制：“可能包含的单独YAML文件不超过100个（直接或间接）”

考虑到我们希望变量组在逻辑上被粒度化和分离，而不是存储在一个大的yml文件中（为了不使作业代理中的变量数量达到另一个限制），我们不能这样做

第二种方法是添加一个简单的脚本（PowerShell？），该脚本将使用一些包含变量（variableName/variableValue）记录的键/值元数据文件，只需使用命令执行作业步骤即可

但作为第一步，它只能在初始工作级别完成，而且它看起来像是Azure DevOps中本机提供的重新设计变量组机制

当当前使用变量时，我们不确定这种方法是否适用于YAML管道中的任何地方。在某个地方，它们作为参数传递给任务。等等

是否将所有变量移动到密钥库中？我们一开始就放弃了这个选项，因为密钥库是存储敏感数据的地方，而不是任何人都可以看到的设置。此外，将其存储在机密中会导致管道日志放置*而不是实际的配置设置，并混淆管道运行日志信息

---

问题：

问题1。关于如何在Azure DevOps YAML管道中实现变量版本控制/更改跟踪，您还有其他建议/备选方案吗

---

问题2。你认为这2个方面有什么问题吗。可能的解决方案，或者有更好的想法？

< P>你可以认为这是替代方案：

将非机密变量存储在存储库中的json文件中

创建要将变量推送到的管道（而不是Vault）

然后，如果您的应用程序中需要此设置，请确保从应用程序引用应用程序配置，而不是在Azure Devops中运行替换任务。或者，如果需要通过管道直接进行此设置

缺点：

• 与您在Powershell案例中提到的相同。你需要在工作层面上做到这一点

你得到的是：

• 回购中的轨道
• 跟踪应用程序内配置和应用程序的所有好处

---

这个问题如何？下面的答案是否解决了您的问题？如果没有，请告诉我有关此问题的最新信息。我想等待其他建议，因为下面的建议不仅仅是将变量组移动到代码库中，还包括代码修改（配置提供程序）适用于系统中的所有应用程序。这是一个很好的替代方案，但它需要修改数十个Web应用程序、FunctionApp、数十个存储库（ConfigurationProviders区域）中的控制台应用程序中的源代码，修改我们当前传递应用程序设置的数十个arm模板，同时，在数以百计的YAML模板中进行了更多的更改，而不仅仅是将当前的组变量引用替换为新的内容。我们不仅将变量用作应用程序设置，还将变量用作ARM模板、脚本参数、元数据令牌替换的基础结构配置。是的，没错。这完全取决于你们的系统有多复杂。我认为这里的好处是慢慢开始，首先可以做的是更改应用程序并将其配置移动到AppConfiguration中。这将带来很多好处。当它发生时，变量组的数量可能会减少，这样你就可以成功地应用你的想法。所以这里的解决方案可能不是单一的方法，而是它们的混合。是的，我知道这是巨大的变化。但是，在复杂系统中，跨应用程序的一切有时都是巨大的。

# Current reference we use
variables:
- group: "Current classical variable group"

##vso[task.setvariable variable=one]secondValue.