Azure Artifacts vereinfacht die Integration in andere Dienste

Mit diesem Update haben wir es einfacher gemacht, Azure Artifacts mit anderen beliebten Paketmanagern zu authentifizieren. Weitere Details zur tatsächlichen Implementierung finden Sie unten.

Features

Azure Boards

• Filter "Übergeordnete Arbeitsaufgabe" zum Task Board hinzufügen und Sprint-Backlog
• Verbesserung der Benutzererfahrung bei der Fehlerbehandlung – erforderliche Felder bei Fehlern/Aufgaben

Azure-Pipelines

• Vorschau der Skalierungsagenten
• Ubuntu 20.04 in der Vorschau für gehostete Azure-Pipelines-Pools
• Unterstützung für GitHub-Pakete in YAML-Pipelines

Azure Artifacts

• Benachrichtigungen für deaktivierte Upstreamquellen
• Lizenzausdrücke und eingebettete Lizenzen
• Einfache Authentifizierungsaufgaben

Azure Boards

Filter "Übergeordnete Arbeitsaufgabe" zur Aufgabentafel und zum Sprint-Backlog hinzufügen

Wir haben sowohl dem Sprintboard als auch dem Sprint-Backlog einen neuen Filter hinzugefügt. Auf diese Weise können Sie Anforderungen auf Backlog-Ebene (erste Spalte links) nach ihrem übergeordneten Element filtern. Im folgenden Screenshot haben wir beispielsweise die Ansicht so gefiltert, dass nur Benutzergeschichten angezeigt werden, bei denen das übergeordnete Element "Mein großes Feature" ist.

Verbesserung der Erfahrung mit der Fehlerbehandlung – erforderliche Felder bei Fehlern/Aufgaben

Wenn Sie eine Arbeitsaufgabe von einer Spalte in eine andere verschoben haben, bei der eine Zustandsänderung Feldregeln ausgelöst hat, zeigt die Karte einfach eine rote Fehlermeldung an, die Sie dazu zwingt, die Arbeitsaufgabe zu öffnen, um die Ursache zu verstehen. In Sprint 170 haben wir die Erfahrung verbessert, sodass Sie jetzt auf die rote Fehlermeldung klicken können, um die Details des Fehlers anzuzeigen, ohne die Arbeitsaufgabe selbst öffnen zu müssen.

Azure-Pipelines

Vorschauversion der Skalierungsgruppen-Agents

Wir zeigen eine Vorschau auf ein neues Feature namens Scale Set Agents, das die Komfort- und Elastizität der von Microsoft gehosteten Agents mit der Kontrolle und Flexibilität von selbst gehosteten Agents kombiniert. Mit dieser Vorschau können Sie jetzt Agents in Ihrer Spezifikation, vollständig automatisiert, in Ihrem Azure-Abonnement verwalten. Sie sollten die Verwendung von Skalen-Agenten anstelle von von Microsoft gehosteten oder selbst gehosteten Agents in Betracht ziehen, wenn Sie:

• benötigen mehr Arbeitsspeicher, mehr Prozessor, mehr Speicher oder mehr E/A als das, was wir in nativen von Microsoft gehosteten Agents anbieten
• Sie möchten nicht zulassen, dass eine große Anzahl von IP-Adressen in Ihrer Unternehmensfirewall aufgeführt wird, damit von Microsoft gehostete Agents mit Ihren Servern kommunizieren können.
• benötigen mehr von Microsoft gehostete Agents, als wir bereitstellen können, um Ihre großen Anforderungen zu erfüllen
• die Fähigkeit, von Microsoft gehostete parallele Aufträge auf einzelne Projekte oder Teams in Ihrer Organisation aufzuteilen
• keine dedizierten Agents rund um die Uhr ausführen möchten, sondern stattdessen Agent-Computer de-provisionieren möchten, die nicht aktiv genutzt werden

