Wie kann ich IF ELSE in Variablen der Azure DevOps Yaml-Pipeline mit Variablengruppe verwenden?

Ich versuche, einer Variablen zusätzlich zur Variablengruppe einen von zwei Werten zuzuweisen, und kann die Referenz zur Verwendung von IF ELSE nicht finden.

Grundsätzlich muss ich diese Wamslogik in azurblaue DevOps konvertieren.

Jenkins

if (branch = 'master') { 
   env = 'a'
} else if (branch = 'dev'){
    env ='b'
}

Ich habe 1 Referenz aus der folgenden gefunden, aber diese scheint zu funktionieren, wenn der Variablenabschnitt keine Variablengruppen enthält.

https://stackoverflow.com/a/57532526/5862540

Aber in meiner Pipeline habe ich bereits eine Variablengruppe für Geheimnisse, daher muss ich die Name / Wert-Konvention verwenden und das Beispiel funktioniert nicht mit den Fehlern wie expected a mappingoder A mapping was not expectedoderUnexpected value 'env'

variables:
- group: my-global
- name: env
  value:
    ${{ if eq(variables['Build.SourceBranchName'], 'master') }}: 
      env: a
    ${{ if eq(variables['Build.SourceBranchName'], 'dev') }}: 
      env: b

oder

variables:
- group: my-global
- name: env
  value:
    ${{ if eq(variables['Build.SourceBranchName'], 'master') }}: a
    ${{ if eq(variables['Build.SourceBranchName'], 'dev') }}: b

Ich denke, für den Moment müssen Sie eine Aufgabe verwenden, um sie mit name/valueSyntaxvariablen und bedingten Variablenwerten anzupassen. Es sieht so aus, als ob die Objektstruktur für die name/valueSyntax das Parsen von Ausdrücken unterbricht, wie Sie bereits betont haben.

Für mich ist das Folgende eine einigermaßen saubere Implementierung, und wenn Sie es von der Pipeline abstrahieren möchten, sollte eine einfache Vorlage für Ihre vielen Pipelines den Wunsch nach einem zentralen "globalen" Standort befriedigen.

variables:
  - group: FakeVarGroup
  - name: env
    value: dev

steps:
  - powershell: |
      if ($env:Build_SourceBranchName -eq 'master') {
        Write-Host ##vso[task.setvariable variable=env;isOutput=true]a
        return
      } else {
        Write-Host ##vso[task.setvariable variable=env;isOutput=true]b
      }      
    displayName: "Set Env Value"

Soweit ich weiß, ist der beste Weg, um eine bedingte Verzweigung zu erstellen, die Verwendung von "Trigger" in Ihrer YAML, anstatt ein komplexes "if-else" zu implementieren. Es ist auch viel sicherer und Sie haben explizitere Steuerelemente für die Verzweigungsauslöser, anstatt sich auf CI-Variablen zu verlassen.

Beispiel:

# specific branch build 
jobs:
- job: buildmaster
  pool:
    vmImage: 'vs2017-win2016'
  trigger:
    - master

  steps:
  - script: |
      echo "trigger for master branch"

- job: buildfeature
  pool:
    vmImage: 'vs2017-win2016'
  trigger:
    - feature

  steps:
  - script: |
      echo "trigger for feature branch"

Um einen Trigger mit Einschluss und Ausschluss von Zweigen zu haben, können Sie eine komplexere Syntax des Auslösers mit Einschluss und Ausschluss von Zweigen verwenden.

Beispiel:

# specific branch build
trigger:
  branches:
    include:
    - master
    - releases/*
    exclude:
    - releases/1.*

Die offizielle Dokumentation zu Azure DevOps-Pipelines triggerin YAML lautet: Dokumentation zu Azure Pipelines YAML-Triggern

UPDATE 1 :

Ich poste meinen Kommentar hier mit zusätzlichen Anmerkungen: Ich dachte, ich hätte verschiedene Pipelines, weil die Komplexität des Jonglierens zwischen CI-Variablen nicht besser zu warten ist als mehrere Jobs in einer YAML mit Triggern. Multijobs mit Triggern zwingen uns auch dazu, eine klare Unterscheidung und Bereitstellung für das Filialmanagement zu treffen. Auslöser und bedingte Verzweigungseinschlüsse werden von meinem Team aufgrund dieser Wartbarkeitsvorteile seit einem Jahr verwendet.

Sie können dem gerne widersprechen, aber für mich ist es eher eine Ad-hoc-Lösung, wenn in einem Skript eine eingebettete Logik vorhanden ist, um zu überprüfen, welcher Zweig sich gerade in der Sitzung befindet und dann weitere Aktionen ausführt. Und das hat meinem Team und mir schon früher Wartungsprobleme bereitet.

Insbesondere wenn die eingebettete Logik dazu neigt, durch Überprüfen anderer Zweige zu wachsen, ist die Komplexität später komplexer als klare Trennungen zwischen Zweigen. Auch wenn die YAML-Datei für längere Zeit aufbewahrt werden soll, sollte sie klare Bestimmungen und Roadmaps für verschiedene Branchen enthalten. Redundanz ist unvermeidlich, aber die Absicht, bestimmte Logik zu trennen, zahlt sich auf lange Sicht mehr für die Wartbarkeit aus.

Deshalb betone ich in meiner Antwort auch Ein- und Ausschlüsse von Zweigen :)