Bereitstellungsaufträge

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Wichtig

• Auftrags- und Phasennamen dürfen keine Schlüsselwörter enthalten (Beispiel: deployment).
• Jeder Auftrag in einer Phase muss einen eindeutigen Namen haben.

Für YAML-Pipelines empfehlen wir Ihnen, Ihre Bereitstellungsschritte in einem speziellen Auftrag anzuordnen, der als Bereitstellungsauftrag bezeichnet wird. Ein Bereitstellungsauftrag ist eine Sammlung von Schritten, die nacheinander für die Umgebung ausgeführt werden. Ein Bereitstellungsauftrag und ein herkömmlicher Auftrag können in der gleichen Phase vorhanden sein. Azure DevOps unterstützt die Strategien runOnce, rolling und canary .

Bereitstellungsaufträge haben folgende Vorteile:

• Bereitstellungsverlauf: Sie erhalten einen pipelineübergreifenden Bereitstellungsverlauf bis hin zu einer bestimmten Ressource und zum Status der Bereitstellungen für die Überwachung.
• Anwenden einer Bereitstellungsstrategie: Sie definieren, wie das Rollout Ihrer Anwendung ablaufen soll.

Ein Bereitstellungsauftrag klont nicht automatisch das Quellrepository. Sie können das Quellrepository in Ihrem Auftrag mit checkout: self auschecken.

Hinweis

Dieser Artikel konzentriert sich auf die Bereitstellung mithilfe von Bereitstellungsaufträgen. Informationen zum Bereitstellen in Azure mit Pipelines finden Sie unter Bereitstellen in Azure: Übersicht.

Schema

Hier sehen Sie die vollständige Syntax für die Angabe eines Bereitstellungsauftrags:

jobs:
- deployment: string   # name of the deployment job, A-Z, a-z, 0-9, and underscore. The word "deploy" is a keyword and is unsupported as the deployment name.
  displayName: string  # friendly name to display in the UI
  pool:                # not required for virtual machine resources
    name: string       # Use only global level variables for defining a pool name. Stage/job level variables are not supported to define pool name.
    demands: string | [ string ]
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  dependsOn: string
  condition: string
  continueOnError: boolean                # 'true' if future jobs should run even if this job fails; defaults to 'false'
  container: containerReference # container to run this job inside
  services: { string: string | container } # container resources to run as a service container
  timeoutInMinutes: nonEmptyString        # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: nonEmptyString  # how much time to give 'run always even if cancelled tasks' before killing them
  variables: # several syntaxes, see specific section
  environment: string  # target environment name and optionally a resource name to record the deployment history; format: <environment-name>.<resource-name>
  strategy:
    runOnce:    #rolling, canary are the other strategies that are supported
      deploy:
        steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

Es gibt eine detailliertere, alternative Syntax, die Sie auch für die environment-Eigenschaft verwenden können.

environment:
    name: string # Name of environment.
    resourceName: string # Name of resource.
    resourceId: string # Id of resource.
    resourceType: string # Type of environment resource.
    tags: string # List of tag filters.

Für virtuelle Computer müssen Sie keinen Pool definieren. Alle Schritte, die Sie in einem Bereitstellungsauftrag mit einer VM-Ressource definieren, werden für diesen virtuellen Computer und nicht für den Agent im Pool ausgeführt. Für andere Ressourcentypen wie Kubernetes müssen Sie einen Pool definieren, damit Aufgaben auf diesem Computer ausgeführt werden können.

Bereitstellungsmethoden

Wenn Sie Anwendungsupdates bereitstellen, ist es wichtig, dass folgende Technik zum Bereitstellen des Updates verwendet wird:

• Aktivieren der Initialisierung.
• Bereitstellen des Updates.
• Weiterleiten des Datenverkehrs an die aktualisierte Version.
• Testen der aktualisierten Version nach dem Weiterleiten des Datenverkehrs.
• Wenn ein Fehler auftritt, führen Sie Schritte zum Wiederherstellen der letzten bekannten fehlerfreien Version aus.

