Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Funktionen
- Updates für gehostete Bilder
- Workload-Identitätsverbund verwendet Entra-Aussteller
- Gradle@4-Aufgabe
- Identität des Benutzers, der eine Phase zum Ausführen von angefordert hat
Gehostete Bildupdates
Wir werden Updates einführen, um die gehosteten Agents von Azure Pipelines sicher und aktuell zu halten. Diese Updates umfassen die neue Unterstützung für Ubuntu-24.04, Windows 2025-Images und macOS-15 Sequoia, während ältere Images wie Ubuntu-20.04 und Windows Server 2019 eingestellt werden.
Weitere Details finden Sie in unserem Blogbeitrag.
macOS-15 Sequoia ist allgemein verfügbar
Das image macOS-15 wird ab dem 1. April auf von Azure Pipelines gehosteten Agents verfügbar sein. Um dieses Bild zu verwenden, aktualisieren Sie Ihre YAML-Datei so, dass sie vmImage:'macos-15'enthält:
- job: macOS15
pool:
vmImage: 'macOS-15'
steps:
- bash: |
echo Hello from macOS Sequoia
sw_vers
Installierte MacOS-15-Software finden Sie unter Imagekonfiguration.
Das Image macOS-14 wird weiterhin verwendet, wenn macOS-latest angegeben wird. Wir werden macOS-latest im April auf die Verwendung von macOS-15 aktualisieren.
Windows-2025-Image ist in der Vorschau verfügbar
Das windows-2025-Image ist jetzt in der Vorschauversion für von Azure Pipelines gehostete Agents verfügbar. Um dieses Bild zu verwenden, aktualisieren Sie Ihre YAML-Datei so, dass sie vmImage:'windows-2025'enthält:
- job: win2025
pool:
vmImage: 'windows-2025'
steps:
- pwsh: |
Write-Host "(Get-ComputerInfo).WindowsProductName"
Get-ComputerInfo | Select-Object WindowsProductName
Write-Host "`$PSVersionTable.OS"
$PSVersionTable.OS
Informationen zur installierten Windows Server 2025-Software finden Sie unter Imagekonfiguration.
Das neueste Ubuntu-Pipelineimage wird mit Ubuntu-24.04 eingeführt
In den kommenden Wochen werden Pipelineaufträge, die ubuntu-latest angeben, beginnen, ubuntu-24.04 anstelle von ubuntu-22.04zu verwenden.
Anleitungen zu Aufgaben, die Tools verwenden, die sich nicht mehr auf dem bild ubuntu-24.04 befinden, finden Sie in unserem Blogbeitrag. Um Ubuntu 22.04 weiterhin zu verwenden, verwenden Sie die ubuntu-22.04 Bildbezeichnung:
- job: ubuntu2404
pool:
vmImage: 'ubuntu-24.04'
steps:
- bash: |
echo Hello from Ubuntu 24.04
lsb_release -d
- pwsh: |
Write-Host "`$PSVersionTable.OS"
$PSVersionTable.OS
Das Ubuntu-20.04-Pipelineimage ist veraltet und wird am 1. April eingestellt.
Wir stellen die Unterstützung für das Ubuntu 20.04-Image in Azure Pipelines ein, da es bald nicht mehr unterstützt wird. Den Einstellungsplan mit dem Zeitplan für Brownouteinschränkungen finden Sie in unserem Blogbeitrag.
Workload-Identitätsverbund verwendet Entra-Aussteller
Vor knapp einem Jahr haben wir den Workload-Identitätsverbund allgemein verfügbar gemacht. Mithilfe des Workload-Identitätsverbunds können Sie eine Dienstverbindung ohne einen geheimen Schlüssel konfigurieren. Die Identität (App-Registrierung, verwaltete Identität), die die Dienstverbindung untermauert, kann nur für den vorgesehenen Zweck verwendet werden: die in den Verbundanmeldeinformationen der Identität konfigurierte Dienstverbindung.
Wir ändern nun das Format der Verbundanmeldeinformationen für neue Azure- und Docker-Dienstverbindungen. Vorhandene Dienstverbindungen funktionieren wie zuvor.
| Azure DevOps-Aussteller | Entra-Aussteller (neue Dienstverbindungen) | |
|---|---|---|
| Emittent | https://vstoken.dev.azure.com/<organization id> |
https://login.microsoftonline.com/<Entra tenant id>/v2.0 |
| Betreff | sc://<organization name>/<project name>/<service connection name> |
<entra prefix>/sc/<organization id>/<service connection id> |
Es gibt keine Änderung der Konfiguration, und die Art und Weise, wie Token abgerufen werden, bleibt gleich. Pipelineaufgaben müssen nicht aktualisiert werden und funktionieren wie zuvor.
Die Schritte zum Erstellen einer Dienstverbindung ändern sich nicht, und in den meisten Fällen ist der neue Aussteller nicht sichtbar. Wenn eine Azure-Dienstverbindung manuell konfiguriert wird, werden die neuen Verbundanmeldeinformationen angezeigt:
Kopieren Sie diese Werte wie zuvor beschrieben, wenn Sie federierte Anmeldeinformationen für eine App-Registrierung oder eine verwaltete Identität erstellen.
Automatisierung
Verwenden Sie beim Erstellen einer Dienstverbindung in der Automatisierung mit der REST-API-die von der API zurückgegebenen Verbundanmeldeinformationen:
authorization.parameters.workloadIdentityFederationIssuer
authorization.parameters.workloadIdentityFederationSubject
Ebenso gibt die azuredevops_serviceendpoint_azurerm Ressource beim Erstellen einer Dienstverbindung mit dem Terraform azuredevops-Anbieter workload_identity_federation_issuer und workload_identity_federation_subject Attribute zurück.
Weitere Informationen
- Herstellen einer Verbindung mit Azure mit einer Azure Resource Manager-Dienstverbindung
- Problembehandlung bei einer Azure Resource Manager-Workload-Identitätsdienstverbindung
Gradle@4-Aufgabe
Es wurde eine neue Gradle@4 Aufgabe mit Unterstützung für Gradle 8.0-erstellt. Die integrierte Code Coverage-Option wird ab Gradle aus der Gradle@4-Aufgabe entfernt. So verwenden Sie Code Coverage mit Gradle in Ihrer Pipeline:
- Geben Sie Code Coverage-Plugins in Ihrer build.gradle-Datei an. Weitere Informationen finden Sie unter Gradle-Codeanalyseoptionen.
- Verwenden Sie die Aufgabe PublishCodeCoverageResults@2 in Ihrer Pipeline nach der Aufgabe
Gradle@4.
Die Konfiguration der SonarQube-Analyse wurde in die Erweiterungen SonarQube oder SonarCloud in der Aufgabe Prepare Analysis Configurationverschoben.
Identität des Benutzers, der die Ausführung einer Phase angefordert hat
Um die Sicherheit Ihrer YAML-Pipelines zu verbessern, sollten Sie wissen, wer eine Phase zur Ausführung angefordert hat. Um diese Notwendigkeit zu beheben, wurden zwei neue vordefinierte Variablen hinzugefügt, Build.StageRequestedBy und Build.StageRequestedById. Diese Variablen ähneln den Variablen Build.RequestedFor und Build.RequestedForId, beziehen sich jedoch auf eine Phase, nicht auf einen Durchlauf.
Wenn ein Benutzer einen Benutzer explizit auslöst, z. B. bei einer manuell ausgelösten Phase oder beim erneuten Ausführen einer Phase, wird seine Identität verwendet, um die beiden Variablen auszufüllen.
Nächste Schritte
Hinweis
Diese Features werden in den nächsten zwei bis drei Wochen bereitgestellt.
Gehen Sie zu Azure DevOps und schauen Sie sich an.
Zu Azure DevOps wechseln
So geben Sie Feedback
Wir würden uns freuen zu hören, was Sie über diese Features denken. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.
Sie können auch die Community auf Stack Overflowum Ratschläge bitten und Ihre Fragen beantworten lassen.