Freigeben über

Verwaltete DevOps-Pools für Azure DevOps (Vorschau)

  • Artikel

Wir freuen uns, die Vorschau verwalteter DevOps-Pools bekanntzugeben, die entwickelt wurden, um Entwicklungs- und Plattformentwicklungsteams dabei zu unterstützen, benutzerdefinierte DevOps-Pools schnell einzurichten und zu verwalten.

Darüber hinaus haben wir die Bewertungs-APIs für die Meternutzung für GitHub Advanced Security verbessert und bieten neue Funktionen, mit denen Sie Benutzer identifizieren können.

Weitere Informationen finden Sie in den Versionshinweisen.

GitHub Advanced Security für Azure DevOps

Azure Pipelines

GitHub Advanced Security für Azure DevOps

Advanced Security Meter Usage API gibt jetzt Benutzeridentitäten zurück.

Um Ihre Advanced Security-Benutzer zu identifizieren, geben die ApIs für die Meternutzungsschätzung jetzt die Azure DevOps-Identität jedes Benutzers zurück, einschließlich anzeigename, CUID, E-Mail-ID und Identitätsbeschreibung. Dieses Feature ist auf Organisations-, Projekt- und Repositoryebene verfügbar. Um diesen neuen Endpunkt zu verwenden, ähnelt die Syntax den vorhandenen Endpunkten der Meterverwendungs-API, die /details an den Endpunkt angefügt wird:

  • Auf Organisationsebene: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Auf Projektebene: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Auf Repositoryebene: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

GitHub Advanced Security-Codeüberprüfung für C#- und Java-Projekte ohne Builds

Codeüberprüfung mit CodeQL umfasst das Ausführen von Abfragen für Datenbanken, die den Code in Ihrem Repository für eine einzelne Sprache darstellen. Für kompilierte Sprachen wie C/C++, C#, Go, Java und Swift erfordert dies in der Regel das Erstellen des Codes zuerst.

CodeQL, das statische Analysemodul hinter GitHub Advanced Security für Azure DevOps, kann jetzt C#- und Java-Projekte scannen, ohne einen Build zu benötigen. Wenn der Buildmodus auf "none" festgelegt ist, wird die CodeQL-Datenbank direkt aus der Codebasis generiert und der Buildschritt umgangen.

Für alle kompilierten Sprachen ist der Standardbuildmodus "manuell". Für C# und Java können Sie jedoch den Buildmodus in "none" ändern.

Sie können den Buildmodus während des Setups von AdvancedSecurity-Codeql-Init@1 konfigurieren. Ausführliche Anweisungen zum Konfigurieren der Codeüberprüfung in GitHub Advanced Security mit Azure DevOps finden Sie unter Einrichten der Codeüberprüfung

Überlegung:

  • Wenn "none" ausgewählt ist und eine andere Sprache als unterstützte erfüllte Sprachen C# oder Java ausgewählt ist, funktioniert die Pipelineaufgabe möglicherweise nicht wie erwartet.

  • Der Buildmodus "none" funktioniert derzeit in Verbindung mit anderen interpretierten Sprachen (z. B. JavaScript, Python, Ruby).

  • Gültiges Beispiel: C# und JavaScript, wobei der Buildmodus auf "none" festgelegt ist. (JavaScript in einer interpretierten Sprache)

  • Ungültiges Beispiel: C#, JavaScript und Swift, wobei der Buildmodus auf "none" festgelegt ist (Swift wird im Buildmodus "none" nicht unterstützt).

Screenshot von AdvancedSecurity-Codeql.

Azure Pipelines

Verwaltete DevOps-Pools (Vorschau)

Entwicklerteams zeichnen sich aus, wenn sie sich auf das Schreiben von Code zum Entwickeln von Anwendungen und Diensten für ihre Benutzer konzentrieren können. In der Praxis wird jedoch häufig ein erheblicher Zeitaufwand für die Verwaltung anderer Aufgaben aufgewendet, z. B. die Wartung der DevOps-Infrastruktur.

