Freigeben über


Pipelinekonformität und Sicherheitsüberprüfungen – Sprint 141 Update

Im Sprint 141-Update von Azure DevOps Services können Sie jetzt Compliance- und Sicherheitsüberprüfungen in Ihre Azure Pipelines einschließen. In Azure Repos können Sie den Zielbranch von Pull Requests ändern.

Weitere Informationen finden Sie in der Liste features unten.

Features

Allgemeines:

Azure Pipelines:

Azure Repos:

Verwaltung:

Nächste Schritte

Hinweis

Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.

Lesen Sie unten mehr über die neuen Features, und wechseln Sie zu Azure DevOps Services, um sie selbst auszuprobieren.

Allgemein

Bereits im Juni dieses Jahres haben wir die erste Iteration unseres neuen Navigationsmodells eingeführt. Wir haben den Sommer damit verbracht, diese Erfahrung basierend auf dem Feedback, das viele von Ihnen gegeben haben, zu verbessern. Vielen Dank! Unser nächster Schritt besteht darin, vom neuen Modell als Vorschauversion zur Navigation für das Produkt zu wechseln. Lesen Sie unseren Blogbeitrag , der die jüngsten Änderungen zusammen mit unserem Zeitplan für die Einführung des neuen Modells in alle Organisationen beschreibt.

Wir verstehen die Bedeutung der Suche und führen das erweiterte Suchfeld im Produktheader zurück. Darüber hinaus können Sie das Suchfeld jetzt aufrufen, indem Sie einfach auf einer beliebigen Dienstseite in Azure DevOps auf "/" klicken. Dieses Feature wurde basierend auf einem Benutzerstimmevorschlag priorisiert.

Hier ist das Standardsuchfeld:

Standardsuchfeld

Nachdem Sie ein "/" eingegeben haben, wird das erweiterte Suchfeld angezeigt:

Erweitertes Suchfeld

Azure Pipelines

Azure Policy Compliance- und Sicherheitsüberprüfungen in Pipelines

Wir wollen die Stabilität und Sicherheit von Software frühzeitig im Entwicklungsprozess gewährleisten und gleichzeitig Entwicklung, Sicherheit und Betrieb zusammenbringen. Hierzu haben wir Unterstützung für Azure Policy hinzugefügt.

Dank Azure Policy können Sie mithilfe von Richtliniendefinitionen, die Regeln und Aktionen für Ihre Ressourcen erzwingen, IT-Probleme verwalten und verhindern. Wenn Sie Azure Policy verwenden, bleiben ressourcenkonform mit Ihren Unternehmensstandards und Vereinbarungen zum Servicelevel.

Um die Compliance- und Sicherheitsrichtlinien im Rahmen des Releaseprozesses zu erfüllen, haben wir unsere Azure-Ressourcengruppenbereitstellung verbessert. Im Falle von Verstößen bei der Bereitstellung von ARM-Vorlagen schlägt nun die Azure-Ressourcengruppe mit relevanten richtlinienbezogenen Fehlern fehl.

Azure Policy

Darüber hinaus haben wir Azure Policy Releasedefinitionsvorlage hinzugefügt. Dadurch können Benutzer Azure-Richtlinien erstellen und diese Richtlinien Ressourcen, Abonnements oder Verwaltungsgruppen aus der Releasedefinition selbst zuweisen.

Azure Policy Vorlage

Vereinfachte Continuous Delivery für azure-VMs

In diesem Release haben wir einen neuen Assistenten hinzugefügt, um das Einrichten von Continuous Delivery für Azure Virtual Machines zu vereinfachen. Nachdem Sie eine Azure DevOps-organization und eine Bereitstellungsgruppe zum Registrieren des virtuellen Computers angegeben haben, wird automatisch eine Releasepipeline mit einem Beispielskriptschritt erstellt. Wenn Sie zusätzliche Azure-Ressourcen bereitstellen, Skripts ausführen, Ihre Anwendung aktualisieren oder zusätzliche Validierungstests ausführen müssen, können Sie diese Releasepipeline problemlos anpassen.

CI zu azure-VMs

Der Xcode-Task unterstützt das neu veröffentlichte Xcode 10.

Mit dem Release von Xcode 10 von Apple können Sie jetzt festlegen, dass Ihre Projekte speziell mit Xcode 10 erstellt oder getestet werden. Ihre Pipeline kann Aufträge auch parallel mit einer Matrix von Xcode-Versionen ausführen. Sie können den von Microsoft gehosteten macOS-Agentpool verwenden, um diese Builds auszuführen. Weitere Informationen finden Sie in den Anleitungen zur Verwendung von Xcode in Azure Pipelines.

