Freigeben über

Allgemeine Verfügbarkeit des Workload-Identitätsverbunds für Azure Resource Manager-Dienstverbindungen

  • Artikel

Wir freuen uns, ihnen mitzuteilen, dass der Workload-Identitätsverbund jetzt in Azure-Pipelines allgemein verfügbar ist! Sie können eine optimierte Erfahrung genießen, ohne geheime Schlüssel und Zertifikate in Azure-Dienstverbindungen verwalten zu müssen.

Mit diesem Update zeigen wir auch eine Vorschau eines neuen Features als Teil unserer erweiterten GitHub-Integration in Azure Boards an. Sie können jetzt direkt mit GitHub-Pullanforderungen oder Commits verknüpfen. Kein Wechsel zwischen Fenstern oder Kopieren/Einfügen mehr. Wählen Sie einfach das gewünschte Repository aus, suchen Sie die pull-Anforderung, oder übernehmen Sie ihn, und verknüpfen Sie es!

Schauen Sie sich die Versionshinweise an, um mehr über diese Features zu erfahren.

Allgemein

GitHub Advanced Security für Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

Allgemein

Abschließender Hinweis auf veraltete Anmeldeinformationen

Alternative Anmeldeinformationen wurden im März 2020 formell nicht mehr unterstützt, aber einige bestehende Benutzer waren mit der laufenden Nutzung ihrer vorhandenen alternativen Anmeldeinformationen großgeschrieben. Seit Januar 2024 sind alle alternativen Anmeldeinformationen vollständig veraltet. Um potenzielle Unterbrechungen zu vermeiden, wechseln Sie zu einem der verfügbaren Authentifizierungsmechanismen , die wir bereitstellen, z. B. persönliche Zugriffstoken oder verwaltete Identitäten.

Azure Devops OAuth Self-Service Secret Rotation

Alle fünf Jahre ist es wichtig, den geheimen Clientschlüssel für Ihre Azure DevOps OAuth-App zu aktualisieren, um die kontinuierliche Generierung von Zugriffs- und Aktualisierungstoken sicherzustellen, die für die Verwendung von Azure DevOps-APIs erforderlich sind. Wenn Ihr Geheimer Clientschlüssel abläuft, können Sie jetzt unabhängig voneinander eine neue generieren und Ihrem Team die Freiheit bieten, sie zu verwalten, ohne sich auf den Kundensupport zu verlassen. Diese Flexibilität bei der Planung der geheimen Drehung minimiert potenzielle Ausfallzeiten für Ihre Kunden, die aufgrund eines abgelaufenen Geheimschlüssels auf einen Ersatz warten.

Screenshot der Option

Suchen Sie diese neue Funktionalität auf jeder Ihrer Azure DevOps-App-Seiten, auf die über Ihr Profil zugegriffen werden kann. Erfahren Sie mehr über diesen neuen Schritt in unserem Azure DevOps OAuth-Leitfaden.

GitHub Advanced Security für Azure DevOps

Codeausschnitte jetzt in der Warnungsdetailsansicht verfügbar

Auf der Warnungsdetailseite für Codescan- und geheime Scanwarnungen werden jetzt Codeausschnitte angezeigt, die die eine oder mehrere Codezeilen markieren, in denen die Warnung aufgetreten ist. Um zur ursprünglichen Datei im Azure DevOps-Repository zu wechseln, klicken Sie auf den Dateinamen oberhalb des Codeausschnitts.

Screenshot des Middlewarepfads mit Groß-/Kleinschreibung.

Abgeschnittene geheime Schlüssel, die in der Warnungsübersicht angezeigt werden

Die abgeschnittenen, letzten sechs Zeichen aller erkannten geheimen Schlüssel werden nun im Übersichtsbildschirm für geheime Schlüssel angezeigt. Dieses Feature ist hilfreich, wenn Sie über mehrere geheime Expositionen desselben geheimen Typs verfügen, sodass Sie schnell erkennen können, wo bestimmte Geheimnisse leben.

Screenshot der Liste der geheimen Warnungen.

Weitere Warnungsschweregrade für Codescanbenachrichtigungen hinzugefügt