Wir freuen uns, die öffentliche Vorschau von Managed DevOps Pools (MDP) bekanntzugeben, ein neues Azure DevOps-Feature, das entwicklungs- und Plattformentwicklungsteams bei der Bereitstellung von benutzerdefinierten DevOps-Pools unterstützt, die auf ihre individuellen Anforderungen zugeschnitten sind. MDP kombiniert die Flexibilität von Scale Set-Agents mit der einfachen Wartung, die mit von Microsoft gehosteten Agents verbunden ist, sodass Teams Konsistenz und bewährte Methoden einrichten können, während sie Leistung, Sicherheit, Compliance und Kosteneffizienz optimieren.

Zu den wichtigsten Vorteilen von verwalteten DevOps-Pools gehören:

  • Gehostet in Ihrem Auftrag: MDP wird von Microsoft gehostet und verwaltet, wobei die virtuellen Computer die Agents unterstützen, die in Microsoft-eigenen Azure-Abonnements erstellt und verwaltet werden.
  • Zeitaufwand im Management: MDP reduziert die zeitaufwendige Verwaltung von Agents, insbesondere diejenigen, die auf der lokalen Infrastruktur oder manuell verwalteten Systemen basieren.
  • Bestimmte Pools: Aufgrund der Leichtigkeit, mit der neue Pools erstellt werden können, können Organisationen problemlos mehrere teamspezifische oder workloadspezifische Pools erstellen.
  • DevOps Billing: MDP hilft bei der Optimierung der DevOps-Rechnung eines Teams durch viele Features. Es erleichtert Teams, ein optimales Gleichgewicht zwischen QoS/Leistung und Kosten eines Pools zu finden.
  • Skalierbar: MDP skaliert auf 1000 Agenten in einem einzigen Pool.

Teams kann Pools mit Schnellstartimages erstellen, die dieselbe Software enthalten, die in von Microsoft gehosteten Agents vorhanden ist, oder mit Bildern, die das Team mit Voraussetzungen erstellt hat, die für ihr Szenario einzigartig sind.

Erfahren Sie mehr über verwaltete DevOps-Pools, indem Sie unseren Blogbeitrag oder ihre Dokumentation lesen.

Azure-Pipelineaufgaben verwenden Node 20

Die meisten Pipelineaufgaben verwenden Node als Läufer. Azure pipelines task that use NodeJS as a runner now use NodeJS 20. Autoren von Aufgabenerweiterungen sollten ihre Aufgaben auf die Verwendung von Node 20 aktualisieren. Anleitungen zum Upgrade finden Sie unter "Wie kann ich meine benutzerdefinierte Aufgabe auf den neuesten Knoten aktualisieren?".

Erstellen der Buildpipelineberechtigung

Um die Pipelinesicherheit zu erhöhen, führen wir auf Pipelineebene eine neue Berechtigung ein Create build pipeline.

Screenshot der Buildpipelineberechtigung erstellen.

Zuvor war die Edit build pipeline Berechtigung zum Erstellen oder Bearbeiten einer Pipeline erforderlich. Dies stellt ein Sicherheitsrisiko dar, da es allen Benutzern ermöglicht wurde, Pipelines zu erstellen, um auch Pipelines zu bearbeiten, die sie nicht erstellt haben. Dies war zeitaufwändig.

Um Ihre Pipelineerfahrung zu verbessern, ohne die Sicherheit zu beeinträchtigen, erhalten alle Benutzer und Gruppen mit der Edit build pipeline Berechtigung jetzt auch die Create build pipeline Berechtigung.

Wenn eine Pipeline erstellt wird, erhält ihr Ersteller die Edit build pipeline Berechtigung.

Um die Pipelinesicherheit zu verbessern, können Sie die Edit build pipeline Berechtigung aus Benutzergruppen wie Mitwirkenden und Lesern entfernen. Dadurch wird sichergestellt, dass standardmäßig nur der Ersteller der Pipeline sie bearbeiten kann.