Xcode 10

Leistungsverbesserungen beim Anstehen eines Builds

Wenn Sie einen gehosteten Agent verwenden, erhalten Sie für jeden Auftrag einen neuen virtuellen Computer. Dies bietet eine zusätzliche Sicherheits- und Steuerungsebene. Sie müssen sich nie sorgen, dass ein vorheriger Build Ausgaben hinterlässt oder dem Computer etwas Schädliches anrichtet. Erste Startaktivitäten führten jedoch früher zu Verzögerungen zwischen dem Klicken auf Build warteschlange und dem Zeitpunkt, an dem die Pipeline tatsächlich ausgeführt wird. Wir haben viele dieser Verzögerungen untersucht und behoben und sehen jetzt eine 5-fache Beschleunigung in der Warteschlangen-zu-Start-Zeit in den gehosteten Pools. Sie können Ihre Builds jetzt schneller starten, was bedeutet, dass Sie schneller durchlaufen können.

Erstellen einer Azure-Dienstverbindung mit einem Dienstprinzipal, der sich mit einem Zertifikat authentifiziert

Sie können jetzt eine Azure-Dienstverbindung in Azure Pipelines oder Team Foundation Server (TFS) mit einem Dienstprinzipal und zertifikat für die Authentifizierung definieren. Da die Azure-Dienstverbindung jetzt den Dienstprinzipal unterstützt, der sich mit einem Zertifikat authentifiziert, können Sie jetzt in Azure Stack bereitstellen, die mit AD FS konfiguriert ist. Informationen zum Erstellen eines Dienstprinzipals mit Zertifikatauthentifizierung finden Sie im Artikel zum Erstellen eines Dienstprinzipals, der sich mit einem Zertifikat authentifiziert.

Verbindung über Dienstprinzipal herstellen

Anzeigen von Testanalysen in Pipelines

Die Überwachung der Testqualität im Laufe der Zeit und die Verbesserung der Testsicherheiten sind der Schlüssel zur Aufrechterhaltung einer fehlerfreien Pipeline. Die Testanalysefunktion bietet nahezu echtzeitbasierte Einblicke in Ihre Testdaten für Builds und Releasepipelines. Dies trägt dazu bei, die Effizienz Ihrer Pipeline zu verbessern, indem wiederkehrende Qualitätsprobleme mit hohen Auswirkungen erkannt werden.

Sie können Testergebnisse nach verschiedenen Elementen gruppieren, wichtige Tests für Ihre Branch- oder Testdateien identifizieren oder einen Drilldown zu einem bestimmten Test durchführen, um Trends anzuzeigen und Qualitätsprobleme wie Flakiness zu verstehen.

Sehen Sie sich Testanalysen für Builds und Release an, vorschau unten:

Analyse testen

Weitere Informationen finden Sie in unserer Dokumentation.

Azure Repos

Ändern des Zielbranchs eines Pull Requests

Für die meisten Teams zielen fast alle Pull Requests auf denselben Branch ab, z master . B. oder develop. Wenn Sie jedoch einen anderen Branch als Ziel verwenden müssen, vergessen Sie leicht, den Zielbranch von der Standardeinstellung zu ändern. Mit dem neuen Feature zum Ändern des Zielbranchs eines aktiven Pull Requests ist dies jetzt eine einfache Aktion. Klicken Sie einfach auf das Stiftsymbol in der Nähe des Zielbranchnamens in der Pull Request-Kopfzeile.

Ändern des Zielbranchs

Neben der Korrektur von Fehlern ermöglicht das Feature zum Ändern von Zielverzweigungen auch das "Retarget" eines Pull Requests, wenn der Zielbranch zusammengeführt oder gelöscht wurde. Stellen Sie sich ein Szenario vor, in dem sie über einen PR für eine Featurebranch die ein Feature enthält, von dem Ihre Änderungen abhängig sind. Sie möchten ihre abhängigen Änderungen isoliert von anderen Änderungen im Featurebranch überprüfen, sodass Sie zunächst als Ziel features/new-featureverwenden. Prüfer können dann nur Ihre Änderungen sehen und die entsprechenden Kommentare hinterlassen.