Dies wird mithilfe von Lebenszyklushooks erreicht, die Schritte während der Bereitstellung ausführen können. Jeder der Lebenszyklushooks wird je nach pool-Attribut in einen Agent- oder Serverauftrag (oder einen Container- oder Validierungsauftrag in der Zukunft) aufgelöst. Standardmäßig erben die Lebenszyklushooks den vom deployment-Auftrag angegebenen pool.

Bereitstellungsaufträge verwenden die Systemvariable $(Pipeline.Workspace).

Beschreibungen von Lebenszyklushooks

preDeploy: Zum Ausführen von Schritten, mit denen vor dem Start der Anwendungsbereitstellung Ressourcen initialisiert werden.

deploy: Zum Ausführen von Schritten, mit denen Ihre Anwendung bereitgestellt wird. Die Aufgabe „download artifact“ wird nur in den deploy-Hook für Bereitstellungsaufträge automatisch eingefügt. Um das Herunterladen von Artefakten zu beenden, verwenden Sie - download: none. Alternativ können Sie bestimmte Artefakte auswählen, die heruntergeladen werden sollen, indem Sie die Aufgabe „Pipelineartefakt herunterladen“ definieren.

routeTraffic: Zum Ausführen von Schritten, die dem Datenverkehr zur aktualisierten Version dienen.

postRouteTraffic: Zum Ausführen von Schritten nach dem Weiterleiten des Datenverkehrs. In der Regel überwachen diese Aufgaben die Integrität der aktualisierten Version für ein definiertes Intervall.

on: failure oder on: success: Zum Ausführen von Schritten für Rollback-Aktionen oder zum Bereinigen.

RunOnce-Bereitstellungsstrategie

runOnce ist die einfachste Bereitstellungsstrategie, bei der alle Lebenszyklus-Hooks, nämlich preDeploy deploy, routeTrafficund postRouteTraffic, einmal ausgeführt werden. Danach wird entweder on: success oder on: failure ausgeführt.

strategy: 
    runOnce:
      preDeploy:        
        pool: [ server | pool ] # See pool schema.        
        steps:
        - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
      deploy:          
        pool: [ server | pool ] # See pool schema.        
        steps:
        ...
      routeTraffic:         
        pool: [ server | pool ]         
        steps:
        ...        
      postRouteTraffic:          
        pool: [ server | pool ]        
        steps:
        ...
      on:
        failure:         
          pool: [ server | pool ]           
          steps:
          ...
        success:          
          pool: [ server | pool ]           
          steps:
          ...

Wenn Sie selbstgehostete Agents verwenden, können Sie Optionen zum Bereinigen des Arbeitsbereichs verwenden, um Ihren Bereitstellungsarbeitsbereich zu bereinigen.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Die Rolling-Bereitstellungsmethode

Bei einer parallelen Bereitstellung werden bei jeder Iteration auf einer festgelegten Gruppe von virtuellen Computern (Gruppe für parallele Vorgänge) Instanzen der vorherigen Version einer Anwendung durch Instanzen der neuen Version ersetzt.

Derzeit wird nur die rollierende Strategie für VM-Ressourcen unterstützt.

Eine rollierende Bereitstellung wartet beispielsweise in der Regel, bis die Bereitstellungen auf den einzelnen virtuellen Computern abgeschlossen sind, bevor mit der nächsten Gruppe von Bereitstellungen fortgefahren wird. Sie könnten nach jeder Iteration eine Integritätsprüfung durchführen. Wenn ein schwerwiegendes Problem auftritt, kann die rollierende Bereitstellung angehalten werden.

Für die Konfiguration von rollierenden Bereitstellungen wird unter dem strategy:-Knoten das Schlüsselwort rolling: angegeben. Die strategy.name-Variable ist in diesem Strategieblock verfügbar, sie nimmt den Namen der Strategie an. In diesem Fall „rolling“.

strategy:
  rolling:
    maxParallel: [ number or percentage as x% ]
    preDeploy:        
      steps:
      - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
    deploy:          
      steps:
      ...
    routeTraffic:         
      steps:
      ...        
    postRouteTraffic:          
      steps:
      ...
    on:
      failure:         
        steps:
        ...
      success:          
        steps:
        ...

