最简单的方法是将Azure DevOps（ADO）环境变量值传递到键中，如下所示：

- task: DotNetCoreCLI@2
  displayName: 'Run tests'
  env:
    SAUCE_USERNAME: $(sauceUsername) #this will store the value from 'sauceUsername' into SAUCE_USERNAME
    SAUCE_ACCESS_KEY: $(sauceKey)

如果您尝试显示或使用该值，则会有效

- bash: echo $(SAUCE_USERNAME) # will output our username stored in SAUCE_USERNAME env variable

如果您在代码中引用SAUCE_USERNAME，代码将从Azure服务器获取值。
这篇文章有很好的解释

以前，我也使用过Powershell，但这种方法更复杂：

1.在Azure DevOps管道中创建变量，并为这些变量提供值。
1.创建一个Powershell脚本，您将在开始时运行它来设置您的Env Variables. This is我的Posh看起来像什么。
1.在开始时作为CI管道中的一个单独步骤运行此Posh，这将为用于运行管道的VM设置环境变量。
这是另一个detailed article，它可以帮助您实现这一点。
根据要求，我还附加了PowerShell代码，使这成为可能。

Param(
[string]$sauceUserName,
[string]$sauceAccessKey,
[string]$sauceHeadlessUserName,
[string]$sauceHeadlessAccessKey
)
Write-Output "sauce.userName that was passed in from Azure DevOps=>$sauceUserName"
Write-Output "sauce.accessKey that was passed in from Azure DevOps=>$sauceAccessKey"
Write-Output "sauce.headless.userName that was passed in from Azure DevOps=>$sauceHeadlessUserName"
Write-Output "sauce.headless.access.key that was passed in from Azure DevOps=>$sauceHeadlessAccessKey"

[Environment]::SetEnvironmentVariable("SAUCE_USERNAME", "$sauceUserName", "User")
[Environment]::SetEnvironmentVariable("SAUCE_ACCESS_KEY", "$sauceAccessKey", "User")
[Environment]::SetEnvironmentVariable("SAUCE_HEADLESS_USERNAME", "$sauceUserName", "User")
[Environment]::SetEnvironmentVariable("SAUCE_HEADLESS_ACCESS_KEY", "$sauceAccessKey", "User")

我尝试使用上面答案中建议的以下两种语法，但是当尝试在管道中更后面的任务中使用环境变量时（比如在构建期间或运行测试时），环境变量总是空白的。

[Environment]::SetEnvironmentVariable("SAUCE_USERNAME", "$(sauceUserName)", "User")

variables:
  sauceUserName: '$(sauceUserName)'

对我有效的是使用该语法在内联PowerShell脚本任务中编写Azure DevOps变量：

- task: PowerShell@2
  displayName: Add the username as an environment variable so the tests can find it.
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "Making the sauceUsername available as an environment variable."
      Write-Host "##vso[task.setvariable variable=SAUCE_USERNAME;]$(sauceUserName)"

然后我的构建任务就能够找到环境变量，而且我还可以在管道中的PowerShell脚本任务中访问它，代码如下：

- task: PowerShell@2
  displayName: Display the environment variable value for debugging purposes.
  inputs:
    targetType: 'inline'
    script: |
      [string] $username= $Env:SAUCE_USERNAME
      Write-Host "The SAUCE_USERNAME environment variable value is '$username'."

设置pipeline变量，然后在yaml文件中尝试以下Map：

# ASP.NET Core (.NET Framework)
# Build and test ASP.NET Core projects targeting the full .NET Framework.
# Add steps that publish symbols, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core

pool:
  vmImage: 'VS2017-Win2016'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  yourEnvVar: '$(yourPipelineVariable)'
  yourOtherEnvVar: '$(yourOtherPipelineVariable)'

我们与此斗争了几个小时，以为这是由于不能设置环境变量，但最终与此无关。
以下是我们在尝试为Azure DevOps解决这一问题时的一些注意事项：

• 管道变量是环境变量，在流程的第一步注入到管道中。您可以通过查看Initialize job任务的日志来确认这一点，该日志列出了所有环境变量。
• 为了证明管道变量在系统中，您可以添加一个powershell任务并内联：

Write-Host "Pipeline Variable: $(FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD)"
Write-Host "Environment Variable: $Env:FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD"

• 如果要在某处使用管道变量，则管道变量周围的()是critical，例如$(myVar)

这与用户的问题无关，但可能对那些尝试使用双因素身份验证（2FA）上传到AppStore的用户有帮助。

• 我们不得不设置FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD和FASTLANE_SESSION，以使其绕过2FA。我们认为会话1允许我们登录AppStoreConnect，但上传时使用了应用程序特定的密码。日志似乎暗示了这一点，但您从未看到使用的会话变量。

如此处所定义，应在步骤/任务环境变量部分中显式设置Secret变量

要传递在YAML外部定义的变量，请务必不要在YAML中定义变量，因为YAML中的变量将优先于外部变量。
定义变量后，可以使用语法$（variablename）在内联powershell脚本中引用该变量，但变量名称必须大写
根据devops提示：要在脚本中使用变量，请使用环境变量语法。将.和空格替换为_，将字母大写，然后使用平台的语法引用环境变量。
如果您需要使用环境变量（例如secrets）来Map它，那么正确的语法是：

script: |
          write-host "env $env:myvariable"

      env:
        #not sure if case matters here
        myvariable: $(myvariable)

完整示例：

- task: PowerShell@2
          inputs:
            targetType: 'inline'
            script: |

              #log the mapped variable, case doesn't matter
              write-host "env $env:myvariable"

              #directly access pipeline variable, CASE MATTERS!
              write-host "pipeline $(MYVARIABLE)"

              #show all environment variables
              get-childitem env:
          env:
            #not sure if case matters here
            myvariable: $(myvariable)