Unterstützung für benutzerdefinierte Agenten von GitHub Copilot in Azure Boards

Azure Boards kann jetzt benutzerdefinierte GitHub Copilot Agents auswählen, wenn eine Pull-Request aus einer Arbeitsaufgabe erstellt wird. Benutzerdefinierte Agents, die auf Repository- oder Organisationsebene in GitHub erstellt werden, erscheinen automatisch in Azure DevOps. Ihr ausgewählter Agent generiert die Codeänderungen und erstellt die Pullanforderung im ausgewählten Repository.

Weitere Informationen finden Sie in den Versionshinweisen.

GitHub Advanced Security for Azure DevOps

• Berechtigungsdurchsetzung in der Sicherheitsübersicht
• Build-Identitätszugriff für erweiterte Sicherheits-APIs eingeschränkt (vorübergehend zurückgesetzt)
• Erkennung veralteter Scans in der Sicherheitsübersicht

Azure Boards

• Azure Boards Integration mit GitHub Copilot unterstützt jetzt benutzerdefinierte Agents
• Erhöhte maximale Begrenzung für verbundene GitHub-Repositories

Azure Repos

• Verbesserte Git-Richtlinienkonfigurations-API

Azure Pipelines

• Verbessertes Debuggen der Pipelineausführung

GitHub Advanced Security for Azure DevOps

Berechtigungsdurchsetzung in der Sicherheitsübersicht

Die Sicherheitsübersicht erzwingt jetzt die Berechtigung \"Erweiterte Sicherheit: Warnungen lesen\" in allen Ansichten (Risiko und Abdeckung). Repositories, bei denen dem aktuellen Benutzer diese Berechtigung fehlt, werden in den Ergebnissen der Sicherheitsübersicht nicht mehr angezeigt. Diese Änderung stellt sicher, dass die Sicherheitsübersicht die gleichen Zugriffssteuerelemente respektiert wie die Warnungen auf Repositoryebene, wodurch nicht autorisierte Sichtbarkeit verhindert wird, in welchen Repositorys aktive Funde vorliegen.

Build-Identitätszugriff für Advanced Security APIs beschränkt (vorübergehend rückgängig gemacht)

Diese Änderung wurde vorübergehend zurückgesetzt. Weitere Informationen finden Sie unter Erstellen Sie den Zugriff auf Identitäten eingeschränkt für Advanced Security-APIs-Rücknahme.

Advanced Security REST-APIs akzeptieren keine Builddienstidentitäten mehr (wie z. B. Project Collection Build Service) als Aufrufer. Diese Änderung verhindert, dass die pipelinebasierte Automatisierung mithilfe von Build-Service-Konten auf Sicherheitswarnungsdaten zugreift oder diese ändert, wodurch das Risiko unbeabsichtigter Änderungen des Warnungszustands während der CI/CD-Ausführung reduziert wird. Wenn Sie über Automatisierung verfügen, die mit Advanced Security-APIs mit einer Buildidentität interagiert, aktualisieren Sie diese Workflows so, dass ein benannter Benutzer oder Dienstprinzipal mit den entsprechenden Erweiterten Sicherheitsberechtigungen verwendet wird.

Erkennung veralteter Scans in der Sicherheitsübersicht

Der Bereich "Sicherheitsübersicht" identifiziert jetzt Tools mit Scans, die älter als 90 Tage sind. Tools, die in über 90 Tagen keine Ergebnisse erzeugt haben, zeigen einen veralteten Indikator an, sodass Sicherheitsteams schnell Repositorys erkennen können, in denen die Überprüfung möglicherweise nicht mehr ausgeführt wurde oder wo Pipelinekonfigurationen Aufmerksamkeit benötigen. Diese Sichtbarkeit erleichtert es Ihnen, eine umfassende Scanabdeckung in Ihrer Organisation aufrechtzuerhalten und Konfigurationsabweichungen abzufangen, bevor blinde Flecken entstehen.

Azure Boards

Azure Boards Integration in GitHub Copilot unterstützt jetzt benutzerdefinierte Agents

