Freigeben über

Azure Artifacts vereinfacht die Integration in andere Dienste

  • Artikel

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

Azure Pipelines

Azure Artifacts

Azure Boards

Hinzufügen des Filters „Übergeordnetes Arbeitselement“ zum Task Board und Sprint-Backlog

Wir haben sowohl dem Sprintboard als auch dem Sprint-Backlog einen neuen Filter hinzugefügt. Auf diese Weise können Sie backlog items (first column on the left) 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.

Add Parent Work Item filter.

Verbessern der Fehlerbehandlung – erforderliche Felder für Fehler/Aufgabe

Wenn Sie eine Arbeitsaufgabe von einer Spalte in eine andere verschoben haben, in der der Zustand ausgelöste Feldregeln geändert wird, würde die Karte in der Vergangenheit nur eine rote Fehlermeldung anzeigen, 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.

Select error message to see details.

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 Skalierungssatz-Agents 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 Möglichkeit, von Microsoft gehostete parallele Aufträge auf einzelne Projekte oder Teams in Ihrer Organisation zu partitionieren
  • 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 Skalierungsgruppen-Agents zu verwenden, erstellen Sie zuerst einen VM-Skalierungssatz in Ihrem Azure-Abonnement und dann einen Agentpool in Azure Pipelines, um auf diesen Skalierungssatz zu verweisen. Azure Pipelines skalieren diesen Pool automatisch basierend auf der Anzahl der ausstehenden Aufträge und der Anzahl der Leerlaufcomputer, die Sie jederzeit Standard 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 von NuGet - und npm-Paketen 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 Aufträge heruntergeladen, daher haben wir ein getPackage-Makro eingeführt, mit dem Sie das Paket nutzen 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.

Red arrow in the Azure Artifacts feed detail page.

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 an, wenn die Integrität der Quelle zuletzt überprüft wurde. Vorgelagerte Quellen, die beschädigt sind, zeigen ein rotes X zusammen mit der Uhrzeit der Überprüfung an. Vorgelagerte Quellen, die die Überprüfung ausstehen, zeigen ein blaues Informationssymbol an.

Icons in the Last synced column.

Wenn Sie auf die letzte Synchronisierungszeit für eine fehlerhafte Upstreamquelle klicken, öffnet ein Dialogfeld die Freigabe weiterer Details zur Ursache des Problems (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.

Example showing the target feed was deleted.

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).

Link to license information.

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).

View license details.

Einfache Authentifizierungsaufgaben

Sie können sich jetzt mit beliebten Paketmanagern aus Azure Pipelines mithilfe von Aufgaben mit leichter Authentifizierung 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 dem Veröffentlichen oder Herunterladen von Paketen ausgeführt haben, können 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:

img

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 in der Dokumentation zur NuGet-, npm-, PIP-, Twine- und Maven-Authentifizierung .

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.

zu Azure DevOps wechseln

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.

Make a suggestion

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Vielen Dank,

Aaron Hallberg