Azure DevOpsServer 2020 Update 1 Versionshinweise

| Entwicklercommunity Systemanforderungen Lizenzbedingungen | | DevOps Blog | SHA-1 Hashes

In diesem Artikel finden Sie Informationen zu der neuesten Version 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-Produkte herunterzuladen, besuchen Sie die Seite "Azure DevOps Server Downloads".

Direktes Upgrade auf Azure DevOps Server 2020 wird von Azure DevOps Server 2019 oder Team Foundation Server 2015 oder neuer unterstützt. Wenn sich Ihre TFS-Bereitstellung auf TFS 2010 oder früher befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie auf Azure DevOps Server 2019 aktualisieren. Weitere Informationen finden Sie unter Installieren und Konfigurieren von Azure DevOps lokal.


Sicheres Upgrade von Azure DevOps Server 2019 auf Azure DevOps Server 2020

Azure DevOps Server 2020 führt ein neues Pipeline-Aufbewahrungsmodell (Build) ein, das basierend auf den Einstellungen auf Projektebene funktioniert.

Azure DevOps Server 2020 behandelt die Aufbewahrung von Builddaten unterschiedlich, basierend auf Aufbewahrungsrichtlinien auf Pipelineebene. Bestimmte Richtlinienkonfigurationen führen dazu, dass die Pipeline nach dem Upgrade gelöscht wird. Die Pipeline führt aus, die manuell aufbewahrt oder von einer Version beibehalten wurde, wird nach dem Upgrade nicht gelöscht.

Lesen Sie unseren Blogbeitrag, um weitere Informationen zum sicheren Upgrade von Azure DevOps Server 2019 auf Azure DevOps Server 2020 zu erhalten.

Azure DevOps Server 2020 Update 1.2 Patch 2 Releasedatum: 9. August 2022

Wir haben einen Patch für Azure DevOps Server 2020 Update 1.2 veröffentlicht, der Korrekturen für folgendes enthält.

  • Beheben Des Identitätswertfehlers beim Zuweisen eines Arbeitselements zu einer Identität, die in verschiedenen Domänen angezeigt wird.

Azure DevOps Server 2020 Update 1.2 Patch 1 Releasedatum: 12. Juli 2022

Wir haben einen Patch für Azure DevOps Server 2020 Update 1.2 veröffentlicht, der Korrekturen für folgendes enthält.

  • Bei TestAusführungs-APIs war das zurückgegebene Fortsetzungstoken größer als der wert "maxLastUpdatedDate", der angegeben wurde.

Azure DevOps Server 2020 Update 1.2 Versionsdatum: 17. Mai 2022

Azure DevOps Server 2020 Update 1.2 ist ein Rollup von Fehlerkorrekturen. Sie können Azure DevOps Server 2020 Update 1.2 oder upgraden von Azure DevOps Server 2020 oder Team Foundation Server 2013 oder höher direkt installieren.

Hinweis

Das Datenmigrationstool steht für Azure DevOps Server 2020 Update 1.2 ungefähr drei Wochen nach dieser Version zur Verfügung. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Diese Version enthält Korrekturen für folgendes:

  • Azure DevOps Server 2020.1.2 deaktiviert das neue Aufbewahrungsmodell (eingeführt in Azure DevOps Server 2020), um den Verlust von Pipelineausführungen (Builds) zu verhindern. Dies bedeutet, dass das System:

    • Erstellen von Leases für die neuesten 3 Builds, die beim Ausführen von Server 2020 generiert wurden
    • Für YAML-Pipelines und klassische Pipelines ohne Aufbewahrungsrichtlinien pro Pipeline werden Builds gemäß den maximalen Aufbewahrungseinstellungen auf Auflistungsebene beibehalten.
    • Für klassische Pipelines mit benutzerdefinierten Aufbewahrungsrichtlinien für Pipelines werden Builds gemäß der pipelinespezifischen Aufbewahrungsrichtlinie beibehalten.
    • Die Builds mit Leases zählen nicht auf das Minimum, um die Einstellung beizubehalten
  • Änderungenet- und Regaletkommentarlinks wurden nicht ordnungsgemäß umgeleitet. Wenn Kommentare zu Dateien in Änderungenets oder Regalets hinzugefügt wurden, wurden diese Kommentare nicht an die richtige Stelle in der Dateiansicht umgeleitet.

  • Die Buildwarteschlange kann nicht über die Schaltfläche "Weiter ausführen" überspringen. Zuvor wurde die Schaltfläche "Weiter ausführen" nur für Projektsammlungsadministratoren aktiviert.

  • Widerrufen Sie alle persönlichen Zugriffstoken, nachdem das Active Directory-Konto eines Benutzers deaktiviert ist.

Azure DevOps Server 2020.1.1 Patch 4 Releasedatum: 26. Januar 2022

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

  • Email Benachrichtigungen wurden beim Verwenden des @mention Steuerelements in einem Arbeitselement nicht gesendet.
  • Die bevorzugte E-Mail-Adresse wurde im Benutzerprofil nicht aktualisiert. Dies führte dazu, dass E-Mails an die vorherige E-Mail-Adresse gesendet wurden.
  • Kopfzeile wurde auf der Seite "Projektzusammenfassung" nicht angezeigt. Die Kopfzeile wurde für einige Millisekunden angezeigt und dann verschwunden.
  • Verbesserung der Active Directory-Benutzersynchronisierung.
  • Das Elasticsearch-Sicherheitsrisiko wurde behoben, indem die jndilookup-Klasse aus Log4j-Binärdateien entfernt wurde.

Installationsschritte

  1. Aktualisieren Sie den Server mit Patch 4.
  2. Überprüfen Sie den Registrierungswert unter HKLM:\Software\Elasticsearch\Version. Wenn der Registrierungswert nicht vorhanden ist, fügen Sie einen Zeichenfolgenwert hinzu, und legen Sie die Version auf 5.4.1 fest (Name = Version, Wert = 5.4.1).
  3. Führen Sie den Updatebefehl PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update wie in der Readme-Datei angegeben aus. Möglicherweise wird eine Warnung wie die folgende angezeigt: Es kann keine Verbindung mit dem Remoteserver hergestellt werden. Schließen Sie das Fenster nicht, da das Update so lange wiederholt wird, bis es abgeschlossen ist.

Hinweis

Wenn Azure DevOps Server und Elasticsearch auf verschiedenen Computern installiert sind, führen Sie die unten beschriebenen Schritte aus.

  1. Aktualisieren Sie den Server mit Patch 4.
  2. Überprüfen Sie den Registrierungswert unter HKLM:\Software\Elasticsearch\Version. Wenn der Registrierungswert nicht vorhanden ist, fügen Sie einen Zeichenfolgenwert hinzu, und legen Sie die Version auf 5.4.1 fest (Name = Version, Wert = 5.4.1).
  3. Kopieren Sie den Inhalt des Ordners namens ZIP, der C:\Program Files\{TFS Version Folder}\Search\zip sich im Remotedateiordner elasticsearch befindet.
  4. Führen Sie auf dem Elasticsearch-Servercomputer aus Configure-TFSSearch.ps1 -Operation update .