Die Azure Boards Integration mit GitHub Copilot unterstützt jetzt die Auswahl von benutzerdefinierten Agents. Wenn Sie noch nicht mit benutzerdefinierten Agents vertraut sind, erfahren Sie mehr über sie in der Dokumentation zum Erstellen von benutzerdefinierten Agents.

Nachdem Sie einen benutzerdefinierten Agent auf Repository- oder Organisationsebene erstellt haben, ist er automatisch in Azure DevOps verfügbar. Wenn Sie einen Pull Request aus einem Arbeitselement erstellen, wird neben der Repository-Liste ein neues Agent-Auswahl-Steuerelement angezeigt.

Nachdem Sie einen benutzerdefinierten Agent ausgewählt und auf " Erstellen" geklickt haben, wird dieser Agent verwendet, um die Codeänderungen zu generieren und die Pullanforderung im ausgewählten Repository zu erstellen.

Erhöhte Maximale Grenze für verbundene GitHub Repositorys

Wir haben den Grenzwert pro Verbindung beim Verknüpfen GitHub Repositorys mit einem Azure DevOps Projekt erhöht. Der neue Höchstwert in der Weboberfläche beträgt jetzt 2.000, was dem grenzwert entspricht, der bereits über die Update-REST-API verfügbar ist.

Azure Repos

Verbesserte Git-Richtlinienkonfigurations-API

Wir haben die Richtlinienkonfigurations-APIs verbessert, damit es einfacher und effizienter ist, alle Richtlinien abzurufen, die für ein bestimmtes Repository gelten. Sie können jetzt auf Repository-Ebene definierte Richtlinien abfragen sowie Richtlinien, die auf alle Verzweigungen oder Refs innerhalb dieses Repositorys angewendet werden, ohne das gesamte Projekt scannen zu müssen. Diese Verbesserung reduziert unnötige API-Aufrufe und verbessert die Leistung für Dienste, die Richtlinien im großen Maßstab verwalten. Vorhandenes Richtlinienverhalten bleibt unverändert.

Policy-Konfigurationen – Get - REST API (Azure DevOps Git) | Microsoft Learn

Azure Pipelines

Verbessertes Debuggen der Pipelineausführung

In diesem Sprint verbessern wir Ihre Fähigkeit, Pipelineläufe zu debuggen.

Es kann vorkommen, dass Sie die Ausführung abbrechen müssen, aber der Auftrag oder die Phase wird weiterhin ausgeführt, und Sie sind verwirrt. Wir haben Warnmeldungen hinzugefügt, um Sie darüber zu informieren, wann und warum dies der Fall ist.

Stellen Sie sich vor, Sie haben folgendes YAML:

stages:
- stage: WUS1
  jobs:
  - job: DeployWUS1
    condition: eq(variables['Build.SourceBranchName'], 'main')
    steps:
    - task: CmdLine@2
      inputs:
        script: echo "Deploying $(System.StageName)"
    - task: CmdLine@2
      inputs:
        script: sleep 60
- stage: WUS2
  condition: eq(variables['Build.SourceBranchName'], 'main')
  jobs:
  - job: DeployWUS2
    steps:
    - task: CmdLine@2
      inputs:
        script: echo "Deploying $(System.StageName)"

Stellen Sie sich nun vor, Sie brechen die Ausführung beim Ausführen des Auftrags DeployWUS1ab. Der Auftrag wird weiterhin ausgeführt, ebenso wie die Phase WUS2. Azure Pipelines teilt Ihnen mit, warum der Auftrag und die Phase weiter ausgeführt wird.

Eine weitere Verbesserung, die wir bringen, informiert Sie darüber, warum eine Phase übersprungen wird.

Stellen Sie sich vor, Sie führen dasselbe YAML aus einer anderen Verzweigung aus, z. B. release_123, und Sie wählen nur die Stage WUS2 aus. Zuvor hatten beide WUS1 und WUS2 Stufen denselben Status, Skippedaber es war nicht klar, warum jede der Stufen übersprungen wurde. Jetzt wissen Sie, ob die Phase übersprungen wurde, weil Sie sie zur Laufzeit der Warteschlange oder aufgrund ihrer Laufzeitbedingungen deaktiviert haben.

Nächste Schritte

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 Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.