Delen via

Ondersteuning voor sequentiële implementaties bij gebruik van exclusieve vergrendelingscontroles

  • Artikel

In deze sprint hebben we de mogelijkheid van exclusieve vergrendelingscontroles in Azure Pipelines uitgebreid om sequentiële implementaties te ondersteunen. U kunt nu meerdere uitvoeringen in een omgeving in de wachtrij plaatsen, zodat slechts één uitvoering tegelijk kan worden uitgevoerd.

Bekijk de volgende functiebeschrijvingen voor meer informatie.

Azure Boards

Azure Pipelines

Azure Boards

In de sectie Ontwikkeling in een werkitem wordt de lijst met relevante doorvoeringen en pull-aanvragen weergegeven. U kunt de auteur van de doorvoer- of pull-aanvraag samen met de bijbehorende tijd weergeven. Met deze update hebben we een probleem opgelost waarbij de avatar van de auteur onjuist werd weergegeven in de weergave.

Azure Pipelines

Ondersteuning voor sequentiële implementaties in plaats van de meest recente, alleen bij gebruik van exclusieve vergrendelingscontroles

In YAML-pijplijnen worden controles gebruikt om de uitvoering van fasen op beveiligde resources te beheren. Een van de algemene controles die u kunt gebruiken, is een exclusieve vergrendelingscontrole. Met deze controle kan slechts één uitvoering vanuit de pijplijn worden uitgevoerd. Wanneer meerdere uitvoeringen tegelijkertijd proberen te implementeren in een omgeving, worden alle oude uitvoeringen geannuleerd en kan de meest recente uitvoering worden geïmplementeerd.

Het annuleren van oude uitvoeringen is een goede aanpak wanneer uw releases cumulatief zijn en alle codewijzigingen van eerdere uitvoeringen bevatten. Er zijn echter enkele pijplijnen waarin codewijzigingen niet cumulatief zijn. Met deze nieuwe functie kunt u ervoor kiezen om alle uitvoeringen toe te staan en opeenvolgend te implementeren in een omgeving, of het vorige gedrag van het annuleren van oude uitvoeringen en het toestaan van alleen de meest recente uitvoeringen behouden. U kunt dit gedrag opgeven met behulp van een nieuwe eigenschap met de naam lockBehavior in het YAML-pijplijnbestand. Een waarde van sequential impliceert dat alle uitvoeringen de vergrendeling sequentieel verkrijgen voor de beveiligde resource. Een waarde van runLatest impliceert dat alleen de meest recente uitvoering de vergrendeling voor de resource verkrijgt.

Als u exclusieve vergrendelingscontrole wilt gebruiken met sequential implementaties of runLatest, voert u de volgende stappen uit:

  1. Schakel de exclusieve vergrendelingscontrole in voor de omgeving (of een andere beveiligde resource).
  2. Geef in het YAML-bestand voor de pijplijn een nieuwe eigenschap op met de naam lockBehavior. Dit kan worden opgegeven voor de hele pijplijn of voor een bepaalde fase:

Instellen op een podium:

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

Instellen voor de pijplijn:

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

Als u geen opgeeft lockBehavior, wordt ervan uitgegaan dat deze is runLatest.

Ondersteuning voor Quebec-versie van ServiceNow

Azure Pipelines heeft een bestaande integratie met ServiceNow. De integratie is afhankelijk van een app in ServiceNow en een extensie in Azure DevOps. We hebben de app nu bijgewerkt om te werken met de Quebec-versie van ServiceNow. Zowel klassieke als YAML-pijplijnen werken nu met Quebec. Voer een upgrade uit naar de nieuwe versie van de app (4.188.0) vanuit het Service Now-archief om ervoor te zorgen dat deze integratie werkt. Zie Integreren met ServiceNow Change Management voor meer informatie.

Wijziging in het beleid voor voorinstallatie van .NET SDK op door Microsoft gehoste Windows- en macOS-agents

Onlangs hebben we een wijziging aangekondigd in het beleid voor vooraf installeren van .NET SDK op door Microsoft gehoste Ubuntu-agents. We brengen nu dezelfde wijziging aan voor door Microsoft gehoste Windows- en macOS-agents.

Momenteel installeren we alle beschikbare en ondersteunde versies van de .NET SDK (2.1.x, 3.1.x, 5.0.x) op Door Microsoft gehoste Windows- en macOS-agents. Deze aanpak wordt gewijzigd ten gunste van het installeren van de nieuwste patchversie voor elke functieversie. Deze wijziging wordt aangebracht om u meer vrije ruimte te bieden en voor nieuwe hulpprogrammaaanvragen.