Um Skalierungssatz-Agents zu verwenden, erstellen Sie zuerst einen VM-Skalierungssatz in Ihrem Azure-Abonnement und dann einen Agentpool in Azure Pipelines, um diesen Skalierungssatz zuzuweisen. Azure Pipelines skalieren diesen Pool automatisch basierend auf der Anzahl der ausstehenden Aufträge und der Anzahl der Leerlaufcomputer, die Sie jederzeit verwalten möchten. Azure Pipelines installieren auch den Agent für Sie auf diesen virtuellen Computern. Weitere Informationen finden Sie unter Skalierungssatz-Agents. Wenn Sie eine Vorschau des Features anzeigen, geben Sie Bitte Ihr Feedback auf der Dokumentationsseite ein.

Ubuntu 20.04 in Vorschauversion für gehostete Azure Pipelines-Pools

Das Ubuntu 20.04-Image ist jetzt in der Vorschau für in Azure Pipelines gehostete Pools verfügbar. Um dieses Image zu verwenden, aktualisieren Sie Ihre YAML-Datei so, dass vmImage: 'ubuntu-20.04' enthalten ist. Bitte beachten Sie, dass die ubuntu-neueste Imagebezeichnung weiterhin auf Ubuntu-18.04 verweist, bis Ubuntu-20.04 später in diesem Jahr aus der Vorschau kommt.

Bitte beachten Sie, da das Ubuntu 20.04-Bild in der Vorschau ist, unterstützt es derzeit nicht alle tools, die in ubuntu-18.04 verfügbar sind. Weitere Informationen

Unterstützung für GitHub-Pakete in YAML-Pipelines

Wir haben kürzlich einen neuen Ressourcentyp namens Pakete eingeführt, der Unterstützung für die Nutzung NuGet- und npm--Pakete von GitHub als Ressource in YAML-Pipelines hinzufügt. Als Teil dieser Ressource können Sie nun den Pakettyp (NuGet oder npm) angeben, den Sie von GitHub nutzen möchten. Sie können auch automatisierte Pipelinetrigger bei der Veröffentlichung einer neuen Paketversion aktivieren. Heute ist der Support nur für die Nutzung von Paketen von GitHub verfügbar, aber in Zukunft planen wir, die Unterstützung für die Nutzung von Paketen aus anderen Paketrepositorys wie NuGet-, npm, AzureArtifacts und vielem mehr zu erweitern. Ausführliche Informationen finden Sie im folgenden Beispiel:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # GitHub service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Hinweis: Heute unterstützt GitHub-Pakete nur PAT-basierte Authentifizierung, was bedeutet, dass die GitHub-Dienstverbindung in der Paketressource vom Typ PAT sein sollte. Sobald diese Einschränkung aufgehoben wurde, bieten wir Unterstützung für andere Arten der Authentifizierung.

Standardmäßig werden Pakete nicht automatisch in ihre Aufgaben heruntergeladen. Deshalb haben wir das Makro getPackage eingeführt, mit dem Sie das Paket verwenden können, das in der Ressource definiert ist. Ausführliche Informationen finden Sie im folgenden Beispiel:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Azure Artifacts

Benachrichtigungen für deaktivierte Upstreamquellen

Die Azure Artifacts-Webschnittstelle benachrichtigt Sie jetzt, wenn eine oder mehrere upstream-Quellen Ihres Feeds nicht funktionieren. Upstreamquellen ermöglichen es Ihnen, einen Feed (Feed A) auf einen anderen Feed (Feed B) zu verweisen, und es Den Verbrauchern von Feed A ermöglichen, auf Pakete von Feed B zuzugreifen, ohne eine direkte Verbindung damit herstellen zu müssen. Weitere Informationen zu upstream-Quellen finden Sie in der Dokumentation zu Azure Artifacts. Upstreamquellen funktionieren möglicherweise nicht, wenn sie an der Quelle deaktiviert sind, z. B. wenn Feed B im Hintergrund gelöscht wird, können Kunden keine Pakete über Feed A abrufen. In der Vergangenheit kann diese Situation ohne Warnung auftreten und zu schwierigen betriebstechnischen Problemen wie plötzlichen Buildunterbrechungen aufgrund fehlender Abhängigkeiten führen (d. h. Pakete, die aus Feed B im obigen Beispiel stammen). Jetzt erhalten Sie von Azure Artifacts eine Warnung, wenn Probleme mit vorgelagerten Quellen Ihrer Feeds auftreten. Wenn ein Problem auftritt, wird auf der Detailseite des Azure Artifacts-Feeds ein Banner (roter Pfeil unten) angezeigt.

