Versionshinweise zu Azure DevOps Server 2022 Update 2
| Entwicklercommunity Systemanforderungen und Kompatibilitätslizenzbedingungen | | 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.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: Sicherheitsanfälligkeit in Azure DevOps Server
- CVE-2024-35267: Sicherheitsanfälligkeit in Azure DevOps Server für Spoofing
- Entwicklercommunity Feedbackticket: Die Agentversion wird nach dem Upgrade auf Azure DevOps Server 2022.1 und der Verwendung des Update-Agents in der Agentpoolkonfiguration nicht aktualisiert.
- Entwicklercommunity Feedbackticket: Problem beim Laden der Teamkonfigurationsseite
- Entwicklercommunity Feedbackticket: 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
- Schnellkopie und Import 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 Testausführungsanlagen 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 weberweiterungen die Kommunikation mit dem Hostframe. 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)
- Abrufen von Designinformationen
- Abrufen eines Autorisierungstokens zur Verwendung in REST-Aufrufen zurück zu Azure DevOps
- Abrufen von Remotediensten, 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
});
Boards
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 Bereitstellungssteuerelemente
Wir entfernen nun die Entwicklungs- und/oder Bereitstellungssteuerelemente aus der Arbeitsaufgabe, je nachdem, wie Ihr Projekt konfiguriert ist. Beispielsweise können Sie Ihre Projekteinstellungen so konfigurieren, dass Repos und/oder Pipelines deaktiviert werden.
Wenn Sie zur Arbeitsaufgabe wechseln, werden die entsprechenden Entwicklungs- und Bereitstellungssteuerelemente im 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 genehmigt und mit strengeren gesetzlichen/Compliance-Anforderungen übereinstimmen, bieten wir eine Möglichkeit, die Genehmigung seiner eigenen Änderungen zu verhindern, es sei denn, der Benutzer ist ausdrücklich zulässig.
Benutzer mit der Möglichkeit, die Verzweigungsrichtlinien zu verwalten, können jetzt die neu hinzugefügte Option "Mindestens eine Genehmigung für jede Iteration anfordern" unter "Wenn neue Änderungen pusht werden" wechseln. Wenn diese Option ausgewählt ist, ist mindestens eine Genehmigungsstimme für die letzte Quellzweigänderung erforderlich. Die Genehmigung des Benutzers wird nicht auf alle vorherigen nicht genehmigten Iterationen gezählt, 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 pull-Anforderung, die von Benutzer A erstellt wurde, und zusätzliche 4 Commits (Iterationen), die an diese Pullanforderung von Benutzern B, C, A erneut und C vorgenommen wurden. Nach der zweiten Iteration (Commit durch Benutzer B) wurde der Benutzer C genehmigt. Zu diesem Zeitpunkt impliziert die Genehmigung des ersten Commits von Benutzer A (beim Erstellen der Pullanforderung) und die neu eingeführte Richtlinie erfolgreich. Nach der fünften Iteration (letzter Commit des Benutzers C) wurde die Genehmigung durch Benutzer A durchgeführt. Diese implizite Genehmigung für einen früheren Commit durch Benutzer C, aber nicht implizierte 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 annehmen, die als Prüfer konfiguriert ist, als Genehmigungsentität. 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 (Blobless Clone) wird am besten für die normale Entwicklung verwendet, während die zweite Option (baumloses Klonen) besser für die Fälle passt, in denen Sie den Klon verwerfen, z. B. einen Build ausführen.
SSH-RSA-Veraltet
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 Veraltetkeit von SSH-RSA als unterstützte Verschlüsselungsmethode für die Verbindung mit Azure Repos mit SSH angekündigt. Weitere Details finden Sie im Blogbeitrag "Ende der SSH-RSA-Unterstützung für Azure Repos ".
Pipelines
Verhindern unbeabsichtigter Pipelineausführungen
Wenn Ihre YAML-Pipeline heute keinen Abschnitt angibt trigger , wird er für änderungen ausgeführt, die an das Repository übertragen wurden. 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 einer Phase, wenn Genehmigungen und Zeitüberschreitungen ausgecheckt werden
Wenn Genehmigungen und Zeitüberschreitungen ausgecheckt werden, 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 wiederholen, wenn Genehmigungen und Timeouts überprüft werden. Bisher war dies nur möglich, wenn ein Genehmigungstimeout erfolgt 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 der Azure-Funktion aufrufen (um eine Verzögerung zwischen verschiedenen Regionen zu erzwingen).
Stellen Sie sich nun vor, Sie müssen eine Hotfixbereitstellung durchführen. Sie starten eine Pipelineausführung, aber es wird nicht fortgesetzt, es wartet auf die meisten Überprüfungen, bis sie abgeschlossen ist. 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 Rest-API-Überprüfungen umgehen.
Umgehen einer Genehmigung.
Überprüfung der Geschäftszeiten umgehen.
Umgehung der Azure-Funktionsüberprüfung. Überprüfung der Geschäftszeiten 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 Ausführen 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- und eine Aufruf-Azure-Funktionsüberprüfung, die eine Sanity-Prüfung für den bereits bereitgestellten Teil des Systems ausfü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 die Azure-Funktion und REST-API-Überprüfungen 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 Vorlageüberprüfung "Anfordern" können Sie erzwingen, dass eine Pipeline aus einer Reihe genehmigter Vorlagen erweitert wird, bevor Sie auf eine geschützte Ressource zugreifen, z. B. einen Agentpool oder eine Dienstverbindung.
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 mit Dienstverbindungen oder Agentpools analysiert. 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, verwalten, anzeigen und verwenden. Dazu gehört auch das Öffnen von Umgebungen für alle Pipelines.
Wenn Sie einer Benutzeradministratorrolle auf Umgebungen-Hub-Ebene gewähren, werden sie Administratoren für alle vorhandenen Umgebungen und für zukünftige 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, auf die Sie mit Bereitstellungen aus einer Pipeline abzielen können. Umgebungen bieten Bereitstellungsverlauf, Rückverfolgbarkeit für 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 an der REST-API für Genehmigungen
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 zur Pipelineausführung, zu der 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 Ressourcenauslastung.
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-Agent und untergeordneten Prozessen verwendet werden, einschließlich Tasks, die in einem Auftrag ausgeführt werden.
Wenn Sie vermuten, dass Ihr Pipelineauftrag möglicherweise zu Ressourceneinschränkungen führt, aktivieren Sie ausführliche Protokolle , um Ressourcennutzungsinformationen in 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 z.B. vsts-agent-linux-musl-x64-3.227.1.tar.gzein Präfixvsts-agent-linux-musl.
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. Agents, die auf Apple Silicon laufen, müssen Rosetta nicht laufen.
Da sich das Ende des Lebenszyklus von Node 16 verschoben hat, haben wir die Arbeit zum Ausführen von Aufgaben mit Node 20 begonnen.
Erhöhte Azure Pipeline-Grenzwerte für die Anpassung an die maximale Größe von 4 MB an azure Resource Manager (ARM).
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. Dadurch wird die maximale Größe von 4 MB an den ARM-Vorlagen angepasst, wobei Größenbeschränkungen bei der Integration großer Vorlagen aufgelöst werden.
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 Codeabdeckungsrichtlinienstatus auf "Fehlgeschlagen" überschrieben, wenn ihr Build in der 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 Codeabdeckungsrichtlinie nicht auf "Failed" überschrieben, wenn der Build fehlschlägt. Dieses Feature wird für alle Kunden aktiviert.
Artifacts
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, zusätzlich zu crates.io als Upstreamquelle verfügbar zu sein. Rost-Entwickler und -Teams können jetzt ihre Cargo-Kisten nahtlos nutzen, veröffentlichen, verwalten und teilen, während Sie die robuste Infrastruktur von Azure nutzen und in der vertrauten Azure DevOps-Umgebung bleiben.
Ankündigung zum Veralteten für 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 bald Benachrichtigungen in Ihren Pipelines, wenn der Übergang noch nicht erfolgt ist. Wenn keine Aktion ausgeführt wird, werden Ihre Builds ab dem 27. November 2023 nicht erfolgreich ausgeführt.
Azure Artifacts-Unterstützung für npm-Überwachung
Azure Artifacts unterstützt npm audit jetzt und npm audit fix Befehle. Mit diesem Feature können Benutzer die Sicherheitsrisiken ihres Projekts analysieren und beheben, indem sie unsichere Paketversionen automatisch aktualisieren. Weitere Informationen finden Sie unter "npm audit", um Paketrisiken zu erkennen und zu beheben.
Reporting
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 über die Filterung von Arbeitsaufgabendiagrammen. Mit diesem Feature können Sie mit dem Mauszeiger auf Ihr Arbeitselementdiagramm zeigen, um eine schnelle Übersicht zu erhalten und einen Drilldown zu bestimmten Diagrammsegmenten zu erhalten, um detaillierte Einblicke zu erhalten. Sie müssen keine benutzerdefinierten Abfragen mehr erstellen, um auf die genauen Daten zuzugreifen, die Sie benötigen. Sie können nun ihre Arbeitsaufgaben in Arbeitsaufgabendiagrammen in wenigen Klicks eintauchen.
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 die Schaltfläche "Ordneransicht " umgeschaltet wird. In diesem Modus können Sie einen Drilldown ausführen und die Codeabdeckung für diese ausgewählte Unterstruktur anzeigen. Verwenden Sie die Umschaltfläche, um zwischen den neuen und alten Ansichten zu wechseln.
Test Plans
Schnellkopie und Import mit Testplan oder Suite-ID
Sie können jetzt mehrere Testpläne in Azure Test-Plänen mühelos verarbeiten! Die Herausforderungen zu erkennen, die zuvor mit langen Dropdownmenüs zum Importieren, Kopieren oder Klonen von Testfällen – insbesondere für umfangreiche Pläne oder Suites – konfrontiert waren, haben wir Schritte unternommen, um Ihren Workflow zu optimieren.
Wir freuen uns, das Feature "Testplan" 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.