Neue Warnungsschweregrade sind jetzt für Warnungsergebnisse aus den CodeQL-Abfragen quality als Error, Warning, und Note Schweregrad vorhanden. Jeder Qualitätswarnungsschweregrad weist ein eigenes Signal und eine eigene Farbe auf, um skalierungsschwere zu kennzeichnen. Sie können auch nach jedem dieser Schweregrade filtern, ähnlich wie der low critical Schweregrad für Sicherheitswarnungen.

Screenshot der Liste der Codeüberprüfungswarnungen und des Schweregradfilters.

Verknüpftes Azure-Abonnement erforderlich für die Aktivierung von GitHub Advanced Security für Azure DevOps

Wenn Sie zuvor Advanced Security für Repositorys in einer Azure DevOps-Organisation ohne ein verknüpftes Azure-Abonnement aktiviert haben, werden Sie möglicherweise feststellen, dass Advanced Security automatisch in diesen Repositorys deaktiviert wurde. Um Advanced Security erneut zu aktivieren, fügen Sie der Organisation ein zugeordnetes Azure-Abonnement hinzu. Weitere Informationen zum Hinzufügen oder Ändern Ihres Abonnements finden Sie unter Ändern des Azure-Abonnements.

Erweiterte Sicherheits-API Updates

Verschiedene Updates für die kürzlich ausgelieferten Advanced Sicherheits-API s:

  • Die GET Alerts-API unterstützt jetzt einen neuen Parameter, ModifiedSinceum eine inkrementelle Liste von Warnungen zurückzugeben und nur Warnungen zurückzugeben, die seit diesem Datum geändert wurden. Weitere Informationen finden Sie unter Warnungen – Liste.
  • Es gibt zwei neue Endpunkte zum Abrufen oder Aktualisieren des Advanced Security-Aktivierungsstatus einer Organisation oder eines Projekts. Beide Endpunkte geben eine Liste von Repositorys zurück, für die Advanced Security aktiviert ist. Weitere Informationen finden Sie unter Org - Enablement oder Project – Enablement.
  • Es gibt zwei neue Endpunkte, um eine Schätzung Ihrer aktiven Committeranzahl für eine Organisation oder ein Projekt abzurufen, um zu berücksichtigen, was Ihre geschätzte Advanced Security-Meter-Nutzung kosten kann. Weitere Informationen finden Sie unter Schätzwert für die Nutzung von Organigrammen oder Project Meter Usage Estimate.

Erweiterte Sicherheitsberechtigungen werden jetzt dauerhaft angezeigt.

In der Vergangenheit wären die drei Advanced Security-Berechtigungsbits nur als zuweisungsfähige Berechtigungen pro Repository vorhanden, wenn Advanced Security aktiviert wurde. Diese Berechtigungen sind jetzt standardmäßig im Bereich "Repository-Sicherheitsberechtigungen>" verfügbar und können zugewiesen werden, ohne dass Advanced Security aktiviert werden muss.

Screenshot der Erweiterten Sicherheitsberechtigungen.

Azure Boards

Sie haben zwei Optionen, um Ihre Arbeitsaufgabe mit einer GitHub-Pullanforderung oder einem Commit zu verbinden. Sie können entweder die AB#-Syntax in der Pullanforderung verwenden oder sie direkt über die Arbeitsaufgabe verknüpfen. Heute umfasst der Prozess das Kopieren der URL der GitHub-Pullanforderung und das Einfügen der URL beim Hinzufügen eines Links. Dazu müssen mehrere Fenster geöffnet und zwischen GitHub und Azure DevOps gewechselt werden.

In diesem Sprint freuen wir uns, eine verbesserte Benutzererfahrung anzukündigen, indem wir Suchfunktionen beim Verknüpfen mit einer GitHub-Pullanforderung oder einem Commit aktivieren. Suchen Sie das gewünschte Repository, und führen Sie einen Drilldown aus, um die spezifische Pullanforderung oder den Commit zu finden und zu verknüpfen. Es ist nicht mehr erforderlich, dass mehrere Fensteränderungen vorgenommen und kopiert/eingefügt werden (obwohl Sie diese Option noch haben).

Gif zum Hinzufügen eines Links zu Demo.

Hinweis

