Verbesserte Pipelinesicherheit mit schreibgeschützten Variablen

Mit diesem Update verbessern wir die Sicherheit von Pipelines mit schreibgeschützten Variablen. Darüber hinaus können Sie jetzt Ausgabevariablen in Ihren Aufgaben innerhalb eines beliebigen Lebenszyklus-Hooks eines Bereitstellungsauftrags definieren und sie in nachgelagerten Schritten und Aufträgen innerhalb derselben Phase nutzen.

Weitere Informationen finden Sie in der Liste Features unten.

Features

Allgemeines:

• Einschränken organization Erstellung über azure AD-Mandantenrichtlinie

Azure Pipelines:

• Schreibgeschützte Variablen
• Unterstützung für Ausgabevariablen in einem Bereitstellungsauftrag
• Vermeiden eines Rollbacks kritischer Änderungen
• Entfernen älterer Images in von Azure Pipelines gehosteten Pools

Allgemein

Einschränken organization Erstellung über azure AD-Mandantenrichtlinie

Azure DevOps-Administratoren können jetzt eine neue Azure AD-Richtlinie nutzen. Mit dieser Richtlinie können Sie das Erstellen neuer Azure DevOps-Organisationen einschränken, die mit Azure Active Directory Ihres Unternehmens verbunden sind. Weitere Informationen zur Richtlinie finden Sie in der Dokumentation.

Azure Pipelines

Schreibgeschützte Variablen

Systemvariablen wurden als unveränderlich dokumentiert, in der Praxis könnten sie jedoch von einer Aufgabe überschrieben werden, und nachgelagerte Aufgaben würden den neuen Wert übernehmen. Mit diesem Update erhöhen wir die Sicherheit rund um Pipelinevariablen, um System- und Warteschlangenzeitvariablen schreibgeschützt zu machen. Darüber hinaus können Sie eine YAML-Variable schreibgeschützt machen, indem Sie sie wie folgt markieren.

variables:
- name: myVar
  value: myValue
  readonly: true

Unterstützung für Ausgabevariablen in einem Bereitstellungsauftrag

Sie können nun Ausgabevariablen in den Lebenszyklus-Hooks eines Bereitstellungsauftrags definieren und sie in anderen nachgelagerten Schritten und Aufträgen innerhalb derselben Phase nutzen.

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['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Für die Canary-Strategie : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Für 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:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: 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

Weitere Informationen zum Festlegen einer Ausgabevariable mit mehreren Aufträgen

Vermeiden eines Rollbacks kritischer Änderungen

In klassischen Releasepipelines ist es üblich, sich für regelmäßige Updates auf geplante Bereitstellungen zu verlassen. Wenn Sie jedoch eine kritische Lösung haben, können Sie eine manuelle Bereitstellung out-of-band starten. Dabei bleiben ältere Releases weiterhin geplant. Dies stellte eine Herausforderung dar, da für die manuelle Bereitstellung ein Rollback ausgeführt wurde, wenn die Bereitstellungen gemäß Zeitplan fortgesetzt wurden. Viele von Ihnen haben dieses Problem gemeldet, und wir haben es jetzt behoben. Mit dem Fix würden alle älteren geplanten Bereitstellungen in der Umgebung abgebrochen, wenn Sie eine Bereitstellung manuell starten. Dies gilt nur, wenn die Warteschlangenoption "Zuletzt bereitstellen und andere abbrechen" ausgewählt ist.

Entfernen älterer Images in von Azure Pipelines gehosteten Pools

Am 23. März 2020 entfernen wir die folgenden Images aus unseren gehosteten Azure Pipelines-Pools.

• Windows Server 2012 R2 mit Visual Studio 2015 (vs2015-win2012r2)
• Mac OS High Sierra 10.13 (macOS-10.13)
• Windows Server Core 1803 (win1803)

Durch das Entfernen dieser Images werden neuere Imageversionen weiterhin effizienter ausgerollt.

Weitere Informationen zum Entfernen dieser Images finden Sie im Blogbeitrag Entfernen älterer Images in gehosteten Azure Pipelines-Pools .

Nächste Schritte

Wechseln Sie zu Azure DevOps, und sehen Sie sich an.

Senden von Feedback

Wir würden uns freuen zu hören, was Sie über diese Features denken. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Vielen Dank,

Vijay Machiraju