Alle Lebenszyklushooks werden unterstützt und Lebenszyklushook-Aufträge werden für die Ausführung auf jedem virtuellen Computer erstellt.

preDeploy, deploy, routeTrafficund postRouteTraffic werden einmal pro durch maxParallel definierter Batchgröße ausgeführt. Danach wird entweder on: success oder on: failure ausgeführt.

Mit maxParallel: <# or % of VMs> können Sie die Anzahl/den Prozentsatz von VM-Zielen steuern, für die parallel bereitgestellt werden soll. Dadurch wird sichergestellt, dass die App auf diesen Computern ausgeführt wird und Anforderungen verarbeiten kann, während die Bereitstellung auf den restlichen Computern erfolgt, wodurch Ausfallzeiten insgesamt reduziert werden.

Hinweis

Es gibt einige bekannte Lücken in diesem Feature. Wenn Sie z. B. eine Phase wiederholen, wird die Bereitstellung auf allen VMs erneut ausgeführt, nicht nur auf Zielen mit Fehlern.

Die Canary-Bereitstellungsmethode

Die Canary-Bereitstellungsstrategie ist eine erweiterte Bereitstellungsstrategie, die hilft, das Risiko bei der Einführung neuer Anwendungsversionen zu minimieren. Mithilfe dieser Strategie können Sie zuerst die Änderungen bei einer kleinen Teilmenge von Servern ausführen. Wenn das Vertrauen in die neue Version zunimmt, können Sie sie für weitere Server in Ihrer Infrastruktur freigeben und mehr Datenverkehr an diese weiterleiten.

strategy: 
    canary:
      increments: [ number ]
      preDeploy:        
        pool: [ server | pool ] # See pool schema.        
        steps:
        - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
      deploy:          
        pool: [ server | pool ] # See pool schema.        
        steps:
        ...
      routeTraffic:         
        pool: [ server | pool ]         
        steps:
        ...        
      postRouteTraffic:          
        pool: [ server | pool ]        
        steps:
        ...
      on:
        failure:         
          pool: [ server | pool ]           
          steps:
          ...
        success:          
          pool: [ server | pool ]           
          steps:
          ...

Die Canary-Bereitstellungsstrategie unterstützt den preDeploy-Lebenszyklushook (einmal ausgeführt) und durchläuft die deploy-, routeTraffic-und postRouteTraffic-Lebenszyklushooks. Anschließend wird über den success- oder failure-Hook beendet.

Die folgenden Variablen sind in dieser Strategie verfügbar:

strategy.name: Name der Strategie. Beispiel: „Canary“.
strategy.action: Die Aktion, die für den Kubernetes-Cluster ausgeführt werden soll. Beispiel: Bereitstellen, höher stufen oder Ablehnen.
strategy.increment: Der in der aktuellen Interaktion verwendete Inkrementwert. Diese Variable ist nur in deploy-, routeTraffic- und postRouteTraffic-Lebenszyklus-Hooks verfügbar.

Beispiele

RunOnce-Bereitstellungsstrategie

Der folgende YAML-Beispielausschnitt zeigt eine einfache Verwendung eines Bereitstellungsauftrags mithilfe der runOnce-Bereitstellungsstrategie. Das Beispiel umfasst einen Checkout-Schritt.

jobs:
  # Track deployments on the environment.
- deployment: DeployWeb
  displayName: deploy Web App
  pool:
    vmImage: 'ubuntu-latest'
  # Creates an environment if it doesn't exist.
  environment: 'smarthotel-dev'
  strategy:
    # Default deployment strategy, more coming...
    runOnce:
      deploy:
        steps:
        - checkout: self 
        - script: echo my first deployment

Bei jeder Ausführung dieses Auftrags wird ein Bereitstellungsverlauf für die smarthotel-dev-Umgebung erfasst.

Hinweis

• Es ist auch möglich, eine Umgebung mit leeren Ressourcen zu erstellen und diese als abstrakte Shell zum Aufzeichnen des Bereitstellungsverlaufs zu verwenden, wie im vorherigen Beispiel gezeigt.