Dieses Feature ist nur in der Vorschau des Neuen Boards-Hubs verfügbar.

Wenn Sie sich für den Zugriff auf dieses Feature interessieren, senden Sie uns eine E-Mail direkt zusammen mit Ihrem Organisationsnamen (dev.azure.com/{Organisationsname}).

Neue Boards Hub-Verbesserungen

Mit dieser Version haben wir eine Reihe von Verbesserungen an der New Boards Hub Preview eingeführt, die sich auf Barrierefreiheit und Seitenumbruch konzentriert.

Hier sehen Sie ein Beispiel für die Seitenumbruchänderungen, die bis zu 400 % zoomfähig sind.

Gif zum Demo neuer Boards Hub-Verbesserungen.

Darüber hinaus haben wir Leistungsverbesserungen auf den Seiten für Arbeitsaufgaben, Boards und Backlogs eingeführt. Mit diesen Änderungen können Sie erwarten, dass Neue Boards den Leistungsstandards entsprechen, die mit Old Boards festgelegt sind.

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.

Screenshots der DevOps-Dienste.

Wenn Sie zur Arbeitsaufgabe wechseln, werden die entsprechenden Entwicklungs- und Bereitstellungssteuerelemente im Formular ausgeblendet.

Screenshots verwandter Arbeiten.

Wenn Sie sich entscheiden, ein GitHub-Repository mit Azure Boards zu verbinden, wird das Entwicklungssteuerelement für GitHub-Repositorys angezeigt.

Screenshots des Entwicklungssteuerelements .

Azure Pipelines

Workload-Identitätsverbund für Azure Resource Manager-Dienstverbindungen ist jetzt allgemein verfügbar

Im September haben wir die Möglichkeit angekündigt , Azure-Dienstverbindungen zu konfigurieren, ohne einen geheimen Schlüssel zu verwenden. Seitdem haben viele Kunden dieses Feature übernommen, und wir freuen uns, diese Funktion bekanntzugeben, ist jetzt allgemein verfügbar.

Wenn Sie den Workload-Identitätsverbund noch nicht verwenden, können Sie die vorteile von beunruhigenden Azure-Dienstverbindungen nutzen, die auf folgende Weise keine ablaufenden Geheimschlüssel haben:

Um eine neue Azure-Dienstverbindung mithilfe des Workload-Identitätsverbunds zu erstellen, wählen Sie den Workload-Identitätsverbund (automatisch) in der Azure-Dienstverbindungserstellung aus:

Screenshot des Workload-Identitätsverbunds (automatisch).

Um eine zuvor erstellte Azure-Dienstverbindung zu konvertieren, wählen Sie die Aktion "Konvertieren" aus, nachdem Sie die Verbindung ausgewählt haben:

Screenshot der Aktion

Um mehrere Dienstverbindungen zu konvertieren, können Sie z. B. das folgende PowerShell-Skript verwenden:

#!/usr/bin/env pwsh
<# 
.SYNOPSIS 
    Convert multiple Azure Resource Manager service connection(s) to use Workload identity federation

.LINK
    https://aka.ms/azdo-rm-workload-identity-conversion

.EXAMPLE
    ./convert_azurerm_service_connection_to_oidc_simple.ps1 -Project <project> -OrganizationUrl https://dev.azure.com/<organization>
#> 
#Requires -Version 7.3

param ( 
    [parameter(Mandatory=$true,HelpMessage="Name of the Azure DevOps Project")]
    [string]
    [ValidateNotNullOrEmpty()]
    $Project,

    [parameter(Mandatory=$true,HelpMessage="Url of the Azure DevOps Organization")]
    [uri]
    [ValidateNotNullOrEmpty()]
    $OrganizationUrl
) 
$apiVersion = "7.1"
$PSNativeCommandArgumentPassing = "Standard" 

#-----------------------------------------------------------
# Log in to Azure
$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