Wenn Sie auf den Link im Banner klicken, wird eine Seite geöffnet, auf der der Status jeder upstream-Quelle angezeigt wird, die Ihren Feed enthält. Neben Informationen zu jeder Upstreamquelle für den aktuellen Feed können Sie den aktuellen Status unter der Spalte "Zuletzt synchronisiert" sehen. Vorgelagerte Quellen, die ordnungsgemäß funktionieren, zeigen ein grünes Häkchen zusammen mit dem Zeitpunkt der letzten Überprüfung der Gesundheit der Quelle an. Vorgelagerte Quellen, die beschädigt sind, zeigen ein rotes X zusammen mit der Uhrzeit der Überprüfung an. Vorgelagerte Quellen, die noch auf die Überprüfung warten, zeigen ein blaues Informationssymbol an.

Wenn Sie auf die letzte Synchronisierungszeit für eine gebrochene Upstreamquelle klicken, wird ein Dialogfeld geöffnet, das weitere Details zur Ursache des Problems bereitstellt (sofern verfügbar). In der nachstehenden Abbildung funktioniert beispielsweise die fragliche Upstreamquelle nicht, da der Zielfeed gelöscht wurde. Das Dialogfeld enthält auch einen Link zum Überwachungsprotokoll, damit Sie verstehen können, wer kürzlich relevante Änderungen vorgenommen hat. Links zu den Berechtigungseinstellungen und der Dokumentation zu Azure Artifacts können auch verwendet werden, um die Ursache zu untersuchen.

Lizenzausdrücke und eingebettete Lizenzen

Jetzt können Sie die Details der Lizenzinformationen für NuGet-Pakete anzeigen, die in Azure Artifacts gespeichert sind, während Sie Pakete in Visual Studio durchsuchen. Dies gilt für Lizenzen, die mit Lizenzausdrücken oder eingebetteten Lizenzen dargestellt werden. Nun sehen Sie einen Link zu den Lizenzinformationen auf der Seite mit den Details des Visual Studio-Pakets (roter Pfeil in der abbildung unten).

Wenn Sie auf den Link klicken, gelangen Sie zu einer Webseite, auf der Sie die Details der Lizenz anzeigen können. Diese Oberfläche ist sowohl für Lizenzausdrücke als auch für eingebettete Lizenzen identisch, sodass Sie Lizenzdetails für Pakete anzeigen können, die in Azure Artifacts an einem Ort gespeichert sind (für Pakete, die Lizenzinformationen angeben und von Visual Studio unterstützt werden).

Einfache Authentifizierungsaufgaben

Sie können sich jetzt mit beliebten Paketmanagern aus Azure Pipelines mithilfe von leichtgewichtigen Authentifizierungsaufgaben authentifizieren. Dazu gehören NuGet, npm, PIP, Twine und Maven. Zuvor konnten Sie sich mit diesen Paketmanagern authentifizieren, indem Sie Aufgaben verwenden, die eine große Funktionalität bereitgestellt haben, einschließlich der Möglichkeit zum Veröffentlichen und Herunterladen von Paketen. Dies erforderte jedoch die Verwendung dieser Aufgaben für alle Aktivitäten, die mit den Paketmanagern interagierten. Wenn Sie Ihre eigenen Skripts zum Ausführen von Aufgaben wie das Veröffentlichen oder Herunterladen von Paketen hätten, könnten Sie sie nicht in Ihrer Pipeline verwenden. Jetzt können Sie Skripts Ihres eigenen Designs in Ihrer Pipeline YAML verwenden und die Authentifizierung mit diesen neuen einfachen Aufgaben ausführen. Beispiel für npm:

Die Verwendung des Befehls "ci" und "veröffentlichen" in dieser Abbildung sind beliebig, Sie können alle Befehle verwenden, die von Azure Pipelines YAML unterstützt werden. Auf diese Weise können Sie die vollständige Kontrolle über befehlsaufrufe haben und die Verwendung freigegebener Skripts in Ihrer Pipelinekonfiguration vereinfachen. Weitere Informationen finden Sie unter NuGet, npm, PIP, Twineund Maven Authentifizierungsaufgabendokumentation.

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.

Vielen Dank,

Aaron Hallberg