Verbeterde beveiliging van pijplijnen met alleen-lezen variabelen

Met deze update verbeteren we de beveiliging van pijplijnen met alleen-lezen variabelen. Daarnaast kunt u nu uitvoervariabelen definiëren in uw taken binnen elke levenscyclushook van een implementatietaak en deze gebruiken in downstreamstappen en taken binnen dezelfde fase.

Bekijk de onderstaande lijst met functies voor meer informatie.

Features

Algemeen:

• Het maken van een organisatie beperken via Azure AD-tenantbeleid

Azure Pipelines:

• Variabelen met het kenmerk Alleen-lezen
• Ondersteuning voor uitvoervariabelen in een implementatietaak
• Terugdraaien van kritieke wijzigingen voorkomen
• Oudere images verwijderen in Azure Pipelines-gehoste pools

General

Het beperken van het aanmaken van een organisatie via een Azure AD-tenantbeleid

Azure DevOps-beheerders kunnen nu gebruikmaken van een nieuw Azure AD-beleid. Met dit beleid kunt u het maken van nieuwe Azure DevOps-organisaties beperken die zijn verbonden met de Azure Active Directory van uw bedrijf. Zie de documentatie hier voor meer informatie over het beleid.

Azure-pipelines

Alleen lezen-variabelen

Systeemvariabelen werden gedocumenteerd als onveranderbaar, maar in de praktijk kunnen ze worden overschreven door een taak en downstreamtaken zouden de nieuwe waarde ophalen. Met deze update verbeteren we de beveiliging rond pijplijnvariabelen om systeem- en wachtrijtijdvariabelen alleen-lezen te maken. Daarnaast kunt u een YAML-variabele alleen-lezen maken door deze als volgt te markeren.

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

Ondersteuning voor uitvoervariabelen in een implementatietaak

U kunt nu uitvoervariabelen definiëren in de levenscyclushook van een implementatietaak en deze gebruiken in andere downstreamstappen en taken binnen dezelfde fase.

Tijdens het uitvoeren van implementatiestrategieën hebt u toegang tot uitvoervariabelen tussen taken met behulp van de volgende syntaxis.

• Voor runOnce-strategie : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Voor kanariestrategie : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Voor rollingstrategie: $[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

Meer informatie over het instellen van een uitvoervariabele voor meerdere taken

Voorkom het terugdraaien van kritieke wijzigingen

In klassieke release-pijplijnen is het gebruikelijk om te vertrouwen op geplande implementaties voor reguliere updates. Maar als u een kritieke oplossing hebt, kunt u ervoor kiezen om een handmatige implementatie buiten de band te starten. Als u dit doet, blijven de oudere releases ingepland. Dit was een uitdaging omdat de handmatige implementatie zou worden teruggedraaid wanneer de implementaties volgens schema worden hervat. Velen van u hebben dit probleem gerapporteerd en we hebben het probleem nu opgelost. Met de oplossing worden alle oudere geplande implementaties naar de omgeving geannuleerd wanneer u handmatig een implementatie start. Dit is alleen van toepassing wanneer de optie Voor wachtrijen is geselecteerd als 'Laatste implementeren en anderen annuleren'.

Oudere afbeeldingen verwijderen in Azure Pipelines-gehoste pools

Op 23 maart 2020 verwijderen we de volgende afbeeldingen uit de bij Azure Pipelines gehoste pools.

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

Door deze afbeeldingen te verwijderen, zullen we nieuwe afbeeldingsversies efficiënter blijven uitrollen.

Bekijk de blogpost over het verwijderen van oudere installatiekopieën in gehoste pools in Azure Pipelines voor meer informatie over het verwijderen van deze installatiekopieën.

Volgende stappen

Ga naar Azure DevOps en kijk eens.

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.

Bedankt

Vijay Machiraju