SHA-256 Hash: 451F0BB73132EFCD2B3D2F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Patch 3 Releasedatum: 15. Dezember 2021

Patch 3 für Azure DevOps Server 2020.1.1 enthält Korrekturen für folgendes.

  • Beheben des Arbeitselementmakros für Abfragen mit "Enthält Wörter". Zuvor wurden Abfragen falsche Ergebnisse für Werte zurückgegeben, die einen Zeilenumbruch enthalten.
  • Erhöhen Sie Grenzwerte für die Länge der Maven-Paketversion.
  • Lokalisierungsproblem für benutzerdefinierte Arbeitselemente layoutzustände.
  • Lokalisierungsproblem in der E-Mail-Benachrichtigungsvorlage.
  • Problem mit NOTSAMEAS-Regelnauswertung, wenn mehrere NOTSAMEAS-Regeln für ein Feld definiert wurden.

Azure DevOps Server 2020.1.1 Patch 2 Releasedatum: 26. Oktober 2021

Patch 2 für Azure DevOps Server 2020.1.1 enthält Korrekturen für folgendes.

  • Zuvor konnte Azure DevOps Server nur Verbindungen mit GitHub Enterprise Server erstellen. Mit diesem Patch können Projektadministratoren Verbindungen zwischen Azure DevOps Server und Repositorys auf GitHub.com erstellen. Diese Einstellung finden Sie auf der Seite "GitHub-Verbindungen " unter "Projekteinstellungen".
  • Problem mit dem Testplan-Widget beheben. Der Testausführungsbericht zeigt einen falschen Benutzer auf Ergebnissen an.
  • Problem mit der Zusammenfassungsseite "Projektübersicht" beheben, die nicht geladen werden kann.
  • Problem mit E-Mails beheben, die nicht gesendet werden, um das Produktupgrade zu bestätigen.

Azure DevOps Server 2020.1.1 Patch 1 Releasedatum: 14. September 2021

Patch 1 für Azure DevOps Server 2020.1.1 enthält Korrekturen für folgendes.

  • Beheben des Fehlers von Artefakten zum Herunterladen/Hochladen.
  • Problem mit inkonsistenten Testergebnissen beheben.

Azure DevOps Server 2020 Update 1.1 Releasedatum: 17. August 2021

Azure DevOps Server 2020 Update 1.1 ist ein Rollup von Fehlerkorrekturen. Sie können Azure DevOps Server 2020 Update 1.1 oder ein Upgrade direkt von Azure DevOps Server 2020 oder Team Foundation Server 2013 oder neuer installieren.

Hinweis

Das Datenmigrationstool steht für Azure DevOps Server 2020 Update 1.1 ungefähr drei Wochen nach dieser Version zur Verfügung. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Diese Version enthält Korrekturen für folgende Fehler:

Azure Boards

  • Der Link "Arbeitselement anzeigen" in den Benachrichtigungs-E-Mails verwendet nicht die öffentliche URL.

Azure Repos

  • Behobene eingeschränkte Seriendrucktypenvererbungsfelder werden angezeigt, um die Änderung von Seriendrucktypen nach der Einstellung von Richtlinien für die Querdruckfunktion zu aktivieren.

Azure Pipelines

  • Beim Ändern der Einstellung für das Agentupdate wurden die Einstellungen nicht an andere Anwendungsebenen in der Umgebung weitergegeben.

Allgemein

  • Die Rechtschreibung im Serverkonfigurations-Assistenten wurde behoben.
  • Erhöhte Erweiterungspaketgröße und ermöglichen Es Ihnen, die Größe in der Registrierung zu ändern.

Azure Test Plans

  • Es kann nicht wieder zu Testergebnissen navigieren, nachdem Sie von der Verlaufsseite auf die Zusammenfassungsseite zurück getroffen haben.

Azure DevOps Server 2020.1 Patch 2 Versionsdatum: 10. August 2021

Wir haben einen Patch für Azure DevOps Server 2020.1 veröffentlicht, der folgendes behoben hat.

  • Beheben sie den Fehler bei der Builddefinitions-UI.
  • Änderte den Browserverlauf, um Dateien anstelle des Stamm-Repositorys anzuzeigen.

Azure DevOps Server 2020.1 Patch 1 Releasedatum: 15. Juni 2021

Wir haben einen Patch für Azure DevOps Server 2020.1 veröffentlicht, der folgendes behoben hat.

  • Sichere Cookies, die in Autorisierungsflüssen verwendet werden, die behaupten SameSite=None.

  • Problem mit dem Benachrichtigungs-SDK beheben. Zuvor wurden Benachrichtigungsabonnements mit dem Bereichspfadfilter nicht ordnungsgemäß analysiert.

Azure DevOps Server 2020.1 RTW Release Date: 25. Mai 2021

Zusammenfassung der Neuerungen in Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW ist ein Rollup von Fehlerkorrekturen. Es enthält alle Features im zuvor veröffentlichten Azure DevOps Server 2020.1 RC2. Azure DevOps Server 2020.1 RTW ist ein Rollup von Fehlerkorrekturen. Sie können Azure DevOps Server 2020.1 oder upgraden von Azure DevOps Server 2020, 2019 oder Team Foundation Server 2015 oder neuer.

Hinweis

Das Datenmigrationstool steht für Azure DevOps Server 2020 Update 1 ungefähr drei Wochen nach dieser Version zur Verfügung. Die Liste der derzeit unterstützten Versionen für den Import finden Sie hier.

Azure DevOps Server 2020.1 RC2 Release Date: 13. April 2021

Zusammenfassung der Neuerungen in Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 ist ein Rollup von Fehlerkorrekturen. Es enthält alle Features im zuvor veröffentlichten Azure DevOps Server 2020.1 RC1.

Azure DevOps Server 2020.1 RC1 Release Date: 23. März 2021

Zusammenfassung der Neuerungen in Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 führt viele neue Features ein. Einige der Highlights sind unter anderem:

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


Boards

Einschränkungsregeln für den Zustandsübergang

Wir schließen weiterhin die Featureparitätslücke zwischen gehosteter XML und dem geerbten Prozessmodell. Mit dieser neuen Arbeitselementtypregel können Sie Arbeitselemente einschränken, die von einem Zustand in einen anderen verschoben werden. Sie können z. B. Fehler einschränken, von "Neu" zu "Aufgelöst" zu wechseln. Stattdessen müssen sie von New –> Active -> Aufgelöst gehen

img

Sie können auch eine Regel erstellen, um Statusübergänge nach Gruppenmitgliedschaft einzuschränken. Beispielsweise können nur Benutzer in der Gruppe "Genehmigende" Benutzergeschichten aus "Neu -> Genehmigt" verschieben.