Im nächsten Beispiel wird veranschaulicht, wie eine Pipeline sowohl auf eine Umgebung als auch auf eine Ressource verweisen kann, die als Ziel für einen Bereitstellungsauftrag verwendet werden soll.

jobs:
- deployment: DeployWeb
  displayName: deploy Web App
  pool:
    vmImage: 'ubuntu-latest'
  # Records deployment against bookings resource - Kubernetes namespace.
  environment: 'smarthotel-dev.bookings'
  strategy: 
    runOnce:
      deploy:
        steps:
          # No need to explicitly pass the connection details.
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            namespace: $(k8sNamespace)
            manifests: |
              $(System.ArtifactsDirectory)/manifests/*
            imagePullSecrets: |
              $(imagePullSecret)
            containers: |
              $(containerRegistry)/$(imageRepository):$(tag)

Dieser Ansatz hat folgende Vorteile:

• Zeichnet den Bereitstellungsverlauf für eine bestimmte Ressource in der Umgebung auf, anstatt den Verlauf für alle Ressourcen in der Umgebung aufzuzeichnen.
• Schritte im Bereitstellungsauftrag erben automatisch die Verbindungsdetails der Ressource (in diesem Fall ein Kubernetes-Namespace, smarthotel-dev.bookings) da der Bereitstellungsauftrag mit der Umgebung verknüpft ist. Dies ist nützlich, wenn dieselben Verbindungsdetails für mehrere Schritte des Auftrags festgelegt sind.

Hinweis

Wenn Sie einen privaten AKS-Cluster verwenden, stellen Sie sicher, dass Sie mit dem virtuellen Netzwerk des Clusters verbunden sind, da der API-Serverendpunkt nicht über eine öffentliche IP-Adresse verfügbar gemacht wird.

Azure Pipelines empfiehlt, einen selbst gehosteten Agent in einem VNET einzurichten, der Zugriff auf das virtuelle Netzwerk des Clusters hat. Weitere Informationen finden Sie unter "Optionen" zum Herstellen einer Verbindung mit dem privaten Cluster .

Die Rolling-Bereitstellungsmethode

Die rollierende Strategie für VMs aktualisiert bei jeder Iteration bis zu fünf Ziele. maxParallel bestimmt die Anzahl von Zielen, auf denen eine parallele Bereitstellung erfolgen kann. Die Auswahl berücksichtigt die absolute Anzahl oder einen Prozentsatz der Ziele, die zu jedem Zeitpunkt verfügbar bleiben müssen, ausgenommen die Ziele, auf denen die Bereitstellung erfolgt. Hiermit werden auch die Erfolgs- und Fehlerbedingungen während der Bereitstellung bestimmt.

jobs: 
- deployment: VMDeploy
  displayName: web
  environment:
    name: smarthotel-dev
    resourceType: VirtualMachine
  strategy:
    rolling:
      maxParallel: 5  #for percentages, mention as x%
      preDeploy:
        steps:
        - download: current
          artifact: drop
        - script: echo initialize, cleanup, backup, install certs
      deploy:
        steps:
        - task: IISWebAppDeploymentOnMachineGroup@0
          displayName: 'Deploy application to Website'
          inputs:
            WebSiteName: 'Default Web Site'
            Package: '$(Pipeline.Workspace)/drop/**/*.zip'
      routeTraffic:
        steps:
        - script: echo routing traffic
      postRouteTraffic:
        steps:
        - script: echo health check post-route traffic
      on:
        failure:
          steps:
          - script: echo Restore from backup! This is on failure
        success:
          steps:
          - script: echo Notify! This is on success

Die Canary-Bereitstellungsmethode

Im nächsten Beispiel stellt die Canary-Strategie für AKS die Änderungen zuerst mit 10-Prozent-Pods bereit, gefolgt von 20 Prozent, wobei die Integrität während postRouteTraffic überwacht wird. Wenn alles gut geht, wird auf 100 Prozent heraufgestuft.

