Unterstützung für sequenzielle Bereitstellungen bei Verwendung exklusiver Sperrüberprüfungen

  • Artikel

In diesem Sprint haben wir die Funktion exklusiver Sperrprüfungen in Azure Pipelines erweitert, um sequenzielle Bereitstellungen zu unterstützen. Jetzt können Sie mehrere Ausführungen in einer Umgebung in eine Warteschlange stellen, damit nur eine von ihnen gleichzeitig ausgeführt werden kann.

Weitere Informationen finden Sie in den folgenden Funktionsbeschreibungen.

Azure Boards

Azure Pipelines

Azure Boards

Der Entwicklungsabschnitt in einem Arbeitselement zeigt die Liste der relevanten Commits und Pull Requests an. Sie können den Autor des Commits oder Pull Requests zusammen mit der zugeordneten Zeit anzeigen. Mit diesem Update wurde ein Problem behoben, bei dem der Avatar des Autors in der Ansicht falsch angezeigt wurde.

Azure Pipelines

Unterstützung für sequenzielle Bereitstellungen statt nur bei verwendung exklusiver Sperrüberprüfungen

In YAML-Pipelines werden Überprüfungen verwendet, um die Ausführung von Phasen für geschützte Ressourcen zu steuern. Eine der gängigen Überprüfungen, die Sie verwenden können, ist eine exklusive Sperrprüfung. Mit dieser Überprüfung kann nur eine einzelne Ausführung aus der Pipeline fortgesetzt werden. Wenn mehrere Ausführungen versuchen, zur gleichen Zeit in einer Umgebung bereitzustellen, werden alle alten Ausführungen abgebrochen und die neueste Ausführung kann bereitgestellt werden.

Das Abbrechen alter Ausführungen ist ein guter Ansatz, wenn Ihre Releases kumulativ sind und alle Codeänderungen aus vorherigen Ausführungen enthalten. Es gibt jedoch einige Pipelines, in denen Codeänderungen nicht kumulativ sind. Mit diesem neuen Feature können Sie festlegen, dass alle Ausführungen sequenziell in einer Umgebung ausgeführt und bereitgestellt werden können, oder das vorherige Verhalten beibehalten, alte Ausführungen abzubrechen und nur die neuesten zuzulassen. Sie können dieses Verhalten mithilfe einer neuen Eigenschaft angeben, die in der YAML-Pipelinedatei genannt wird lockBehavior . Ein Wert von sequential impliziert, dass alle Ausführungen die Sperre sequenziell für die geschützte Ressource abrufen. Ein Wert von runLatest impliziert, dass nur die letzte Ausführung die Sperre für die Ressource erhält.

Führen Sie die folgenden Schritte aus, um die Überprüfung „Exklusive Sperre“ mit sequenziellen Bereitstellungen (sequential) oder mit runLatest zu verwenden:

  1. Aktivieren Sie die Überprüfung „Exklusive Sperre“ für die Umgebung (oder für eine andere geschützte Ressource).
  2. Geben Sie in der YAML-Datei für die Pipeline eine neue Eigenschaft mit dem Namen an lockBehavior. Diese kann für die gesamte Pipeline oder für eine bestimmte Phase angegeben werden:

Festlegen für eine Phase:

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

Festlegen für die Pipeline:

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

Wenn Sie keinen angeben lockBehavior, wird angenommen, dass es ist runLatest.

Unterstützung für die Quebec-Version von ServiceNow

Azure Pipelines verfügt über eine vorhandene Integration mit ServiceNow. Die Integration basiert auf einer App in ServiceNow und einer Erweiterung in Azure DevOps. Wir haben die App jetzt so aktualisiert, dass sie mit der Quebec-Version von ServiceNow funktioniert. Sowohl klassische als auch YAML-Pipelines funktionieren jetzt mit Quebec. Um sicherzustellen, dass diese Integration funktioniert, führen Sie ein Upgrade auf die neue Version der App (4.188.0) aus dem Service Now-Speicher aus. Weitere Informationen finden Sie unter Integrieren in serviceNow Change Management.

Änderung der .NET SDK-Vorinstallationsrichtlinie für von Microsoft gehostete Windows- und macOS-Agents

Kürzlich haben wir eine Änderung der .NET SDK-Vorinstallationsrichtlinie für von Microsoft gehostete Ubuntu-Agents angekündigt . Wir nehmen nun dieselbe Änderung für von Microsoft gehostete Windows- und macOS-Agents vor.

Derzeit installieren wir alle verfügbaren und unterstützten Versionen des .NET SDK (2.1.x, 3.1.x, 5.0.x) unter von Microsoft gehosteten Windows- und macOS-Agents. Dieser Ansatz wird zugunsten der Installation der neuesten Patchversion für jede Featureversion geändert. Diese Änderung wird vorgenommen, um Ihnen mehr freien Speicherplatz und neue Toolanforderungen bereitzustellen.