Kopieren von Arbeitselementen zum Kopieren von Untergeordneten Elementen

Eine der wichtigsten angeforderten Features für Azure Boards ist die Möglichkeit, ein Arbeitselement zu kopieren, das auch die untergeordneten Arbeitselemente kopiert. Wir haben eine neue Option zum Dialogfeld "Untergeordnete Arbeitselemente einschließen" hinzugefügt. Diese Option kopiert das Arbeitselement, und kopieren Sie alle untergeordneten Arbeitselemente (bis zu 100).

Auf dieser Seite wird die neue Option in Azure Boards angezeigt, um untergeordnete Arbeitselemente in ein kopiertes Arbeitselement einzuschließen.

Verbesserte Regeln für aktivierte und aufgelöste Felder

Bis jetzt sind die Regeln für aktiviertes, aktiviertesDatum, Aufgelöst von und Aufgelöstes Datum ein Geheimnis. Sie sind nur für Systemarbeitselementtypen festgelegt und sind spezifisch für den Statuswert "Aktiv" und "Aufgelöst". Wir haben die Logik geändert, damit diese Regeln nicht mehr für einen bestimmten Zustand gelten. Stattdessen werden sie durch die Kategorie (Statuskategorie) ausgelöst, in der sich der Zustand befindet. Angenommen, Sie verfügen über einen benutzerdefinierten Zustand von "Anforderungentests" in der Kategorie "Aufgelöst". Wenn sich das Arbeitselement von "Active" zu "Bedarfstests" ändert, werden die Regeln "Durch" und "AufgelöstesDatum " ausgelöst.

Dadurch können Kunden benutzerdefinierte Statuswerte erstellen und weiterhin das aktivierte Nach-, Aktivierte Datum- und Aufgelöste Datumsfelder generieren, ohne benutzerdefinierte Regeln zu verwenden.

Beteiligte können Arbeitselemente über Diekspalten verschieben

Die Beteiligten konnten immer den Zustand der Arbeitselemente ändern. Wenn sie aber zum Kanban-Board wechseln, können sie die Arbeitselemente nicht von einer Spalte in eine andere verschieben. Stattdessen müssen die Beteiligten jedes Arbeitselement gleichzeitig öffnen und den Statuswert aktualisieren. Dies ist seit langem ein Schmerzpunkt für Kunden, und wir freuen uns, bekannt zu geben, dass Sie jetzt Arbeitselemente über Boardspalten verschieben können.

Systemarbeitselementtypen auf Backlogs und Boards

Jetzt können Sie einen Systemarbeitselementtyp zur Auswahlebene hinzufügen. Bisher sind diese Arbeitselementtypen nur von Abfragen verfügbar.

Prozess Arbeitselementtyp
Agilität Problem
Scrum Impediment
CMMI Change Request
Problem
Überprüfung
Risiko

Das Hinzufügen eines Systemarbeitselementtyps zu einer Backlogebene ist einfach. Wechseln Sie einfach zu Ihrem benutzerdefinierten Prozess, und klicken Sie auf die Registerkarte "Zurücklogstufen". Wählen Sie die Auswahlebene für den Backlog (Beispiel: Anforderungsbacklog) aus, und wählen Sie die Bearbeitungsoption aus. Fügen Sie dann den Arbeitselementtyp hinzu.

Rückstände

Azure Boards GitHub-App-Repolimits ausgelöst

Die Repogrenze für die Azure Boards-Anwendung auf dem GitHub-Marketplace wurde von 100 auf 250 erhöht.

Anpassen des Arbeitselementstatus, wenn die Pullanforderung zusammengeführt wird

Nicht alle Workflows sind identisch. Einige Kunden möchten ihre verwandten Arbeitselemente schließen, wenn eine Pull-Anforderung abgeschlossen ist. Andere möchten die Arbeitselemente auf einen anderen Zustand festlegen, der vor dem Schließen überprüft werden soll. Wir sollten beides zulassen.

Wir haben ein neues Feature, mit dem Sie die Arbeitselemente auf den gewünschten Zustand festlegen können, wenn die Pullanforderung zusammengeführt und abgeschlossen wird. Dazu scannen wir die Pull-Anforderungsbeschreibung, und suchen Sie nach dem Statuswert, gefolgt vom #mention der Arbeitselemente(n). In diesem Beispiel legen wir zwei Benutzergeschichten auf "Aufgelöst" und "Schließen" von zwei Vorgängen fest.

Arbeitselementstatus

Sie können Ihre Buildabhängigkeiten jetzt einfach im gesamten Projekt nachverfolgen, indem Sie Ihre Arbeitsaufgabe nur mit einem Build, einem Build gefunden oder integriert in Build verknüpfen.

Verknüpfen von Arbeitselementen

Bearbeitungsbeschreibung (Hilfetext) auf Systemfeldern

Sie haben immer die Beschreibung von benutzerdefinierten Feldern bearbeiten können. Für Systemfelder wie Priorität, Schweregrad und Aktivität wurde die Beschreibung jedoch nicht bearbeitet. Dies war eine Featurelücke zwischen dem gehosteten XML und Erben, die verhinderte, dass einige Kunden zum Geerbten Modell migrieren. Sie können nun die Beschreibung auf Systemfeldern bearbeiten. Der bearbeitete Wert wirkt sich nur auf dieses Feld im Prozess und für diesen Arbeitselementtyp aus. Dies ermöglicht Ihnen die Flexibilität, unterschiedliche Beschreibungen für dasselbe Feld auf verschiedenen Arbeitselementtypen zu haben.

Beschreibung bearbeiten

Anpassen des Arbeitselementstatus, wenn die Pullanforderung zusammengeführt wird

Pull-Anforderungen verweisen häufig auf mehrere Arbeitselemente. Wenn Sie eine Pullanforderung erstellen oder aktualisieren, möchten Sie möglicherweise einige davon schließen, einige davon auflösen und den Rest geöffnet halten. Sie können jetzt Kommentare wie die in der nachstehenden Abbildung gezeigten Kommentare verwenden, um dies zu erreichen. Weitere Informationen finden Sie in der Dokumentation.

Status anpassen

Übergeordnetes Feld im Taskboard

Aufgrund der beliebten Anforderung können Sie nun das übergeordnete Feld sowohl dem untergeordneten als auch der übergeordneten Karten im Task Board hinzufügen.

übergeordnetes Feld-Taskboard

Entfernen der Regel "Zugewiesen an" im Typ "Fehlerarbeitselement"

Es gibt mehrere ausgeblendete Systemregeln in allen verschiedenen Arbeitselementtypen in Agile, Scrum und CMMI. Diese Regeln sind seit über einem Jahrzehnt vorhanden und haben im Allgemeinen ohne Beschwerden gut gearbeitet. Es gibt jedoch einige Regeln, die ihre Begrüßung auslaufen. Eine Regel hat insbesondere viele Schmerzen für neue und vorhandene Kunden verursacht und wir haben beschlossen, es zu entfernen. Diese Regel ist im Agile-Prozess auf dem Fehler-Arbeitselementtyp vorhanden.

