Versionshinweise zu Azure DevOps Server 2022 Update 2
| Entwickler-Community | Systemanforderungen und Kompatibilität | Lizenzbedingungen | DevOps-Blog | SHA-256-Hashes |
In diesem Artikel finden Sie Informationen zur neuesten Version für Azure DevOps Server.
Weitere Informationen zum Installieren oder Aktualisieren einer Azure DevOps Server-Bereitstellung finden Sie unter Azure DevOps Server Requirements.
Informationen zum Herunterladen von Azure DevOps Server-Produkten finden Sie auf der Seite "Azure DevOps Server-Downloads".
Direktes Upgrade auf Azure DevOps Server 2022 Update 2 wird von Azure DevOps Server 2019 oder Team Foundation Server 2015 oder höher unterstützt. Wenn Sich Ihre TFS-Bereitstellung auf TFS 2013 oder einer früheren Version befindet, müssen Sie einige Zwischenschritte ausführen, bevor Sie ein Upgrade auf Azure DevOps Server 2022 durchführen. Weitere Informationen finden Sie auf der Seite "Installieren" .
Azure DevOps Server 2022 Update 2 Patch 4 Veröffentlichungsdatum: 11. März 2025
| Datei | SHA-256 Hash-Wert |
|---|---|
| devops2022.2patch4 | 975B0FC28737C15BA40D6E084663D1A735A66FA821EB40C7A377AE3D58F0C7DA |
Wir haben Patch 4 für Azure DevOps Server 2022 Update 2 veröffentlicht, um Folgendes einzuschließen:
- Aktualisieren von Aufgaben wegen der Abschaffung von Edgio CDN. Weitere Informationen finden Sie im Blogbeitrag Wechseln von CDN-Anbietern.
- Die Mermaid-Abhängigkeit wurde aktualisiert.
Azure DevOps Server 2022 Update 2 Patch 3 Veröffentlichungsdatum: 11. Februar 2025
Hinweis
Am Montag, dem 24. Februar 2025, haben wir Patch 3 für Azure DevOps Server 2022.2 erneut veröffentlicht. Wenn Sie zuvor die frühere Version dieses Patches installiert haben, aktualisieren Sie sie über den bereitgestellten Link. Diese erneute Version behebt ein Problem, das dazu führt, dass YAML-Pipelines fehlschlagen. Weitere Details zum Problem finden Sie in der Developer Community.
| Datei | SHA-256 Hash |
|---|---|
| devops2022.2patch3 | F5C2DA846B8A38A1FB55D1EB555FB2FD6B974B0436F573CC01A0FEBAF3D67521 |
Wir haben Patch 3 für Azure DevOps Server 2022 Update 2 veröffentlicht, um Folgendes einzuschließen:
- Aktualisierungen an Artefakten, um Python Enhancement Proposals (PEPs) 685hinzuzufügen. Diese Aktualisierung adressiert Feedback, das in der Developer Communitygeteilt wurde.
Azure DevOps Server 2022 Update 2 Patch 2 Veröffentlichungsdatum: 12. November 2024
| Datei | SHA-256-Hashwert |
|---|---|
| devops2022.2patch2.exe | 70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23 |
Wir haben Patch 2 für Azure DevOps Server 2022 Update 2 veröffentlicht, um ein Upgrade auf eine anfällige Abhängigkeit aufzunehmen.
Azure DevOps Server 2022.2 RTW-Veröffentlichungsdatum: 9. Juli 2024
Zusammenfassung der Neuerungen in Azure DevOps Server 2022.2 RTW
Hinweis
Wir haben Azure DevOps Server 2022.2 erneut veröffentlicht, um ein Problem beim Laden von Teams-Namen zu beheben. Das Problem wurde im jetzt verfügbaren Blogbeitrag von Azure DevOps Server 2022.2 RTW gemeldet. Wenn Sie die Version von Azure DevOps Server 2022.2 installiert haben, die am 9. Juli veröffentlicht wurde, können Sie Patch 1 für Azure DevOps Server 2022.2 installieren, um das Problem zu beheben. Patch 1 ist nicht erforderlich, wenn Sie Azure DevOps Server 2022.2 zum ersten Mal installieren, nachdem die Downloadlinks aktualisiert wurden, um den Fix einzuschließen.
Azure DevOps Server 2022.2 RTW ist ein Rollup von Fehlerbehebungen. Es enthält alle Features in azure DevOps Server 2022.2 RC, die zuvor veröffentlicht wurden. Sie können Azure DevOps Server 2022.2 oder ein Upgrade von Azure DevOps Server 2020, 2019 oder Team Foundation Server 2015 oder höher direkt installieren. Die folgenden Probleme und Sicherheitsrisiken wurden mit dieser Version behoben:
- CVE-2024-35266: Spoofing-Sicherheitsanfälligkeit in Azure DevOps Server
- CVE-2024-35267: Spoofing-Sicherheitsanfälligkeit in Azure DevOps Server
- Entwickler-Community-Feedbackticket: Die Agentversion wird nach dem Upgrade auf Azure DevOps Server 2022.1 und der Verwendung des Update-Agents in der Agent-Pool-Konfiguration nicht aktualisiert.
- Entwickler-Community Feedback-Ticket: Problem beim Laden der Teamkonfigurationsseite
- Entwickler-Community Feedback-Ticket: Korrigieren der falschen Datumsbehandlung in der PR-E-Mail-Benachrichtigung für bestimmte regionale Formate
Azure DevOps Server 2022 Update 2 RC Veröffentlichungsdatum: 7. Mai 2024
Azure DevOps Server 2022.2 RC enthält viele neue Features. Einige der Highlights sind unter anderem:
- Grenzwerte für Bereiche und Iterationspfade
- Umgehen von Genehmigungen und Überprüfungen in Pipelines
- Verbesserte YAML-Validierung
- Azure Artifacts-Unterstützung für Frachtkrates
- Neue Dashboard-Verzeichnisoberfläche
- Schnelles Kopieren und Importieren mit Testplan- oder Suite-ID
Sie können auch zu einzelnen Abschnitten springen, um alle neuen Features für jeden Dienst anzuzeigen:
Allgemein
Task zum Veröffentlichen der Testergebnisse
Die Aufgabe "Testergebnisse veröffentlichen" unterstützt jetzt Anhänge zu Testläufen für das JUnit-Berichtsformat.
Neue Version des Azure DevOps Web Extension SDK
Mit diesem Update veröffentlichen wir eine neue Version des Azure DevOps Web Extension SDK. Das Client-SDK ermöglicht den Weberweiterungen Kommunikation mit dem Host-Frame. Es kann verwendet werden, um:
- Benachrichtigen des Hosts, dass die Erweiterung geladen wird oder Fehler aufweist
- Abrufen grundlegender kontextbezogener Informationen zur aktuellen Seite (aktuelle Benutzer-, Host- und Erweiterungsinformationen)
- Informationen zum Thema abrufen
- Abrufen eines Autorisierungstokens zur Verwendung in REST-Rückrufen an Azure DevOps
- Remotedienste abrufen, die vom Hostframe angeboten werden
Eine vollständige API-Referenz finden Sie in der Dokumentation zum Azure-devops-extension-sdk-Paket. Diese neue Version bietet Unterstützung für die folgenden Module:
ES-Modulunterstützung: SDK unterstützt jetzt ZUSÄTZLICH zu den vorhandenen AMD-Modulen (asynchrone Moduldefinition) ES (ECMAScript)-Module. Sie können nun SDK mithilfe der ES-Modulsyntax importieren, die Leistungsverbesserungen bietet und die Anwendungsgröße reduziert.
Abwärtskompatibilität für AMD-Module: Vorhandene Unterstützung für AMD-Module bleibt intakt. Wenn Ihr Projekt AMD-Module verwendet, können Sie diese weiterhin wie zuvor ohne Änderungen verwenden.
Verwendung:
Für ES-Module können Sie unsere Module mithilfe der Import-Anweisung importieren:
import * as SDK from 'azure-devops-extension-sdk';
// Use the module here
Wenn Sie AMD-Module verwenden, können Sie das SDK weiterhin mithilfe der require Funktion importieren:
require(['azure-devops-extension-sdk'], function(SDK) {
// Use the module here
});
Bretter
Grenzwerte für Bereiche und Iterationspfade
Grenzwerte spielen einen wichtigen Teil bei der Aufrechterhaltung der Integrität und Effizienz eines großen, globalen Dienstes. Mit dieser Version werden harte Grenzwerte von 10.000 pro Projekt für Bereiche und Iterationspfade eingeführt. Besuchen Sie die Seite "Work tracking", "Process" und "Project Limits ", um mehr über unterschiedliche Grenzwerte im Dienst zu erfahren.
Entwicklungs- und Bereitstellungskontrollen
Wir entfernen nun je nach Konfiguration Ihres Projekts die Entwicklungs- und/oder Bereitstellungskontrollen aus dem Arbeitselement. Beispielsweise können Sie Ihre Projekteinstellungen so konfigurieren, dass Repos und/oder Pipelines deaktiviert werden.
Wenn Sie zum Arbeitselement wechseln, werden die entsprechenden Entwicklungs- und Bereitstellungssteuerelemente aus dem Formular ausgeblendet.
Wenn Sie sich entscheiden, ein GitHub-Repository mit Azure Boards zu verbinden, wird das Entwicklungssteuerelement für GitHub-Repositorys angezeigt.
Repos
Neue "Branch-Richtlinie" verhindert, dass Benutzer ihre eigenen Änderungen genehmigen
Um die Kontrolle darüber zu verbessern, welche Änderungen der Benutzer genehmigen darf und um die strengeren gesetzlichen/Compliance-Anforderungen zu erfüllen, bieten wir die Möglichkeit, die Genehmigung seiner eigenen Änderungen zu verhindern, es sei denn, dies wird ausdrücklich erlaubt.
Benutzer, die die Berechtigung haben, die Zweigstellenrichtlinien zu verwalten, können jetzt die neu hinzugefügte Option "Für jede Iteration mindestens eine Genehmigung erforderlich machen" unter "Wenn neue Änderungen übertragen werden" umstellen. Wenn diese Option ausgewählt ist, ist mindestens eine Genehmigungsstimme für die letzte Quellzweigänderung erforderlich. Die Genehmigung des Benutzers wird nicht auf frühere nicht genehmigte Iterationen angerechnet, die von diesem Benutzer gepusht wurden. Daher ist eine zusätzliche Genehmigung für die letzte Iteration von einem anderen Benutzer erforderlich.
Die folgende Abbildung zeigt die Pull-Anfrage, die von Benutzer A erstellt wurde, und zusätzliche 4 Commits (Iterationen), die an diese Pull-Anfrage von den Benutzern B, C, erneut A und C vorgenommen wurden. Nachdem die zweite Iteration (Commit von Benutzer B) abgeschlossen war, genehmigte Benutzer C diese. Zum damaligen Zeitpunkt bedeutete es die Genehmigung des ersten Commits von Benutzer A (als die Pull-Anforderung erstellt wurde), und die neu eingeführte Richtlinie wird erfolgreich sein. Nach der fünften Iteration (letzter Commit des Benutzers C) wurde die Genehmigung durch Benutzer A erteilt. Dies implizierte die Genehmigung eines früheren Commits von Benutzer C, jedoch nicht die Genehmigung für den zweiten Commit, der von Benutzer A in der vierten Iteration durchgeführt wurde. Damit die neu eingeführte Richtlinie erfolgreich ausgeführt werden kann, muss die nicht genehmigte Iteration 4 entweder durch Genehmigung von Benutzer B, C oder einem anderen Benutzer genehmigt werden, der keine Änderung an der Pullanforderung vorgenommen hat.
Hinweis
Es gibt ein bekanntes Problem, bei dem Verzweigungsrichtlinien eine Gruppe, die als Prüfer konfiguriert ist, als Genehmigungsentität betrachten. Stellen wir uns vor, es gibt eine erforderliche Genehmigung für jeden Benutzer von Group G. Benutzer A ist Mitglied dieser Gruppe G. Nachdem Benutzer A die Genehmigung wie im obigen Bild (nach fünfter Iteration) erteilt hat, genehmigt die Gruppen-G-Genehmigung die von Benutzer A vorgenommene Änderung. Dies wird nicht erwartet und wird in der RTW-Version aufgelöst.
Unterstützung für bloblose und baumlose Filter
Wichtig
Die Funktion ist standardmäßig deaktiviert. Um das Feature zu aktivieren, führen Sie die folgende Abfrage für Config DB aus:
exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1
Azure DevOps unterstützt jetzt zwei zusätzliche Filter beim Klonen/Abrufen. Dies sind:
--filter=blob:none und
--filter=tree:0 Die erste Option (Blobloses Klonen) wird am besten für die normale Entwicklung verwendet, während die zweite Option (Baumloses Klonen) besser geeignet ist für Fälle, in denen Sie den Klon verwerfen, z. B. nach dem Ausführen eines Builds.
SSH-RSA-Abschaffung
Azure Repos bietet zwei Methoden für den Zugriff auf ein Git-Repository in Azure Repos – HTTPS und SSH. Um SSH zu verwenden, müssen Sie ein Schlüsselpaar mit einer der unterstützten Verschlüsselungsmethoden erstellen. In der Vergangenheit haben wir nur SSH-RSA unterstützt und wir haben Benutzer gebeten, hier ssh-RSA zu aktivieren.
Mit diesem Update wird die Abschaffung von SSH-RSA als unterstützte Verschlüsselungsmethode für die Verbindung mit Azure Repos angekündigt. Weitere Details finden Sie im Blogbeitrag "Ende der SSH-RSA-Unterstützung für Azure Repos ".
Rohrleitungen
Verhindern unbeabsichtigter Pipelineausführungen
Heute, wenn Ihre YAML-Pipeline keinen trigger-Abschnitt angibt, wird sie für Änderungen ausgeführt, die an das Repository übertragen werden. Dies kann Verwirrung darüber erzeugen, warum eine Pipeline ausgeführt wurde und zu vielen unbeabsichtigten Läufen führen kann.
Wir haben eine Projektsammlungs- und Pipelineseinstellung auf Projektebene mit dem Namen "Konkludente YAML CI-Trigger deaktivieren" hinzugefügt, mit der Sie dieses Verhalten ändern können. Sie können auswählen, dass Pipelines nicht ausgelöst werden, wenn deren Triggerabschnitt fehlt.
Wiederholen Sie eine Phase, wenn Genehmigungen und Prüfungen ablaufen.
Wenn Genehmigungen und Überprüfungen zeitlich ablaufen, wird die Phase, zu der sie gehören, übersprungen. Phasen, die eine Abhängigkeit von der übersprungenen Phase aufweisen, werden ebenfalls übersprungen.
Jetzt können Sie eine Phase erneut versuchen, wenn Genehmigungen und Prüfungen abgelaufen sind. Bisher war dies nur möglich, wenn eine Genehmigung abgelaufen ist.
Umgehen von Genehmigungen und Überprüfungen
Genehmigungen und Überprüfungen schützen den Zugriff auf wichtige Ressourcen, z. B. Dienstverbindungen, Repositorys oder Agentpools. Ein gängiger Anwendungsfall ist die Verwendung von Genehmigungen und Überprüfungen bei der Bereitstellung in der Produktion, und Sie möchten die ARM-Dienstverbindung schützen.
Angenommen, Sie haben die folgenden Überprüfungen für die Dienstverbindung hinzugefügt: eine Genehmigung, eine Überprüfung der Geschäftszeiten und eine Überprüfung des Azure Functions-Aufrufs (um eine Verzögerung zwischen verschiedenen Regionen zu erzwingen).
Stellen Sie sich nun vor, Sie müssen ein Hotfix-Deployment durchführen. Sie starten eine Pipelineausführung, aber sie wird nicht fortgeführt, sie wartet, bis die meisten Überprüfungen abgeschlossen sind. Sie können nicht warten, bis die Genehmigungen und Überprüfungen abgeschlossen sind.
Mit dieser Version haben wir es ermöglicht, die Ausführung von Genehmigungen und Überprüfungen zu umgehen, damit Sie Ihren Hotfix abschließen können.
Sie können die Ausführung von Genehmigungen, Geschäftszeiten, Aufrufen der Azure-Funktion und Aufrufen der REST-API-Überprüfungen umgehen.
Umgehen einer Genehmigung.
Geschäftszeitenprüfung umgehen.
Azure-Funktionsprüfung beim (Be-)Rufen umgehen. Geschäftszeitenprüfung umgehen.
Wenn eine Überprüfung umgangen wird, können Sie sie im Kontrollkästchen sehen.
Sie können eine Überprüfung nur umgehen, wenn Sie ein Administrator der Ressource sind, für die die Prüfungen definiert wurden.
Erneutes Aufrufen von Azure-Funktionsüberprüfungen
Stellen Sie sich vor, Dass Sie Ihr System in mehreren Phasen bereitstellen. Vor der Bereitstellung der zweiten Phase gibt es eine Genehmigungsüberprüfung sowie einen Aufruf der Azure-Funktion, die eine Integritätsprüfung auf den bereits bereitgestellten Teil des Systems durchführt.
Bei der Überprüfung der Genehmigungsanforderung bemerken Sie, dass die Sanity-Prüfung zwei Tage früher ausgeführt wurde. In diesem Szenario sind Sie möglicherweise einer anderen Bereitstellung bewusst, die das Ergebnis der Sanity-Überprüfung beeinflusst hat.
Mit diesem Update können Sie Azure-Funktions- und REST-API-Abfragen erneut aufrufen. Diese Funktionalität ist nur für Überprüfungen verfügbar, die erfolgreich waren und keine Wiederholungen aufweisen.
Hinweis
Sie können eine Überprüfung nur dann erneut ausführen, wenn Sie ein Administrator der Ressource sind, für die die Prüfungen definiert wurden.
Unterstützung für GitHub Enterprise Server bei der erforderlichen Vorlagenüberprüfung
Vorlagen sind ein Sicherheitsmechanismus, mit dem Sie die Phasen, Aufträge und Schritte von Pipelines in Ihrer Projektsammlung steuern können.
Mit der Anforderung der Vorlagenprüfung können Sie erzwingen, dass eine Pipeline aus einem Satz genehmigter Vorlagen stammt, bevor auf eine geschützte Ressource zugegriffen wird, wie etwa einen Agentpool oder eine Dienstkontoverbindung.
Sie können jetzt Vorlagen angeben, die sich in GitHub Enterprise Server-Repositorys befinden.
Administratorrolle für alle Umgebungen
Umgebungen in YAML-Pipelines stellen eine Computeressource dar, für die Sie Ihre Anwendung bereitstellen, z. B. einen AKS-Cluster oder eine Reihe von VMs. Sie bieten Ihnen Sicherheitskontrollen und Rückverfolgbarkeit für Ihre Bereitstellungen.
Das Verwalten von Umgebungen kann sehr schwierig sein. Dies liegt daran, dass die Person, die sie erstellt, automatisch zum alleinigen Administrator wird, wenn eine Umgebung erstellt wird. Wenn Sie beispielsweise die Genehmigungen und Überprüfungen aller Umgebungen zentral verwalten möchten, mussten Sie jeden Umgebungsadministrator bitten, einen bestimmten Benutzer oder eine bestimmte Gruppe als Administrator hinzuzufügen, und dann die REST-API zum Konfigurieren der Prüfungen verwenden. Dieser Ansatz ist mühsam, fehleranfällig und wird nicht skaliert, wenn neue Umgebungen hinzugefügt werden.
Mit dieser Version haben wir eine Administratorrolle auf Umgebungen-Hub-Ebene hinzugefügt. Dadurch werden Umgebungen auf das Niveau von Dienstverbindungen oder Agentpools gebracht. Um einem Benutzer oder einer Gruppe die Administratorrolle zuzuweisen, müssen Sie bereits ein Umgebungenhubadministrator oder Projektsammlungsbesitzer sein.
Ein Benutzer mit dieser Administratorrolle kann Berechtigungen verwalten, jede Umgebung verwalten, anzeigen und verwenden. Dazu gehört auch, Umgebungen für alle Pipelines zu öffnen.
Wenn Sie einem Benutzer eine Administratorrolle auf der Ebene des Umgebungs-Hubs zuweisen, werden sie Administratoren für alle bestehenden und zukünftigen Umgebungen.
Verbesserte YAML-Validierung
Um zu überprüfen, ob Ihre YAML-Syntax korrekt ist, können Sie die Validate-Funktion des Azure Pipelines-Web-Editors verwenden. Daher ist es wichtig, dass diese Funktionalität so viele YAML-Probleme wie möglich abfangen kann.
Die YAML-Überprüfung ist jetzt gründlicher, wenn es um Ausdrücke geht.
Beim Schreiben von YAML-Pipelines können Sie Funktionen verwenden, um Variablenwerte zu definieren.
Stellen Sie sich vor, Sie definieren die folgenden Variablen:
variables:
Major: '1'
Minor: '0'
Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]
Die Patch Variable wird mithilfe der counter Funktion und der anderen beiden Variablen definiert. Im obigen YAML-Code ist das Wort format falsch. Dieser Fehler wurde zuvor nicht erkannt. Nun erkennt die Funktion "Überprüfen " dies und zeigt eine Fehlermeldung an.
Azure-Pipelines erkennen falsche Variablendefinitionen auf Pipeline-/Phasen-/Auftragsebene.
In YAML-Pipelines können Sie die Ausführung der Phase mit Bedingungen überspringen. Tippfehler können hier ebenfalls angezeigt werden, wie im folgenden Beispiel.
steps:
- task: NuGetCommand@2
condition: eq(variable.Patch, 0)
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'
Die NuGetCommand Aufgabe wird nur ausgeführt, wenn der Wert der Patch Variablen 0 ist. Auch hier gibt es einen Tippfehler in der Bedingung, und die Validate-Funktion zeigt sie an.
Azure-Pipelines erkennen falsche YAML-Bedingungen, die auf Pipeline-/Stufen-/Auftragsebene definiert sind.
REST-APIs für Umgebungen
Eine Umgebung ist eine Sammlung von Ressourcen, die Sie mit Bereitstellungen aus einer Pipeline anvisieren können. Umgebungen bieten Bereitstellungsverlauf, Nachverfolgbarkeit von Arbeitsaufgaben und Commits sowie Zugriffssteuerungsmechanismen.
Wir wissen, dass Sie Umgebungen programmgesteuert erstellen möchten, daher haben wir die Dokumentation für ihre REST-API veröffentlicht.
Verbesserungen der REST-API für Genehmigungsprozesse
Wir haben das Auffinden von Genehmigungen verbessert, die einem Benutzer zugewiesen wurden, indem die Gruppen eingeschlossen werden, zu denen der Benutzer in die Suchergebnisse gehört.
Genehmigungen enthalten jetzt Informationen über den Pipeline-Durchlauf, zu dem sie gehören.
Der folgende GET-REST-API-Aufruf gibt z. B. https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending zurück.
{
"count": 1,
"value":
[
{
"id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
"steps":
[],
"status": "pending",
"createdOn": "2023-11-09T10:54:37.977Z",
"lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers":
[],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
}
},
"pipeline":
{
"owner":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
},
"self":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
}
},
"id": 73222930,
"name": "20231109.1"
},
"id": "4597",
"name": "FabrikamFiber"
}
}
]
}
Pipelineprotokolle enthalten jetzt die Ressourcennutzung.
Azure-Pipelineprotokolle können jetzt Metriken zu Ressourcen erfassen, z. B. zur Arbeitsspeicherauslastung, CPU-Auslastung und zum verfügbaren Speicherplatz. Die Protokolle enthalten auch Ressourcen, die vom Pipeline-Agenten und untergeordneten Prozessen verwendet werden, einschließlich Aufgaben, die in einem Auftrag ausgeführt werden.
Wenn Sie vermuten, dass Ihr Pipelineauftrag möglicherweise auf Ressourceneinschränkungen stößt, aktivieren Sie ausführliche Protokolle, um Informationen zur Ressourcennutzung in die Pipelineprotokolle einzufügen. Das funktioniert für jeden Agent, unabhängig vom Hostingmodell.
Azure Pipelines-Agent unterstützt jetzt Alpine Linux
Der Pipeline-Agent v3.227 unterstützt jetzt alpine Linux-Versionen 3.13 und höher. Alpine Linux ist ein beliebtes Containerimage (Basisimage). Sie finden den Agent auf der Seite " Releases ". Alpine Linux-Versionen des Agents haben ein Präfix vsts-agent-linux-musl, z.B. vsts-agent-linux-musl-x64-3.227.1.tar.gz.
Azure Pipelines-Aufgaben verwenden Node 16
Aufgaben in der Pipeline werden mithilfe eines Läufers ausgeführt, wobei in den meisten Fällen Node.js verwendet werden. Azure Pipelines-Aufgaben, die einen Knoten als Läufer nutzen, verwenden jetzt alle Node 16. Da Node 16 die erste Node-Version ist, die Apple Silicon nativ unterstützt, wird auch die vollständige Aufgabenunterstützung für macOS auf Apple Silicon abgeschlossen. Agenten, die auf Apple Silicon-Prozessoren laufen, benötigen Rosetta nicht.
Da sich das Ende des Lebenszyklus von Node 16 verschoben hat, haben wir die Arbeit zum Ausführen von Aufgaben mit Node 20 begonnen.
Die Grenzen für Azure-Pipelines wurden erhöht, um sie an die maximale Größe von 4 MB für Azure Resource Manager (ARM)-Vorlagen anzupassen.
Sie können die Azure Resource Manager-Vorlagenbereitstellungsaufgabe zum Erstellen der Azure-Infrastruktur verwenden. Als Reaktion auf Ihr Feedback haben wir die Integrationsgrenze von Azure Pipelines von 2 MB auf 4 MB erhöht. Dies wird mit der maximalen Größe von 4 MB der ARM-Vorlagen übereinstimmen und dadurch die Größenbeschränkungen bei der Integration großer Vorlagen auflösen.
AzureRmWebAppDeployment-Aufgabe unterstützt die Microsoft Entra ID-Authentifizierung
Die Aufgaben "AzureRmWebAppDeploymentV3" und "AzureRmWebAppDeployment@4 " wurden aktualisiert, um den App-Dienst mit deaktivierter Standardauthentifizierung zu unterstützen. Wenn die Standardauthentifizierung für den App-Dienst deaktiviert ist, verwenden die AzureRmWebAppDeploymentV3/4-Aufgaben die Microsoft Entra ID-Authentifizierung, um Bereitstellungen am App Service Kudu-Endpunkt durchzuführen. Dies erfordert eine aktuelle Version von msdeploy.exe auf dem Agent installiert, was bei den windows-2022/windows-latest Hosted Agents der Fall ist (siehe Aufgabenreferenz).
Deaktivierte Außerkraftsetzung des Codeabdeckungsrichtlinienstatus auf "Fehlgeschlagen", wenn der Build fehlschlägt
Zuvor wurde der Status der Codeabdeckungsrichtlinie auf "Fehlgeschlagen" überschrieben, wenn Ihr Build im PR fehlschlug. Dies war ein Blocker für einige von Ihnen, die den Build als optionale Überprüfung und die Codeabdeckungsrichtlinie als erforderliche Überprüfung für PRs hatten, was dazu führt, dass PRs blockiert werden.
Jetzt wird die Code Coverage-Policy nicht mehr auf "Failed" gesetzt, wenn der Build fehlschlägt. Dieses Feature wird für alle Kunden aktiviert.
Artefakte
Einführung in die Azure Artifacts-Unterstützung für Frachtkrates
Wir freuen uns, ihnen mitzuteilen, dass Azure Artifacts jetzt native Unterstützung für Cargo-Kisten bieten. Diese Unterstützung umfasst die Featureparität in Bezug auf unsere vorhandenen Protokolle, sowie die Verfügbarkeit von crates.io als Upstreamquelle. Rost-Entwickler und -Teams können nun ihre Cargo-Crates nahtlos nutzen, veröffentlichen, verwalten und teilen, und dabei die robuste Infrastruktur von Azure nutzen und in der vertrauten Azure DevOps-Umgebung verbleiben.
Ankündigung der Ausmusterung für die NuGet Restore v1- und NuGet Installer v0-Pipelineaufgaben
Wenn Sie die Pipelineaufgaben NuGet Restore v1 und NuGet Installer v0 verwenden, wechseln Sie umgehend zur NuGetCommand@2 Pipelineaufgabe. Sie erhalten in Kürze Benachrichtigungen in Ihren Pipelines, wenn der Übergang noch nicht durchgeführt wurde. Wenn keine Maßnahmen ergriffen werden, schlagen Ihre Builds ab dem 27. November 2023 fehl.
Azure Artifacts-Unterstützung für npm-Überwachung
Azure Artifacts unterstützt jetzt npm audit und npm audit fix Befehle. Mit diesem Feature können Benutzer die Sicherheitsrisiken ihres Projekts analysieren und beheben, indem sie unsichere Paketversionen automatisch aktualisieren. Um mehr zu erfahren, besuchen Sie npm audit, um Sicherheitslücken in Paketen zu erkennen und zu beheben.
Berichterstattung
Neue Dashboard-Verzeichnisoberfläche
Wir haben Uns Ihr Feedback anhört und sind begeistert, die neue Dashboard-Verzeichnisoberfläche einzuführen. Es verfügt nicht nur über ein modernes UI-Design, sondern ermöglicht es Ihnen auch, nach jeder Spalte zu sortieren, und zwar mit dem Hinzufügen der Spalte "Zuletzt konfiguriert ". Diese Spalte bietet Ihnen bessere Einblicke in die allgemeine Dashboardnutzung in Ihrer Projektsammlung. Darüber hinaus können Sie jetzt nach Dashboards auf Team- oder Projektebene filtern, sodass Sie nur auf die Liste der Elemente zugreifen können, die Sie sehen müssen, während Sie die Dashboards ausblenden, die Sie nicht anzeigen möchten.
Probieren Sie es jetzt aus, und teilen Sie uns ihre Meinung in unserer Azure DevOps-Community mit
Arbeitsaufgabenfilterung
Wir freuen uns, die Filterung von Arbeitselementdiagrammen anzukündigen. Mit dieser Funktion können Sie mit der Maus über Ihr Arbeitselementdiagramm fahren, um schnell einen Überblick zu erhalten und in bestimmte Diagrammsegmente einzutauchen, um detaillierte Einblicke zu gewinnen. Sie müssen keine benutzerdefinierten Abfragen mehr erstellen, um auf die genauen Daten zuzugreifen, die Sie benötigen. Sie können nun Ihre Arbeitselemente in Arbeitsaufgabendiagrammen mit wenigen Klicks abrufen.
Ihr Feedback ist von unschätzbarem Wert bei der Gestaltung der Zukunft dieses Features. Probieren Sie es jetzt aus, und teilen Sie uns ihre Meinung in unserer Azure DevOps-Community mit.
Codeabdeckungsergebnisse für Ordner
Ergebnisse für die Codeabdeckung sind jetzt für jede einzelne Datei und jeden Ordner und nicht nur als Nummer der obersten Ebene verfügbar. Die Codeabdeckungsansicht wird angezeigt, wenn der Ordneransichtsmodus umgeschaltet wird. In diesem Modus können Sie sich detailliert die Codeabdeckung der ausgewählten Unterstruktur ansehen. Verwenden Sie die Umschaltfläche, um zwischen den neuen und alten Ansichten zu wechseln.
Testpläne
Schnelles Kopieren und Importieren mit Testplan- oder Suite-ID
Sie können jetzt mehrere Testpläne in Azure Test-Plänen mühelos verarbeiten! Angesichts der Herausforderungen, die zuvor mit langen Dropdown-Menüs beim Importieren, Kopieren oder Klonen von Testfällen auftraten – insbesondere für umfangreiche Pläne oder Suiten – haben wir Schritte unternommen, um Ihren Workflow zu optimieren.
Wir freuen uns, die Funktion "Test Plan und Suite ID Search" bekanntzugeben. Geben Sie Ihren Testplan oder Ihre Suite-ID ein, um Testfälle ohne Verzögerungen schnell zu importieren oder zu kopieren. Dieses Update ist Teil unseres kontinuierlichen Engagements zur Verbesserung Ihrer Testverwaltungserfahrung und macht es intuitiver und weniger zeitaufwendig.
Update für Azure Test Runner
Wir freuen uns, dass Azure Test Runner auf eine neuere Version aktualisiert wurde. Dieses Update verbessert die Stabilität und Leistung, sodass Sie Ihre Tests ohne Unterbrechungen oder Verzögerungen ausführen können. Die ältere Version von Azure Test Runner wird nicht mehr unterstützt. Um die beste Leistung und Zuverlässigkeit Ihrer Testvorgänge zu erzielen, empfehlen wir, so schnell wie möglich auf die neueste Version zu aktualisieren.
Neuigkeiten
- Verbesserte Stabilität und Leistung: Wir haben erhebliche Verbesserungen am Test Runner vorgenommen, um Probleme zu beheben, die bei einigen Benutzern aufgetreten sind. Dieses Upgrade stellt einen zuverlässigeren Testprozess sicher, wodurch Unterbrechungen für Ihre Arbeit minimiert werden.
- Upgradeaufforderung: Um den Übergang zur neuen Version nahtlos durchzuführen, wird eine Aufforderung zum Upgrade angezeigt. Dadurch wird sichergestellt, dass jeder auf einfache Weise zur verbesserten Version wechseln kann, um Kompatibilität und Leistung zu verbessern.
Feedback
Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden oder eine Idee bereitstellen und über Entwicklercommunity nachverfolgen und Ratschläge zu Stack Overflow erhalten.