jobs: 
- deployment: 
  environment: smarthotel-dev.bookings
  pool: 
    name: smarthotel-devPool
  strategy:                  
    canary:      
      increments: [10,20]  
      preDeploy:                                     
        steps:           
        - script: initialize, cleanup....   
      deploy:             
        steps: 
        - script: echo deploy updates... 
        - task: KubernetesManifest@0 
          inputs: 
            action: $(strategy.action)       
            namespace: 'default' 
            strategy: $(strategy.name) 
            percentage: $(strategy.increment) 
            manifests: 'manifest.yml' 
      postRouteTraffic: 
        pool: server 
        steps:           
        - script: echo monitor application health...   
      on: 
        failure: 
          steps: 
          - script: echo clean-up, rollback...   
        success: 
          steps: 
          - script: echo checks passed, notify... 

Verwenden von Pipelinedecorators zum automatischen Einfügen von Schritten

Pipelinedecorators können in Bereitstellungsaufträgen verwendet werden, um jeden benutzerdefinierten Schritt (z. B. die Sicherheitsrisikoüberprüfung) automatisch in jede Lebenszyklushook-Ausführung jedes Bereitstellungsauftrags einzuschleusen. Da Pipelinedecorators auf alle Pipelines in einer Organisation angewendet werden können, kann dies für die Erzwingung sicherer Bereitstellungsmethoden angewendet werden.

Darüber hinaus können Bereitstellungsaufträge als Containerauftrag zusammen mit Service-Sidecar ausgeführt werden, wenn definiert.

Unterstützung für Ausgabevariablen

Definieren Sie Ausgabevariablen in den Lebenszyklushooks eines Bereitstellungsauftrags und verwenden Sie sie in anderen nachgeschalteten Schritten und Aufträgen derselben Phase.

Um Variablen zwischen Phasen weiterzugeben, geben Sie ein Artefakt in einer Phase aus und verwenden Sie es dann in einer nachfolgenden Phase, oder verwenden Sie die unter Variablen beschriebene stageDependencies-Syntax.

Beim Ausführen von Bereitstellungsstrategien können Sie mit der folgenden Syntax auftragsübergreifend auf Ausgabevariablen zugreifen.

• Für die runOnce-Strategie: $[dependencies.<job-name>.outputs['<job-name>.<step-name>.<variable-name>']] (z. B. $[dependencies.JobA.outputs['JobA.StepA.VariableA']])
• Für runOnce-Strategie und einen resourceType: $[dependencies.<job-name>.outputs['Deploy_<resource-name>.<step-name>.<variable-name>']]. (Beispiel: $[dependencies.JobA.outputs['Deploy_VM1.StepA.VariableA']])
• Für die Canary-Strategie : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Für die rollierende Strategie: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

# Set an output variable in a lifecycle hook of a deployment job executing canary strategy.
- deployment: A
  pool:
    vmImage: 'ubuntu-latest'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # Creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - bash: echo $(setvarStep.myOutputVar)
          name: echovar

# Map the variable from the job.
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Geben Sie für einen runOnce-Auftrag den Namen des Auftrags anstelle des Lebenszyklushooks an:

# Set an output variable in a lifecycle hook of a deployment job executing runOnce strategy.
- deployment: A
  pool:
    vmImage: 'ubuntu-latest'
  environment: staging
  strategy:                  
    runOnce:
      deploy:
        steps:
        - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - bash: echo $(setvarStep.myOutputVar)
          name: echovar

# Map the variable from the job.
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Wenn Sie eine Umgebung in einem Bereitstellungsauftrag definieren, hängt die Syntax der Ausgabevariablen davon ab, wie die Umgebung definiert wird. In diesem Beispiel verwendet env1 die Kurzschreibweise und env2 enthält die vollständige Syntax mit einem definierten Ressourcentyp.

