YAML-Verbesserungen in Azure Pipelines – Sprint 142 Update
Im Sprint 142-Update von Azure DevOps wurden mehrere Verbesserungen an YAML vorgenommen, z . B. das Hinzufügen benutzerdefinierter Indikatoren zu Ihren Builds, das Angeben von Branches zum Erstellen für Pull Requests und die Verwendung von Vorlagen inline. Wir haben auch die neue Navigation für alle Benutzer aktiviert, ein dunkles Design eingeführt und die Verknüpfungs- und Anlagenerfahrungen in Azure Boards verbessert.
Weitere Informationen finden Sie in der Liste features unten.
Features
Allgemeines:
Azure Boards:
- Organisieren von Referenzmaterialien mit umfangreicheren Arbeitselementanlagen
- Verwalten von Abhängigkeiten durch Verknüpfen von Arbeitselementen in Ihren Organisationen
- Öffnen von Arbeitselementen aus der Suche
Azure Repos:
Azure Pipelines:
- Hinzufügen benutzerdefinierter Buildindikatoren zu Ihren Builds
- Verwenden von YAML zum Angeben von Branches, die für Pull Requests erstellt werden sollen
- Verwenden von YAML-Vorlagenausdrücken inline
- Verbessern der Problembehandlung mit dem Pipelineinitialisierungsprotokoll
- Standardaufbewahrung für YAML-Pipelines
- Erstellen auf Linux/ARM- und Windows-32-Bit-Plattformen
- Klonen von Variablengruppen
- Siehe Commits und Arbeitselemente für alle verknüpften Quellen
- Ausführen von Paketen, die in Azure App Service Bereitstellungen unterstützt werden
- Bereitstellen von Linux-Containern mit dem App Server-Task "Bereitstellen"
Azure Test Plans:
Azure Artifacts:
Wiki:
Verwaltung:
Allgemein
Neue Navigation ist für alle Benutzer aktiviert
Wir haben unsere neue Navigation für alle Benutzer aktiviert! Dies ist ein wichtiger Meilenstein bei der Einführung unseres neuen Produktdesigns. Während wir mit diesem Release alle auf das neue Navigationsmodell umstellen, können Benutzer die alte Navigation noch bis zum 16. Januar 2019 deaktivieren und verwenden. Sie können dies deaktivieren, indem Sie im Menü unter Ihrem Avatar oben rechts auf jeder Seite Vorschaufeatures auswählen.
Weitere Informationen finden Sie im Blogbeitrag Zum Navigationsupdate .
Dunkles Design
Eine unserer langjährigen Featureanforderungen war es, ein dunkles Thema anzubieten. Wir freuen uns, Ihnen mitteilen zu können, dass dies jetzt im Rahmen der neuen Navigation verfügbar ist. Sie können dunkles Design aktivieren, indem Sie im Menü unter Ihrem Avatar oben rechts auf jeder Seite Design auswählen.
Azure Boards
Organisieren von Referenzmaterialien mit umfangreicheren Arbeitselementanlagen
Durch das Anfügen von Dateien an Arbeitselemente können Sie und Ihr Team Referenzmaterialien zentralisieren, sodass sie bei Bedarf immer in der Nähe sind. Es ist jetzt einfacher, eine neue Anlage hinzuzufügen, indem Sie die Datei einfach an eine beliebige Stelle im Arbeitselementformular ziehen und ablegen. Sie können die Anlagen weiterhin als Liste anzeigen oder zu einer Rasteransicht wechseln, um eine Miniaturansicht anzuzeigen. Doppelklicken Sie auf die Datei, um eine Vorschau zu öffnen, und durchlaufen Sie diese, um schnell die benötigten Informationen zu finden.
Verwalten von Abhängigkeiten durch Verknüpfen von Arbeitselementen in Ihren Organisationen
Durch das Verknüpfen verwandter oder abhängiger Arbeiten erhalten Sie einen umfassenderen Kontext für die Arbeit, die Sie nachverfolgen, und sie hilft Ihnen bei der Verwaltung von Abhängigkeiten mit anderen Teams. Mit Links für Remotearbeit können Sie jetzt die Arbeit in Organisationen innerhalb Ihres Unternehmens nachverfolgen. Kopieren Sie einfach die URL eines vorhandenen Arbeitselements, wechseln Sie zu einem anderen Arbeitselement, und erstellen Sie einen Link mit einem der drei neuen Linktypen: Consumes From, Produces For und Remote Related. Weitere Informationen zur Nachverfolgbarkeit in Azure Boards finden Sie in der Dokumentation zum Verknüpfen von Arbeitselementen.
Hinweis
Berechtigungen werden in beiden Azure DevOps-Organisationen respektiert, die beide durch denselben Azure AD-Mandanten unterstützt werden müssen.
Wenn Sie mit der Verwaltung mehrerer Abhängigkeiten beginnen, verwenden Sie das neue Feld Remotelinkanzahl in Abfragen , um die Arbeitselemente aufzulisten, die Remoteabhängigkeiten in Ihrem Projekt aufweisen, oder erwägen Sie die Installation der Dependency Tracker-Erweiterung . Diese Erweiterung, die von der Windows-Gruppe bei Microsoft erstellt wurde, um ihre Skalierungsanforderungen zu erfüllen, baut auf Remotelinks auf, um eine umfassende Hierarchie und grafische Darstellung Ihrer Abhängigkeiten anzuzeigen.
Öffnen von Arbeitselementen aus der Suche
Zuvor konnte ein Arbeitselement nicht auf der Suchergebnisseite geöffnet werden, wenn der Vorschaubereich für Arbeitselemente deaktiviert war. Dies würde es schwierig machen, in Ihre Suchergebnisse zu suchen. Jetzt können Sie auf den Titel des Arbeitselements klicken, um die Arbeitselemente in einem modalem Fenster zu öffnen. Dieses Feature wurde von UserVoice priorisiert.
Azure Repos
Erweiterungsautoren können den Kontext zum aktuellen Repository abfragen.
Eine der Herausforderungen für einen Autor einer Versionsverwaltungserweiterung besteht darin, den Kontext des Repositorys abzurufen, das dem Benutzer angezeigt wird, z. B. Name, ID und URL. Um dies zu unterstützen, haben wir den VersionControlRepositoryService als erweiterungszugriffsfähigem Dienst hinzugefügt. Damit kann ein Erweiterungsautor Informationen zum aktuellen Git-Repositorykontext auf der Web-Benutzeroberfläche abfragen. Sie verfügt derzeit über eine Methode, getCurrentGitRepository().
- Wenn ein Git-Repository ausgewählt ist, wird ein GitRepository-Objekt mit grundlegenden Daten zum Repository (Name, ID und URL) zurückgegeben.
- Wenn ein TFVC-Repository ausgewählt ist oder außerhalb der Azure Repos Seiten auf den Dienst zugegriffen wird, wird NULL zurückgegeben.
Hier sehen Sie eine Beispielerweiterung , die diesen Dienst verwendet.
Azure Pipelines
Hinzufügen benutzerdefinierter Buildindikatoren zu Ihren Builds
Buildindikatoren bieten eine Möglichkeit, Builds eindeutig zu nummerieren und zu beschriften. Zuvor konnten Sie dazu die Sondervariable $(rev:r) verwenden. Jetzt können Sie ihre eigenen Zählervariablen in Ihrer Builddefinition definieren, die bei jeder Ausführung eines Builds automatisch inkrementiert werden. Dies geschieht auf der Registerkarte Variablen einer Definition. Dieses neue Feature bietet Ihnen auf folgende Weise mehr Leistung:
- Sie können einen benutzerdefinierten Leistungsindikator definieren und dessen Seedwert festlegen. Für instance können Sie Ihren Zähler mit 100 starten. $(rev:r) beginnt immer bei 0.
- Sie können Ihre eigene benutzerdefinierte Logik verwenden, um einen Zähler zurückzusetzen. $(rev:r) ist an die Buildnummerngenerierung gebunden und wird automatisch zurückgesetzt, wenn ein neues Präfix in der Buildnummer vorhanden ist.
- Sie können mehrere Indikatoren pro Definition definieren.
- Sie können den Wert eines Indikators außerhalb eines Builds abfragen. Für instance können Sie die Anzahl der Builds zählen, die seit dem letzten Zurücksetzen mit einem Zähler ausgeführt wurden.
Weitere Informationen zu Buildindikatoren finden Sie in der Dokumentation zu benutzerdefinierten Variablen .
Verwenden von YAML zum Angeben von Branches, die für Pull Requests erstellt werden sollen
YAML-Pipelines können angeben, welche Branches für PRs (Pull Requests) erstellt werden sollen. Sie können Zweige auswählen, die eingeschlossen und ausgeschlossen werden sollen. Diese Funktion war zuvor auf der Web-Benutzeroberfläche verfügbar. Durch Das Verschieben in die YAML-Datei wird es Teil Ihres Konfigurations-as-Code-Workflows.
Ein Beispiel für die Verwendung von PR-Triggern könnte wie folgt aussehen:
pr:
branches:
include:
- features/*
exclude:
- features/experimental/*
paths:
include:
- **/*.cs
steps:
- script: echo My PR build!
Verwenden von YAML-Vorlagenausdrücken inline
YAML-Vorlagen sind eine leistungsstarke Möglichkeit, Teile von Pipelines wiederzuverwenden. Zusätzlich zum Berücksichtigen von allgemeinem Code können Sie mit Vorlagenausdrücken Werte ändern und steuern, welche YAML enthalten ist. Bisher musste ein Vorlagenausdruck den gesamten Wert in einem YAML-Ausdruck belegen. Dieses Beispiel würde funktionieren, da der Ausdruck der gesamte Wert der Lösungseigenschaft ist.
- task: msbuild@1
inputs:
solution: ${{ parameters.solution }}
Wir haben nun die Einschränkung gelockert und lassen Inlinevorlagen zu, wie sie im folgenden Beispiel dargestellt werden.
- script: echo The solution file is ${{ parameters.solution }}
Verbessern der Problembehandlung mit dem Pipelineinitialisierungsprotokoll
Wenn eine Pipeline ausgeführt wird, muss Azure Pipelines sicherstellen, dass die Pipelinedefinition korrekt ist, entscheiden, welche Aufträge geplant werden sollen, Agents zum Ausführen der Aufträge anfordern und vieles mehr. Bis jetzt war dieser Prozess völlig undurchsichtig, sodass es für einen Kunden fast unmöglich war, das Problem zu beheben, wenn etwas schief ging. Wir führen eine neue Art von Protokoll ein, das pipelineinitialisierungsprotokoll genannt wird, das diese Details sichtbar macht. Sie können auf das Pipelineinitialisierungsprotokoll zugreifen, indem Sie die Option Alle Protokolle herunterladen für einen abgeschlossenen Build auswählen.
Standardaufbewahrung für YAML-Pipelines
Wir arbeiten an einer Möglichkeit für Benutzer, Aufbewahrungsrichtlinien für YAML-Pipelines zu konfigurieren. Bis dieses neue Feature verfügbar ist, haben wir die Standardaufbewahrung für alle YAML-Builds auf 30 Tage erhöht, da viele Benutzer ihre Builds länger als die vorherige 10-Tage-Standardaufbewahrung beibehalten möchten. Die Registerkarte "Aufbewahrung" im Editor für YAML-Pipelines wurde entfernt, bis das neue Modell vorhanden ist.
Erstellen auf Linux/ARM- und Windows 32-Bit-Plattformen
Der plattformübergreifende Agent von Azure Pipelines Open Source wurde immer unter 64-Bit (x64) Windows, macOS und Linux unterstützt. In diesem Sprint führen wir zwei neue unterstützte Plattformen ein: Linux/ARM und Windows/32-Bit. Diese neuen Plattformen bieten Ihnen die Möglichkeit, auf weniger gängigen, aber nicht weniger wichtigen Plattformen wie dem Raspberry Pi, einem Linux-/ARM-Computer, zu bauen.
Klonen von Variablengruppen
Wir haben Unterstützung für das Klonen von Variablengruppen hinzugefügt. Wenn Sie eine Variablengruppe replizieren und nur einige der Variablen aktualisieren möchten, müssen Sie nicht den mühsamen Prozess des einzelnen Hinzufügens von Variablen durchlaufen. Sie können jetzt schnell eine Kopie Ihrer Variablengruppe erstellen, die Werte entsprechend aktualisieren und als neue Variablengruppe speichern.
Hinweis
Die Geheimnisvariablenwerte werden beim Klonen einer Variablengruppe nicht kopiert. Sie müssen die verschlüsselten Variablen aktualisieren und dann die geklonte Variablengruppe speichern.
Weitere Informationen finden Sie unter Commits und Arbeitselemente für alle verknüpften Quellen.
Wir setzen unser Engagement für eine verbesserte Rückverfolgbarkeit fort und freuen uns, bekannt geben zu können, dass Kunden jetzt die Details zu Commits und Arbeitselementen für alle artefakte anzeigen können, die mit der Pipeline verknüpft sind. Standardmäßig werden Commit und Arbeitselement mit der letzten Bereitstellung in derselben Phase verglichen. Sie können jedoch bei Bedarf mit jeder anderen vorherigen Bereitstellung vergleichen.
Ausführen von Paketen, die in Azure App Service Bereitstellungen unterstützt werden
Die version Azure App Service Deploy-Aufgabe (4.*) unterstützt jetzt RunFromPackage (früher RunFromZip genannt).
App Service unterstützt eine Reihe verschiedener Techniken zum Bereitstellen Ihrer Dateien, z. B. msdeploy (auch bekannt als WebDeploy), Git, ARM und mehr. Aber all diese Techniken haben eine Einschränkung. Ihre Dateien werden unter Ihrem Ordner wwwroot (insbesondere d:\home\site\wwwroot) bereitgestellt, und die Runtime führt dann die Dateien dort aus.
Mit Run From Package gibt es keinen Bereitstellungsschritt mehr, der die einzelnen Dateien in wwwroot kopiert. Stattdessen zeigen Sie es einfach auf eine ZIP-Datei, und die ZIP-Datei wird in wwwroot als schreibgeschütztes Dateisystem eingebunden. Dies hat mehrere Vorteile:
- Reduziert das Risiko von Sperrungen beim Kopieren von Dateien.
- Kann in einer Produktions-App (mit Neustart) bereitgestellt werden.
- Sie können sich sicher sein, dass die Dateien, die in Ihrer App ausgeführt werden, sicher sind.
- Verbessert die Leistung von Azure App Service Bereitstellungen.
- Kann Kaltstartzeiten verringern, insbesondere für JavaScript-Funktionen mit großen npm-Paketstrukturen.
Bereitstellen von Linux-Containern mit dem App Server-Task "Bereitstellen"
Die Version 4.* der Aufgabe Azure App Service Bereitstellen unterstützt jetzt die Bereitstellung Ihres eigenen benutzerdefinierten Containers für Azure Functions unter Linux.
Das Linux-Hostingmodell für Azure Functions basiert auf Docker-Containern, die eine höhere Flexibilität beim Packen und Nutzen von App-spezifischen Abhängigkeiten bieten. Funktionen unter Linux können in zwei verschiedenen Modi gehostet werden:
- Integriertes Containerimage: Sie bringen den Funktions-App-Code mit und Azure stellt den Container (integrierter Imagemodus) bereit und verwaltet sie, sodass keine spezifischen Docker-Kenntnisse erforderlich sind. Dies wird in der vorhandenen Version von App Service Task Bereitstellen unterstützt.
- Benutzerdefiniertes Containerimage: Wir haben den Task App Service Bereitstellen verbessert, um die Bereitstellung benutzerdefinierter Containerimages für Azure Functions unter Linux zu unterstützen. Wenn Ihre Funktionen eine bestimmte Sprachversion benötigen oder eine bestimmte Abhängigkeit oder Konfiguration benötigen, die nicht im integrierten Image bereitgestellt wird, können Sie mithilfe von Azure Pipelines ein benutzerdefiniertes Image in Azure Function unter Linux erstellen und bereitstellen.
Azure Test Plans
Azure Test Runner-Client zum Ausführen manueller Tests für Desktopanwendungen
Sie können jetzt den Azure Test Runner-Client (ATR) verwenden, um manuelle Tests für Desktopanwendungen auszuführen. Dadurch können Sie von Microsoft Test Manager zu Azure Test Plans wechseln. Weitere Informationen finden Sie hier in unserer Anleitung. Mithilfe des ATR-Clients können Sie Ihre manuellen Tests ausführen und die Testergebnisse für jeden Testschritt aufzeichnen. Außerdem verfügen Sie über Datensammlungsfunktionen wie Screenshot, Bildaktionsprotokoll und Audiovideoaufzeichnung. Wenn beim Testen ein Problem auftritt, verwenden Sie Test Runner, um einen Fehler mit Testschritten, Screenshots und Kommentaren zu erstellen, die automatisch in den Fehler eingeschlossen werden.
ATR erfordert einen einmaligen Download und die Installation des Runners. Wählen Sie Ausführen für Desktopanwendung aus, wie unten gezeigt.
Azure Artifacts
Öffentliche Vorschau von Pipelineartefakten
Wir veröffentlichen eine öffentliche Vorschau von Pipelineartefakten, einem neuen hochgradig skalierbaren Artefakttyp, der für die Verwendung mit Azure Pipelines entwickelt wurde. Pipeline Artifacts basiert auf derselben Technologie, die auch vom kürzlich angekündigten Feature "Universelle Pakete " verwendet wird, und kann die Zeit zum Speichern von Buildausgaben für große Builds der Unternehmensklasse erheblich reduzieren.
Wiki
Veröffentlichen von Code als Wiki mit Den Berechtigungen "Mitwirken"
Zuvor konnten nur Benutzer mit der Berechtigung Repository erstellen für ein Git-Repository Code als Wiki veröffentlichen. Dies machte die Repositoryadministratoren oder Ersteller zu einem Engpass für alle Anforderungen, Markdown-Dateien zu veröffentlichen, die in Git-Repositorys als Wikis gehostet wurden. Jetzt können Sie Code als Wiki veröffentlichen , wenn Sie nur über die Berechtigung Mitwirken für das Coderepository verfügen.
Verwaltung
PATs erzwingen CAP
Im Februar 2017 haben wir die Unterstützung für die Azure Active Directory-Richtlinie für bedingten Zugriff (CAP) angekündigt, aber es gab eine Einschränkung, dass alternative Authentifizierungsmechanismen, z. B. persönliche Zugriffstoken, keine CAP erzwingen würden. Wir freuen uns, ihnen mitteilen zu können, dass wir diese Lücke geschlossen haben und Azure DevOps nun CAP-IP-Fencing-Richtlinien berücksichtigen wird, wenn PATs, SSH-Schlüssel, alternative Authentifizierungsanmeldeinformationen und OAuth verwendet werden. Administratoren müssen nichts tun, um dieses Feature zu nutzen. Sie wird automatisch auf alle vorhandenen Richtlinien angewendet.
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, um sie selbst auszuprobieren.
Senden von Feedback
Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Feedbackmenü, um ein Problem zu melden oder einen Vorschlag zu machen.
Sie können auch Rat und Ihre Fragen von der Community auf Stack Overflow beantworten lassen.
Vielen Dank,
Aaron Bjork