"Legen Sie den zugewiesenen Wert auf "Erstellt nach" fest, wenn der Zustand in "Aufgelöst" geändert wird.

Wir haben viel Feedback zu dieser Regel erhalten. Als Antwort ging es weiter und entfernte diese Regel aus dem Fehler-Arbeitselementtyp im Agile-Prozess. Diese Änderung wirkt sich auf jedes Projekt mit einem geerbten Agile- oder einem angepassten geerbten Agile-Prozess aus. Für diejenigen Kunden, die diese aktuelle Regel mögen und abhängig sind, lesen Sie bitte unseren Blogbeitrag zu den Schritten, die Sie ausführen können, um die Regel mithilfe benutzerdefinierter Regeln neu hinzuzufügen.

Entfernte Elemente auf der Seite "Arbeitselemente"

Die Seite "Arbeitselemente " ist ein hervorragender Ort, um schnell Elemente zu finden, die Sie erstellt haben oder Ihnen zugewiesen sind, unter anderem. Es bietet mehrere personalisierte Pivots und Filter. Eine der wichtigsten Beschwerden für den Pivot "Zugewiesen an mich" besteht darin, dass entfernte Arbeitselemente angezeigt werden (das heißt, Arbeitselemente im Entfernten Zustand). Und wir stimmen zu! Entfernte Elemente sind Arbeit, die nicht mehr von Wert ist und somit aus dem Backlog entfernt wurde, daher ist es in dieser Ansicht nicht hilfreich.

Sie können jetzt alle entfernten Elemente aus dem "Zugewiesen" auf der Seite "Arbeitselemente" ausblenden.

Repos

Standard-Branch-Name-Einstellung

Azure Repos bietet jetzt einen anpassbaren Standardzweignamen für Git. In Repositoryeinstellungen können Sie einen beliebigen Rechtszweignamen auswählen, der verwendet werden soll, wenn ein Repository initialisiert wird. Azure Repos hat immer das Ändern des Standardzweignamens für ein vorhandenes Repository unterstützt. Besuchen Sie die Verwaltung von Zweigstellen , um weitere Details zu erhalten.

 Standardzweigname

Hinweis: Wenn Sie dieses Feature nicht aktivieren, werden Ihre Repositorys mit dem Standardnamen Azure Repos initialisiert. Jetzt ist dieser Standard master. Um das Engagement von Microsoft zu berücksichtigen und Kundenanfragen für inklusive Sprache zu berücksichtigen, werden wir Branchenkollegen beitreten, um diese Standardeinstellung in den Hauptbereich zu ändern. Diese Änderung wird später im Sommer auftreten. Wenn Sie master verwenden möchten, sollten Sie dieses Feature jetzt aktivieren und auf Master festlegen.

Einstellung auf Organisationsebene für Standardzweige

Es gibt jetzt eine Einstellung auf Auflistungsebene für Ihren bevorzugten initialen Zweignamen für neue Repositorys. Wenn ein Projekt keinen ursprünglichen Zweignamen ausgewählt hat, wird diese Einstellung auf Organisationsebene verwendet. Wenn Sie den ursprünglichen Zweignamen in den Organisationseinstellungen oder den Projekteinstellungen nicht angegeben haben, verwenden neue Repositorys einen azure DevOps-definierten Standard.

Verzweigungseinstellung für Organisationsebene

Hinzufügen eines neuen Authentifizierungsbereichs für die Beiträge zu PR-Kommentaren

Diese Version fügt einen neuen OAuth-Bereich zum Lesen/Schreiben von Pull-Anforderungskommentaren hinzu. Wenn Sie über einen Bot oder eine Automatisierung verfügen, die nur mit Kommentaren interagieren muss, können Sie es nur mit diesem Bereich ein PAT geben. Dieser Prozess reduziert den Strahlradius, wenn die Automatisierung einen Fehler aufweist oder das Token kompromittiert wurde.

Verbesserungen der Pull-Anforderung

Die neue Pull-Anforderungsumgebung wurde mit den folgenden Verbesserungen verbessert:

  • Anzeigen der optionalen Überprüfungen

Kunden verwenden optionale Prüfungen, um die Aufmerksamkeit eines Entwicklers auf potenzielle Probleme zu lenken. In der vorherigen Erfahrung war es offensichtlich, wenn diese Überprüfungen fehlschlagen. Das ist jedoch nicht der Fall in der Vorschauumgebung. Ein großes, grünes Häkchen auf den erforderlichen Überprüfungen maskiert die Fehler in optionalen Prüfungen. Benutzer konnten nur feststellen, dass optionale Überprüfungen fehlgeschlagen sind, indem Sie die Systemsteuerung öffnen. Entwickler tun das nicht häufig, wenn kein Problem angegeben wird. In dieser Bereitstellung haben wir den Status optionaler Überprüfungen in der Zusammenfassung sichtbarer gemacht.


Anzeigen der optionalen Überprüfungen


  • Strg-Klicks auf Menüelemente

Registerkartenmenüs in einer PR unterstützt nicht STRG-Klick. Benutzer öffnen häufig neue Browserregisterregister, während sie eine Pullanforderung überprüfen. Dies wurde behoben.

  • Position von [+] Anmerkungen

Die Strukturliste der Dateien in einer PR zeigt eine Anmerkung [+] an, um Autoren und Prüfer zu helfen, neue Dateien zu identifizieren. Da sich die Anmerkungen nach den Auslassungszeichen befanden, war es oft nicht für längere Dateinamen sichtbar.


Anzeigen von Speicherorten von Anmerkungen

  • Dropdown-Updates für PR-Updates erhalten Zeitdauerinformationen

Die Dropdownliste zum Auswählen von Aktualisierungs- und Vergleichsdateien in einer PR verloren ein wichtiges Element in der Vorschauumgebung. Es wurde nicht angezeigt, wann dieses Update vorgenommen wurde. Dies wurde behoben.


Pr-Updates dropdown fehlende Zeitdauerinformationen

  • **Verbessertes Kommentarfilterlayout **

Beim Filtern von Kommentaren auf der Zusammenfassungsseite einer Pullanforderung war die Dropdownliste rechts, aber der Text wurde links ausgerichtet. Dies wurde behoben.


Verbessertes Kommentarfilterlayout

  • Navigation zu übergeordneten Commits

Auf der Seite "Commits" können Sie die in einem bestimmten Commit vorgenommenen Änderungen mit dem übergeordneten Commit vergleichen. Sie können jedoch zu dem übergeordneten Commit navigieren und weiter verstehen, wie sich dieses Commit von einem eigenen übergeordneten Element unterscheidet. Dies ist häufig erforderlich, wenn Sie alle Änderungen in einer Version verstehen möchten. Wir haben eine Übergeordnete(n) Karte hinzugefügt, um Ihnen dabei zu helfen, dies zu erreichen.


