Versionshinweise zu Azure DevOps Server 2022


| | Entwicklercommunity Systemanforderungen und Kompatibilität Lizenzbedingungen | | DevOps Blog | SHA-256 Hashes |


In diesem Artikel finden Sie Informationen zum neuesten Release für Azure DevOps Server.

Weitere Informationen zum Installieren oder Aktualisieren einer Azure DevOps Server-Bereitstellung finden Sie unter Azure DevOps Server Anforderungen.

Um Azure DevOps Server Produkte herunterzuladen, besuchen Sie die Seite Azure DevOps Server Downloads.

Das direkte Upgrade auf Azure DevOps Server 2022 wird ab Azure DevOps Server 2019 oder Team Foundation Server 2015 oder höher unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2013 oder früher befindet, müssen Sie vor dem Upgrade auf Azure DevOps Server 2022 einige Zwischenschritte ausführen. Weitere Informationen finden Sie auf der Seite Installieren .


Azure DevOps Server Veröffentlichungsdatum von Patch 1 2022: 24. Januar 2023

Wir haben einen Patch für Azure DevOps Server 2022 veröffentlicht, der Fehlerbehebungen für folgendes enthält.

  • Testdaten wurden nicht gelöscht, sodass die Datenbank vergrößert wurde. Mit diesem Fix wurde die Buildaufbewahrung aktualisiert, um das Erstellen neuer verwaister Testdaten zu verhindern.
  • Aktualisierungen zu AnalyticCleanupJob lautete der Auftragsstatus Beendet, und jetzt melden wir Erfolgreich.
  • Der Befehl "tfx extension publish" wurde behoben, bei dem der Fehler "Der angegebene Schlüssel war im Wörterbuch nicht vorhanden" fehlschlägt.
  • Es wurde eine Problemumgehung implementiert, um fehler und beim Zugriff auf die Teamkalendererweiterung zu beheben.

Azure DevOps Server Veröffentlichungsdatum 2022: 6. Dezember 2022

Azure DevOps Server 2022 ist ein Rollup von Fehlerbehebungen. Es enthält alle Features der Azure DevOps Server 2022 RC2 und RC1, die zuvor veröffentlicht wurden.

Veröffentlichungsdatum der Azure DevOps Server 2022 RC2: 25. Oktober 2022

Azure DevOps Server 2022 RC2 ist ein Rollup von Fehlerbehebungen. Sie enthält alle Features der zuvor veröffentlichten Azure DevOps Server 2022 RC1.

Hinweis

Neue SSH-RSA-Algorithmen aktiviert

Die Unterstützung für öffentliche RSA-Schlüssel wurde verbessert, um zusätzlich zu sha1 SSH-RSA, die wir zuvor unterstützt haben, auch die Typen öffentlicher SHA2-Schlüssel zu unterstützen.

Zu den unterstützten Typen für öffentliche Schlüssel gehören jetzt:

  • SSH-RSA
  • RSA-SHA2-256
  • RSA-SHA2-512

Aktion erforderlich

Wenn Sie die Umgehung implementiert haben, um SSH-RSA durch explizite Angabe in der .ssh/config1 Datei zu aktivieren, müssen Sie entweder entfernen PubkeyAcceptedTypesoder ändern, um RSA-SHA2-256 oder RSA-SHA2-512 oder beides zu verwenden. Details dazu, was zu tun ist, wenn Sie weiterhin zur Eingabe Ihres Kennworts aufgefordert werden und GIT_SSH_COMMAND="ssh -v" git fetch keinen Algorithmus für gegenseitige Signaturen anzeigt, finden Sie hier in der Dokumentation.

Die Unterstützung für elliptische Schlüssel wurde noch nicht hinzugefügt und ist weiterhin ein stark angefordertes Feature in unserem Backlog.

Azure DevOps Server Veröffentlichungsdatum 2022 RC1: 9. August 2022

Zusammenfassung der Neuerungen in Azure DevOps Server 2022

Wichtig

Der Warehouse- und Analysis-Dienst war in der vorherigen Version von Azure DevOps Server (2020) veraltet. In Azure DevOps Server 2022 wurde der Warehouse and Analysis Service aus dem Produkt entfernt. Analytics bietet jetzt die In-Product-Berichterstellung.

Azure DevOps Server 2022 werden viele neue Features eingeführt. Einige der Highlights sind unter anderem:

Sie können auch zu einzelnen Abschnitten springen, um alle neuen Features für jeden Dienst anzuzeigen:


Boards

Lieferpläne

Wir freuen uns, Ihnen mitteilen zu können, dass Lieferpläne jetzt in Azure DevOps Server enthalten sind. Übermittlungspläne liefern drei wichtige Szenarien:

  • Eine Zeitachsenansicht des Plans
  • Fortschritt der Arbeit
  • Abhängigkeitsüberwachung

Im Folgenden finden Sie die wichtigsten Features. Filter, Marker und Feldkriterien sind ebenfalls Teil von Übermittlungsplänen.

Es gibt zwei Hauptansichten: verdichtet und erweitert

Übermittlungspläne 2.0 ermöglichen das Anzeigen aller Arbeitselemente in Ihrem Plan auf einer Zeitachse unter Verwendung von Start- und Zielterminen oder Iterationsterminen. Die Reihenfolge der Rangfolge ist das Startzieldatum & und dann die Iteration. Auf diese Weise können Sie Arbeitselemente auf Portfolioebene wieEpic hinzufügen, die häufig nicht für eine Iteration definiert sind.

Es gibt zwei Hauptansichten, die verkürzte Ansicht und die erweiterte Ansicht. Sie können den Plan auch vergrößern und verkleineren, indem Sie auf die Lupe in der Ecke des Plans klicken.