Wat betekent dit?

De SDK-versie bestaat uit de volgende onderdelen: x.y.znn. z is de functieversie en nn is de patchversie. Voor 2.1.302 is de functieversie bijvoorbeeld 3 en 02 de patchversie. Volgens de nieuwe aanpak installeren we alleen de nieuwste patchversie voor elke functieversie, dat wil weten dat alleen 2.1.302 wordt geïnstalleerd voor 2.1.3x, alleen 2.1.403 voor 2.1.4x, enzovoort. Alle versies van de .NET SDK die niet de nieuwste patchversies zijn, worden op 6 september verwijderd uit Windows- en macOS-installatiekopieën. Deze wijziging is van invloed op alle versies van Windows en macOS op door Microsoft gehoste agents.

Doeldatum

De implementatie van bijgewerkte installatiekopieën begint op 6 september en duurt 3-4 dagen.

Mogelijke gevolgen

Als u een global.json-bestand gebruikt, wordt uw build beïnvloed in de volgende gevallen:

Uw build mislukt als het bestand global.json de rollForward: disable eigenschap en een SDK-versie bevat die niet de meest recente patchversie is. Bijvoorbeeld:

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

De .NET SDK-versie wordt automatisch gewijzigd in de meest recente patch als het bestand global.json de rollForward: patch eigenschap bevat. Bijvoorbeeld:

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

Als het rollForward veld niet is opgegeven in het bestand global.json, verandert er niets voor u. Het meest recent geïnstalleerde patchniveau wordt gebruikt.

Als u een exacte .NET SDK-versie moet gebruiken die niet de meest recente patch is, gebruikt u de UseDotNet taak om deze te installeren als onderdeel van de build:

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

Wijzigingen in PublishBuildArtifacts en DownloadBuildArtifacts-taken

Azure Pipelines ondersteunt twee sets taken voor het publiceren/downloaden van artefacten. PublishPipelineArtifact en DownloadPipelineArtifact zijn de nieuwere en aanbevolen taken voor het uitvoeren van deze stappen.

PublishBuildArtifacts en DownloadBuildArtifacts zijn de oudere taken en ze hebben niet dezelfde optimalisaties voor prestaties en opslag die aanwezig zijn in de bijbehorende PipelineArtifact-taken. Deze oudere taken hadden ook schaalbeperkingen wat betreft de wijze waarop ze zijn geïmplementeerd. Sommige van onze grotere klanten lopen tegen deze limieten aan.

Hoewel we willen dat alle klanten overstappen op de PipelineArtifact-taken, moesten we ook enkele stappen uitvoeren om de schaalbaarheid van oudere BuildArtifact-taken aan te pakken. Als onderdeel van een recente update om de schaalbaarheid te verbeteren, communiceren Azure Pipelines-agents nu rechtstreeks met buildartefacten via blobstore-domeinen (in plaats van routering via tfs-domeinen). Deze pijplijnen krijgen toegang tot IP-adressen en domeinen die al lang op de acceptatielijst van Azure DevOps staan, maar mogelijk nog niet eerder zijn gebruikt door specifieke pijplijnen.

Voor de bijgewerkte implementatie van BuildArtifact-taken is een agentupgrade vereist. Deze moet automatisch worden uitgevoerd, tenzij automatische upgrades specifiek zijn uitgeschakeld of de firewalls onjuist zijn geconfigureerd.

Als uw agents worden uitgevoerd in omgevingen met firewalls die de gekoppelde instructies niet hebben gevolgd, zien ze mogelijk fouten bij het bijwerken van de agent of in de taken PublishBuildArtifacts of DownloadBuildArtifacts totdat de firewallconfiguratie is gecorrigeerd.

Een veelvoorkomend symptoom van dit probleem zijn plotselinge fouten met betrekking tot SSL-handshakes of fouten bij het downloaden van artefacten, meestal op implementatiegroepen waarop releasebeheerdefinities zijn gericht. Als agentupgrades zijn geblokkeerd, kunt u ook zien dat releases wachten op een agent in de pool die nooit arriveert, of dat agents halverwege hun update offline gaan (dit laatste is gerelateerd aan omgevingen die ten onrechte het AGENT-CDN blokkeren).

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 van deze functies vindt. Gebruik het menu Help om een probleem te melden of een suggestie te geven.

Een suggestie doen

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

Met vriendelijke groet,

Aaron Hallberg