Dela via

Stöd för sekventiella distributioner när du använder exklusiva låskontroller

  • Artikel

I den här sprinten har vi utökat funktionen för exklusiva låskontroller i Azure Pipelines för att stödja sekventiella distributioner. Nu kan du köa flera körningar i en miljö så att bara en av dem kan köras i taget.

Mer information finns i följande funktionsbeskrivningar.

Azure-tavlor

Azure-pipelines

Azure-tavlor

Utvecklingsavsnittet i ett arbetsobjekt visar listan över relevanta incheckningar och pull-begäranden. Du kan visa författaren till inchecknings- eller pull-begäran tillsammans med den associerade tiden. Med den här uppdateringen har vi åtgärdat ett problem med att författarens avatar visas felaktigt i vyn.

Azure-pipelines

Stöd för sekventiella distributioner i stället för endast senaste när du använder exklusiva låskontroller

I YAML-pipelines används kontroller för att styra körningen av faser på skyddade resurser. En av de vanliga kontroller som du kan använda är en exklusiv låskontroll. Med den här kontrollen kan endast en enda körning från pipelinen fortsätta. När flera körningar försöker distribuera till en miljö samtidigt avbryter kontrollen alla gamla körningar och tillåter att den senaste körningen distribueras.

Att avbryta gamla körningar är en bra metod när dina versioner är kumulativa och innehåller alla kodändringar från tidigare körningar. Det finns dock vissa pipelines där kodändringar inte är kumulativa. Med den här nya funktionen kan du välja att tillåta att alla körningar fortsätter och distribueras sekventiellt till en miljö, eller bevara det tidigare beteendet att avbryta gamla körningar och bara tillåta det senaste. Du kan ange det här beteendet med hjälp av en ny egenskap som heter lockBehavior i YAML-pipelinefilen. Värdet sequential innebär att alla körningar hämtar låset sekventiellt till den skyddade resursen. Värdet runLatest innebär att endast den senaste körningen hämtar låset till resursen.

Följ dessa steg om du vill använda exklusiv låskontroll med sequential distributioner eller runLatest:

  1. Aktivera den exklusiva låskontrollen i miljön (eller en annan skyddad resurs).
  2. I YAML-filen för pipelinen anger du en ny egenskap med namnet lockBehavior. Detta kan anges för hela pipelinen eller för ett visst steg:

Ställ in på en scen:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Ange på pipelinen:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Om du inte anger en lockBehaviorantas den vara runLatest.

Stöd för Quebec-versionen av ServiceNow

Azure Pipelines har en befintlig integrering med ServiceNow. Integreringen förlitar sig på en app i ServiceNow och ett tillägg i Azure DevOps. Nu har vi uppdaterat appen så att den fungerar med Quebec-versionen av ServiceNow. Både klassiska pipelines och YAML-pipelines fungerar nu med Quebec. För att säkerställa att den här integreringen fungerar uppgraderar du till den nya versionen av appen (4.188.0) från Service Now Store. Mer information finns i Integrera med ServiceNow Change Management.

Ändra i förinstallationsprincipen för .NET SDK på Microsoft-värdbaserade Windows- och macOS-agenter

Nyligen tillkännagav vi en ändring i förinstallationsprincipen för .NET SDK på Microsofts värdbaserade Ubuntu-agenter. Vi gör nu samma ändring för Microsoft-värdbaserade Windows- och macOS-agenter.

För närvarande installerar vi alla tillgängliga och stödda versioner av .NET SDK (2.1.x, 3.1.x, 5.0.x) på Microsoft-värdbaserade Windows- och macOS-agenter. Den här metoden ändras till förmån för att installera den senaste korrigeringsversionen för varje funktionsversion. Den här ändringen görs för att ge dig mer ledigt utrymme och för nya verktygsförfrågningar.

Vad betyder det?