Es gibt zwei Hauptansichten, die verkürzte Ansicht und die erweiterte Ansicht. Sie können den Plan auch vergrößern und verkleineren, indem Sie auf die Lupe rechts neben dem Plan klicken.

  • Verkürzte Ansicht

    In der verkürzten Ansicht sind alle Arbeitselementkarten reduziert , sodass nicht alle Karteninformationen angezeigt werden. Diese Ansicht ist nützlich für eine Gesamtansicht der Arbeit im Plan. Um die Kartenfelder zu reduzieren, klicken Sie auf das Kartensymbol neben den Vergrößerungssymbolen auf der rechten Seite des Plans.

    Hier sehen Sie ein Beispiel für einen Plan, der zwischen den verkürzten und erweiterten Ansichten umschaltet.

    Gif zur Demo der verkürzten Ansicht.

  • Erweiterte Ansicht

    In der erweiterten Ansicht wird der Fortschritt eines Arbeitselements angezeigt, indem die Anzahl der untergeordneten und verknüpften Elemente gezählt und der Prozentsatz der abgeschlossenen Elemente angezeigt wird. Der Aktuelle Fortschritt wird durch die Anzahl der Arbeitselemente bestimmt.

    Hier sehen Sie ein Beispiel für einen Plan mit einer erweiterten Ansicht. Beachten Sie die Statusanzeigen und den Prozentsatz abgeschlossen.

    Beispiel für einen Plan mit einer erweiterten Ansicht

Abhängigkeitsüberwachung

Die Abhängigkeitsnachverfolgung basiert auf Vorgänger- und Nachfolgerlinks, die in Arbeitselementen definiert werden. Wenn diese Verknüpfungen nicht definiert sind, werden keine Abhängigkeitszeilen angezeigt. Wenn ein Abhängigkeitsproblem mit einem Arbeitselement vorliegt, wird das Abhängigkeitslinksymbol rot eingefärbt.

Abhängigkeitsnachverfolgung mit Abhängigkeitssymbol in Rot zum Anzeigen von Abhängigkeiten

  • Anzeigen von Abhängigkeiten

    Bestimmte Abhängigkeiten werden über den Abhängigkeitsbereich angezeigt, in dem alle Abhängigkeiten für dieses Arbeitselement einschließlich der Richtung angezeigt werden. Ein rotes Ausrufezeichen weist auf ein Abhängigkeitsproblem hin. Klicken Sie zum Öffnen des Bereichs einfach auf das Abhängigkeitslinksymbol in der oberen rechten Ecke der Karte. Hier finden Sie Beispiele für Abhängigkeiten.

    Beispiel für das Anzeigen von Abhängigkeiten

    Ein weiteres Beispiel für das Anzeigen von Abhängigkeiten

  • Abhängigkeitslinien

    Abhängigkeiten zwischen Arbeitselementen werden mit richtungsgerichteten Pfeillinien zwischen den jeweiligen Arbeitselementen visualisiert. Mehrere Abhängigkeiten werden als mehrere Zeilen angezeigt. Eine rote Linie weist auf ein Problem hin.

    Die folgende Auflistung enthält einige Beispiele:

    Abhängigkeiten von Arbeitselementen, die mit richtungsgerichteten Pfeillinien zwischen den jeweiligen Arbeitselementen visualisiert werden

    Hier sehen Sie ein Beispiel für ein Arbeitselement mit mehreren Abhängigkeiten, das auch mit der verkürzten Ansicht funktioniert.

    Beispiel für ein Arbeitselement mit mehreren Abhängigkeiten in der verkürzten Ansicht

    Wenn ein Problem vorliegt, ist die Linienfarbe rot, ebenso das Abhängigkeitssymbol.

    Beispiel:

    Beispiel für ein Arbeitselement mit mehreren Abhängigkeiten

Kartenformatierung

Karten können jetzt mithilfe von Regeln wie den Kanban-Boards formatiert werden. Öffnen Sie die Planeinstellungen, und klicken Sie auf Formatvorlagen. Klicken Sie im Bereich Formatvorlagen auf + Formatvorlage hinzufügen , um die Regel hinzuzufügen, und klicken Sie dann auf Speichern. Es kann bis zu 10 Regeln geben, und jede Regel kann bis zu 5 Klauseln enthalten.

Formatierungseinstellungen

  • vor

Kartenformatierung vor

  • Danach

Kartenformatierung nach

Weitere Informationen zu Lieferplänen finden Sie in der Dokumentation.

Entfernte Elemente im Hub für Arbeitselemente

Im Hub für Arbeitselemente wird eine Liste der Elemente angezeigt, die Sie erstellt haben oder die Ihnen zugewiesen sind. Es bietet mehrere personalisierte Pivot- und Filterfunktionen, um das Auflisten von Arbeitselementen zu optimieren. Eine der häufigsten Beschwerden des Pivots Zugewiesen für mich ist, dass entfernte Arbeitselemente angezeigt werden. Wir stimmen zu, dass entfernte Arbeitselemente nicht mehr von Wert sind und nicht im Backlog enthalten sein sollten. In diesem Sprint werden alle Entfernten Elemente aus den Ansichten Mir zugewiesen im Arbeitselemente-Hub ausgeblendet.

Im Abschnitt "Entwicklung" in einem Arbeitselement wird die Liste der relevanten Commits und Pull Requests angezeigt. 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.

Entfernen der Möglichkeit zum Herunterladen einer gelöschten Anlage aus dem Arbeitselementverlauf