#-----------------------------------------------------------
# Retrieve the service connection
$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=${apiVersion}"
az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug
if (!$serviceEndpoints -or ($serviceEndpoints.count-eq 0)) {
    Write-Warning "No convertible service connections found"
    exit 1
}

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prompt user to confirm conversion
    $choices = @(
        [System.Management.Automation.Host.ChoiceDescription]::new("&Convert", "Converting service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Skip", "Skipping service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Exit", "Exit script")
    )
    $prompt = $serviceEndpoint.isShared ? "Convert shared service connection '$($serviceEndpoint.name)'?" : "Convert service connection '$($serviceEndpoint.name)'?"
    $decision = $Host.UI.PromptForChoice([string]::Empty, $prompt, $choices, $serviceEndpoint.isShared ? 1 : 0)

    if ($decision -eq 0) {

        Write-Host "$($choices[$decision].HelpMessage)"
    } elseif ($decision -eq 1) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        continue 
    } elseif ($decision -ge 2) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        exit 
    }

    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    
    $updatedServiceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    if (!$updatedServiceEndpoint) {
        Write-Debug "Empty response"
        Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
        exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

Weitere Informationen finden Sie in unserer Dokumentation.

Der Pipelines-Agent zeigt Probleme mit der Ressourcenauslastung deutlicher an

Im vergangenen Oktober haben wir die Möglichkeit hinzugefügt, die Speicher- und Speicherplatznutzung durch den Pipelines-Agent nachzuverfolgen.

Um Kunden darauf aufmerksam zu machen, haben sie möglicherweise Ressourceneinschränkungen wie Arbeitsspeicher- oder Festplattenspeicherbeschränkungen für ihren Agent, wir haben Ressourceneinschränkungen besser sichtbar gemacht:

Screenshot der Warnung zu eingeschränktem Arbeitsspeicher und Speicherplatz.

Wenn eine der oben genannten Meldungen angezeigt wird, kann dies durch eine Aufgabe verursacht werden, die mehr Ressourcen verwendet, als der Agent dimensioniert ist und dazu führen kann, dass der Agent nicht reaktionsfähig ist und ein Pipelineauftrag fehlschlägt:

"Wir hörten nicht mehr vom Agenten ab"

Aktivieren Sie in solchen Fällen ausführlicheRe Protokolle , um detailliertere Ressourcenauslastungsmeldungen zu erhalten und nachzuverfolgen, wo Ihr Agent nicht mehr ressourcenfähig war. Wenn Sie einen selbst gehosteten Agent verwenden, stellen Sie sicher, dass Ihr Agent über ausreichende Ressourcen verfügt.

Out-of-Band-Installation des Node 6-Aufgabenläufers

Azure Pipelines bietet zwei Versionen von Agentpaketen:

  • vsts-agent-* Pakete unterstützen Aufgaben mithilfe von Node 6 zum Ausführen.
  • Pipelines-agent-* -Pakete unterstützen keine Aufgaben, für die Node 6 ausgeführt werden muss.

Kunden, die selbst gehostete Agents erstellen, können diese von der Seite "Pipeline-Agent-Versionen" herunterladen. Die im Agent enthaltenen Node-Versionen werden zum Ausführen von Aufgaben verwendet. Siehe Knotenausführungsversionen.

Nach der Agent-Registrierung laden Agents, die von Pipelines-agent-* -Paketen installiert wurden, jetzt Knotenversionen herunter, die nicht im Agent enthalten sind und in den Organisationseinstellungen nicht unter "Aufgabeneinschränkungen" blockiert sind. Auf diese Weise können Kunden Pipelines-agent-*-Agentpakete verwenden und die Installation von Node 6 mit "Aufgabeneinschränkungen" in Den Organisationseinstellungen steuern.

Verzögerte Genehmigung

Genehmigungen können verwendet werden, um sich bei einer Bereitstellung abzumelden. Es gibt jedoch Situationen, in denen der Zeitpunkt, zu dem die Genehmigung erteilt wird, und der Zeitpunkt, zu dem die Bereitstellung gestartet werden sollte, nicht übereinstimmen. Für die bestimmte Bereitstellung, die Sie überprüfen, wissen Sie beispielsweise, dass es sich um eine gebundene Bereitstellung handelt. Stellen Sie sich vor, sie kann nicht sofort fortgesetzt werden, sondern sollte während der Nacht stattfinden.

Um solche Szenarien abzudecken, haben wir die Option zum Zurückstellen von Genehmigungen für YAML-Pipelines hinzugefügt. Jetzt können Sie eine Pipelineausführung genehmigen und angeben, wann die Genehmigung wirksam sein soll.

Screenshot der Genehmigung einer Pipelineausführung.

Wenn Sie "Genehmigung zurückstellen" auswählen, können Sie den Zeitpunkt konfigurieren, zu dem die Genehmigung wirksam wird.

Screenshot der Zurückstellungsgenehmigung.

Screenshot der after_approval_deferred.

Die Genehmigung wird im Kontrollbereich als verzögert angezeigt. Nach ablauf der Zurückstellung ist die Genehmigung wirksam.

Screenshot der Genehmigung ist wirksam.

Sequenzierungsgenehmigungen und -prüfungen

Mit diesem Sprint können Sie die Reihenfolge angeben, in der Genehmigungen und Prüfungen ausgeführt werden.

Genehmigungen und Überprüfungen ermöglichen es Ihnen, Bereitstellungen in der Produktion zu steuern. Sie können z. B. angeben, dass nur Pipelines, die auf der main Verzweigung eines Repositorys ausgeführt werden, eine ARM-Produktionsdienstverbindung verwenden dürfen. Darüber hinaus können Sie eine menschliche Genehmigung anfordern und dass das System eine Leistungsüberprüfung bestanden hat.

Bis heute laufen alle Genehmigungen und Prüfungen parallel, mit Ausnahme der exklusiven Sperre. Dies bedeutete, dass Sie dies in Azure Pipelines nicht erzwingen konnten, wenn Ihr Bereitstellungsprozess Leistungsprüfungen vor der manuellen Genehmigung bestanden hat. Sie mussten sich auf Genehmigungsanweisungen und interne Prozessdokumentation verlassen.

Mit diesem Sprint führen wir die Sequenzierung in Genehmigungen und Prüfungen ein. Es gibt jetzt fünf Kategorien von Genehmigungen und Prüfungen:

  1. Statische Prüfungen: Branch-Kontrolle, Erforderliche Vorlage und Artefakt auswerten
  2. Genehmigung vor dynamischer Überprüfungen
  3. Dynamische Prüfungen: Genehmigen, Azure Function aufrufen, REST-API aufrufen, Geschäftszeiten, Azure Monitor-Warnhinweise abfragen
  4. Genehmigung nach dynamischen Überprüfungen
  5. Exklusive Sperre

Screenshot der Überprüfung zum Hinzufügen.

Die Reihenfolge wird auch auf der Registerkarte "Genehmigungen" und "Prüfungen" angezeigt.

Screenshot der Registerkarte

Innerhalb jeder Kategorie werden die Prüfungen parallel ausgeführt. Das heißt, wenn Sie über eine Überprüfung der Azure-Funktion und eine Überprüfung der Geschäftszeiten verfügen, werden sie gleichzeitig ausgeführt.

Screenshot der Überprüfungen für die Bereitstellung.

Überprüfungskategorien werden nacheinander ausgeführt, und wenn ein Fehler auftritt, werden die restlichen Prüfungen nicht ausgeführt. Dies bedeutet, dass, wenn Sie über eine Verzweigungssteuerung und eine Genehmigung verfügen, wenn das Branch-Steuerelement fehlschlägt, auch die Genehmigung fehlschlägt. Daher werden keine überflüssigen E-Mails gesendet.

Screenshot der Überprüfungen für die Bereitstellung schlägt fehl.

Sie können sich bei einer Bereitstellung abmelden, nachdem alle dynamischen Prüfungen ausgeführt wurden, eine Genehmigung nach dynamischen Überprüfungen verwenden oder eine manuelle Überprüfung durchführen, bevor Sie mit dynamischen Überprüfungen fortfahren, indem Sie eine vorab dynamische Überprüfungsgenehmigung verwenden.

Standardmäßiges Überprüfen und Speichern beim Bearbeiten von YAML-Pipelines

Eine falsche YAML-Pipeline kann zu verschwendeter Zeit und Aufwand führen. Um ihre Produktivität bei der Pipelinebearbeitung zu verbessern, ändern wir die Schaltfläche "Speichern " im Editor so, dass auch die YAML-Überprüfung ausgeführt wird.

Screenshot der schaltfläche

Screenshot der Überprüfung und Speicherung.

Wenn Ihre Pipeline Fehler aufweist, können Sie sie trotzdem speichern.

Screenshot der Pipeline ist gültig.

Screenshot der erkannten Fehler.

Außerdem wurde die Überprüfungsfunktion verbessert, sodass Sie die Fehler in einer Liste sehen können, die einfacher zu verstehen ist.

Screenshot der Fehlerliste.

Azure Repos

Verhinderung nicht autorisierter Benutzer zum Konfigurieren der Pipeline als Buildrichtlinie

Verhinderung nicht autorisierter Benutzer zum Konfigurieren der Pipeline als Buildrichtlinie

Wenn Sie zuvor eine neue Buildrichtlinie hinzugefügt haben, können Sie konfigurieren, dass eine beliebige Pipeline aus der Dropdownliste ausgeführt wird (einschließlich der Pipelines, für die Sie keine Warteschlangenbuildberechtigung hatten). Ebenso können Sie die vorhandene Buildrichtlinie bearbeiten, auch wenn dies für die Ausführung der Pipeline konfiguriert wurde, für die Sie keine Warteschlangenbuildberechtigungen hatten.

Jetzt verhindern wir, dass Benutzer dies tun. Wenn ein Benutzer die Berechtigung " Warteschlangenbuilds " für die angegebene Pipeline verweigert wird, wird diese Pipeline beim Hinzufügen einer neuen Buildrichtlinie in der Dropdownliste als deaktiviert (abgeblendet) angezeigt.

Sehen Sie sich die folgende Abbildung an, in der die Pipeline mit dem Namen "Sandbox" mit der Berechtigung "Warteschlangenbuilds verweigert" angezeigt wird.

Screenshot der Berechtigungen für Sandkasten.

Sehen Sie sich die folgende Abbildung an, in der die Pipeline mit dem Namen "Sandbox" deaktiviert (abgeblendt) in der Dropdownliste angezeigt wird, wenn Der Benutzer mit der Berechtigung "Abgelehnte Warteschlangenbuilds " versucht, eine neue Buildrichtlinie hinzuzufügen.

Screenshot des Hinzufügens einer Buildrichtlinie.

Wenn die Für die Ausführung der Pipeline mit dem Namen "Sandbox" konfigurierte Buildrichtlinie bereits vorhanden ist, kann der Benutzer ohne Warteschlangenbuildberechtigung die Buildrichtlinie nicht bearbeiten oder anzeigen. Dieser Fall wird in der folgenden Abbildung angezeigt.

Screenshot der Buildüberprüfung.

Wenn Sie versuchen, diese Richtlinie zu löschen, wird das Popupdialogfeld mit der Aufforderung zur Löschbestätigung angezeigt.

Screenshot der Bestätigung des Löschvorgangs.

Diese Änderungen gelten auch für alle API-Aufrufe, die entweder zum Erstellen oder Bearbeiten der Buildrichtlinie führen. Wenn eine dieser Aktionen mit einer Benutzeridentität ohne Berechtigung "Warteschlangenbuilds " ausgeführt wird, schlägt der Aufruf fehl, der den entsprechenden Fehlercode zurückgibt, und die Fehlermeldung besagt, “TFS.WebApi.Exception: TF401027: dass Sie die QueueBuild-Berechtigung für diese Pipeline benötigen, um diese Aktion auszuführen."

Das Löschen einer Buildrichtlinie, die über die API mit einer user identity Berechtigung ohne Warteschlangenbuilds durchgeführt wird, ist erfolgreich, und es wird keine Warnung oder Verhinderung ausgeführt (keine Änderungen bei der Funktionsweise des Löschvorgangs über DIE API).

Azure Artifacts

Unterstützung für Rostkrates ist allgemein verfügbar

Ab dem 16. Februar 2024 wird die Rust Crates-Unterstützung zu einem allgemein verfügbaren Feature für Azure Artifacts. Abrechnungszähler werden aktiviert, wobei das gleiche Preismodell verwendet wird, das für die anderen unterstützten Protokolle gilt.

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.

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.

Navigieren Sie zu Azure DevOps.

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.

Einen Vorschlag unterbreiten

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Vielen Dank,

Dan Hellem