Navigation zu übergeordneten Commits

  • Mehr Speicherplatz für Ordner und Dateien mit langen Namen auf der Registerkarte PR-Dateien

Ordner und Dateien mit langen Namen wurden aufgrund eines fehlenden horizontalen Abstands in der Dateistruktur abgeschnitten. Wir haben einige zusätzliche Leerzeichen in der Struktur wiederhergestellt, indem Sie den Einzug der Struktur ändern, um dem Stammknoten zu entsprechen, und indem Sie die Auslassungsschaltfläche aus der Seite ausblenden, außer auf der Mauszeiger.

Abbildung der neuen Dateistruktur:


Mehr Speicherplatz für Ordner und Dateien

Abbildung der Dateistruktur beim Zeigen auf ein Verzeichnis:


Nameanzeige

  • Beibehalten der Bildlaufposition beim Ändern des Diff-Bereichs auf der Registerkarte "PR-Dateien"

Wenn Sie die Größe des seitenseitigen Diff-Bereichs auf der Registerkarte "PR-Dateien" ändern, gehen die Bildlaufspeicherorte des Benutzers verloren. Dieses Problem wurde behoben; Der Bildlaufspeicherort des Benutzers wird nun in einem Diff-Bereich geändert.

  • Suchen nach einem Commit auf einem mobilen Gerät

Beim Anzeigen der Seite "Commits" auf einem mobilen Gerät fehlt das Suchfeld in der neuen Benutzeroberfläche. Daher ist es schwer, einen Commit durch seinen Hash zu finden und es zu öffnen. Dies wurde jetzt behoben.


Suchen nach einem Commit auf einem mobilen Gerät

  • Verbesserte Nutzung von Speicherplatz für neue PR-Datei diff mobile Ansicht

Wir haben diese Seite aktualisiert, um den Speicherplatz besser zu nutzen, damit Benutzer mehr der Datei in mobilen Ansichten sehen können, anstatt 40 % des Bildschirms von einer Kopfzeile aufgenommen zu haben.


Verbesserte Verwendung des Speicherplatzes neuer PR-Dateiname

  • Erweiterte Bilder in der PR-Zusammenfassungsansicht

Bilder, die in einer PR-Zusammenfassungsansicht bearbeitet wurden, wurden nicht in der PR-Zusammenfassungsansicht angezeigt, aber in der PR-Dateienansicht ordnungsgemäß angezeigt. Dieses Problem wurde behoben.

  • Erweiterte Zweigerfahrung beim Erstellen einer neuen PR

Vor diesem Update war diese Erfahrung nicht ideal, da sie die Änderungen mit dem Standardzweig des Repositorys anstelle des Vergleichszweigs vergleichen würde.


Erweiterung der Zweigumgebung

Pipelines

Zusätzliche Agentplattform: ARM64

Wir haben Linux/ARM64 zur Liste der unterstützten Plattformen für den Azure Pipelines-Agent hinzugefügt. Obwohl die Codeänderungen minimal waren, mussten viele Hintergrundarbeiten zuerst abgeschlossen werden, und wir freuen uns, seine Version bekannt zu geben!

Tagfilterunterstützung für Pipelineressourcen

Wir haben nun "Tags" in YAML-Pipelines hinzugefügt. Sie können Tags verwenden, um die CI-Pipeline so festzulegen, dass sie ausgeführt oder automatisch ausgelöst werden soll.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

Der obige Codeausschnitt zeigt, dass Tags verwendet werden können, um die Standardversion der CI -Pipeline (fortlaufende Integration) zu ermitteln, die ausgeführt werden soll, wenn die Ausführung der CD (fortlaufende Bereitstellung) von einigen anderen Quell-/Ressourcen oder einem geplanten Ausführungsauslöser nicht ausgelöst wird.

Wenn Sie beispielsweise einen geplanten Triggersatz für Ihre CD-Pipeline haben, die Sie nur ausführen möchten, wenn Ihre CI über das Produktionstag verfügt, stellt die Tags im Triggerabschnitt sicher, dass die CD-Pipeline nur ausgelöst wird, wenn die Taggingbedingung vom CI-Abschlussereignis erfüllt ist.

Steuern, welche Vorgänge in Pipelines zulässig sind

Jetzt können Sie Marketplace-Aufgaben deaktivieren. Einige von Ihnen können Marketplace-Erweiterungen zulassen, aber nicht die Pipelines-Aufgaben, die sie zusammenbringen. Für noch mehr Kontrolle ermöglichen wir Es Ihnen auch, alle In-the-Box-Aufgaben unabhängig zu deaktivieren (außer Auschecken, was eine spezielle Aktion ist). Mit beiden dieser Einstellungen ist die einzige Aufgabe, die in einer Pipeline ausgeführt werden darf, die mithilfe von tfx hochgeladen werden. Besuchen https://dev.azure.com/<your_org>/_settings/pipelinessettings Sie den Abschnitt namens "Aufgabeneinschränkungen", um zu beginnen.

Exklusive Bereitstellungssperresrichtlinie

Mit diesem Update können Sie sicherstellen, dass nur eine einzelne Ausführung für eine Umgebung gleichzeitig bereitgestellt wird. Wenn Sie die Option "Exklusive Sperre" für eine Umgebung auswählen, wird nur eine Ausführung fortgesetzt. Anschließende Ausführung, die für diese Umgebung bereitgestellt werden soll, wird angehalten. Sobald die Ausführung mit der exklusiven Sperre abgeschlossen ist, wird die neueste Ausführung fortgesetzt. Alle Zwischenläufe werden abgebrochen.

Wählen Sie auf der Seite

Phasenfilter für Pipelineressourcenauslöser

Wir haben Unterstützung für "Phasen" als Filter für Pipelineressourcen in YAML hinzugefügt. Mit diesem Filter müssen Sie nicht warten, bis die gesamte CI-Pipeline abgeschlossen wird, um Ihre CD-Pipeline auszulösen. Sie können jetzt entscheiden, ihre CD-Pipeline nach Abschluss einer bestimmten Phase in Ihrer CI-Pipeline auszulösen.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Wenn die phasen, die im Triggerfilter bereitgestellt werden, in Ihrer CI-Pipeline erfolgreich abgeschlossen werden, wird eine neue Ausführung automatisch für Ihre CD-Pipeline ausgelöst.

Generische Webhook-basierte Trigger für YAML-Pipelines