Es wurde ein kleines Problem behoben, bei dem Benutzer Anlagen aus dem Arbeitselementverlauf herunterladen konnten, auch nachdem die Anlage aus dem Formular entfernt wurde. Nachdem die Anlage entfernt wurde, kann sie nicht aus dem Verlauf heruntergeladen werden, noch ist die Download-URL in der REST-API-Antwort verfügbar.

Der Wert "Will not Fix" (Wird nicht korrigiert) wurde zum Fehlerursachenfeld hinzugefügt.

Wie bei allen anderen Arbeitselementtypen verfügt der Arbeitselementtyp Fehler über einen klar definierten Workflow. Jeder Workflow besteht aus drei oder mehr Status und einem Grund. Gründe geben an, warum das Element von einem Zustand in einen anderen gewechselt ist. Mit diesem Update wurde der Wert Will not fix reason für die Fehlerarbeitselementtypen im Agile-Prozess hinzugefügt. Der Wert steht als Grund zur Verfügung, wenn Fehler von "Neu" oder "Aktiv" in "Aufgelöst" verschoben werden. Weitere Informationen zum Definieren, Erfassen, Selektieren und Verwalten von Softwarefehlern finden Sie in Azure Boards Dokumentation.

Pipelines

Entfernen von Aufbewahrungsrichtlinien pro Pipeline in klassischen Builds

Sie können jetzt Aufbewahrungsrichtlinien sowohl für klassische Builds als auch für YAML-Pipelines in den Azure DevOps-Projekteinstellungen konfigurieren. Aufbewahrungsregeln pro Pipeline für klassische Buildpipelines werden nicht mehr unterstützt. Obwohl dies die einzige Möglichkeit ist, die Aufbewahrung für YAML-Pipelines zu konfigurieren, können Sie auch die Aufbewahrung für klassische Buildpipelines pro Pipeline konfigurieren. Wir haben alle Aufbewahrungsregeln pro Pipeline für klassische Buildpipelines in einem bevorstehenden Release entfernt.

Was dies für Sie bedeutet: Jede klassische Buildpipeline, die früher über Aufbewahrungsregeln pro Pipeline verfügte, wird durch die Aufbewahrungsregeln auf Projektebene gesteuert.

Um sicherzustellen, dass Sie beim Upgrade keine Builds verlieren, erstellen wir eine Lease für alle Builds, die zum Zeitpunkt des Upgrades vorhanden sind und keine Lease besitzen.

Es wird empfohlen, die Aufbewahrungseinstellungen auf Projektebene nach dem Upgrade zu überprüfen. Wenn Ihre Pipeline speziell benutzerdefinierte Regeln erfordert, können Sie eine benutzerdefinierte Aufgabe in Ihrer Pipeline verwenden. Informationen zum Hinzufügen von Aufbewahrungsleases über eine Aufgabe finden Sie in der Dokumentation zum Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests.

Neue Steuerelemente für Umgebungsvariablen in Pipelines

Der Azure Pipelines-Agent überprüft die Standardausgabe auf spezielle Protokollierungsbefehle und führt sie aus. Der setVariableBefehl kann verwendet werden, um eine Variable festzulegen oder eine zuvor definierte Variable zu ändern. Dies kann möglicherweise von einem Akteur außerhalb des Systems ausgenutzt werden. Wenn Ihre Pipeline beispielsweise über einen Schritt verfügt, der die Liste der Dateien auf einem FTP-Server ausgibt, kann eine Person mit Zugriff auf den FTP-Server eine neue Datei hinzufügen, deren Name den setVariable Befehl enthält und dazu führt, dass die Pipeline ihr Verhalten ändert.

