Einstellung zum Deaktivieren der Erstellung von TFVC-Repositorys
Mit diesem Update führen wir eine neue Einstellung ein, um die Erstellung von TFVC-Repositorys zu deaktivieren. Diese Änderung konzentriert sich auf neue Projekte und stellt sicher, dass Ihre vorhandenen TFVC-Repositorys nicht betroffen sind.
Darüber hinaus freuen wir uns, ihnen mitzuteilen, dass in Azure Pipelines ein neuer REST-API-Endpunkt zum Anfordern von OIDC-Token verfügbar ist! Auf diese Weise können Aufgabenentwickler idTokens für die Entra-ID-Authentifizierung generieren und die Sicherheit und Benutzerfreundlichkeit verbessern.
Schließlich können In Azure Boards, Bereichs- und Iterationspfaden jetzt nur gelöscht werden, wenn sie keiner Arbeitsaufgaben mehr zugeordnet sind. Diese Verbesserung verhindert Unterbrechungen und stellt sicher, dass Teams zugriff auf ihre Boards und Backlogs behalten.
Weitere Informationen finden Sie in den Versionshinweisen.
GitHub Advanced Security für Azure DevOps
Azure Boards:
Azure Repos
Azure Pipelines
- Zugreifen auf Azure Service Bus über Pipelines mithilfe der Microsoft Entra ID-Authentifizierung
- Pipelines und Aufgaben füllen Variablen auf, um die Workload-Identitätsverbundauthentifizierung anzupassen
- Wiederholungen für Serveraufgaben
- Aufgaben, die eine End-of-Life Node Runner-Version zum Ausführen von Warnungen verwenden
- DockerCompose0 verwendet Docker Compose v2 im v1-Kompatibilitätsmodus
Azure Test Plans:
GitHub Advanced Security für Azure DevOps
Api-Dokumentation zur Sicherheitsübersicht ist jetzt verfügbar
Dokumentation für die API, die die Registerkarte "Erweiterte Sicherheit – Übersicht über Risiken" aktiviert, ist jetzt verfügbar. Verwenden Sie den Endpunkt /{organization}/_apis/reporting/summary/alerts
, um eine Zusammenfassung der Warnungskritischität in allen advanced Security-fähigen Repositorys anzuzeigen. Stellen Sie sicher, dass Ihr ADO-PAT über die vso.advsec
Berechtigung verfügt, die die Möglichkeit zum Lesen von Warnungen, Ergebnisinstanzen und Analyseergebnisinstanzen gewährt.
Azure Boards
Änderung für das Löschen von Bereichs- und Iterationspfaden
Das Löschen eines Bereichs oder Iterationspfads kann störend sein. Sie kann Arbeitsaufgaben in einen neuen Pfad verschieben und dazu führen, dass Teams den Zugriff auf ihre Boards und Backlogs verlieren. Trotz Warnungen und Eingabeaufforderungen werden Pfade manchmal gelöscht, ohne die Folgen vollständig zu verstehen. Um dies zu beheben, haben wir das Verhalten geändert: Bereichs- und Iterationspfade können jetzt nur gelöscht werden, wenn sie nicht mehr von Arbeitsaufgaben verwendet werden.
Azure Repos
Neue Einstellung zum Deaktivieren der Erstellung von TFVC-Repositorys
In den letzten Jahren wurden keine neuen Features zu Team Foundation-Versionskontrolle (TFVC) hinzugefügt, da Git zum bevorzugten Versionssteuerungssystem in Azure Repos geworden ist. Alle jüngsten Verbesserungen an Sicherheit, Leistung und Bedienungshilfen wurden ausschließlich an Git-Repositorys vorgenommen, was zu einem kontinuierlichen Rückgang der TFVC-Nutzung führt. Während einige noch auf TFVC angewiesen sind und wir nicht beabsichtigen, diesen Feature-Satz zu entfernen, planen wir, TFVC schrittweise für neue Projekte und Organisationen sowie für Projekte, die derzeit TFVC nicht verwenden, auszuschalten.
Im Rahmen dieses Übergangs führen wir eine neue Einstellung zum Thema „Erstellung von TFVC-Repositorys deaktivieren“ ein, die sich nur auf die Erstellung neuer TFVC-Repositorys auswirkt und keine Auswirkungen auf vorhandene hat.
Azure Pipelines
Zugreifen auf Azure Service Bus über Pipelines mithilfe der Microsoft Entra ID-Authentifizierung
Sie können jetzt die Microsoft Entra ID-Authentifizierung verwenden, um über Azure Pipelines auf Azure Service Bus zuzugreifen. Auf diese Weise können Sie den Workload-Identitätsverbund nutzen, um die Geheimschlüsselverwaltung und Azure RBAC für eine differenzierte Zugriffssteuerung zu entfernen.
Identitäten, die auf Azure Service Bus zugreifen, müssen einer der integrierten Azure-Rollen für Azure Service Bus auf dem ServiceBus gewährt werden, auf die zugegriffen wird.
PublishToAzureServiceBus@2 Aufgabe
Die neuen PublishToAzureServiceBus@2 Aufgaben können mithilfe einer Azure-Dienstverbindung konfiguriert werden. Erstellen Sie eine Azure-Dienstverbindung , und füllen Sie die serviceBusQueueName
Eigenschaften serviceBusNamespace
und Eigenschaften der neuen Aufgabe auf:
- task: PublishToAzureServiceBus@2
inputs:
azureSubscription: my-azure-service-connection
serviceBusQueueName: my-service-bus-queue
serviceBusNamespace: my-service-bus-namespace
useDataContractSerializer: false
messageBody: |
{
"foo": "bar"
}
Serveraufgaben
Benutzerdefinierte Serveraufgaben (agentlose) Aufgaben, die die Ausführung verwenden ServiceBus
, können eine Azure-Dienstverbindung angeben und EndpointId
weglassen ConnectionString
. Siehe Serveraufgabenerstellung.
Pipelines und Aufgaben füllen Variablen auf, um die Workload-Identitätsverbundauthentifizierung anzupassen
Der REST-API-Endpunkt zum Anfordern von OIDC-Token ist jetzt in der System.OidcRequestUri
Pipelinevariable verfügbar. Aufgabenentwickler können diese Variable nutzen, um ein idToken für die Authentifizierung mit Entra-ID zu generieren.
Wenn Sie Marketplace-Aufgaben oder benutzerdefinierte Aufgaben für die Bereitstellung in Azure verwenden, beachten Sie bitte, dass diese Aufgaben den Workload-Identitätsverbund möglicherweise noch nicht unterstützen. Es wird empfohlen, Aufgabenentwicklern die Aktivierung des Workloadidentitätsverbunds zur Verbesserung der Sicherheitsmaßnahmen zu ermöglichen.
Aufgaben, die eine Eingabe in task.json ausführen, können aktualisiert werden, um den connectedService:AzureRM
Workload-Identitätsverbund zu unterstützen, indem Sie die folgenden Schritte ausführen:
- Verwenden Sie die Oidctoken-REST-API , um ein idToken anzufordern (Pfeil 1 im obigen Diagramm).
- Exchange the idToken for an access token using the federated credential flow of the OAuth API, specifying the idToken as
client_assertion
(arrows 2 & 4 in above diagram);
oder: - Verwenden Sie für Aufgaben, die als Wrapper für ein Tool fungieren, das die Authentifizierung selbst durchführt, die Authentifizierungsmethode der Tools, um das Verbundtoken anzugeben.
Knotenaufgaben können das "azure-pipelines-tasks-artifacts-common npm"-Paket verwenden, um das idToken abzurufen. Weitere Informationen zur Implementierung finden Sie im Codebeispiel .
Anfordern eines neuen idTokens
Die System.OidcRequestUri
Pipelinevariable und AZURESUBSCRIPTION_SERVICE_CONNECTION_ID
Umgebungsvariable, die in den AzureCLI@2
und AzurePowerShell@5
Aufgaben verfügbar gemacht wird, ermöglichen Es Pipelineautoren, sich über ihr eigenes Skript zu authentifizieren:
PowerShell Az
- task: AzurePowerShell@5
inputs:
azureSubscription: 'my-azure-subscription'
scriptType: inlineScript
inline: |
# Request fresh idToken
Invoke-RestMethod -Headers @{
Authorization = "Bearer $(System.AccessToken)"
'Content-Type' = 'application/json'
} `
-Uri "${env:SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${env:AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}" `
-Method Post `
| Select-Object -ExpandProperty oidcToken
| Set-Variable idToken
# Fetch current context
$azContext = Get-AzContext
# Start new Az session
Connect-AzAccount -ApplicationId $azContext.Account.Id `
-TenantId $azContext.Tenant.Id `
-SubscriptionId $azContext.Subscription.Id `
-FederatedToken $idToken
Azure CLI
- task: AzureCLI@2
inputs:
addSpnToEnvironment: true
azureSubscription: 'my-azure-subscription'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
# Request fresh idToken
OIDC_REQUEST_URL="${SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}"
ARM_OIDC_TOKEN=$(curl -s -H "Content-Length: 0" -H "Content-Type: application/json" -H "Authorization: Bearer $(System.AccessToken)" -X POST $OIDC_REQUEST_URL | jq -r '.oidcToken')
# Save subscription context
ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv)
# New az-cli session
az login --service-principal -u $servicePrincipalId --tenant $tenantId --allow-no-subscriptions --federated-token $ARM_OIDC_TOKEN
az account set --subscription $ARM_SUBSCRIPTION_ID
Wiederholungen für Serveraufgaben
Serveraufgaben, die externe Systeme aufrufen, wie z AzureFunction
. B. oder InvokeRESTAPI
, können gelegentlich aufgrund vorübergehender Fehler wie Rechenressourcenausschöpfung fehlschlagen. Bisher würden solche Fehler dazu führen, dass der gesamte Auftrag und möglicherweise die Pipeline fehlschlagen.
Um die Resilienz gegen vorübergehende Fehler zu verbessern, haben wir Unterstützung für die retryCountOnTaskFailure
Eigenschaft in Serveraufgaben eingeführt. Gehen Sie davon aus, dass Sie den folgenden YAML-Code in Ihrer Pipeline haben:
- stage: deploy
jobs:
- job:
pool: server
steps:
- task: AzureFunction@1
retryCountOnTaskFailure: 2
inputs:
function: 'https://api.fabrikamfiber.com'
key: $(functionKey)
method: 'POST'
waitForCompletion: 'false'
Wenn https://api.fabrikamfiber.com
ein vorübergehender Fehler auftritt, wird die Anforderung von Azure Pipelines bis zu dreimal wiederholt (der anfängliche Versuch plus zwei Wiederholungsversuche, die durch retryCountOnTaskFailure
angegeben werden). Jeder Wiederholungstest enthält einen zunehmenden Wartezeitszeitraum. Die maximale Anzahl zulässiger Wiederholungsversuche beträgt 10.
Dies retryCountOnTaskFailure
ist für den ManualValidation
Vorgang und andere Vorgänge, die keine externen Systemaufrufe umfassen, nicht verfügbar.
Aufgaben, die eine End-of-Life Node Runner-Version zum Ausführen von Warnungen verwenden
Pipelineaufgaben, die auf einer Node-Version basieren, werden keine Warnungen mehr erhalten :
Die Aufgabenversion
TaskName
<version>
ist von einer Node-Version (10) abhängig, die das Ende der Lebensdauer ist. Wenden Sie sich an den Erweiterungsbesitzer für eine aktualisierte Version der Aufgabe. Task maintainers should review Node upgrade guidance: https://aka.ms/node-runner-guidance
Um diese Warnungen zu unterdrücken, können Sie eine Umgebung oder Pipelinevariable entweder auf Pipelineebene (Auftrag) oder Auf Vorgangsebene festlegen. Zum Beispiel:
variables:
AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false
DockerCompose@0 verwendet Docker Compose v2 im v1-Kompatibilitätsmodus
Docker Compose v1 erreicht das Ende der Lebensdauer und wird vom 24. Juli 2024 aus gehosteten Agents entfernt. Wir haben die aufgabe DockerCompose@0 so aktualisiert, dass Docker Compose v2 im v1-Kompatibilitätsmodus verwendet wird, wenn Docker Compose v1 für den Agent nicht verfügbar ist.
Der Kompatibilitätsmodus behebt jedoch nicht alle Kompatibilitätsprobleme. Siehe Migrieren zu Compose V2. Einige Benutzer benötigen mehr Zeit, um ihre Docker Compose-Projekte für die Docker Compose v2-Kompatibilität zu aktualisieren. Befolgen Sie in diesen Fällen diese Anweisungen, um die DockerComposeV0-Aufgabe mit docker-compose v1 zu verwenden.
HINWEIS: Dieses Handbuch basiert auf der eigenständigen Dokumentation zum Installieren von Verfassen
Verwenden von docker-compose v1 unter Windows
Fügen Sie der Pipeline den PowerShell-Schritt hinzu, um die Docker-Compose v1.29.2 herunterzuladen und mit der DockerComposeV0-Aufgabe unter Windows zu verwenden:
variables:
dockerComposePath: C:\docker-compose
steps:
- powershell: |
mkdir -f $(dockerComposePath)
# GitHub now requires TLS1.2. In PowerShell, run the following
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: '**/docker-compose.yml'
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)\docker-compose.exe
Verwenden von docker-compose v1 unter Linux
Fügen Sie der Pipeline den Bash-Schritt hinzu, um Docker-Compose v1.29.2 herunterzuladen und mit der DockerComposeV0-Aufgabe unter Linux zu verwenden:
variables:
dockerComposePath: /tmp/docker-compose
steps:
- bash: |
sudo mkdir $(dockerComposePath)
sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
sudo chmod 755 $(dockerComposePath)/docker-compose
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)/docker-compose
Azure Test Plans
Test- und Feedbackerweiterung in Manifest V3
Wir freuen uns, ein neues Update für die Azure DevOps-Test- und Feedback-Erweiterung bekanntzugeben! Dieses Upgrade übergibt unsere Implementierung von Manifest Version 2 zu Version 3 und richtet sich an den Veralteten Zeitplan von Google für Manifest V2.
Während die Kernfunktionen der Erweiterung unverändert bleiben, verbessert dieses Update die Sicherheit und Leistung. Die aktualisierte Erweiterung wird in den kommenden Wochen schrittweise für Chrome- und Edge-Browser eingeführt. Wir überwachen die Leistung und das Feedback, um einen reibungslosen Übergang sicherzustellen, bevor wir den Rollout basierend auf den Ergebnissen erweitern.
Weitere Details finden Sie in unserem aktuellen Blogbeitrag zu diesem Update. Test- und Feedbackerweiterung im Manifest V3
Nächste Schritte
Hinweis
Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.
Wechseln Sie zu Azure DevOps, und sehen Sie sich an.
Senden von Feedback
Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.
Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.
Vielen Dank,
Silviu Andrica