Verbeterde beveiliging van pijplijnen met alleen-lezenvariabelen

Met deze update verbeteren we de beveiliging van pijplijnen met alleen-lezen variabelen. Bovendien kunt u nu uitvoervariabelen in uw taken definiëren 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.

Functies

Algemeen:

• Het maken van een organisatie via Azure AD tenantbeleid beperken

Azure Pipelines:

Notitie

Het installeren van .NET 4.6.2 of hoger is vereist om de VSTest-taak goed te laten werken op buildagents.

• Alleen-lezenvariabelen
• Ondersteuning voor uitvoervariabelen in een implementatietaak
• Terugdraaien van kritieke wijzigingen voorkomen
• Oudere installatiekopieën verwijderen in gehoste azure-pijplijnenpools

Algemeen

Het maken van een organisatie via Azure AD tenantbeleid beperken

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-lezenvariabelen

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 van pijplijnvariabelen om systeem- en wachtrijvariabelen 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 voor taken met behulp van de volgende syntaxis.

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

Meer informatie over het instellen van een uitvoervariabele voor meerdere taken

Terugdraaien van kritieke wijzigingen voorkomen

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

Oudere installatiekopieën verwijderen in gehoste azure-pijplijnenpools

Op 23 maart 2020 verwijderen we de volgende installatiekopieën uit onze gehoste Azure Pipelines-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 installatiekopieën te verwijderen, blijven we nieuwere versies van installatiekopieën efficiënter implementeren.

Raadpleeg het blogbericht Oudere installatiekopieën verwijderen in gehoste pools in Azure Pipelines voor meer informatie over het verwijderen van deze installatiekopieën.

Volgende stappen

Notitie

Deze functies worden in de komende twee tot drie weken uitgerold.

Ga naar Azure DevOps en neem een kijkje.

Ga naar Azure DevOps

Feedback geven

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

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

Met vriendelijke groet,

Vijay Machiraju