Wir haben viele Benutzer, die sich darauf verlassen, Variablen mithilfe des Protokollierungsbefehls in ihrer Pipeline festzulegen. Mit dieser Version nehmen wir die folgenden Änderungen vor, um das Risiko unerwünschter Verwendungen des setVariable Befehls zu verringern.

  • Wir haben ein neues Konstrukt für Aufgabenautoren hinzugefügt. Durch Einfügen eines Codeausschnitts wie dem folgenden in task.jsonkann ein Aufgabenautor steuern, ob Variablen durch seine Aufgabe festgelegt werden.
{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 
  • Darüber hinaus aktualisieren wir eine Reihe von integrierten Aufgaben, z. B. SSH, damit sie nicht ausgenutzt werden können.

  • Schließlich können Sie jetzt YAML-Konstrukte verwenden, um zu steuern, ob ein Schritt Variablen festlegen kann.

steps:
- script: echo hello
  target:
    settableVariables: none
steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Generieren von uneingeschränkten Token für Forkbuilds

GitHub Enterprise-Benutzer verwenden häufig Forks, um zu einem Upstreamrepository beizutragen. Wenn Azure Pipelines Beiträge aus einem Fork eines GitHub Enterprise-Repositorys erstellt, schränkt es die Berechtigungen ein, die dem Auftragszugriffstoken gewährt werden, und der Zugriff auf Pipelinegeheimnisse durch solche Aufträge ist nicht zulässig. Weitere Informationen zur Sicherheit von Bau-Forks finden Sie in unserer Dokumentation.

Dies kann in solchen geschlossenen Umgebungen restriktiver sein als gewünscht, in denen Benutzer weiterhin von einem Modell für die Zusammenarbeit mit einer internen Quelle profitieren können. Sie können zwar eine Einstellung in einer Pipeline konfigurieren, um Geheimnisse für Forks verfügbar zu machen, es gibt jedoch keine Einstellung zum Steuern des Auftragszugriffstokenbereichs. Mit dieser Version geben wir Ihnen die Möglichkeit, ein reguläres Auftragszugriffstoken auch für Builds von Forks zu generieren.

Sie können diese Einstellung über Trigger im Pipeline-Editor ändern. Bevor Sie diese Einstellung ändern, stellen Sie sicher, dass Sie die Auswirkungen der Aktivierung dieser Konfiguration auf die Sicherheit vollständig verstehen.

Generieren von uneingeschränkten Token für Forkbuilds

Repositorys als geschützte Ressource in YAML-Pipelines

Sie können Ihr Azure DevOps-Projekt so organisieren, dass es viele Unterprojekte hostet – jedes mit einem eigenen Azure DevOps-Git-Repository und einer oder mehreren Pipelines. In dieser Struktur können Sie steuern, welche Pipelines auf welche Repositorys zugreifen können. Angenommen, Sie haben zwei Repositorys A und B im selben Projekt und zwei Pipelines X und Y, die normalerweise diese Repositorys erstellen. Möglicherweise möchten Sie verhindern, dass Pipeline Y auf Repository A zugreift. Im Allgemeinen möchten Sie, dass die Mitwirkenden von A steuern, auf welche Pipelines sie Zugriff gewähren möchten.

Obwohl dies teilweise mit Azure Git-Repositorys und -Pipelines möglich war, gab es keine Erfahrung für die Verwaltung. Dieses Feature schließt diese Lücke. Azure Git-Repositorys können jetzt wie Dienstverbindungen und Agentpools als geschützte Ressourcen in YAML-Pipelines behandelt werden.

Als Mitwirkender von Repository A können Sie Ihrem Repository Überprüfungen und Pipelineberechtigungen hinzufügen. Navigieren Sie dazu zu den Projekteinstellungen, wählen Sie Repositorys und dann Ihr Repository aus. Sie werden ein neues Menü mit dem Namen "Checks" bemerken, in dem Sie jede der im Kontrollkästchen enthaltenen oder benutzerdefinierten Überprüfungen in Form von Azure-Funktionen konfigurieren können.

Hinzufügen von Überprüfungen

Auf der Registerkarte "Sicherheit" können Sie die Liste der Pipelines verwalten, die auf das Repository zugreifen können.

Verwalten der Liste der Pipelines auf der Registerkarte

Immer wenn eine YAML-Pipeline ein Repository verwendet, überprüft und stellt die Azure Pipelines-Infrastruktur sicher, dass alle Überprüfungen und Berechtigungen erfüllt sind.

Hinweis

Diese Berechtigungen und Überprüfungen gelten nur für YAML-Pipelines. Klassische Pipelines erkennen diese neuen Features nicht.

Berechtigungen und Überprüfungen für Variablengruppen und sichere Dateien

Sie können verschiedene Arten von freigegebenen Ressourcen in YAML-Pipelines verwenden. Beispiele hierfür sind Dienstverbindungen, Variablengruppen, sichere Dateien, Agentpools, Umgebungen oder Repositorys. Um eine Pipeline vor dem Zugriff auf eine Ressource zu schützen, kann der Besitzer der Ressource Berechtigungen und Überprüfungen für diese Ressource konfigurieren. Jedes Mal, wenn eine Pipeline versucht, auf die Ressource zuzugreifen, werden alle konfigurierten Berechtigungen und Überprüfungen ausgewertet. Diese Schutzmaßnahmen sind für Dienstverbindungen, Umgebungen und Agentpools seit einer Weile verfügbar. Sie wurden kürzlich zu Repositorys hinzugefügt. Mit dieser Version fügen wir den gleichen Schutz für Variablengruppen und sichere Dateien hinzu.

Verwenden Sie das Feature Pipelines-Berechtigungen , um den Zugriff auf eine Variablengruppe oder eine sichere Datei auf eine kleine Gruppe von Pipelines einzuschränken.

Meine geheimen Variablen

Verwenden Sie zum Konfigurieren von Überprüfungen oder Genehmigungen, die bei jeder Ausführung einer Pipeline ausgewertet werden sollen, das Feature Genehmigungen und Überprüfungen für Bibliothek .

Hinzufügen der Überprüfungsgenehmigung

Änderungen bei der automatischen Erstellung von Umgebungen

Wenn Sie eine YAML-Pipeline erstellen und auf eine Umgebung verweisen, die nicht vorhanden ist, erstellt Azure Pipelines die Umgebung automatisch. Diese automatische Erstellung kann entweder im Benutzerkontext oder im Systemkontext erfolgen. In den folgenden Flows kennt Azure Pipelines den Benutzer, der den Vorgang ausführt:

  • Sie verwenden den YAML-Pipelineerstellungs-Assistenten in der Azure Pipelines-Weboberfläche und verweisen auf eine Umgebung, die noch nicht erstellt wurde.
  • Sie aktualisieren die YAML-Datei mithilfe des Azure Pipelines-Web-Editors und speichern die Pipeline, nachdem Sie einen Verweis auf eine Umgebung hinzugefügt haben, die nicht vorhanden ist. In jedem der oben genannten Fälle verfügt Azure Pipelines über ein klares Verständnis des Benutzers, der den Vorgang ausführt. Daher wird die Umgebung erstellt und der Benutzer der Administratorrolle für die Umgebung hinzugefügt. Dieser Benutzer verfügt über alle Berechtigungen, um die Umgebung zu verwalten und/oder andere Benutzer in verschiedene Rollen für die Verwaltung der Umgebung einzuschließen.

In den folgenden Flows verfügt Azure Pipelines nicht über Informationen zum Benutzer, der die Umgebung erstellt: Sie aktualisieren die YAML-Datei mithilfe eines anderen externen Code-Editors, fügen einen Verweis auf eine Umgebung hinzu, die nicht vorhanden ist, und führen dann dazu, dass eine Continuous Integration-Pipeline ausgelöst wird. In diesem Fall kennt Azure Pipelines den Benutzer nicht. Zuvor haben wir diesen Fall behandelt, indem wir alle Projektmitwirkenden der Administratorrolle der Umgebung hinzugefügt haben. Jedes Mitglied des Projekts kann dann diese Berechtigungen ändern und verhindern, dass andere auf die Umgebung zugreifen.

Wir haben Ihr Feedback zum Erteilen von Administratorberechtigungen für eine Umgebung für alle Mitglieder eines Projekts erhalten. Als wir Ihr Feedback gehört haben, haben wir gehört, dass wir keine automatische Umgebung erstellen sollten, wenn nicht klar ist, wer der Benutzer ist, der den Vorgang ausführt. Mit dieser Version haben wir Änderungen an der automatischen Erstellung von Umgebungen vorgenommen:

  • In Zukunft wird bei Pipelineausführungen nicht automatisch eine Umgebung erstellt, wenn sie nicht vorhanden ist und der Benutzerkontext nicht bekannt ist. In solchen Fällen schlägt die Pipeline mit dem Fehler Umgebung nicht gefunden fehl. Sie müssen die Umgebungen mit der richtigen Sicherheits- und Überprüfungskonfiguration vorab erstellen, bevor Sie sie in einer Pipeline verwenden.
  • Pipelines mit bekanntem Benutzerkontext erstellen weiterhin automatisch Umgebungen wie in der Vergangenheit.
  • Abschließend ist zu beachten, dass das Feature zum automatischen Erstellen einer Umgebung nur hinzugefügt wurde, um den Prozess der ersten Schritte mit Azure Pipelines zu vereinfachen. Es war für Testszenarien gedacht und nicht für Produktionsszenarien. Sie sollten immer Produktionsumgebungen mit den richtigen Berechtigungen und Überprüfungen vorab erstellen und diese dann in Pipelines verwenden.

Entfernen des Insights-Dialogs aus der Buildpipeline

Basierend auf Ihrem Feedback wurde das Dialogfeld "Aufgaben-/Pipelineeinblicke", das beim Navigieren in der Buildpipeline angezeigt wird, entfernt, um den Workflow zu verbessern. Die Pipelineanalysen sind weiterhin verfügbar, damit Sie über die erforderlichen Erkenntnisse verfügen.

Unterstützung für sequenzielle Bereitstellungen anstelle der neuesten 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 allgemeinen Überprüfungen, die Sie verwenden können, ist eine exklusive Sperrüberprüfung. Bei dieser Überprüfung kann nur eine einzelne Ausführung über die Pipeline fortgesetzt werden. Wenn mehrere Ausführungen gleichzeitig versuchen, in einer Umgebung bereitzustellen, werden durch die Überprüfung alle alten Ausführungen abgebrochen und die bereitstellung der letzten Ausführung ermöglicht.

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 fortgesetzt und sequenziell in einer Umgebung 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 namens lockBehavior in der YAML-Pipelinedatei angeben. Der Wert impliziert sequential , dass alle Ausführungen die Sperre sequenziell für die geschützte Ressource abrufen. Der Wert impliziert runLatest , dass nur die letzte Ausführung die Sperre für die Ressource erhält.

Führen Sie die folgenden Schritte aus, um die exklusive Sperrüberprüfung mit sequential Bereitstellungen oder runLatestzu verwenden:

  1. Aktivieren Sie die exklusive Sperrüberprüfung für die Umgebung (oder eine andere geschützte Ressource).
  2. Geben Sie in der YAML-Datei für die Pipeline eine neue Eigenschaft namens an lockBehavior. Dies kann für die gesamte Pipeline oder für eine bestimmte Phase angegeben werden:

Auf einer Bühne festlegen:

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

Legen Sie für die Pipeline fest:

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

Wenn Sie kein 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 in 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 aus dem Service Now Store ein Upgrade auf die neue Version der App (4.188.0) aus. Weitere Informationen finden Sie unter Integrieren in ServiceNow Change Management.

Neue bedingte YAML-Ausdrücke

Das Schreiben von bedingten Ausdrücken in YAML-Dateien wurde durch die Verwendung von ${{ else }} - und ${{ elseif }} -Ausdrücken einfacher. Im Folgenden finden Sie Beispiele für die Verwendung dieser Ausdrücke in YAML-Pipelinedateien.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg
variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Unterstützung für Wildcards in Pfadfiltern

Wildcards können verwendet werden, wenn Einschluss- und Ausschlussbranches für CI- oder PR-Trigger in einer YAML-Pipelinedatei angegeben werden. Sie können jedoch nicht verwendet werden, wenn Pfadfilter angegeben werden. Beispielsweise können Sie nicht alle Pfade einschließen, die übereinstimmen src/app/**/myapp*. Dies wurde von mehreren Kunden als Unannehmlichkeit bezeichnet. Dieses Update füllt diese Lücke. Jetzt können Sie Beim Angeben von Pfadfiltern Wildcardzeichen (**, *oder ?) verwenden.

Die Standard-Agent-Spezifikation für Pipelines lautet Windows-2022.

Das windows-2022 Image ist bereit, die Standardversion für die windows-latest Bezeichnung in Von Microsoft gehosteten Azure Pipelines-Agents zu sein. Bisher verweist diese Bezeichnung auf Windows-2019-Agents. Diese Änderung wird ab dem 17. Januar über mehrere Wochen eingeführt. Wir planen, die Migration bis März abzuschließen.

Azure Pipelines wird seit September 2021 unterstützt windows-2022 . Wir haben Ihr Feedback überwacht, um die windows-2022 Bildstabilität zu verbessern, und jetzt sind wir bereit, es als das neueste festzulegen.

Das windows-2022 Bild enthält Visual Studio 2022. Eine vollständige Liste der Unterschiede zwischen windows-2022 und windows-2019finden Sie im GitHub-Problem. Eine vollständige Liste der im Image installierten Software finden Sie hier.

Pipelineordnerumbenennung überprüft Berechtigungen

Ordner, die Pipelines enthalten, können umbenannt werden. Das Umbenennen eines Ordners ist jetzt nur erfolgreich, wenn der Benutzer über Bearbeitungsberechtigungen für mindestens eine Pipeline verfügt, die im Ordner enthalten ist.

Planung des Pipelines-Agent-Runtimeupgrades

Was ist der Pipeline-Agent?

Der Azure DevOps-Pipeline-Agent ist das Softwareprodukt, das auf einem Pipelinehost ausgeführt wird, um Pipelineaufträge auszuführen. Sie wird auf von Microsoft gehosteten Agents, Skalierungsgruppen-Agents und selbstgehosteten Agents ausgeführt. Im letzteren Fall installieren Sie es selbst. Der Pipeline-Agent besteht aus einem Listener und Worker (implementiert in .NET), der Worker führt Aufgaben aus, die entweder in Node oder PowerShell implementiert sind und daher diese Laufzeiten für sie hosten.

Bevorstehendes Upgrade auf .NET 6 & Red Hat 6 wird eingestellt

Mit der Veröffentlichung von .NET 6 können wir die neuen plattformübergreifenden Funktionen nutzen. Insbesondere werden wir in der Lage sein, native Kompatibilität für Apple Silicon und Windows Arm64 bereitzustellen. Daher planen wir, in den kommenden Monaten auf .NET 6 für Pipeline-Agent (Listener und Worker) umzusteigen.

Aufgrund einer Reihe von Einschränkungen, die dadurch auferlegt werden, werden wir die Unterstützung für Red Hat Enterprise Linux 6 vom 30. April 2022 aus unserem Agent entfernen.

Aktualisierungen zum Azure-Dateikopiertask

Wir stellen eine neue Version des Azure-Dateikopiertasks bereit. Diese Aufgabe wird verwendet, um Dateien in Microsoft Azure-Speicherblobs oder virtuelle Computer (VMs) zu kopieren. Die neue Version enthält mehrere Updates, die häufig von der Community angefordert wurden:

  • Die Version des AzCopy-Tools wurde auf 10.12.2 aktualisiert, das Dateiinhaltstypen unterstützt. Daher wird beim Kopieren von PDF, Excel, PPT oder einem der unterstützten MIME-Typen der Inhaltstyp der Datei ordnungsgemäß festgelegt.

  • Mit der neuen Version von AzCopy können Sie auch eine Einstellung konfigurieren, um das Ziel zu bereinigen, wenn der Zieltyp Azure Blob ist. Wenn Sie diese Option festlegen, werden alle Ordner/Dateien in diesem Container gelöscht. Wenn ein Blobpräfix bereitgestellt wird, werden alle Ordner/Dateien in diesem Präfix gelöscht.

  • Die neue Version der Aufgabe basiert auf Az-Modulen, die auf dem Agent anstelle von AzureRM-Modulen installiert werden. Dadurch wird in einigen Fällen bei Verwendung der Aufgabe eine unnötige Warnung entfernt.

Die Änderungen sind Teil eines Hauptversionsupdates für diese Aufgabe. Sie müssen Ihre Pipelines explizit aktualisieren, um die neue Version zu verwenden. Wir haben diese Wahl getroffen, um die Hauptversion zu aktualisieren, um sicherzustellen, dass keine Pipelines unterbrochen werden, die noch von AzureRM-Modulen abhängig sind.

Neue Erweiterungspunkte für die Detailansicht von Pipelines

Wir haben zwei neue Erweiterbarkeitspunkte hinzugefügt, die Sie in Ihren Erweiterungen als Ziel verwenden können. Mit diesen Erweiterbarkeitspunkten können Sie eine benutzerdefinierte Schaltfläche im Pipelineheader und ein benutzerdefiniertes Menü für einen Pipelineordner hinzufügen:

  • Benutzerdefinierte Schaltfläche im Pipelineheader: ms.vss-build-web.pipelines-header-menu
  • Benutzerdefiniertes Menü in einem Pipelineordner: ms.vss-build-web.pipelines-folder-menu

Um diese neuen Erweiterbarkeitspunkte zu verwenden, fügen Sie einfach einen neuen Beitrag hinzu, der auf sie abzielt, in der vss-extension.json Manifestdatei Ihrer Azure DevOps-Erweiterung.

Zum Beispiel:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Das Ergebnis ist:

  • Schaltfläche "Benutzerdefinierte" im Pipelineheader

    Schaltfläche

  • Benutzerdefiniertes Menü in einem Pipelineordner

    Benutzerdefiniertes Menü in einem Pipelineordner

Verbesserte Migration zu Azure DevOps Services

Wenn Sie einen Import von Azure DevOps Server in Azure DevOps Services ausführen, müssen Sie berücksichtigen, dass Azure DevOps keine Aufbewahrungsregeln pro Pipeline mehr unterstützt. Mit diesem Update wurden diese Richtlinien entfernt, wenn Sie zu Azure DevOps Services aus Ihrem lokalen Azure DevOps Server migrieren. Weitere Informationen zum Konfigurieren von Aufbewahrungsrichtlinien finden Sie in unserer Dokumentation zum Festlegen von Aufbewahrungsrichtlinien für Builds, Releases und Tests.

Verbesserung der REST-API für Pipelineausführungen

Zuvor hat die REST-API für Pipelineausführungen nur das self Repository zurückgegeben. Mit diesem Update gibt die REST-API für Pipelineausführungen alle Repositoryressourcen eines Builds zurück.

Erweiterte YAML-Pipelines-Vorlagen können jetzt Kontextinformationen für Phasen, Aufträge und Bereitstellungen übergeben werden.

Mit diesem Update fügen wir eine neue templateContext Eigenschaft für job, deploymentund stage YAML-Pipelinekomponenten hinzu, die in Verbindung mit Vorlagen verwendet werden sollen.

Im Folgenden finden Sie ein Szenario für die Verwendung templateContextvon :

  • Sie verwenden Vorlagen, um die Codeduplizierung zu reduzieren oder die Sicherheit Ihrer Pipelines zu verbessern.

  • Ihre Vorlage verwendet als Parameter eine Liste von stages, jobsoder deployments

  • Die Vorlage verarbeitet die Eingabeliste und führt einige Transformationen für die einzelnen Phasen, Aufträge oder Bereitstellungen durch. Sie legt beispielsweise die Umgebung fest, in der jeder Auftrag ausgeführt wird, oder fügt zusätzliche Schritte hinzu, um die Konformität zu erzwingen.

  • Für die Verarbeitung müssen zusätzliche Informationen vom Pipelineautor an die Vorlage für jede Phase, jeden Auftrag oder jede Bereitstellung in der Liste übergeben werden.

Schauen wir uns ein Beispiel an. Angenommen, Sie erstellen eine Pipeline, die End-to-End-Tests für die Überprüfung von Pull Request ausführt. Ihr Ziel ist es, nur eine Komponente Ihres Systems zu testen. Da Sie jedoch End-to-End-Tests ausführen möchten, benötigen Sie eine Umgebung, in der mehr Komponenten des Systems verfügbar sind, und Sie müssen deren Verhalten angeben.

Sie erkennen, dass andere Teams ähnliche Anforderungen haben werden, daher entscheiden Sie sich, die Schritte zum Einrichten der Umgebung in eine Vorlage zu extrahieren. Der Code sieht wie folgt aus:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Die Vorlage legt für jeden Auftrag im testSet Parameter die Antwort der systemeigenen Komponenten fest, die durch ${{ testJob.templateContext.requiredComponents }} angegeben werden, um ${{ testJob.templateContext.expectedHTTPResponseCode }} zurückzugeben.

Anschließend können Sie eine eigene Pipeline erstellen, die wie im folgenden Beispiel erweitert wird testing-template.yml .

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Diese Pipeline führt zwei Tests aus, einen positiven und einen negativen. Beide Tests erfordern, dass die dimensionsapi Komponente verfügbar ist. Der positive_test Auftrag erwartet den dimensionsapi HTTP-Rückgabecode 200, während negative_test er HTTP-Code 500 zurückgibt.

Unterstützung von gruppenverwalteten Dienstkonten als Agent-Dienstkonto

Der Azure Pipelines-Agent unterstützt jetzt gruppenverwaltete Dienstkonten auf selbstgehosteten Agents unter Windows.

Gruppenverwaltete Dienstkonten bieten eine zentralisierte Kennwortverwaltung für Domänenkonten, die als Dienstkonten fungieren. Der Azure Pipelines-Agent kann diesen Kontotyp erkennen, sodass während der Konfiguration kein Kennwort erforderlich ist:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Informationsausführungen

Eine Informationsausführung teilt Ihnen mit, dass Azure DevOps den Quellcode einer YAML-Pipeline nicht abrufen konnte. Eine solche Ausführung sieht wie folgt aus.

Kürzlich ausgeführte Pipelines

Azure DevOps ruft den Quellcode einer YAML-Pipeline als Reaktion auf externe Ereignisse ab, z. B. einen gepushten Commit oder als Reaktion auf interne Trigger, um z. B. zu überprüfen, ob Codeänderungen vorliegen und eine geplante Ausführung zu starten. Wenn dieser Schritt fehlschlägt, erstellt das System eine Informationsausführung. Diese Ausführungen werden nur erstellt, wenn sich der Code der Pipeline in einem GitHub- oder BitBucket-Repository befindet.

Das Abrufen des YAML-Codes einer Pipeline kann aus folgenden Gründen fehlschlagen:

  • Beim Repositoryanbieter tritt ein Ausfall auf
  • Anforderungsdrosselung
  • Authentifizierungsprobleme
  • Der Inhalt der YML-Datei der Pipeline kann nicht abgerufen werden.

Erfahren Sie mehr über Informationsausführungen.

Rest-API-Eigenschaft retentionRules der Builddefinition ist veraltet

Im Antworttyp der Builddefinitions-REST-APIBuildDefinition ist die retentionRules Eigenschaft jetzt als veraltet markiert, da diese Eigenschaft immer einen leeren Satz zurückgibt.

Repos

Neue TFVC-Seiten

Wir haben verschiedene Seiten in Azure DevOps aktualisiert, um eine neue Webplattform zu verwenden, mit dem Ziel, die Benutzeroberfläche für die verschiedenen Dienste konsistenter und zugänglicher zu machen. TFVC-Seiten wurden aktualisiert, um die neue Webplattform zu verwenden. Mit dieser Version machen wir die neuen TFVC-Seiten allgemein verfügbar.

Deaktivieren eines Repositorys

Kunden haben oft eine Möglichkeit angefordert, um ein Repository zu deaktivieren und zu verhindern, dass Benutzer auf seine Inhalte zugreifen. Dies können Sie beispielsweise in folgenden Fällen tun:

  • Sie haben ein Geheimnis im Repository gefunden.
  • Ein Überprüfungstool eines Drittanbieters hat festgestellt, dass ein Repository nicht konform ist.

In solchen Fällen können Sie das Repository vorübergehend deaktivieren, während Sie an der Behebung des Problems arbeiten. Mit diesem Update können Sie ein Repository deaktivieren, wenn Sie über die Berechtigung Repository löschen verfügen. Wenn Sie ein Repository deaktivieren, gehen Sie wie folgt vor:

  • Kann das Repository in der Liste der Repositorys auflisten.
  • Der Inhalt des Repositorys kann nicht gelesen werden.
  • Der Inhalt des Repositorys kann nicht aktualisiert werden.
  • Sehen Sie sich eine Meldung an, dass das Repository deaktiviert wurde, wenn sie versuchen, auf das Repository in der Azure Repos-Benutzeroberfläche zuzugreifen.

Nachdem die erforderlichen Schritte zur Entschärfung ausgeführt wurden, können Benutzer mit der Berechtigung Repository löschen das Repository erneut aktivieren. Um ein Repository zu deaktivieren oder zu aktivieren, wechseln Sie zu Projekteinstellungen, wählen Sie Repositorys und dann das jeweilige Repository aus.

Deaktivieren eines Repositorys

Konfigurieren von Brancherstellern, um keine "Berechtigungen verwalten" für ihre Branches zu erhalten

Wenn Sie einen neuen Branch erstellen, erhalten Sie "Berechtigungen verwalten" für diesen Branch. Mit dieser Berechtigung können Sie die Berechtigungen anderer Benutzer ändern oder zusätzlichen Benutzern einen Beitrag zu diesem Branch gewähren. Beispielsweise kann ein Branchersteller diese Berechtigung verwenden, um einem anderen externen Benutzer zu erlauben, Änderungen am Code vorzunehmen. Oder sie können zulassen, dass eine Pipeline (Builddienstidentität) den Code in diesem Branch ändert. In bestimmten Projekten mit höheren Complianceanforderungen sollten Benutzer solche Änderungen nicht vornehmen können.

Mit diesem Update können Sie alle Repositorys in Ihrem Teamprojekt konfigurieren und Branchersteller daran hindern, die Berechtigung "Berechtigungen verwalten" zu erhalten. Navigieren Sie dazu zu den Projekteinstellungen, wählen Sie Repositorys und dann Einstellungen für alle Repositorys oder ein bestimmtes Repository aus.

Einstellungen für alle Repositorys

Diese Einstellung ist standardmäßig aktiviert, um das vorhandene Verhalten nachzuahmen. Sie können es jedoch deaktivieren, wenn Sie dieses neue Sicherheitsfeature nutzen möchten.

Verhindern, dass Fork-Benutzer für ihre Upstream-PRs abstimmen

Mit Azure Repos können Benutzer mit der Berechtigung "Lesen" für ein Repository das Repository forken und Änderungen in ihrem Fork vornehmen. Um einen Pull Request mit ihren Änderungen an der Upstreamversion zu übermitteln, benötigen Benutzer die Berechtigung "Mitwirken an Pull Requests" im Upstream. Diese Berechtigung bestimmt jedoch auch, wer über Pull Requests im Upstreamrepository abstimmen kann. Infolgedessen können Sie in Situationen kommen, in denen ein Benutzer, der kein Mitwirkender am Repository ist, einen Pull Request übermitteln und ihn je nach Einrichtung der Branchrichtlinien zusammenführen kann.

In Projekten, die ein Modell mit innerer Quelle fördern, ist fork-and-contribute ein gängiges Muster. Um dieses Muster weiter zu sichern und zu fördern, ändern wir die Berechtigung zur Abstimmung über einen Pull Request von "Zu Pull Requests beitragen" in "mitwirken". Diese Änderung wird jedoch nicht standardmäßig in allen Projekten vorgenommen. Sie müssen sich anmelden und eine neue Richtlinie für Ihr Repository auswählen, die als "Strikter Abstimmungsmodus" bezeichnet wird, um diese Berechtigung zu ändern. Es wird empfohlen, dies zu tun, wenn Sie sich auf Forks in Azure Repos verlassen.

Repositoryeinstellungen

Berichterstellung

Gruppierung nach Tags, die in Diagrammwidgets verfügbar sind

Das Diagrammwidget Gruppierung nach Tags ist jetzt standardmäßig für alle Kunden verfügbar. Wenn Sie das Diagrammwidget verwenden, ist jetzt eine Option für Tags verfügbar. Benutzer können ihre Informationen visualisieren, indem sie alle Tags oder eine Reihe von Tags im Widget auswählen.


Gruppierung nach Tags, die in Diagrammwidgets verfügbar sind

Anzeigen benutzerdefinierter Arbeitselementtypen im Burndownwidget

Zuvor konnten Sie keine benutzerdefinierten Arbeitselementtypen sehen, die im Burndown-Widget konfiguriert und von einem benutzerdefinierten Feld zusammengefasst oder gezählt wurden. Mit diesem Update wurde dieses Problem behoben, und jetzt können Sie benutzerdefinierte Arbeitselementtypen im Burndownwidget sehen.


Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen, es über Entwicklercommunity nachverfolgen und Sich zu Stack Overflow beraten lassen.


Seitenanfang