stages:
- stage: StageA
  jobs:
  - deployment: A1
    pool:
      vmImage: 'ubuntu-latest'
    environment: env1
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
            name: setvarStep
          - bash: echo $(System.JobName)
  - deployment: A2
    pool:
      vmImage: 'ubuntu-latest'
    environment: 
      name: env2
      resourceName: vmsfortesting
      resourceType: virtualmachine
    strategy:                  
      runOnce:
        deploy:
          steps:
          - script: echo "##vso[task.setvariable variable=myOutputVarTwo;isOutput=true]this is the second deployment variable value"
            name: setvarStepTwo
  
  - job: B1
    dependsOn: A1
    pool:
      vmImage: 'ubuntu-latest'
    variables:
      myVarFromDeploymentJob: $[ dependencies.A1.outputs['A1.setvarStep.myOutputVar'] ]
      
    steps:
    - script: "echo $(myVarFromDeploymentJob)"
      name: echovar
 
  - job: B2
    dependsOn: A2
    pool:
      vmImage: 'ubuntu-latest'
    variables:
      myVarFromDeploymentJob: $[ dependencies.A2.outputs['A2.setvarStepTwo.myOutputVarTwo'] ]
      myOutputVarTwo: $[ dependencies.A2.outputs['Deploy_vmsfortesting.setvarStepTwo.myOutputVarTwo'] ]
    
    steps:
    - script: "echo $(myOutputVarTwo)"
      name: echovartwo

Wenn Sie eine Variable aus einem Auftrag in Stufe 1 ausgeben, verwendet das Verweisen aus einem Bereitstellungsauftrag in der nächsten Phase unterschiedliche Syntax, je nachdem, ob Sie eine Variable festlegen oder als Bedingung für die Phase verwenden möchten.

stages:
- stage: StageA
  jobs:
  - job: A1
    steps:
      - pwsh: echo "##vso[task.setvariable variable=RunStageB;isOutput=true]true"
        name: setvarStep
      - bash: echo $(System.JobName)

- stage: StageB
  dependsOn: 
    - StageA
 
  # when referring to another stage, stage name is included in variable path
  condition: eq(dependencies.StageA.outputs['A1.setvarStep.RunStageB'], 'true')
  
  # Variables reference syntax differs slightly from inter-stage condition syntax
  variables:
    myOutputVar: $[stageDependencies.StageA.A1.outputs['setvarStep.RunStageB']]
  jobs:
  - deployment: B1
    pool:
      vmImage: 'ubuntu-latest'
    environment: envB
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo $(myOutputVar)

Wenn Sie eine Variable aus einem Bereitstellungsauftrag ausgeben, verwenden Sie die Phasenabhängigkeitssyntax, um sie aus der nächsten Phase zu referenzieren (z. B $[stageDependencies.<stage-name>.<job-name>.outputs[Deploy_<resource-name>.<step-name>.<variable-name>]]. ).

stages:
- stage: StageA
  jobs:
    - deployment: A1
      environment: 
        name:  env1
        resourceName: DevEnvironmentV
        resourceType: virtualMachine
      strategy:
        runOnce:
          deploy:
            steps:
              - script: echo "##vso[task.setvariable variable=myVar;isOutput=true]true"
                name: setvarStep
              - script: |
                  echo "Value of myVar in the same Job : $(setVarStep.myVar)"
                displayName: 'Verify variable in StageA'
- stage: StageB
  dependsOn: StageA

  # Full Variables syntax for inter-stage jobs
  variables:
    myOutputVar: $[stageDependencies.StageA.A1.outputs['Deploy_DevEnvironmentV.setvarStep.myVar']]
  jobs:
  - deployment: B1
    pool:
      vmImage: 'ubuntu-latest'
    environment: envB
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo $(myOutputVar)

Weitere Informationen zum Festlegen einer Ausgabevariable für mehrere Aufträge

Häufig gestellte Fragen

Meine Pipeline bleibt mit der Meldung „Auftrag steht aus...“ hängen. Wie kann ich dieses Problem beheben?

Dies kann vorkommen, wenn es einen Namenskonflikt zwischen zwei Aufträgen gibt. Vergewissern Sie sich, dass alle Bereitstellungsaufträge in derselben Phase einen eindeutigen Namen haben und dass Auftrags- und Phasennamen keine Schlüsselwörter enthalten. Wenn das Problem durch die Umbenennung nicht behoben wird, ziehen Sie die Problembehandlung für Pipelineausführungen zurate.

Werden Decorators in Bereitstellungsgruppen unterstützt?

Nein. Sie können keine Decorators in Bereitstellungsgruppen verwenden.