Heute haben wir verschiedene Ressourcen (z. B. Pipelines, Container, Build und Pakete), durch die Sie Artefakte nutzen und automatisierte Trigger aktivieren können. Bisher konnten Sie ihren Bereitstellungsprozess jedoch nicht basierend auf anderen externen Ereignissen oder Diensten automatisieren. In dieser Version führen wir die Unterstützung von Webhook-Triggern in YAML-Pipelines ein, um die Integration der Pipelineautomatisierung mit jedem externen Dienst zu ermöglichen. Sie können alle externen Ereignisse über ihre Webhooks (Github, Github Enterprise, Nexus, Aritfactory usw.) abonnieren und Ihre Pipelines auslösen.

Hier sind die Schritte zum Konfigurieren der Webhook-Trigger:

  1. Richten Sie einen Webhook auf Ihrem externen Dienst ein. Wenn Sie Ihren Webhook erstellen, müssen Sie die folgenden Informationen bereitstellen:

    • Anforderungs-URL – "https://dev.azure.com/<ADO-Auflistung>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
    • Geheim - Dies ist optional. Wenn Sie Ihre JSON-Nutzlast sichern müssen, geben Sie den Geheimen Wert an.
  2. Erstellen Sie eine neue "Eingehende Webhook"-Dienstverbindung. Dies ist ein neu eingeführter Dienstverbindungstyp, mit dem Sie drei wichtige Informationen definieren können:

    • Webhook-Name: Der Name des Webhook sollte mit dem Webhook übereinstimmen, der in Ihrem externen Dienst erstellt wurde.
    • HTTP-Header - Der Name des HTTP-Headers in der Anforderung, die den Nutzlast-Hashwert für die Anforderungsüberprüfung enthält. Im Fall des GitHubs ist der Anforderungsheader beispielsweise "X-Hub-Signature"
    • Geheimer Schlüssel – Der geheime Schlüssel wird verwendet, um den Nutzlasthash zu analysieren, der für die Überprüfung der eingehenden Anforderung verwendet wird (dies ist optional). Wenn Sie einen Geheimschlüssel zum Erstellen Ihres Webhooks verwendet haben, müssen Sie denselben geheimen Schlüssel bereitstellen.

    Konfigurieren Sie auf der Seite

  3. Ein neuer Ressourcentyp, der in YAML-Pipelines aufgerufen webhooks wird, wird eingeführt. Zum Abonnieren eines Webhook-Ereignisses müssen Sie eine Webhook-Ressource in Ihrer Pipeline definieren und auf die Verbindung des eingehenden Webhook-Diensts verweisen. Sie können auch zusätzliche Filter auf der Webhook-Ressource basierend auf den JSON-Nutzlastdaten definieren, um die Trigger für jede Pipeline weiter anzupassen, und Sie können die Nutzlastdaten in Form von Variablen in Ihren Aufträgen verwenden.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. Wenn ein Webhook-Ereignis von der Eingehenden Webhook-Dienstverbindung empfangen wird, wird eine neue Ausführung für alle Pipelines ausgelöst, die dem Webhook-Ereignis abonniert sind.

YAML-Ressourcenauslöserprobleme unterstützung und Ablaufverfolgung

Es kann verwirrend sein, wenn Pipelineauslöser nicht ausgeführt werden können, da Sie sie erwarten. Um dies besser zu verstehen, haben wir ein neues Menüelement auf der Pipelinedefinitionsseite namens "TriggerProbleme" hinzugefügt, bei denen Informationen zur Ausführung von Triggern angezeigt werden.

Ressourcenauslöser können aus zwei Gründen nicht ausgeführt werden.

  1. Wenn die Quelle der bereitgestellten Dienstverbindung ungültig ist oder syntaxfehler im Trigger vorhanden sind, wird der Trigger nicht konfiguriert. Diese werden als Fehler angezeigt.

  2. Wenn die Triggerbedingungen nicht übereinstimmen, wird der Trigger nicht ausgeführt. Wenn dies geschieht, wird eine Warnung angezeigt, damit Sie verstehen können, warum die Bedingungen nicht übereinstimmen.

    Auf dieser Pipelinedefinitionsseite mit dem Namen Triggerprobleme werden Informationen darüber angezeigt, warum Trigger nicht ausgeführt werden.

Multi-Repo-Trigger

Sie können mehrere Repositorys in einer YAML-Datei angeben und dazu führen, dass eine Pipeline durch Updates für alle Repositorys ausgelöst wird. Dieses Feature ist beispielsweise in den folgenden Szenarien nützlich:

  • Sie verwenden ein Tool oder eine Bibliothek aus einem anderen Repository. Sie möchten Tests für Ihre Anwendung ausführen, wenn das Tool oder die Bibliothek aktualisiert wird.
  • Sie behalten Ihre YAML-Datei in einem separaten Repository aus dem Anwendungscode. Sie möchten die Pipeline jedes Mal auslösen, wenn ein Update an das Anwendungs-Repository weitergeleitet wird.

Mit diesem Update funktionieren Multi-Repo-Trigger nur für Git-Repositorys in Azure Repos. Sie funktionieren nicht für GitHub- oder BitBucket-Repositoryressourcen.

Hier finden Sie ein Beispiel, das zeigt, wie Mehrere Repositoryressourcen in einer Pipeline definiert werden und wie Sie Trigger für alle konfigurieren.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

Die Pipeline in diesem Beispiel wird ausgelöst, wenn Updates vorhanden sind:

  • main branch in the repo mit der self YAML-Datei
  • main oder release Verzweigungen im tools Repo

Weitere Informationen finden Sie unter Mehrere Repositorys in Ihrer Pipeline.

Verbesserte Agent-Protokolluploads

Wenn ein Agent die Kommunikation mit dem Azure-Pipelines-Server beendet, wird der Vorgang, der ausgeführt wird, abgebrochen. Wenn Sie sich die Streamingkonsolenprotokolle ansehen, haben Sie möglicherweise einige Hinweise darauf erhalten, was der Agent richtig war, bevor er nicht mehr reagierte. Wenn Sie aber nicht waren oder wenn Sie die Seite aktualisiert haben, wurden diese Konsolenprotokolle verschwunden. Wenn der Agent mit dieser Version nicht mehr reagiert, bevor er seine vollständigen Protokolle sendet, halten wir die Konsolenprotokolle als nächstes bestes Fest. Konsolenprotokolle sind auf 1000 Zeichen pro Zeile beschränkt und können gelegentlich unvollständig sein, aber sie sind viel hilfreicher als nichts anzuzeigen! Die Untersuchung dieser Protokolle kann Ihnen helfen, Ihre eigenen Pipelines zu beheben, und es hilft unseren Supporttechnikern sicherlich, wenn sie bei der Problembehandlung helfen.

Optional containervolumes schreibgeschützt

