Freigeben über


Verbesserte Sicherheits- und Pipelineworkflows

Mit diesem Sprint verbessern wir Ihren DevOps-Workflow mit einer größeren Sicherheitssichtbarkeit und optimierten Pipelineworkflows. GitHub Advanced Security enthält jetzt eine detaillierte Nachverfolgung der Aktivierung von Abhängigkeitsscans, Code-Scans und Geheimnis-Scans, die tiefere Insights in die Sicherheitsabdeckung Ihrer Organisation bieten.

Darüber hinaus freuen wir uns, pipelineorientierte Verbesserungen einzuführen, einschließlich neuer YAML-Ausdrucksfunktionen und erweiterter Steuerelemente für manuelle Überprüfungsaufgaben, sodass Sie effizientere und sicherere Workflows erstellen können.

Weitere Informationen finden Sie in den Versionshinweisen.

GitHub Advanced Security für Azure DevOps

Azure Boards:

Azure Repos

Azure-Pipelines

Testpläne

GitHub Advanced Security für Azure DevOps

Toolspezifische Sicherheitsübersichtsberichterstattung

Die Sicherheitsübersicht in GitHub Advanced Security for Azure DevOps bietet jetzt eine detaillierte Aufschlüsselung des Aktivierungsstatus für jedes Scan-Tool, einschließlich Abhängigkeitsüberprüfung, Codelesung, und geheime Abtastung. Diese Erweiterung ermöglicht es Ihnen, detaillierte Aktivierungsstatus für alle Repositories in Ihrer Organisation anzuzeigen.

Screenshot der Sicherheitsübersicht.

Weitere Informationen finden Sie unter Sicherheitsübersicht für Erweiterte Sicherheit.

Azure Boards

Azure Boards-Integration mit GitHub Enterprise Cloud mit Data Residency (Vorschau)

Anmerkung

Dieses Feature befindet sich derzeit in der Vorschau. Bitte schreiben Sie uns, wenn Sie die Integration von Boards in die GitHub Enterprise Cloud mit Data Residency ausprobieren möchten.

Azure Boards unterstützt jetzt die Integration mit GitHub Enterprise Cloud-Organisationen, die über aktivierte Datenresidenz verfügen. Dieses Update steht im Einklang mit GitHubs Ankündigung vom September 2024, die Datenresidenz für Enterprise Cloud-Kunden einzuführen, beginnend mit denen in der Europäischen Union (EU).

So verbinden Sie ein Azure Boards-Projekt mit Ihrer GitHub Enterprise Cloud-Organisation mit Data Residency:

  1. Erstellen Sie eine neue Verbindung in Azure Boards.

Screenshot von GitHub mit Boards verbinden.

  1. Wählen Sie die Option GitHub Enterprise Cloud mit der Datenresidenz-Option aus.

Screenshot der neuen GitHub-Verbindung.

Azure Repos

Sparse-Check-Out für Azure Repos

Der befehl git sparse-checkout wird jetzt in der YAML-Auscheckaufgabe unterstützt, zusammen mit dem teilweisen Klonfilter, um die Leistung des Repository-Auscheckens zu verbessern. Sie können die Eigenschaften sparseCheckoutDirectories und sparseCheckoutPatternsverwenden.

Das Festlegen sparseCheckoutDirectories aktiviert den Kegelmodus, bei dem der Auscheckvorgang Verzeichnisabgleich verwendet. Alternativ können Sie sparseCheckoutPatterns festlegen, das den Nicht-Cone-Modus auslöst und damit die Möglichkeit bietet, komplexere Mustervergleiche durchzuführen.

Wenn beide Eigenschaften festgelegt sind, initialisiert der Agent den Kegelmodus mit Verzeichnisabgleich. Wenn keine der beiden Eigenschaften in der Checkout-Aufgabe angegeben ist, ist der Sparse-Checkout-Prozess deaktiviert. Alle Während der Befehlsausführung aufgetretenen Probleme führen dazu, dass die Auscheckaufgabe fehlschlägt.

YAML-Beispiel für Sparse Checkout im Cone-Modus:

    checkout: repo
    sparseCheckoutDirectories: src

