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

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

• Advanced Security Meter Usage API gibt jetzt Benutzeridentitäten zurück.
• GitHub Advanced Security-Codeüberprüfung für C#- und Java-Projekte ohne Builds

Azure-Pipelines

• Verwaltete DevOps-Pools (Vorschau)
• Azure Pipelines-Aufgaben verwenden Node 20
• Build-Pipeline-Berechtigung erstellen
• Exklusive Sperrüberprüfung auf Stufenebene
• Vorlageninformationen in Pipelineausführungen
• Manuell ausgelöste YAML-Pipelinephasen

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-Kennung und Identitätsbeschreibung. Dieses Feature ist auf Organisations-, Projekt- und Repositoryebene verfügbar. Um diesen neuen Endpunkt zu verwenden, ist die Syntax ähnlich wie bei den vorhandenen Endpunkten der Meterverwendungs-API: /details wird an den Endpunkt angefügt.

• 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 die unterstützten kompilierten Sprachen C# oder Java ausgewählt wird, 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 mit Buildmodus auf "none" (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).

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.
• Für die Verwaltung aufgewendete Zeit: MDP reduziert die zeitaufwendige Verwaltung von Agents, insbesondere diejenigen, die auf lokaler 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-Abrechnung: MDP hilft beim Optimieren 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 Agents in einem einzigen Pool.

Teams können Pools mit Schnellstart-Images erstellen, die dieselbe Software enthalten, die in von Microsoft gehosteten Agents vorhanden ist. Oder sie können eigene Images mit speziellen Voraussetzungen erstellen, die einzigartig für ihr Szenario 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 Ausführungsumgebung. Azure-Pipeline-Aufgaben, die NodeJS als Runner verwenden, nutzen jetzt alle 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.

Zuvor war die Edit build pipeline Berechtigung zum Erstellen oder Bearbeiten einer Pipeline erforderlich. Dies stellte ein Sicherheitsrisiko dar, da es allen Benutzern mit der Fähigkeit, Pipelines zu erstellen, auch ermöglichte, Pipelines zu bearbeiten, die sie nicht erstellt haben. Das Verhindern 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.

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

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 zu jedem Zeitpunkt nur ein einzelner Pipeline-Lauf Zugriff auf eine Stufe haben 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 Sperrprüfung in dieser Umgebung. Dieser Ansatz kann zeitaufwendig sein, Komplexität hinzufügen und wartungsintensive Anstrengungen erhöhen.

In diesem Sprint wird die Unterstützung für die Festlegung der exklusiven Sperre auf Stufenebene 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 Stufenebene 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 Runs - Get REST-API mit Informationen über die in einer Pipelineausführung erweiterten und enthaltenen Vorlagen aktualisiert.

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 integrierte Pipeline möchten, die nicht immer bis zum Ende ausgeführt werden muss.

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 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, sieht das Erlebnis folgendermaßen aus:

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

Nächste Schritte

Gehen Sie zu Azure DevOps und schauen Sie sich an.

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.

Danke

Silviu Andrica