Überlegen Sie nun, was passieren würde, wenn die Featurebranch auch einen PR aktiv hätte und vor Ihren Änderungen in master fusioniert wurde? Zuvor mussten Sie Ihre Änderungen aufgeben und einen neuen PR in mastererstellen, oder Ihren PR in features/new-featurezusammenführen und dann einen weiteren PR von in features/new-featuremastererstellen. Mit dieser neuen Aktion zum Aktualisieren des Zielbranchs können Sie einfach den Zielbranch des PR von features/new-feature in masterändern, wobei der gesamte Kontext und die Kommentare beibehalten werden. Wenn Sie den Zielbranch ändern, wird sogar ein neues Update für den PR erstellt, das es leicht macht, auf frühere Diffs zurückzuschauen, bevor sich der Zielbranch ändert.

Aktualisierung des Zielbranchs

Schützen von Git-Repositorys mit plattformübergreifenden Kompatibilitätseinstellungen

Da Git eine plattformübergreifende Technologie ist, ist es möglich, dass Dateien oder Verzeichnisse ihren Weg zu einem Dateisystem finden, wo sie auf einer bestimmten Plattform möglicherweise inkompatibel sind. Details zu diesen Inkompatibilitäten finden Sie in unserer Dokumentation.

Um Teams beim Schutz ihres Repositorys und seiner Entwickler zu unterstützen, haben wir neue Repositoryeinstellungen hinzugefügt, um Pushes zu blockieren, die Commits mit Dateien/Verzeichnissen enthalten, die mit einer oder mehreren Betriebssystemplattformen nicht kompatibel sind. Weitere Informationen zu diesen Einstellungen finden Sie hier.

Verwaltung

Unterstützung von AAD-Benutzern in MSA-Konten

Azure DevOps unterstützt jetzt AzureAD-Benutzer (AAD), die auf Organisationen zugreifen, die von MSA unterstützt werden. Für Administratoren bedeutet dies: Wenn Ihr Azure DevOps-organization MSAs für Unternehmensbenutzer verwendet, können Sie jetzt neue Mitarbeiter über ihre AAD-Anmeldeinformationen zugreifen, anstatt eine neue MSA-Identität nur für die Verwendung mit Azure DevOps zu erstellen.

Wir sind nach wie vor davon überzeugt, dass unternehmenseigene Benutzer azure DevOps mit AAD verbinden, aber wir haben anfang des Jahres erfahren, dass Administratoren mehr Zeit für diese Konvertierung benötigen. Durch das Zulassen von AAD-Benutzern in MSA-gedeckten Organisationen können neue Benutzer auf Azure DevOps zugreifen, sobald Azure DevOps die Erstellung neuer MSA-Benutzer mit benutzerdefinierten Domänennamen verhindert hat, die von AzureAD am Ende des Monats unterstützt werden.

Für Organisationen, die bereits AAD-Identitäten mit Azure DevOps verwenden, gilt dieses Feature nicht. Für Organisationen, die derzeit MSA-Identitäten verwenden, beachten Sie bitte, dass sich alle vorhandenen Benutzer weiterhin wie heute mit ihren MSA-Identitäten anmelden können. Dies gilt nur für Benutzer, die in Zukunft hinzugefügt werden (die möglicherweise keine MSA mit ihrer Unternehmens-E-Mail-Adresse erstellen können).

Hier sehen Sie ein Beispielszenario, in dem diese Erfahrung nützlich sein kann: Dorothy ist die Azure DevOps-Organisationsbesitzer für ihr Unternehmen Fabrikam. Sie und ihr Team von 10 Teammitgliedern melden sich bei Azure DevOps mit MSA-Identitäten an, die ihre Unternehmens-E-Mail-Adresse verwenden, z. B. Dorothy@fabrikam.com. Sam ist ein neues Teammitglied, das heute dem Unternehmen beigetreten ist. Dorothy lädt ihn mithilfe seiner E-Mail sam@fabrikam.comzu Azure DevOps ein. Wenn er in der E-Mail auf den Link "Jetzt beitreten" klickt, kann er sich mit derselben AAD-Identität bei Azure DevOps anmelden, die er für den Zugriff auf seine E-Mail mit Microsoft 365 erhalten hat. Dies ermöglicht Sam die Zusammenarbeit mit seinen 11 Kollegen und gibt Dorothy die Freiheit, ihre Azure DevOps-organization mit AAD zu verbinden, wenn sie bereit ist.

Weitere Informationen finden Sie in unserem Blogbeitrag .

Senden von Feedback

Wir würden uns freuen zu hören, was Sie über diese Features denken. Verwenden Sie das Feedbackmenü, 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,

Gopinath Chigakkagari (Twitter)