Was bedeutet das?

Die SDK-Version besteht aus den folgenden Teilen: x.y.znn. z ist die Featureversion und nn ist die Patchversion. Beispielsweise ist für 2.1.302 die Featureversion 3 und 02 die Patchversion. Gemäß dem neuen Ansatz installieren wir nur die neueste Patchversion für jede Featureversion, d. h. nur 2.1.302 wird für 2.1.3x, nur 2.1.403 für 2.1.4x usw. installiert. Alle Versionen des .NET SDK, die nicht die neuesten Patchversionen sind, werden am 6. September aus Windows- und macOS-Images entfernt. Diese Änderung wirkt sich auf alle Versionen von Windows und macOS in von Microsoft gehosteten Agents aus.

Zieldatum

Die Bereitstellung aktualisierter Images beginnt am 6. September und dauert 3 bis 4 Tage.

Mögliche Auswirkungen

Wenn Sie eine datei global.json verwenden, ist Ihr Build in den folgenden Fällen betroffen:

Ihr Build schlägt fehl, wenn die Datei global.json die rollForward: disable Eigenschaft und eine SDK-Version enthält, die nicht die neueste Patchversion ist. Zum Beispiel:

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

Die .NET SDK-Version wird automatisch in den neuesten Patch geändert, wenn die Datei global.json die rollForward: patch Eigenschaft enthält. Zum Beispiel:

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

Wenn das rollForward Feld in Der Datei global.json nicht angegeben ist, wird keine Änderung für Sie vorgenommen. Die neueste installierte Patchebene wird verwendet.

Wenn Sie eine genaue .NET SDK-Version verwenden müssen, die nicht der neueste Patch ist, verwenden Sie die UseDotNet Aufgabe , um sie als Teil des Builds zu installieren:

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

Änderungen an den Aufgaben PublishBuildArtifacts und DownloadBuildArtifacts

Azure Pipelines unterstützt zwei Gruppen von Aufgaben zum Veröffentlichen/Herunterladen von Artefakten. PublishPipelineArtifact und DownloadPipelineArtifact sind die neueren und empfohlenen Aufgaben zum Ausführen dieser Schritte.

PublishBuildArtifacts und DownloadBuildArtifacts sind die älteren Aufgaben und weisen nicht die gleichen Leistungs- und Speicheroptimierungen auf, die in den entsprechenden PipelineArtifact-Aufgaben vorhanden sind. Diese älteren Aufgaben hatten auch Skalierungseinschränkungen in Bezug auf ihre Implementierung. Einige unserer größeren Kunden sind an diese Grenzen gelaufen.

Obwohl wir möchten, dass alle Kunden zu den PipelineArtifact-Aufgaben wechseln, mussten wir auch einige Schritte unternehmen, um die Skalierbarkeit älterer BuildArtifact-Aufgaben zu berücksichtigen. Im Rahmen eines aktuellen Updates zur Verbesserung ihrer Skalierbarkeit interagieren Azure Pipelines-Agents jetzt direkt mit Buildartefakten über Blobstore-Domänen (anstatt über tfs-Domänen zu routingen). Diese Pipelines beginnen mit dem Zugriff auf IP-Adressen und Domänen, die sich schon lange in der Azure DevOps-Zulassungsliste befinden, aber möglicherweise noch nicht von bestimmten Pipelines verwendet wurden.

Die aktualisierte Implementierung von BuildArtifact-Tasks erfordert ein Agentupgrade, das automatisch erfolgen sollte, es sei denn, automatische Upgrades wurden ausdrücklich deaktiviert oder die Firewalls wurden falsch konfiguriert.

Wenn Ihre Agents in Firewallumgebungen ausgeführt werden, die die verknüpften Anweisungen nicht befolgt haben, können fehler beim Aktualisieren des Agents oder in den PublishBuildArtifacts- oder DownloadBuildArtifacts-Tasks auftreten, bis die Firewallkonfiguration korrigiert wurde.

Ein häufiges Symptom dieses Problems sind plötzliche Fehler in Bezug auf SSL-Handshakes oder Fehler beim Herunterladen von Artefakten, in der Regel für Bereitstellungspools, die von Release Management Definitionen betroffen sind. Wenn Agent-Upgrades blockiert wurden, können Sie alternativ feststellen, dass Releases auf einen Agent im Pool warten, der nie ankommt, oder dass Agents zur Hälfte ihres Updates offline gehen (letzteres bezieht sich auf Umgebungen, die das Agent-CDN fälschlicherweise blockieren).

Nächste Schritte

Hinweis

Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.

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

Navigieren Sie zu Azure DevOps.

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.

Einen Vorschlag unterbreiten

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

Vielen Dank,

Aaron Hallberg