GitHub Advanced Security und Managed Identity and Managed Identity and Service Principal Support für Azure DevOps sind jetzt allgemein verfügbar
Wir freuen uns, ihnen mitzuteilen, dass GitHub Advanced Security und Managed Identity und Service Principal Support für Azure DevOps jetzt allgemein verfügbar sind!
Auf GitHub Advanced Security haben wir auch die Codeüberprüfung verbessert, um alle vom Benutzer bereitgestellten Eingaben in die CodeQL Initialize-Aufgabe einzuschließen. Darüber hinaus haben wir die CodeQL-Unterstützung um Swift erweitert.
In Boards veröffentlichen wir Teamautomatisierungsregeln in der privaten Vorschau. Jetzt können Sie jede Backlog-Ebene konfigurieren, um das Öffnen und Schließen/Auflösen von Arbeitsaufgaben basierend auf den Status(en) ihrer untergeordneten Elemente zu automatisieren. Schauen Sie sich die Versionshinweise an, wenn Sie sich für die private Vorschau registrieren möchten.
Navigieren Sie zur nachstehenden Featureliste, um mehr über diese Features zu erfahren.
Allgemein
- Verwaltete Identitäts- und Dienstprinzipalunterstützung für Azure DevOps jetzt in allgemeiner Verfügbarkeit (GA)
- Neue Azure DevOps-Bereiche, die für delegierte Microsoft Identity OAuth-Fluss-Apps verfügbar sind
GitHub Advanced Security für Azure DevOps
- Änderungen an CodeScans (CodeQL)-Benutzereingabeaufgabe und -variablen
- Die Veröffentlichungsaufgabe ist für das Einrichten der Codeüberprüfung nicht mehr erforderlich.
- CodeQL-Codeüberprüfung unterstützt jetzt Swift
Azure Boards
Azure Pipelines
- Pipelineprotokolle enthalten jetzt die Ressourcenauslastung.
- Azure Pipelines-Agent unterstützt jetzt Alpine Linux
Allgemein
Verwaltete Identitäts- und Dienstprinzipalunterstützung für Azure DevOps jetzt in allgemeiner Verfügbarkeit (GA)
Die Unterstützung für von Microsoft Entra ID verwaltete Identitäten und Dienstprinzipale in Azure DevOps hat jetzt die allgemeine Verfügbarkeit (GA) erreicht.
Heutzutage verlassen sich viele Anwendungsintegrationsszenarien auf persönliche Zugriffstoken (PERSONAL Access Tokens, PATs), um sie in Azure DevOps zu integrieren. Während einfach zu verwenden, können PATs leicht geleeckt werden, wodurch potenziell böswillige Akteure sich als leistungsstarke Benutzer authentifizieren können. Um unerwünschten Zugriff zu verhindern, erfordern PATs häufig auch zeitaufwendig Standard Tenance durch regelmäßige Drehungen von Anmeldeinformationen.
Sie können anwendungen jetzt aktivieren, stattdessen verwaltete Identitäten und Dienstprinzipale für die Integration in Azure DevOps über REST-APIs und Clientbibliotheken zu verwenden. Dieses hoch angeforderte Feature bietet Azure DevOps-Kunden eine sicherere Alternative zu PATs. Verwaltete Identitäten bieten die Möglichkeit für Anwendungen, die auf Azure-Ressourcen ausgeführt werden, Azure AD-Token abzurufen, ohne überhaupt Anmeldeinformationen verwalten zu müssen.
Verwaltete Identitäten und Dienstprinzipale können in Azure DevOps eingerichtet und bestimmten Ressourcen (Projekte, Repositorys, Pipelines) wie normale Benutzer Berechtigungen erteilt werden. Auf diese Weise können Anwendungen, die verwaltete Identitäten oder Dienstprinzipale verwenden, eine Verbindung mit Azure DevOps herstellen und Aktionen im Auftrag von sich selbst statt im Auftrag eines Benutzers ausführen, wie PAT. Teams können ihre Dienste jetzt besser zusammen verwalten, anstatt sich auf eine einzelne Person zu verlassen, um ein Token für die Authentifizierung bereitzustellen. Erfahren Sie mehr über die GA-Version in unserer Ankündigung zu unserem öffentlichen Blogbeitrag und unserer Featuredokumentation.
Neue Azure DevOps-Bereiche, die für delegierte Microsoft Identity OAuth-Fluss-Apps verfügbar sind
Wir haben neue Azure DevOps-Bereiche für delegierte OAuth-Apps auf der Microsoft Identity Platform hinzugefügt, auch bekannt als Microsoft Entra ID OAuth-Apps. Mit diesen neuen Bereichen können App-Entwickler festlegen, welche Berechtigungen sie vom Benutzer anfordern möchten, um App-Aufgaben auszuführen. Mit diesem hoch angeforderten Feature können App-Entwickler nur die Berechtigungen anfordern, die sie für ihre App benötigen.
Zuvor war user_impersonation der einzige Bereich, aus dem App-Entwickler auswählen können. Dieser Bereich ermöglicht der App vollständigen Zugriff auf alle Azure DevOps-APIs. Dies bedeutet, dass der Benutzer alles tun kann, was der Benutzer in allen Organisationen tun kann, zu denen der Benutzer gehört. Jetzt mit detaillierteren Bereichen können Sie ganz einfach sein, dass Apps nur die APIs anfordern und darauf zugreifen können, denen die angeforderten Bereiche ihnen die Berechtigung zum Zugriff erteilt haben.
Erfahren Sie mehr über diese neuen Bereiche in unserer Ankündigung und Featuredokumentation für öffentliche Blogbeiträge.
GitHub Advanced Security für Azure DevOps
Änderungen an CodeScans (CodeQL)-Benutzereingabeaufgabe und -variablen
Alle vom Benutzer bereitgestellten Eingaben werden nun in der Aufgabe CodeQL Initialize angegeben, die für die Konfiguration der CodeQL-Analyseumgebung verantwortlich ist, die für die Codeanalyse mit CodeQL "AdvancedSecurity-Codeql-Init@1" verwendet wird. Weitere Informationen zum Konfigurieren von GitHub Advanced Security für Azure DevOps-Features finden Sie in der Dokumentation zu den Features von GitHub Advanced Security für Azure DevOps.
Darüber hinaus haben Benutzereingaben Vorrang vor allen von Variablen festgelegten Werten. Wenn Sie beispielsweise die Sprachvariable während advancedsecurity.codeql.language: Java
der CodeQL-Initialisierungsphase einrichten, geben Sie die Sprache als Eingabe mit Language: cpp,
der Eingabe die Variable Java
für die Sprache außer Kraftcpp
. Stellen Sie sicher, dass Ihre Eingaben korrekt konfiguriert sind.
Die Veröffentlichungsaufgabe ist für das Einrichten der Codeüberprüfung nicht mehr erforderlich.
Zuvor mussten Sie beim Konfigurieren der Codeüberprüfung die Veröffentlichungsaufgabe (AdvancedSecurity-Publish@1) entweder in der YAML-Pipeline oder der klassischen Pipeline einschließen. Mit diesem Update haben wir die Notwendigkeit der Veröffentlichungsaufgabe beseitigt, und die Ergebnisse werden jetzt direkt in den erweiterten Sicherheitsdienst innerhalb der Analyseaufgabe (AdvancedSecurity-Codeql-Analyze@1) gepostet.
Im Folgenden finden Sie die Anforderungsaufgabe für die Codeüberprüfung.
Weitere Informationen finden Sie in der Dokumentation zur Codeüberprüfung.
CodeQL-Codeüberprüfung unterstützt jetzt Swift
Wir erweitern unsere Unterstützung für die CodeQL-Codeüberprüfung, um Swift einzuschließen! Dies bedeutet, dass Entwickler, die an Swift-Bibliotheken und -Anwendungen für Apple-Plattformen arbeiten, jetzt unsere erstklassige Codesicherheitsanalyse nutzen können. Zu unseren aktuellen Funktionen gehören die Erkennung von Problemen wie Pfadinjektion, riskante Webansichtsabrufe, verschiedene kryptografische Missbrauche und andere Formen der unsicheren Behandlung oder Verarbeitung von ungefilterten Benutzerdaten.
Swift ist jetzt Teil unserer Liste der unterstützten Programmiersprachen, einschließlich C/C++, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, C# und Go. Insgesamt ermöglichen uns diese Sprachen, fast 400 umfassende Überprüfungen ihres Codes durchzuführen, während Standard eine niedrige Rate falsch positiver Ergebnisse und eine hohe Genauigkeit gewährleisten.
Weitere Informationen zum Konfigurieren von GitHub Advanced Security für Azure DevOps-Features finden Sie in der Dokumentation zum Konfigurieren von GitHub Advanced Security für Azure DevOps für Ihre Repositorys.
Azure Boards
Teamautomatisierungsregeln (private Vorschau)
Wichtig
Ab dem 11.9.2023 nehmen wir keine neuen Organisationen in die private Vorschau ein. Wir haben ein tolles Feedback mit nur wenigen kleinen Fehlern zur Lösung gegeben. Wir arbeiten an diesen Fehlern und werden das Feature für alle in den nächsten Sprints veröffentlichen.
Sie können jetzt jede Backlog-Ebene konfigurieren, um das Öffnen und Schließen/Auflösen von Arbeitsaufgaben basierend auf dem Status(en) ihrer untergeordneten Elemente zu automatisieren. Es gibt zwei Standard Szenarien, die wir lösen möchten.
Wenn ein einzelnes untergeordnetes Element aktiviert wird, aktivieren Sie das übergeordnete Element.
Wenn alle untergeordneten Elemente geschlossen sind, schließen Sie das übergeordnete Element (oder lösen Sie es auf).
Um diese Einstellungen zu aktivieren, klicken Sie auf die Konfiguration der Backlogebene für Ihr Team. Wechseln Sie dann zur Registerkarte "Automatisierungsregeln>", um die beiden verschiedenen Regeln anzuzeigen, die Sie auf Ihren Backlog anwenden können. Jede Backlog-Ebene (Anforderungen, Features, Epen) kann so konfiguriert werden, wie Ihr Team arbeiten möchte.
Wenn beispielsweise eine untergeordnete Aufgabe auf "Aktiv" festgelegt ist, wird der übergeordnete Benutzerabschnitt aktiviert. Wenn dann alle Aufgaben abgeschlossen sind, legen Sie den Benutzerabschnitt auf "Geschlossen" fest.
Wenn Sie sich für die private Vorschau registrieren möchten, senden Sie uns bitte eine E-Mail mit Ihrem Organisationsnamen (dev.azure.com/{Organisationsname}). Bitte verstehen Sie, dass wir die Anzahl der Organisationen in die Vorschau beschränken werden. Unsere Hoffnung besteht darin, ein paar Organisationen zu erhalten, um Feedback zu geben und dann innerhalb von 2-3 Sprints für alle freizugeben.
Die Features wurden basierend auf diesem Entwicklercommunity Vorschlagsticket priorisiert.
Hinweis
Dieses Feature ist nur in der Vorschauversion von New Boards Hubs verfügbar.
Azure Pipelines
Pipelineprotokolle enthalten jetzt die Ressourcenauslastung.
Azure-Pipelineprotokolle können jetzt Metriken zu Ressourcen erfassen, z. B. zur Arbeitsspeicherauslastung, CPU-Auslastung und zum verfügbaren Speicherplatz. Die Protokolle enthalten auch Ressourcen, die vom Pipeline-Agent und untergeordneten Prozessen verwendet werden, einschließlich Tasks, die in einem Auftrag ausgeführt werden.
Wenn Sie vermuten, dass Ihr Pipelineauftrag möglicherweise zu Ressourceneinschränkungen führt, aktivieren Sie ausführliche Protokolle , um Ressourcennutzungsinformationen in Pipelineprotokolle einzufügen. Das funktioniert für jeden Agent, unabhängig vom Hostingmodell.
Azure Pipelines-Agent unterstützt jetzt Alpine Linux
Der Pipeline-Agent v3.227 unterstützt jetzt alpine Linux-Versionen 3.13 und höher. Alpine Linux ist ein beliebtes Containerimage (Basisimage). Sie finden den Agent auf der Seite " Releases ". Alpine Linux-Versionen des Agents haben z.B. vsts-agent-linux-musl-x64-3.227.1.tar.gz
ein Präfixvsts-agent-linux-musl
.
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.
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.
Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.
Vielen Dank,
Rajesh Ramamurthy