SDK-versionen består av följande delar: x.y.znn. z är funktionsversionen och nn är korrigeringsversionen. För 2.1.302 är till exempel funktionsversionen 3 och 02 är korrigeringsversionen. Enligt den nya metoden installerar vi bara den senaste korrigeringsversionen för varje funktionsversion, dvs. endast 2.1.302 installeras för 2.1.3x, endast 2.1.403 för 2.1.4x och så vidare. Alla versioner av .NET SDK som inte är de senaste korrigeringsversionerna tas bort från Windows- och macOS-avbildningar den 6 september. Den här ändringen påverkar alla versioner av Windows och macOS på Microsoft-värdbaserade agenter.

Måldatum

Distributionen av uppdaterade avbildningar börjar den 6 september och tar 3–4 dagar.

Möjlig påverkan

Om du använder en global.json-fil påverkas bygget i följande fall:

Bygget misslyckas om filen global.json innehåller rollForward: disable egenskapen och en SDK-version som inte är den senaste korrigeringsversionen. Ett exempel:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

.NET SDK-versionen ändras automatiskt till den senaste korrigeringen om filen global.json innehåller rollForward: patch egenskapen . Ett exempel:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

Om fältet rollForward inte anges i filen global.json ändras inte för dig. Den senaste installerade korrigeringsnivån används.

Om du behöver använda en exakt .NET SDK-version som inte är den senaste korrigeringen UseDotNet använder du uppgiften för att installera den som en del av versionen:

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

Ändringar i aktiviteterna PublishBuildArtifacts och DownloadBuildArtifacts

Azure Pipelines stöder två uppsättningar uppgifter för publicering/nedladdning av artefakter. PublishPipelineArtifact och DownloadPipelineArtifact är de nyare och rekommenderade uppgifterna för att utföra dessa steg.

PublishBuildArtifacts och DownloadBuildArtifacts är de äldre uppgifterna och de har inte samma prestanda- och lagringsoptimeringar som finns i motsvarande PipelineArtifact-uppgifter. Dessa äldre uppgifter hade också skalningsbegränsningar när det gäller hur de implementerades. Några av våra större kunder har stött på dessa gränser.

Vi vill att alla kunder ska flytta till PipelineArtifact-uppgifterna, men vi var också tvungna att vidta några åtgärder för att åtgärda skalbarheten för äldre BuildArtifact-uppgifter. Som en del av en ny uppdatering för att förbättra skalbarheten interagerar Azure Pipelines-agenter nu direkt med byggartefakter via blobstore-domäner (i stället för att dirigera via tfs-domäner). Dessa pipelines börjar komma åt IP-adresser och domäner som länge har funnits i listan över tillåtna Azure DevOps-enheter , men som kanske inte har använts tidigare av specifika pipelines.

Den uppdaterade implementeringen av BuildArtifact-uppgifter kräver en agentuppgradering, vilket ska ske automatiskt om inte automatiska uppgraderingar har inaktiverats specifikt eller brandväggarna har konfigurerats felaktigt.

Om dina agenter körs i brandväggsmiljöer som inte följer de länkade instruktionerna kan de se fel vid uppdatering av agenten eller i uppgifterna PublishBuildArtifacts eller DownloadBuildArtifacts tills brandväggskonfigurationen har korrigerats.

Ett vanligt symptom på det här problemet är plötsliga fel som rör ssl-handskakningar eller fel vid nedladdning av artefakter, vanligtvis på distributionspooler som omfattas av Versionshanteringsdefinitioner. Om agentuppgraderingar har blockerats kan du också se att versioner väntar på en agent i poolen som aldrig tas emot, eller att agenter går offline halvvägs genom uppdateringen (det senare är relaterat till miljöer som felaktigt blockerar agenten CDN).

Nästa steg

Anteckning

De här funktionerna kommer att lanseras under de kommande två till tre veckorna.

Gå till Azure DevOps och ta en titt.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om dessa funktioner. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.

Ge ett förslag

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Aaron Hallberg