Hinweis

Die Berechtigung "Buildpipeline bearbeiten" verhindert nicht, dass andere Personen eine YAML-Pipeline bearbeiten. Sie schützt nur, dass die Eigenschaften der Pipeline bearbeitet werden.

Für neue Projekte verfügen Benutzer und Gruppen mit der Edit build pipeline Berechtigung ebenfalls über die Create build pipeline Berechtigung. Dies kann sich in Zukunft ändern.

Exklusive Sperrüberprüfung auf Stufenebene

In einigen Anwendungsfällen muss eine Pipeline nur einmal auf eine bestimmte Ressource zugreifen. Um diesen Fall zu unterstützen, haben wir die exklusive Sperrüberprüfung .

Eine ähnliche Situation tritt auf, wenn jeweils nur eine Pipelineausführung auf eine Phase zugreifen sollte. Wenn Sie beispielsweise eine Phase haben, die für eine Azure-Ressourcengruppe bereitgestellt wird, sollten Sie verhindern, dass mehrere Pipelineausführungen gleichzeitig dieselbe Ressourcengruppe aktualisieren. Zurzeit erfordert dies die Verwendung einer Proxyressource, z. B. einer Umgebung, und das Platzieren der exklusiven Sperrüberprüfung in dieser Umgebung. Dieser Ansatz kann zeitaufwendig sein, Komplexität hinzufügen und wartungsintensive Anstrengungen erhöhen.

In diesem Sprint wird Unterstützung für die Angabe der exklusiven Sperre auf Stufesebene eingeführt. Wenn Sie über eine Phase mit einer ID verfügen und deren lockBehavior Eigenschaft angeben, wird automatisch eine Sperre für diese Phase erstellt. Das sequential Verhalten bleibt für Sperren auf Ressourcenebene und Stufe konsistent. Das runLatest Verhalten unterscheidet sich jedoch, da nur Builds für dieselbe Verzweigung abgebrochen runLatest werden, nicht für alle Verzweigungen der Pipeline.

Vorlageninformationen in Pipelineausführungen

Wir haben die Pipelines-Ausführung aktualisiert – REST-API mit Informationen zu den erweiterten Und in einer Pipelineausführung enthaltenen Vorlagen abrufen.

Angenommen, Sie haben den folgenden YAML-Pipelinecode:

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

Die neue REST-API verfügt über die folgenden neuen Eigenschaften:

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

Manuell ausgelöste YAML-Pipelinephasen

Häufig erhalten wir Anfragen zu manuell ausgelösten YAML-Pipelinephasen. Diese sind hilfreich, wenn Sie eine einheitliche Pipeline wünschen, sie aber nicht immer zum Abschluss ausführen möchten.

Ihre Pipeline kann z. B. Phasen für das Erstellen, Testen, Bereitstellen in einer Stagingumgebung und die Bereitstellung in der Produktion umfassen. Möglicherweise möchten Sie, dass alle Phasen automatisch ausgeführt werden, mit Ausnahme der Produktionsbereitstellung, die Sie bei Bedarf manuell auslösen möchten.

Mit diesem Sprint fügen wir Unterstützung für manuell ausgelöste YAML-Pipelinephasen hinzu. Um dieses Feature zu verwenden, müssen Sie die trigger: manual Eigenschaft zu einer Phase hinzufügen.

Betrachten Sie das folgende YAML-Pipelinebeispiel:

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

Wenn Sie diese Pipeline ausführen, lautet die Oberfläche wie folgt:

Screenshot der manuell ausgelösten YAML-Pipelinephasen.

Manuell ausgelöste Phasen weisen keine Abhängigkeiten auf und können jederzeit ausgeführt werden. Die Pipelineausführung wird abgeschlossen, wenn nur manuell ausgelöste Phasen ausgeführt werden müssen.

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,

Silviu Andrica