Wenn Sie einen Containerauftrag in Azure Pipelines ausführen, werden mehrere Volumes, die den Arbeitsbereich, Aufgaben und andere Materialien enthalten, als Volumes zugeordnet. Diese Volumes werden standardmäßig zum Lese-/Schreibzugriff verwendet. Für erhöhte Sicherheit können Sie die Volumes schreibgeschützt bereitstellen, indem Sie ihre Containerspezifikation in YAML ändern. Jeder Schlüssel mountReadOnly unter kann für schreibgeschützt festgelegt werden true (der Standardwert ist false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Feinkornierte Kontrolle über den Containerstart/Stopp

Im Allgemeinen wird empfohlen, Azure Pipelines zum Verwalten des Lebenszyklus Ihrer Auftrags- und Dienstcontainer zuzulassen. In einigen ungewöhnlichen Szenarien können Sie jedoch beginnen und sie selbst beenden. Mit dieser Version haben wir diese Funktion in die Docker-Aufgabe integriert.

Hier ist eine Beispielpipeline mit der neuen Funktion:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Außerdem enthalten wir die Liste der Container in einer Pipelinevariable, Agent.ContainerMapping. Sie können dies verwenden, wenn Sie z. B. die Liste der Container in einem Skript überprüfen möchten. Es enthält eine zeichenfolgenbasierte JSON-Objektzuordnung des Ressourcennamens ("Generator" aus dem obigen Beispiel) zur Container-ID, die der Agent verwaltet.

Entzippen von Aufgabenbündeln für jeden Schritt

Wenn der Agent einen Auftrag ausführt, lädt er zunächst alle Aufgabenbündel herunter, die von den Schritten des Auftrags benötigt werden. Normalerweise entzippen sie die Vorgänge einmal pro Auftrag, auch wenn die Aufgabe in mehreren Schritten verwendet wird. Wenn Sie Bedenken haben, dass nicht vertrauenswürdiger Code den entzippten Inhalt ändert, können Sie ein wenig Leistung verlieren, indem der Agent die Aufgabe für jede Verwendung entzippen muss. Um diesen Modus zu aktivieren, übergeben --alwaysextracttask Sie beim Konfigurieren des Agents.

Verbessern der Releasesicherheit durch Einschränken des Umfangs von Zugriffstoken

Auf unserer Initiative zur Verbesserung der Sicherheitseinstellungen für Azure-Pipelines unterstützen wir jetzt das Einschränken des Umfangs von Zugriffstoken für Versionen.

Jeder Auftrag, der in Versionen ausgeführt wird, erhält ein Zugriffstoken. Das Zugriffstoken wird von den Aufgaben und von Ihren Skripts zum Rückruf in Azure DevOps verwendet. Beispielsweise verwenden wir das Zugriffstoken, um Quellcode abzurufen, Artefakte herunterzuladen, Protokolle, Testergebnisse hochzuladen oder REST-Aufrufe in Azure DevOps zu tätigen. Ein neues Zugriffstoken wird für jeden Auftrag generiert und läuft nach Abschluss des Auftrags ab.

Mit diesem Update bauen wir auf der Verbesserung der Pipelinesicherheit auf, indem wir den Umfang von Zugriffstoken einschränken und auf klassische Versionen erweitern.

Dieses Feature ist standardmäßig für neue Projekte und Sammlungen aktiviert. Für vorhandene Auflistungen müssen Sie sie in den Einstellungen für Die Pipelineseinstellungen >> der Sammlung aktivieren. > Beschränken Sie den Auftragsautorisierungsbereich auf das aktuelle Projekt für Releasepipelinen. Hiererhalten Sie weitere Informationen.

Verbesserungen der YAML-Vorschau-API

Sie können jetzt die vollständige YAML einer Pipeline anzeigen, ohne sie auszuführen. Darüber hinaus haben wir eine dedizierte neue URL für die Vorschaufunktion erstellt. Jetzt können Sie POST zum https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview Abrufen des abgeschlossenen YAML-Texts bereitstellen. Diese neue API verwendet die gleichen Parameter wie das Queuing einer Ausführung, erfordert jedoch nicht mehr die Berechtigung "Warteschlangenbuilds".

Führen Sie diesen Auftrag als nächstes aus.

Haben Sie jemals ein Bugfix gehabt, das Sie für die Bereitstellung in dieser Minute benötigt haben, aber hinter CI- und PR-Aufträgen warten mussten? Mit dieser Version können Sie jetzt die Priorität eines warteschlangenhaften Auftrags abstoßen. Benutzer mit der Berechtigung "Verwalten" im Pool – in der Regel Pooladministratoren – werden auf der Seite "Auftragsdetails" eine neue Schaltfläche "Weiter ausführen" angezeigt. Wenn Sie auf die Schaltfläche klicken, wird der Auftrag so schnell wie möglich ausgeführt. (Sie benötigen weiterhin Parallelismus und einen geeigneten Agent, natürlich.)

Im YAML-Block resources zulässige Vorlagenausdrücke

Zuvor wurden Kompilierungszeitausdrücke (${{ }}) im resources Abschnitt einer Azure Pipelines YAML-Datei nicht zulässig. Mit dieser Version haben wir diese Einschränkung für Container aufgehoben. Auf diese Weise können Sie Laufzeitparameterinhalte in Ihren Ressourcen verwenden, z. B. zum Auswählen eines Containers zur Warteschlangenzeit. Wir planen, diese Unterstützung im Laufe der Zeit auf andere Ressourcen zu erweitern.

Kontrolle über automatisierte Aufgabenupdates von Marketplace

Wenn Sie eine YAML-Pipeline schreiben, geben Sie normalerweise nur die Hauptversionsnummer der enthaltenen Aufgaben an. Auf diese Weise können Ihre Pipelines automatisch die neuesten Featureerweiterungen und Fehlerkorrekturen übernehmen. Gelegentlich müssen Sie möglicherweise zurück zu einer früheren Point Release einer Aufgabe zurückkehren, und mit diesem Update haben wir ihnen die Möglichkeit hinzugefügt, dies zu tun. Sie können jetzt eine vollständige haupt-minor.patch-Taskversion in Ihren YAML-Pipelines angeben.

Es wird nicht empfohlen, dies regelmäßig zu tun und nur als temporäre Problemumgehung zu verwenden, wenn Sie feststellen, dass eine neuere Aufgabe Ihre Pipelines umbricht. Außerdem wird dadurch keine ältere Version einer Aufgabe aus dem Marketplace installiert. Es muss bereits in Ihrer Sammlung vorhanden sein, oder Ihre Pipeline schlägt fehl.

Beispiel:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Unterstützung von Knoten 10 in Agent und Aufgaben

Da Knoten 6 nicht mehr unterstützt wird, migrieren wir die Aufgaben, um mit Node 10 zu arbeiten. Für dieses Update haben wir fast 50 % der Box-Aufgaben zu Node 10 migriert. Der Agent kann jetzt sowohl Node 6 als auch Node 10-Aufgaben ausführen. In einem zukünftigen Update werden wir Node 6 vollständig aus dem Agent entfernen. Um sich auf die Entfernung von Node 6 aus dem Agent vorzubereiten, bitten wir Sie, Ihre internen Erweiterungen und benutzerdefinierten Aufgaben zu aktualisieren, um Knoten 10 bald auch zu verwenden. Um Knoten 10 für Ihre Aufgabe zu verwenden, aktualisieren Sie in Ihrem task.json, unter execution, aktualisieren von Node auf Node10.

Verbessern der YAML-Konvertierung im klassischen Build-Designer

Mit dieser Version stellen wir ein neues Feature "Export in YAML" für Designer-Buildpipelinen vor. Speichern Sie Ihre Pipelinedefinition, und suchen Sie dann im ... Menü nach "Exportieren in YAML".

Die neue Exportfunktion ersetzt die Funktion "Als YAML anzeigen", die zuvor im klassischen Build-Designer gefunden wurde. Diese Funktion war unvollständig, da sie nur überprüfen konnte, was die Web-UI über den Build wusste, was manchmal dazu führte, dass falsche YAML generiert wird. Die neue Exportfunktion berücksichtigt genau die Verarbeitung der Pipeline und generiert YAML mit voller Genauigkeit für die Designerpipeline.

Neue Webplattformkonvertierung – Repositoryeinstellungen

Wir haben die beiden Repository-Einstellungsseiten in eine einzige Oberfläche konvertiert, die auf eine neue Webplattform aktualisiert wurde. Dieses Upgrade macht die Erfahrung nicht nur schneller und moderner, sondern auch einen einzigen Einstiegspunkt für alle Richtlinien von der Projektebene bis zur Verzweigungsebene.

Neue Webplattformkonvertierung.

Mit dieser neuen Erfahrung ist die Navigation für Projekte mit einer erheblichen Anzahl von Repositorys aufgrund schnellerer Ladezeiten und eines hinzugefügten Suchfilters einfacher geworden. Sie können auch Richtlinien auf Projektebene und die Liste der richtlinienübergreifenden Repositorys auf der Registerkarte "Richtlinien" anzeigen.

Zeigen Sie auf der Registerkarte

Wenn Sie in ein Repository klicken, können Sie Richtlinien und Berechtigungen anzeigen, die auf Repositoryebene festgelegt sind. Auf der Registerkarte "Richtlinien" können Sie eine Liste aller Verzweigung anzeigen, auf der die Richtlinie festgelegt ist. Klicken Sie nun auf den Verzweigung, um die Richtlinien alle anzuzeigen, während Sie die Seite "Repositoryeinstellungen" nie verlassen.

Wählen Sie Verzweigung aus, um die Richtlinien anzuzeigen.

Wenn nun Richtlinien von einem höheren Bereich geerbt werden als mit dem, mit dem Sie arbeiten, zeigen wir Ihnen, wo die Richtlinie neben jeder einzelnen Richtlinie geerbt wurde. Sie können auch zur Seite navigieren, auf der die Richtlinie auf höherer Ebene festgelegt wurde, indem Sie auf den Bereichsnamen klicken.

Zeigen Sie an, von wo die Richtlinie geerbt wurde.

Die Richtlinienseite selbst wurde auch auf die neue Webplattform mit kollapsiblen Abschnitten aktualisiert! Um die Erfahrung der Suche nach einer bestimmten Buildüberprüfungs-, Statusüberprüfungs- oder automatischen Prüferrichtlinie zu verbessern, haben wir Suchfilter für jeden Abschnitt hinzugefügt.

Suchfilter für jeden Abschnitt.

ServiceNow-Änderungsverwaltungsintegration in YAML-Pipelines

Die Azure Pipelines-App für ServiceNow hilft Ihnen bei der Integration von Azure Pipelines und ServiceNow Change Management. Mit diesem Update nehmen wir unseren Weg, Azure-Pipelines über den in ServiceNow verwalteten Änderungsverwaltungsprozess weiter zu YAML-Pipelines zu machen.

Durch das Konfigurieren der Überprüfung "ServiceNow Change Management" auf einer Ressource können Sie nun angehalten werden, dass die Änderung genehmigt werden soll, bevor Sie den Build für diese Ressource bereitstellen. Sie können automatisch eine neue Änderung für eine Phase erstellen oder auf eine vorhandene Änderungsanforderung warten.


ServiceNow Change Management Integration

Sie können die UpdateServiceNowChangeRequest Aufgabe auch in einem Serverauftrag hinzufügen, um die Änderungsanforderung mit Dem Bereitstellungsstatus, Notizen usw. zu aktualisieren.

Artifacts

Möglichkeit zum Erstellen von organisationsbezogenen Feeds aus der Benutzeroberfläche

Wir bringen die Möglichkeit für Kunden zurück, sammlungsbezogene Feeds über die Web-UI sowohl für lokale als auch gehostete Dienste zu erstellen und zu verwalten.

Sie können jetzt organisationsbezogene Feeds über die Benutzeroberfläche erstellen, indem Sie zu Artefakten wechseln –> Feed erstellen und einen Feedtyp innerhalb des Bereichs auswählen.

Erstellen Sie Auflistungsfeeds, indem Sie Artefakte und dann

Während wir die Verwendung von projektbezogenen Feeds in Übereinstimmung mit den restlichen Azure DevOps-Angeboten empfehlen, können Sie erneut feeds mit Sammlungsbereich über die Benutzeroberfläche und verschiedene REST-APIs erstellen, verwalten und verwenden. Weitere Informationen finden Sie in unserer Feeds-Dokumentation.

Update Package Version REST API jetzt verfügbar für Maven-Pakete

Sie können jetzt die REST-API von Azure Artefakten "Update Package Version" verwenden, um Maven-Paketversionen zu aktualisieren. Zuvor können Sie die REST-API verwenden, um Paketversionen für NuGet-, Maven-, npm- und Universelle Pakete, aber nicht maven-Pakete zu aktualisieren.

Um Maven-Pakete zu aktualisieren, verwenden Sie den HTTP PATCH-Befehl wie folgt.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Sie können Folgendes festlegen:

URI-Parameter

Name In Erforderlich Typ Beschreibung
artifactId path TRUE Zeichenfolge Artefakte-ID des Pakets
feed path TRUE Zeichenfolge Name oder ID des Feeds
groupId path TRUE Zeichenfolge Gruppen-ID des Pakets
collection path TRUE Zeichenfolge Der Name der Azure DevOps-Auflistung
version path TRUE Zeichenfolge Version des Pakets
Projekt path Zeichenfolge Projekt-ID oder Projektname
api-version Abfrage TRUE Zeichenfolge Version der zu verwendenden API. Dies sollte auf "5.1-preview.1" festgelegt werden, um diese Version der API zu verwenden.

Anforderungstext

Name Typ Beschreibung
views JsonPatchOperation Die Ansicht, zu der die Paketversion hinzugefügt wird

Weitere Informationen finden Sie in der REST-API-Dokumentation , da sie aktualisiert wird.

Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen und sie über Entwicklercommunity nachverfolgen und Beratung über Stack Overflow erhalten.


Seitenanfang