YAML-Beispiel für Sparse-Checkout Non-Cone-Modus:


   checkout: repo
   sparseCheckoutPatterns: /* !/img 

Wichtig

Die Funktion Sparse-Checkout erfordert Agent v3.248.0 (v4.248.0 für .NET 8) oder höhere Versionen.

Sie finden den Agent auf der Seite Releases.

Groß- und Kleinschreibung bei Repos-übergreifenden Richtlinien beachten

Zuvor wurden in der Vorschau für Branch-Kandidaten für Repository-übergreifende Richtlinien die Ergebnisse ohne Berücksichtigung der Groß-/Kleinschreibung angezeigt, obwohl beim Branch-Abgleich die Groß-/Kleinschreibung berücksichtigt wurde. Diese Inkonsistenz erzeugte eine potenzielle Fehlanpassung, da es den Anschein haben konnte, dass bestimmte Branches geschützt waren, obwohl sie es nicht waren. Um dieses Problem zu beheben, haben wir die Vorschau der Branch-Muster aktualisiert, um sie an das vertrauliche Verhalten der Richtlinienanwendung anzupassen.

Zuvor:

Screenshot vor der Korrektur

Danach:

Screenshot nach der Korrektur.

Azure-Pipelines

Neue Ausdrucksfunktionen in der Pipeline

Mithilfe von Pipelineausdrucksfunktionen können Sie leistungsstarke YAML-Pipelines schreiben. In diesem Sprint haben wir zwei neue Funktionen eingeführt:

  • iif(condition, value_when_true, value_when_false), die value_when_true zurückgibt, wenn condition zu true oder value_when_false ausgewertet wird, ansonsten

  • trim(string), die eine neue Zeichenfolge zurückgibt, in der Leerzeichen am Anfang und Ende der Zeichenfolge entfernt werden

Mit der iif-Funktion können Sie zum Beispiel dynamisch einen Pool zum Ausführen Ihrer Pipeline auswählen. Wenn Sie Pullanforderungen mithilfe des Azure-Pipelines-Pools erstellen möchten, aber alle anderen Läufe einen verwalteten DevOps-Pool verwenden sollten, können Sie die folgende Pipeline schreiben.

variables:
  poolToUse: ${{ iif(eq(variables['Build.Reason'], 'PullRequest'), 'Azure Pipelines', 'ManagedDevOpsPool')}}

stages:
- stage: build
  pool: ${{variables.poolToUse}}
  jobs:
  - job:
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'

Sie können die trim-Funktion verwenden, um Ihr YAML robuster gegenüber Benutzereingaben zu machen. In der folgenden Pipeline verwenden wir beispielsweise die trim-Funktion, um sicherzustellen, dass der Stufenname nicht mit Leerzeichen beginnt.

parameters:
- name: regions
  type: string
  default: '  wus1,   wus2, wus3,wus4'

stages:
- ${{ each region in split(parameters.regions, ',')}}:
  - stage: stage_${{trim(region)}}
    displayName: Deploy to ${{trim(region)}}
    jobs:
    - job: deploy
      steps:
      - script: ./deploy.sh ${{trim(region)}}

Erweiterungen der Aufgabe ManualValidation

Die Aufgabe ManuelleValidierung ermöglicht es Ihnen, das Ausführen einer Pipeline anzuhalten und auf einen manuellen Eingriff zu warten. Ein Szenario für die Verwendung dieser Aufgabe ist manuelle Tests.

Um die Sicherheit Ihrer Pipeline zu erhöhen, möchten Sie möglicherweise einschränken, wer die Aufgabe abschließen und die Pipelineausführung fortsetzen kann. Zu diesem Zweck führen wir eine neue Version der Aufgabe ein, die zwei zusätzliche Parameter bereitstellt:

  • approvers: Einschränken, wer die Aufgabe auf einen vordefinierten Satz von Benutzern/ Sicherheitsgruppen /Teams ausführen kann

  • allowApproversToApproveTheirOwnRuns: den Benutzer, der die Pipeline-Ausführung in die Warteschlange gestellt hat, daran hindern, sie wieder aufzunehmen

Der folgende YAML-Codeausschnitt schränkt beispielsweise die Gruppe von Personen ein, die den Pipeline-Lauf fortsetzen können, auf Mitglieder der Gruppe "Release-Genehmiger", jedoch nicht auf den Benutzer, der den Pipeline-Lauf ausgelöst hat.

- task: ManualValidation@1
  inputs:
    notifyUsers: 'Release Approvers'
    approvers: 'Release Approvers'
    allowApproversToApproveTheirOwnRuns: false

In der approvers-Eigenschaft können Sie die folgenden Werte (komma-getrennt) verwenden.

  • E-Mail-Adresse
  • Permission-Group,
  • Projektteam,
  • [ProjectName][Berechtigungsgruppe],
  • [Org][Permission Group],
  • [ProjectName][Projektteam]

Testpläne

Fehlerbehebungen für Azure-Testpläne

Mit diesem Sprint haben wir Updates für Azure Testpläne vorgenommen, um mehrere Fehler zu beheben und die Benutzerfreundlichkeit zu verbessern. Hier sehen Sie, was behoben wurde:

  • Gemeinsame Schritt-Ergebnisse sind sichtbar: Es wurde ein Fehler behoben, bei dem gemeinsame Schritt-Ergebnisse nicht im Abfrage-Editor angezeigt wurden, wenn Sie auf Testfälle im New Boards Hub zugriffen.

  • Verbesserte Sitzungen im Stakeholdermodus: Ein Problem in der Test- und Feedbackerweiterung wurde behoben, durch das Benutzer mit Dembeteiligtenzugriff am Start von Sitzungen gehindert wurden.

  • Saubereres Kopieren von Testplänen: Es wurde ein Problem behoben, bei dem Anforderungen dupliziert wurden, wenn ein Testplan mit der Option „Vorhandene Testfälle referenzieren“ kopiert wurde.

Nächste Schritte

Anmerkung

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

Bereitstellen von 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.

Vorschlag

Sie können auch in der Community auf Stack OverflowRatschläge erhalten und Ihre Fragen beantworten lassen.

Danke

Silviu Andrica