Team Foundation Server 2018: Anmerkungen zu dieser Version

Last Update: 22.11.2017

In diesem Artikel erhalten Sie Informationen zu dem neuesten Release für Team Foundation Server 2018. Klicken Sie zum Herunterladen auf die Schaltfläche.

Download the latest version of Team Foundation Server

Weitere Informationen zu Team Foundation Server 2018 finden Sie auf der Seite Team Foundation Server Requirements and Compatibility (Team Foundation Server: Anforderungen und Kompatibilität).


Neues in TFS 2018: Video


Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden und es über das Entwicklercommunity-Portal nachverfolgen und Ratschläge zu Stack Overflow (Stapelüberlauf) erhalten. Teilen Sie uns Ihre Ideen zu Themen, die Sie durch uns priorisiert sehen möchten, wie immer unter UserVoice mit. Dort können Sie Ihre Idee hinzufügen oder bestehende Ideen bewerten.


Veröffentlichungsdatum: 15. November 2017

Zusammenfassung: Team Foundation Server 2018-Updates

Wir haben Team Foundation Server 2018 viele neue Werte hinzugefügt. Einige der Highlights sind unter anderem:

In dieser Version nicht mehr vorhandene Features


Details: Neues in diesem Release

Arbeitselementverfolgung

Assistent zur Projekterstellung im Web

Wir haben das Erstellen eines Teamprojekts über den Webzugriff verbessert. Ihnen wird nun der Großteil der Features geboten, die Ihnen zum Erstellen eines Teamprojekts im Visual Studio-Client zur Verfügung stehen. Der Vorteil beim Verwenden der Weboberfläche ist, dass Sie keine passende Version von Visual Studio benötigen. Der Unterschied zwischen der Verwendung von Visual Studio und der Webversion ist der, dass die Webversion Ihre Berichte nicht in SSRS bereitstellt. Wenn Sie die Webversion zum Erstellen von Teamprojekten verwenden, können Sie den Befehl tfsconfig auf der Anwendungsebene verwenden, um SSRS-Berichte bereitzustellen oder zu aktualisieren. Weitere Informationen finden Sie unter Add project reports (Hinzufügen von Projektberichten).

Prozessvorlagen-Manager im Web

Ab TFS 2018 können Sie den Webzugriff verwenden, um Ihre Prozessvorlagen hochzuladen. Das Verwenden der Weboberfläche ist wesentlich einfacher, da Sie nicht die richtige Version von Visual Studio installieren müssen, um mit Ihren Prozessvorlagen zu interagieren. In Visual Studio 2017 Update 4 und früher wird das Dialogfeld Prozessvorlagen-Manager immer noch angezeigt. Wir empfehlen dennoch das Verwenden der Weboberfläche. In Visual Studio 2017 Update 5 und höher werden Sie automatisch zum Webzugriff weitergeleitet.

Anpassen des Headers des Arbeitselementformulars

Sie können nun den Kopfbereich des Arbeitselementformulars anpassen, indem Sie die bestehenden Steuerelemente ersetzen oder Steuerelemente verbergen, die für Ihren Prozess nicht relevant sind. Dadurch wird das Ersetzen des Bereichspfads mit einem benutzerdefinierten Teamfeld ermöglicht, wobei Iteration verborgen wird, wenn Ihre Teams sich auf Kanban konzentrieren, sowie das Ersetzen des Felds „Grund“ durch ein benutzerdefiniertes Feld. Das Feld „Status“ kann nicht verborgen oder ersetzt werden.

Weitere Informationen finden Sie in der Dokumentation zu Weblayout und Steuerelementen.

Mobiles Arbeitselementformular

Wir bieten eine umfassende ganzheitliche Oberfläche, die ein optimiertes Erscheinungsbild und Verhalten für Arbeitsaufgaben (Abbildung 1) vorsieht. Es wird eine einfache Möglichkeit geboten, über Ihr Telefon mit Elementen zu interagieren, die Ihnen zugewiesen sind, denen Sie folgen, die Sie besucht oder kürzlich bearbeitet haben.

Mobile work item query

(Abbildung 1) Mobile Arbeitselementabfrage

Zusammen mit dem ansprechenden Erscheinungsbild wird auch eine optimierte Steuerung für alle Feldtypen unterstützt (Abbildung 2).

Mobile work item form

(Abbildung 2) Mobiles Arbeitselementformular

Mit der neuen mobilen Navigation (Abbildung 3) können die Benutzer alle anderen Teile von TFS erreichen, die für Mobilgeräte konzipiert sind und zur vollständigen Desktop-Website zurückkehren, wenn sie mit anderen Hubs interagieren müssen.

Mobile navigation

(Abbildung 3) Mobile Navigation

Filtern von Backlogs, Kanban-Boards, Sprints und Abfragen

Alle unsere Raster zum Nachverfolgen von Arbeitselementen (Abfragen, Backlogs, Kanban-Boards, Sprints-Backlogs und Testfallverwaltung) verwenden nun unsere allgemeine, konsistente Filterkomponente (Abbildung 4). Zusätzlich zum Anwenden eines Schlüsselwortfilters für die angezeigten Spalten und dem Auswählen von Tags können Sie auch nach Arbeitselementtypen, -zuständen und -zuweisungen filtern, um schnell zu den Arbeitselementen zu gelangen, die Sie suchen.

Filtering on query

(Abbildung 4) Filtern von Abfragen

Erweitern, um leere Felder auf einer Kanban-Karte anzuzeigen

Heute haben Sie die Möglichkeit, zusätzliche Felder zu einer Karte hinzuzufügen und dann in den Einstellungen leere Felder zu verbergen (Abbildung 5), um unnötige Elemente vom Board zu entfernen. Der Nachteil dieses Features war, dass ein Feld, sobald es verborgen wurde, nur noch aktualisiert werden konnte, indem das Arbeitselementformular geöffnet wurde. Mit der neu verfügbaren Option „Erweitern“ auf den Kanban-Karten können Sie nun vom Verbergen leerer Felder auf dem Board profitieren und dennoch ein bestimmtes Feld auf der Karte mit einem Klick aktualisieren. Zeigen Sie einfach auf die Karte und suchen Sie unten auf der Karte das Chevron, das nach unten zeigt, um das verborgene Feld zu aktualisieren.

Hidden field

(Abbildung 5) Ausgeblendetes Feld auf der Kanban-Karte

Klicken Sie unten auf der Karte auf das Chevron, das nach unten zeigt, um das Feld zu aktualisieren (Abbildung 6).

Update hidden field

(Abbildung 6) Aktualisieren des ausgeblendeten Felds auf der Kanban-Karte

Erweiterungen zum Blockieren des Speicherns von Arbeitselementen

Die benutzerdefinierten Steuerelemente, Gruppen und Seiten von Arbeitselementformularen können nun das Speichern von Arbeitselementen blockieren, um Daten zu überprüfen und sicherzustellen, dass der Benutzer alle erforderlichen Informationen ausfüllt, bevor er das Arbeitselementformular speichert.

Inline-Hinzufügen bei Lieferplänen

Neue Ideen für Features können jederzeit eingehen, darum wurde das direkte Hinzufügen neuer Features zu Ihren Lieferplänen vereinfacht (Abbildung 7). Klicken Sie auf die Schaltfläche Neues Element, die verfügbar ist, wenn Sie darauf zeigen, geben Sie einen Namen ein, und drücken Sie die EINGABETASTE. Ein neues Feature wird mit dem erwarteten Bereichs- und Iterationspfad erstellt.

Inline add on delivery plans

(Abbildung 7) Inline-Hinzufügen von Lieferplänen

Versionskontrolle

Forks

TFS 2018 fügt Unterstützung für Git-Forks hinzu (Abbildung 8). Ein Fork ist eine serverseitige Kopie eines Repositorys. Durch das Verwenden von Forks können Sie einer Vielzahl von Personen ermöglichen, etwas zu Ihrem Repository beizutragen, ohne diesen direkten Zugriff zum Commit gewähren zu müssen. Stattdessen übergeben sie ihre Arbeit an ihren eigenen Fork des Repositorys. Dadurch wird es Ihnen ermöglicht, deren Änderungen in einem Pull Request zu überprüfen, bevor Sie diese Änderungen im zentralen Repository annehmen.

Git forks

(Abbildung 8) Git-Forks

GVFS

Das virtuelle Git-Dateisystem (Git Virtual File System, GVFS) wird nicht unterstützt. Durch GVFS wird es Git-Repositorys ermöglicht, Millionen von Dateien durch Virtualisieren und Optimieren der Git-Funktionsweise auf dem Dateisystem zu skalieren.

Erstellen Sie im Web einen Ordner in einem Repository.

Sie können nun über das Web Ordner in Ihren Git- und TFVC-Repositorys erstellen (Abbildung 9). Dadurch wird die Erweiterung Ordnerverwaltung ersetzt, die nun deaktiviert wird.

Klicken Sie zum Erstellen eines Ordners in der Befehlsleiste oder im Kontextmenü auf Neu > Ordner:

New folder option

(Abbildung 9) Neue Ordneroption

In TFVC geben Sie einen Ordnernamen an und checken diesen dann ein. In Git sind leere Ordner nicht zulässig, darum müssen Sie einen Dateinamen angeben, die Datei optional bearbeiten und dann einen Commit für diese ausführen.

Zusätzlich wurde in Git das Dialogfeld Neue Datei (Abbildung 10) verbessert, um Schrägstriche zum Erstellen von Unterordnern zu akzeptieren.

New file dialog

(Abbildung 10) Dialogfeld „Neue Datei“

Minikarte für Dateien

Sie können beim Anzeigen oder Bearbeiten nun die Minikarte einer Datei anzeigen, um einen schnellen Überblick über den Code zu erhalten (Abbildung 11). Öffnen Sie zum Aktivieren der Minikarte die Befehlspalette (F1 oder Rechtsklick), und wählen Sie Toggle Minimap (Minikarte umschalten) aus.

File minimap

(Abbildung 11) Minikarte für Dateien

Zuordnen von Klammern

Beim Bearbeiten oder Anzeigen einer Datei gibt es auf der linken Seite nun Führungslinien, um das Zuordnen Ihrer Klammern zu erleichtern (Abbildung 12).

Bracket matching

(Abbildung 12) Zuordnen von Klammern

Umschalten von Leerräumen

Sie können Leerräume nun ein- oder ausschalten, wenn Sie eine Datei anzeigen oder bearbeiten. Wir entwickeln gerade ein Feature, das es Ihnen ermöglichen wird, Leerräume beim Unterscheiden umzuschalten. Öffnen Sie zum Anzeigen der Leerräume (Abbildung 13) die Befehlspalette (F1 oder Rechtsklick), und wählen Sie Toggle White Space (Leerräume umschalten) aus. Dadurch können Sie zwischen Leerräumen und Tabstopps unterscheiden.

Toggle white space

(Abbildung 13) Umschalten von Leerräumen

Einstellung zum Deaktivieren der Webbearbeitung für TFVC-Repositorys

Teams, die TFVC häufig verwenden, verwenden in Visual Studio häufig Eincheckrichtlinien, um die Codequalität zu gewährleisten. Da die Eincheckrichtlinien jedoch nur auf dem Client durchgesetzt werden, unterliegt Code, der im Web bearbeitet wird, nicht denselben Richtlinien.

Deshalb haben einige Benutzer nach einer Möglichkeit gebeten, die Webbearbeitung zu deaktivieren, um den Code vor Änderungen zu schützen, die die Eincheckrichtlinien umgehen. Wir haben Ihnen eine Möglichkeit bereitgestellt, die Webbearbeitung (Hinzufügen, Löschen, Umbenennen und Bearbeiten) für TFVC auf Projekt- bzw. Repositoryebene zu deaktivieren.

Navigieren Sie zum Deaktivieren der Webbearbeitung von der Seite Dateien zu Einstellungen und dann zu Versionskontrolle (Abbildung 14). Klicken Sie auf das TFVC-Repository in der Struktur zum Pivot „Optionen“, und deaktivieren Sie Enable web-editing for this TFVC repository (Webbearbeitung für dieses TFVC-Repository aktivieren). Standardmäßig ist die Webbearbeitung aktiviert.

Hinweis

Dies hat keine Auswirkungen auf das Bearbeiten der Infodatei auf der Seite „Projektübersicht“.

Turn off web editing

(Abbildung 14) Deaktivieren der Webbearbeitung

Wenn Sie versuchen, eine Webbearbeitung in einem Projekt durchzuführen, für das die Webbearbeitung deaktiviert ist, werden Sie benachrichtigt, dass die Webbearbeitung nicht zugelassen ist (Abbildung 15).

Web editing not allowed dialog

(Abbildung 15) Dialogfeld „Webbearbeitung unzulässig“

Dies wurde aufgrund eines verwandten Vorschlags entwickelt.

Identifizieren von veralteten Branches

Halten Sie Ihr Repository übersichtlich, indem Sie Branches löschen, die sie nicht länger benötigen. Dadurch wird es Teams ermöglicht, Branches zu finden, die für sie relevant sind und Favoriten in der richtigen Granularität festzulegen. Wenn Ihr Repository jedoch viele Branches enthält, kann es schwierig sein, herauszufinden, welche inaktiv sind und gelöscht werden können. Wir haben es nun einfacher gestaltet, „veraltete“ Branches (Branches, die auf Commits zeigen, die älter als 3 Monate sind) zu identifizieren. Navigieren Sie zum Pivot Veraltet auf der Seite Branches, um Ihre veralteten Branches anzuzeigen (Abbildung 16).

Stale branches

(Abbildung 16) Veraltete Branches

Suche nach einem gelöschten Branch und Neuerstellung desselben

Wenn ein Branch versehentlich vom Server gelöscht wird, kann es schwierig sein, herauszufinden, was mit ihm geschehen ist. Nun können Sie nach einem gelöschten Branch suchen und anzeigen lassen, wer ihn wann gelöscht hat. Dann können Sie ihn bei Bedarf neu erstellen.

Geben Sie den vollständigen Namen des Branchs in das Suchfeld für Branches ein, um nach einem gelöschten Branch zu suchen. Es werden alle vorhandenen Branches zurückgegeben, die dem Text entsprechen. Ihnen wird auch die Option angezeigt, nach einer genauen Übereinstimmung in der Liste der gelöschten Branches zu suchen. Klicken Sie auf den Link, um gelöschte Branches zu suchen (Abbildung 17).

Search for deleted branches

(Abbildung 17) Suchen nach gelöschten Branches

Wenn eine Übereinstimmung gefunden wurde, wird Ihnen angezeigt, wer diese wann gelöscht hat. Sie können den Branch auch wiederherstellen (Abbildung 18).

Restore deleted branches

(Abbildung 18) Wiederherstellen von gelöschten Branches

Das Wiederherstellen des Branchs erstellt diesen auf dem Commit neu, auf den er zuletzt gezeigt hat. Es werden jedoch keine Richtlinien und Berechtigungen wiederhergestellt.

Suche nach einem Commit in Branches, die mit einem Präfix beginnen

Wenn Ihnen eine Branchstruktur in hierarchischer Form vorliegt, bei der allen Branches ein Text vorangestellt ist, wird dieses Feature Ihnen dabei helfen, einen Commit innerhalb aller Branches zu finden, die mit diesem Präfixtext beginnen. Wenn Sie beispielsweise überprüfen möchten, ob ein Commit in allen Branches vorhanden ist, denen „dev“ vorangestellt ist, geben Sie einfach „dev“ in das Suchfeld ein, und klicken Sie auf Search in branches starting with „dev“ (Suche in Branches, die mit „dev“ beginnen) (Abbildung 19).

Search for a commit

(Abbildung 19) Suchen nach einem Commit

Umfangreichere Legende der Pull Requests auf der Seite „Commit-Details“

Die Legende der Pull Requests auf der Seite „Commit-Details“ zeigt weitere wichtige Informationen an, die Ihnen bei der Diagnose helfen (Abbildung 20). Nun wird in der Legende auch der erste Pull Request angezeigt, der den Commit in sämtliche Branches eingeführt hat und der Pull Request, der der Standardbranches zugeordnet ist.

Pull request callout

(Abbildung 20) Legende der Pull Requests

Filtern der Strukturansicht in Code

Sie müssen nun nicht mehr durch alle Dateien scrollen, die ein Commit modifiziert haben könnte, nur um zu Ihren Dateien zu gelangen. Die Strukturansicht auf den Seiten „Commit-Details“, „Pull Requests“, „Shelvesetdetails“ und „Changesetdetails“ unterstützt nun das Filtern nach Dateien und Ordnern. Dabei handelt es sich um einen intelligenten Filter, der untergeordnete Dateien eines Ordners anzeigt, wenn Sie nach Ordnername filtern. Außerdem wird eine reduzierte Strukturansicht einer Datei angezeigt, um die Dateihierarchie anzuzeigen, wenn Sie nach Dateiname filtern.

Suchen einer gefilterten Datei oder eines gefilterten Ordners in der Commitstruktur (Abbildung 21) und (Abbildung 22):

Find a file or folder

(Abbildung 21) Suchen von Dateien oder Ordnern

Filtered view

(Abbildung 22) Gefilterte Ansicht in der Commitstruktur

Die Seite „Branchaktualisierungen“ heißt nun „Pushes“

Die Seite Branchaktualisierungen ist enorm wichtig. Sie war jedoch als Pivot unter dem Hub Verlauf verborgen. Jetzt ist die Seite „Branchaktualisierungen“ als Hub mit dem Namen Pushes (Abbildung 23) unter Code sichtbar, zusammen mit Commits, Branches, Tags und Pull Requests. Die neue URL für die Seite „Push-Vorgänge“ lautet: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Die alten URLs werden weiterhin funktionieren.

Pushes page

(Abbildung 23) Seite für Pushvorgänge

Gleichzeitig wurde der Hub Verlauf in Commits umbenannt (Abbildung 24), da der Hub nur Commits anzeigt. Wir haben Feedback erhalten, dass die Benutzer es als schwierig empfunden haben, auf Commits bezogene Probleme zu beheben, da die Ansicht der Commitliste nur eine detaillierte Zeitangabe angezeigt hat, wenn darauf gezeigt wurde. Jetzt zeigt die Ansicht der Commitliste auf Ihrer Instanz Datum und Zeit im Format „dd/mm/yy hh:mm“ an. Die neue URL für die Seite „Commits“ lautet: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. Die alten URLs werden weiterhin funktionieren.

Commits page

(Abbildung 24) Seite für Commits

Beibehalten des Dateinamens beim Verschieben von „Dateien“ nach „Commits“

Wir haben Feedback von Benutzern erhalten, dass beim Filtern des Verzeichnisses einer bestimmten Datei im Pivot Dateien des Hubs Code und beim späteren Wechsel zum Pivot Verlauf der Dateiname nicht beibehalten wird, wenn der Commit mehr als 1.000 Dateien geändert hat. Dadurch mussten die Benutzer mehr Dateien laden und mehr Inhalte filtern, um Dateien zu suchen, wodurch die Produktivität beeinträchtigt wurde. Entwickler arbeiten normalerweise im selben Verzeichnis und möchten die Verzeichnisse beibehalten, in denen sie arbeiten, wenn sie Änderungen verfolgen. Nun behalten wir den Dateinamen bei, wenn Sie zwischen den Pivots des Hubs Code wechseln, unabhängig von der Anzahl der Dateien, die Sie in einem Commit geändert haben. Das bedeutet, dass Sie nicht auf Load More (Weitere laden) klicken müssen, um die gewünschte Datei zu suchen.

Anzeigen von Git-Tags

Sie können alle Tags in Ihrem Repository auf der Seite Tags anzeigen lassen (Abbildung 25). Wenn Sie alle Ihre Tags als Releases verwalten, kann ein Benutzer die Seite „Tags“ besuchen, um alle Produktversionen aus der Vogelperspektive zu betrachten.

View Git tags

(Abbildung 25) Anzeigen von Git-Tags

Sie können mühelos zwischen einem einfachen und einem kommentierten Tag unterscheiden. Kommentierte Tags zeigen den Tagger und das Erstellungsdatum zusammen mit dem zugeordneten Commit an, während einfache Tags nur die Commit-Informationen anzeigen.

Löschen von Git-Tags

Es kann vorkommen, dass Sie einen Tag aus Ihrem Remoterepository entfernen sollten. Der Grund dafür kann ein Tippfehler im Tagnamen sein, oder dass Sie den falschen Commit markiert haben. Sie können Tags einfach aus der Webbenutzeroberfläche löschen, indem Sie auf das Kontextmenü eines Tags auf der Seite Tags und dann auf Tag löschen klicken (Abbildung 26).

Warnung

Das Löschen von Tags von Remoterepositorys sollte mit Bedacht erfolgen.

Delete git tags

(Abbildung 26) Löschen von Git-Tags

Filtern von Git-Tags

Bei alten Repositorys kann die Anzahl der Tags mit der Zeit erheblich ansteigen. Es gibt auch Repositorys, bei denen die Tags in Hierarchien erstellt wurden, was die Suche nach Tags erschweren kann.

Wenn Sie das Tag, nach dem Sie suchen, nicht auf der Seite Tags finden können, können Sie einfach nach dem Tagnamen suchen, indem Sie den Filter oben auf der Seite Tags verwenden (Abbildung 27).

Filter Git tags

(Abbildung 27) Filtern von Git-Tags

Sicherheit von Git-Tags

Sie können Benutzern des Repositorys nun granulare Berechtigungen erteilen, um Tags zu verwalten. Sie können Benutzern die Berechtigung erteilen, Tags zu löschen oder Tags von dieser Schnittstelle aus zu verwalten (Abbildung 28).

Git tag security

(Abbildung 28) Sicherheit von Git-Tags

Weitere Informationen zu Git-Tags finden Sie im Microsoft DevOps-Blog.

Automatisches Abschließen von Arbeitselementen, wenn Pull Requests abgeschlossen werden

Beim Verknüpfen von Arbeitselementen mit Ihren PRs (Pull Requests) ist es nun einfacher geworden, alles auf dem neuesten Stand zu halten. Wenn Sie nun einen PR abschließen, besteht die Möglichkeit, automatisch die verknüpften Arbeitselemente abzuschließen, nachdem der PR erfolgreich zusammengeführt wurde (Abbildung 29). Wenn Sie Richtlinien verwenden und die PRs auf „automatische Vervollständigung“ festgelegt haben, wird Ihnen dieselbe Option angezeigt. Sie müssen nun nicht mehr daran denken, die Arbeitselemente erneut aufzurufen, um deren Status zu aktualisieren, sobald der PR abgeschlossen wurde. Dies wird automatisch für Sie ausgeführt.

Complete linked work items

(Abbildung 29) Vollständig verknüpfte Arbeitselemente

Zurücksetzen von Stimmen für Push bzw. neue Iterationen

Teams, die sich für einen strikteren Genehmigungsworkflow in PRs entscheiden, können nun Stimmen zurücksetzen, wenn Änderungen mittels Push durchgeführt werden (Abbildung 30). Die neue Einstellung ist eine Option in der Richtlinie und benötigt eine Mindestanzahl von Reviewern.

Reset votes setting

(Abbildung 30) Zurücksetzen der Einstellung für Stimmen

Wenn diese Option festgelegt ist, werden alle Stimmen von allen Reviewern immer dann zurückgesetzt, wenn der Quellbranch des PR aktualisiert wird. Die Zeitachse des PR zeichnet einen Eintrag immer dann auf, wenn die Stimmen als Ergebnis dieser Option zurückgesetzt werden (Abbildung 31).

Reset votes in timeline

(Abbildung 31) Zurücksetzen von Stimmen in der Zeitachse

Filtern der Pull Request-Struktur nach Dateiname

Das Suchen einer bestimmten Datei in einem Pull Request ist einfacher als je zuvor. Das neue Filterfeld in der Ansicht Dateien ermöglicht es Benutzern, die Dateiliste in eine Strukturansicht zu filtern (Abbildung 32).

Find file or folder in pull request

(Abbildung 32) Suchen von Dateien oder Ordnern in Pull Requests

Der Filter vergleicht jeden Teil des Dateipfads im Pull Request, sodass Sie nach Ordnernamen, partiellen Pfaden, Dateinamen oder Erweiterungen suchen können (Abbildung 33).

Find results

(Abbildung 33) Suchen von Ergebnissen

Weitere Filteroptionen für Pull Request-Kommentare

Die Kommentare in der Übersicht der Pull Requests und in der Dateiansicht verfügen nun über dieselben Optionen (Abbildung 34). Sie können auch nur nach den Diskussionen filtern, an denen Sie teilgenommen haben.

PR comment filtering

(Abbildung 34) Filtern von PR-Kommentaren

Anzeigen der ursprünglichen Unterschiede von Code-Kommentaren in den Pull Request-Details

In manchen Fällen kann es schwierig sein, den Sinn eines PR-Kommentars nachzuvollziehen, nachdem der Code, auf den er verweist, verändert wurde (häufig, wenn eine angeforderte Änderung durchgeführt wurde) (Abbildung 35).

View original diff

(Abbildung 35) Anzeigen der ursprünglichen Unterschiede

Wenn dies der Fall ist, wird Ihnen nun ein Infoanzeiger mit einer Updatenummer angezeigt, auf den Sie klicken können, um anzuzeigen, wie der Code zu dem Zeitpunkt ausgesehen hat, als der Kommentar ursprünglich erstellt wurde (Abbildung 36).

Update badge

(Abbildung 36) Aktualisieren von Badges

Reduzierbare Pull Request-Kommentare

Das Überprüfen des Codes ist ein kritischer Teil der Pull Requests, sodass wir neue Features hinzugefügt haben, die es den Reviewern erleichtern, sich auf den Code zu konzentrieren. Codereviewer können Kommentare einfach ausblenden, damit sie beim ersten Überprüfen von neuem Code nicht mehr sichtbar sind (Abbildung 37).

Hide comments

(Abbildung 37) Ausblenden von Kommentaren

Durch das Ausblenden von Kommentaren (Abbildung 38) werden diese in der Strukturansicht nicht mehr angezeigt, und die Kommentarthreads in der Dateiansicht werden reduziert:

Collapsed comments

(Abbildung 38) Reduzierte Kommentare

Wenn die Kommentare reduziert wurden, können sie leicht wieder erweitert werden, indem Sie auf das Symbol am Rand klicken. Mit einem weiteren Klick werden sie wieder reduziert. QuickInfos (Abbildung 39) erleichtern es, einen Kommentar einzusehen, ohne den gesamten Thread anzeigen zu lassen.

Collapsed comment tooltip

(Abbildung 39) QuickInfo für reduzierte Kommentare

Aufgabenlisten in den Beschreibungen und Kommentaren von Pull Requests

Wenn Sie eine PR vorbereiten oder kommentieren, gibt es häufig eine Liste von Aufgaben, denen Sie nachgehen möchten, aber letztendlich bearbeiten Sie nur den Text oder fügen mehrere Kommentare hinzu. Einfache Aufgabenlisten sind eine gute Möglichkeit, um den Fortschritt einer Liste mit anstehenden Aufgaben entweder als PR-Ersteller oder PR-Reviewer in der Beschreibung oder in einem einzigen, konsolidierten Kommentar nachzuverfolgen. Klicken Sie auf die Symbolleiste „Markdown“, um damit zu beginnen, oder wenden Sie das Format auf den ausgewählten Text an (Abbildung 40).

Task list toolbar

(Abbildung 40) Symbolleiste der Aufgabenliste

Sobald Sie eine Aufgabenliste hinzugefügt haben (Abbildung 41), können Sie einfach die Kontrollkästchen anklicken, um Elemente als abgeschlossen zu markieren. Diese werden im Kommentar als [ ] ausgedrückt und gespeichert und im Markdown als [x]. Weitere Informationen finden Sie im Markdown guidance (Markdown-Leitfaden).

Task list

(Abbildung 41) Aufgabenliste

Möglichkeit, Kommentare in Pull Requests mit „Gefällt mir“ zu markieren

Zeigen Sie Ihre Unterstützung für einen PR-Kommentar, indem Sie auf die Schaltfläche Gefällt mir klicken (Abbildung 42). Sie können eine Liste aller Personen anzeigen lassen, die den Kommentar mit „Gefällt mir“ markiert haben, indem Sie auf die Schaltfläche zeigen.

Like pull request comments

(Abbildung 42) Pull Request-Kommentare mit „Gefällt mir“ markieren

Verbesserter Workflow beim Genehmigen mit Vorschlägen

Durch das Verwenden der Option Automatische Vervollständigung (Abbildung 43) mit Pull Requests können Sie zwar leicht Ihre Produktivität steigern, jedoch sollten dadurch keine aktiven Diskussionen mit Codereviewern vorzeitig beendet werden. Zur besseren Nutzung dieser Diskussionen wird nun die Stimme Mit Vorschlägen genehmigen angezeigt, wenn ein Pull Request auf „automatische Vervollständigung“ festgelegt ist. Der Benutzer hat die Option, die automatische Vervollständigung zu beenden, sodass dessen Feedback gelesen werden kann oder die automatische Vervollständigung beizubehalten. Dadurch wird ermöglicht, dass der Pull Request automatisch vervollständigt wird, wenn die Richtlinien erfüllt sind.

Cancel auto-complete dialog

(Abbildung 43) Abbrechen des Dialogfelds „Automatisch vervollständigen“

Unterstützung für das Filtern von Pfaden für Git-Benachrichtigungen

Statt Benachrichtigungen für alle Ordner in einem Repository zu erhalten, können Sie nun auswählen, dass Sie nur dann benachrichtigt werden, wenn Teammitglieder in den für Sie relevanten Ordnern Pull Requests erstellen oder Code mithilfe von Push übertragen. Wenn Sie benutzerdefinierte Git-Pushes oder Git-Pull Requests für E-Mail-Benachrichtigungsabonnements erstellen, wird Ihnen eine neue Option angezeigt, durch die Sie diese Benachrichtigungen nach Ordnerpfaden filtern können (Abbildung 44).

Path filtering for notifications

(Abbildung 44) Filtern von Pfaden für Benachrichtigung

Aktualisierte E-Mail-Vorlagen für Pull Request-Workflows

Die E-Mail-Benachrichtigungen für Pull Requests wurden aktualisiert, um diese klar, präzise und umsetzbar zu gestalten (Abbildung 45). Die Betreffzeile beginnt mit dem Titel des PR und sekundären Informationen, wie zum Beispiel dem Namen des Repository, während die ID an dass Ende gestellt wird. Der Name des Autors wurde dem Betreff hinzugefügt, damit das Anwenden von Regeln und Filtern basierend auf der Person, die den PR erstellt hat, einfacher gestaltet werden kann.

Für den Text der E-Mail-Warnungen gibt es eine aktualisierte Vorlage, die zunächst zusammenfasst, warum die Warnung gesendet wurde, gefolgt von kritischen Metadaten (Titel, Verzweigungsnamen und Beschreibung) und einer Hauptschaltfläche für Handlungsaufforderungen. Zusätzliche Einzelheiten wie der Reviewer, die Dateien und die Commits sind weiter unten in der E-Mail enthalten.

Improved email template

(Abbildung 45) Verbesserte E-Mail-Vorlage

Bei den meisten Benachrichtigungen beinhaltet die Handlungsaufforderung (Abbildung 46) das Anzeigen des Pull Request im Web. Wenn Sie jedoch über einen bestimmten Kommentar benachrichtigt werden, wird die Handlungsaufforderung einen direkten mit diesem Kommentar verknüpft sein, sodass Sie den Code und den Konversationsverlauf leicht finden und einen Kontext herstellen können.

Email call-to-action

(Abbildung 46) Handlungsaufforderung per E-Mail

Aktualisierte E-Mail-Vorlagen für Pushbenachrichtigungen

Pushbenachrichtigungen wurden aktualisiert, um den neuen, optimierten E-Mail-Vorlagen zu entsprechen, die eindeutig, präzise und umsetzbar sind (Abbildung 47). Die Betreffzeile unterstützt Sie beim klaren Unterscheiden von Push-E-Mails sowie beim Identifizieren des Branches, des Repositorys und des Autors sowie beim Zusammenfassen der Anzahl von Commits, die im Push enthalten sind. Diese Änderungen erleichtern auch das Erstellen von Regeln und Filtern, um das Verwalten dieser E-Mail-Benachrichtigungen zu erleichtern.

Der Text der E-Mail ist identisch mit dem anderer E-Mails und hebt hervor, warum die E-Mail gesendet wurde, wer die Aktion initiiert hat und was genau passiert ist. Als Besonderheit sind bei Push-Warnungen Details zum Repository und Branch sowie zu den Dateien und Commits enthalten, die den Empfänger über den Umfang der Änderungen informieren. Die wichtigste Handlungsaufforderung für Push-Warnungen ist Push anzeigen. Dadurch wird die Anzeige für den Push geöffnet, der die Warnung generiert hat.

Push template

(Abbildung 47) Push-Vorlage

Wiki

Jedes Projekt unterstützt nun sein eigenes Wiki (Abbildung 48). Nun können Sie ganz einfach Seiten schreiben, die Ihren Teammitgliedern dabei helfen, Ihr Projekt nachzuvollziehen, zu verwenden und dazu beizutragen.

Wiki page

(Abbildung 48) PR-Wiki-Seite

Zu den wichtigsten Features des neuen Wiki gehören:

  • Ein vereinfachtes Bearbeiten mithilfe der markdown syntax (Markdown-Syntax).
  • Auf der neuen Seite können Sie nun einen Titel eingeben und Inhalt hinzufügen. Abbildung 49

Title wiki

(Abbildung 49) PR für Titel-Wiki

  • Unterstützung für HTML-Tags in Markdown (Abbildung 50)

Wiki HTML tags

(Abbildung 50) PR-Wiki-HTML-Tags

  • Einfaches Ändern der Bildgröße im Markdown-Ordner (Abbildung 51)

Image resize

(Abbildung 51) Ändern der PR-Bildgröße

  • Ein leistungsfähiger Bereich zur Seitenverwaltung, der es ermöglicht, Seiten neu anzuordnen, neu zuzuordnen und zu verwalten.
  • Filtern von Seiten nach Titel für große Wikis (Abbildung 52)

Wiki menu

(Abbildung 52) PR-Wiki-Menü

Weitere Informationen finden Sie unter getting started with Wiki (Erste Schritte mit dem Wiki).

  • Wenn Sie das Wiki häufiger verwenden, besteht die Möglichkeit, dass Sie unbeabsichtigte Änderungen speichern. Sie können die Überarbeitung einer Wiki-Seite nun rückgängig machen, indem Sie zu den Überarbeitungsdetails navigieren und auf die Schaltfläche Wiederherstellen klicken (Abbildung 53).

Wiki revert button

(Abbildung 53) PR-Wiki-Schaltfläche „Wiederherstellen“

Wir haben bei der Wiki-Erstellung ein Muster bemerkt, bei dem ein Inhaltsverzeichnis auf einer Wiki-Seite nicht vorhandene Links (Abbildung 54) enthielt. Benutzer würden auf diese Links klicken, um zu versuchen, eine tatsächliche Seite zu erstellen. Früher haben wir dieses Szenario so behandelt, dass eine Warnung angezeigt wurde, die darauf hinwies, dass der Link fehlerhaft war oder die Seite nicht existierte. Mittlerweile behandeln wir dies als das gängige Szenario für Wiki, indem wir Ihnen stattdessen ermöglichen, diese Seiten zu erstellen.

Create wiki page

(Abbildung 54) PR-Seite „Wiki erstellen“

Deep Linking von Wiki-Seiten

Wiki unterstützt nun Deep Linking für Abschnitte innerhalb einer Seite oder seitenübergreifend. Beim Erstellen eines Inhaltsverzeichnisses ist dies besonders nützlich. Sie können auf der gleichen oder auf einer anderen Seite auf eine Überschrift verweisen, indem Sie folgende Syntax verwenden:

  • Gleiche Seite: [text to display](#section-name)
  • Andere Seite: [text to display](/page-name#section-name)

Die Wiki extension (Wiki-Erweiterung) auf dem Marketplace ist nun veraltet. Wenn Sie bereits Wiki-Erweiterungen nutzen, können Sie Ihre Wiki-Seiten zum neuen Wiki migrieren, indem Sie dieses migration tool (Migrationstool) verwenden. Weitere Informationen finden Sie unter migrate your existing wiki pages to the new Wiki (Migrieren Ihrer bestehenden Wiki-Seiten zum neuen Wiki).

Paketverwaltung

Updates zur Benutzerfreundlichkeit für die Paketverwaltung

Paket-URLs funktionieren nun auch mit dem Paketnamen und der Paketversion statt nur mit GUIDs. Dadurch wird es einfacher, Paket-URLs selbst zu erstellen (Abbildung 55). Das Format lautet: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Package URL

(Abbildung 55) PR-Paket-URL

Sie können nun gelöschte Paketversionen (Abbildung 56) von allen Feedbenutzern ausblenden und so durchgestrichene Pakete vermeiden. Diese Änderung ist eine Reaktion auf diesen UserVoice-Vorschlag.

Hide deleted packages

(Abbildung 56) Ausblenden gelöschter Pakete

Alle Aktionen, die Sie auf der Seite „Paketdetails“ durchführen könnten, können Sie nun auch vom Kontextmenü aus in der Paketliste durchführen.

Die Paketliste enthält die neue Spalte Last pushed (Zuletzt mittels Push übertragen) (Abbildung 57), die relative Datumsangaben enthält, sodass Sie kürzlich aktualisierte Pakete leicht finden können.

Last pushed column

(Abbildung 57) Letzte mithilfe von Push übertragene Spalte

Maven-Pakete

Ab sofort werden Maven-Artefakte in TFS 2018 unterstützt (Abbildung 58). Maven-Artefakte ermöglichen es Java-Entwicklern, auf einfache Weise Code und Komponenten zu veröffentlichen. Informationen zum Veröffentlichen von Maven-Artefakten mithilfe der Paketverwaltung finden Sie im getting started guide (Leitfaden für erste Schritte).

Maven packages

(Abbildung 58) Maven-Pakete

Neue einheitliche NuGet-Aufgabe

Wir haben die Aufgaben NuGet-Wiederherstellung, NuGet-Manager und NuGet-Herausgeber zu einer einheitlichen NuGet-Buildaufgabe vereint, um eine bessere Anpassung an die restliche Buildaufgabenbibliothek zu erreichen. Die neue Aufgabe verwendet standardmäßig NuGet 4.0.0. Dementsprechend sind die alten Aufgaben nun veraltet und wir empfehlen, zu den neuen NuGet-Aufgaben zu wechseln, sobald Sie Zeit dafür finden. Diese Änderung fällt mit einer Reihe von unten beschriebenen Verbesserungen zusammen, auf die Sie nur zugreifen können, indem Sie die vereinte Aufgabe verwenden.

Als Teil dieser Arbeit haben wir auch eine neue Aufgabe, den NuGet-Installer, veröffentlicht, das die auf dem Pfad verfügbare und von der neuen NuGet-Aufgabe verwendete NuGet-Version steuert. Somit müssen Sie am Anfang Ihres Builds nur den NuGet-Installer hinzufügen, um eine neuere Version von NuGet zu verwenden (Abbildung 59).

Nuget task

(Abbildung 59) NuGet-Aufgaben

Erfahren Sie mehr zum aktuellsten NuGet in Ihrem Build im Microsoft DevOps-Blog.

NuGet-Option „Überspringen von Duplikaten zulassen“

Von vielen NuGet-Kunden haben wir erfahren, dass diese eine Reihe von Paketen generieren, von denen nur manche aktualisiert werden sollen (und somit aktualisierte Versionsnummern aufweisen sollen). Die Buildaufgabe NuGet verfügt über die neue Option Allow duplicates to be skipped (Überspringen von Duplikaten zulassen). Dadurch kann die Aufgabe fortfahren, wenn sie versucht, Pakete mittels Push an ein VSTS- oder TFS-Feed zu übertragen, bei dem diese Version bereits verwendet wird.

Updates für die npm-Buildaufgabe

Unabhängig davon, ob Sie Ihr npm-Projekt unter Windows, Linux oder Mac erstellen, wird die neue npm-Buildaufgabe reibungslos funktionieren. Wir haben die Aufgabe zudem neu angeordnet, um die npm-Installation und das npm-Veröffentlichen einfacher zu gestalten. Für die Installation und Veröffentlichung haben wir das Abrufen von Anmeldeinformationen vereinfacht. Anmeldeinformationen für Registrierungen, die in der „.npmrc“-Datei Ihres Projekts aufgelistet sind, können nun sicher in einem Dienstendpunkt gespeichert werden können. Falls Sie einen VSTS- oder TFS-Feed verwenden, steht Ihnen alternativ eine Auswahl zur Verfügung, durch die Sie zunächst einen Feed auswählen können. Anschließend wird eine „.npmrc“-Datei mit den erforderlichen Anmeldeinformationen generiert, die vom Build-Agenten verwendet werden.

Maven unterstützt nun authentifizierte Feeds

Im Gegensatz zu NuGet und npm hat die Maven-Buildaufgabe zuvor keine authentifizierten Feeds unterstützt. Wir haben den Maven-Aufgabe aktualisiert, sodass Sie einfacher mit VSTS- und TFS-Feeds arbeiten können (Abbildung 60).

dotnet task

(Abbildung 60) dotnet-Aufgaben

Eine dotnet-Aufgabe unterstützt authentifizierte Feeds und Webprojekte.

Die nächste Hauptversion der dotnet-Aufgabe (2.x) wird viele Ihrer Feedbackanforderungen beinhalten und eine Reihe von Fehlern beheben, die wir seit einer Weile verfolgt haben.

  1. dotnet unterstützt nun authentifizierte Paketquellen wie den Paketverwalter, sodass Sie nicht mehr die NuGet-Aufgabe verwenden müssen, um Pakete von privaten Paketquellen wiederherzustellen.
  2. Das Verhalten des Felds Pfad zu Projekten hat sich mit Version 2.0 der Aufgabe geändert. In vorherigen Versionen der Aufgabe hat diese eine Warnung ausgegeben, wenn die Projektdateien, die dem angegebenen Muster entsprechen, nicht gefunden wurden und wurde dann als „erfolgreich“ angezeigt. In solchen Szenarios ist manchmal schwer nachzuvollziehen, warum der Build als „erfolgreich“ angezeigt wurde, aber die Abhängigkeiten nicht wiederhergestellt wurden. Nun schlägt die Aufgabe fehl, wenn die Projektdateien, die dem angegebenen Muster entsprechen, nicht gefunden werden. Dies entspricht dem Verhalten anderer Aufgaben und ist einfach nachzuvollziehen und zu verwenden.
  3. Bei früheren Versionen des Befehls „Veröffentlichen“ hat die Aufgabe den Ausgabepfad geändert, indem sie alle Dateien in einem Ordner gespeichert hat, der nach dem Namen der Projektdatei benannt war. Dies geschah auch, wenn Sie einen expliziten Ausgabepfad angegeben haben. Dadurch wird es schwierig, Befehle miteinander zu verketten. Nun haben Sie die Steuerung über den Ausgabepfad der Datei.

Wir haben auch eine neue Aufgabe, den dotnet-Tool-Installer, veröffentlicht, das die auf dem Pfad verfügbare und von der neuen dotnet-Aufgabe verwendete dotnet-Version steuert. Somit müssen Sie am Anfang Ihres Builds nur den dotnet-Tool-Installer hinzufügen, um eine neuere Version von dotnet zu verwenden.

Arbeiten außerhalb Ihres Kontos oder Ihrer Sammlung

Es ist nun einfacher, mit Feeds außerhalb Ihres TFS-Servers oder Ihres VSTS-Kontos zu arbeiten (Abbildung 61). Dies ist unabhängig davon, ob es sich um Feeds mit Paketverwaltung in einem anderen VSTS-Konto oder TFS-Server oder um Feeds ohne Paketverwaltung wie z.B. NuGet.org/npmjs.com, Artifactory oder MyGet handelt (Abbildung 60). Durch dedizierte Dienstendpunkt-Typen für NuGet und npm wird es leichter, die richtigen Anmeldeinformationen anzugeben und die Buildaufgaben zu aktivieren. Dadurch wird ein reibungsloses Arbeiten über Paketdownloads und Pushvorgänge für Pakete ermöglicht.

Feeds to use

(Abbildung 61) Zu verwendender Feed

Auswahl für VSTS- und TFS-Feeds

Wir empfehlen stets das Einchecken einer Konfigurationsdatei (z.B. NuGet.Config, .npmrc usw.), sodass Ihr Quellrepository einen Datensatz darüber enthält, woher Ihre Pakete stammen. Wir haben jedoch von einer Reihe von Szenarios erfahren, bei denen diese Vorgehensweise nicht optimal ist, sodass wir die neue Option Pakete aus diesem VSTST-/TFS-Feed verwenden hinzugefügt haben. Dadurch können Sie einen Feed auswählen und automatisch eine Konfigurationsdatei generieren, die für diesen Buildschritt verwendet wird (Abbildung 62).

Feed picker

(Abbildung 62) Feed-Auswahl

Build und Release

Aufhebung der Unterstützung für XAML-Builds

Mit TFS 2015 haben wir ein webbasiertes, plattformübergreifendes Buildsystem eingeführt. Das ist das einzige Modell, das wir in TFS 2018 unterstützen. XAML-Builds werden in TFS 2018 nicht unterstützt. Wir empfehlen Ihnen, migrate your XAML builds (Ihre XAML-Builds zu migrieren). Wenn Sie für die Migration noch nicht bereit sind und Ihre XAML-Builds weiterhin verwenden müssen, sollten Sie kein Upgrade auf TFS 2018 durchführen.

Wenn Sie auf TFS 2018 aktualisieren:

  • Wenn sich noch irgendwelche XAML-Builddaten in Ihrer Teamprojektsammlung befinden, wird Ihnen eine Warnung angezeigt, dass die XAML-Buildfeatures entfernt werden sollten.

  • In TFS 2018 können Sie abgeschlossene XAML-Builds anzeigen lassen, aber Sie können keine neuen in die Warteschlange stellen.

  • Es gibt in TFS 2018 keine neue Version des XAML-Buildcontrollers oder des XAML-Build-Agenten und Sie können keine ältere Version derselben darauf konfigurieren, mit TFS 2018 zu arbeiten.

Eine Erläuterung unseres Plans, wie XAML-Builds veralten, finden Sie im Blogbeitrag Evolving TFS/Team Services build automation capabilities.

Exportieren und Importieren von Builddefinitionen

Builddefinitionen werden intern als JSON-Dateien implementiert, sodass Sie Details zu den Änderungen im Dateiverlauf anzeigen lassen können. Es ist bereits möglich, Ihre Builddefinitionen zu klonen und Vorlagen aus ihnen zu erstellen. Einige Benutzer haben jedoch nach der Möglichkeit verlangt, eine Kopie ihrer CI-Buildlogik zu erstellen, um diese in einem anderen Teamprojekt wiederzuverwenden. Dabei handelte es sich um eine der top-ten request on UserVoice (zehn häufigsten Anfragen auf UserVoice).

Wir freuen uns bekanntzugeben, dass dies nun möglich ist (Abbildung 63 und Abbildung 64)!

Export build definition

(Abbildung 63) Exportieren der Builddefinition

Import build definition

(Abbildung 64) Importieren der Builddefinition

Erweiterungen mit Buildvorlagen

Buildvorlagen ermöglichen Ihnen das Erstellen einer Baseline für Benutzer, damit diese mit dem Definieren Ihres Buildprozesses beginnen können. Wir liefern heute einige davon in das Feld. Obwohl Sie früher neue Vorlagen in Ihr Konto hochladen konnten, war es Erweiterungsautoren nicht möglich, neue Vorlagen in eine Erweiterung zu integrieren. Sie können nun Buildvorlagen In Ihre Erweiterungen integrieren. Zum Beispiel:

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

Das vollständige Beispiel finden Sie unter https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

Tipp

Sie können diese Funktion verwenden, um dieselben benutzerdefinierten Vorlagen für alle Ihre Teamprojekte anzubieten und zu veröffentlichen.

Eine Aufgabe in einer Erweiterung als veraltet deklarieren

Sie können nun eine Aufgabe in Ihrer Erweiterung als veraltet deklarieren. Damit dies funktioniert, müssen sie die folgende Variable zur neuesten Version Ihrer Aufgabe hinzufügen:

"deprecated": true

Wenn der Benutzer nach veralteten Aufgaben sucht (Abbildung 65), werden diese Aufgaben ans Ende gestellt und in einem reduzierbaren Abschnitt gruppiert. Dieser Abschnitt ist standardmäßig reduziert. Wenn eine Definition bereits eine veraltete Aufgabe verwendet, wird der Badge „Veraltete Aufgabe“ angezeigt, um die Benutzer dazu aufzufordern, zum Ersatz für diese zu wechseln.

Deprecated task badge

(Abbildung 65) Badge „Veraltete Aufgaben“

Sie können Ihre Benutzer über die Ersatzaufgaben informieren, indem Sie diese in der Aufgabenbeschreibung erwähnen (Abbildung 66). Die Beschreibung wird den Benutzern der Aufgabe den richtigen Weg zum Aufgabenkatalog und zu bestehenden Build- und Releasedefinitionen zeigen.

Deprecated task description

(Abbildung 66) Beschreibung für veraltete Aufgaben

Steuern der Sichtbarkeit von Abschnitten durch beigetragene Buildabschnitte

Wenn Sie zuvor eine Erweiterung verwendet haben, die über Buildaufgaben und Buildzusammenfassungen verfügte, wurde Ihnen der Abschnitt „Buildzusammenfassung“ angezeigt, auch wenn Sie diese Buildaufgabe in diesem Build nicht verwendet haben. Nun können Sie auf der Seite „Buildzusammenfassung“ wählen, ob Sie diesen Abschnitt verbergen oder anzeigen wollen, indem Sie die folgende Zeile zu Ihrem Erweiterungscode hinzufügen und den Wert auf „true“ oder „false“ festlegen:

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

Weitere Informationen dazu finden Sie in dem Beispiel im Microsoft vsts-extension-samples repository (Repository für Microsoft VSTS-Erweiterungsbeispiele).

Unterstützung für variable Gruppen

Variable Gruppen konnten in Releasedefinitionen verwendet werden, nun können Sie auch in Builddefinitionen verwendet werden. Weitere Informationen zum creating a variable group (Erstellen einer variablen Gruppe). Dies wurde basierend auf zugehörigen Vorschlägen für project-level build/release variables (Build-/Releasevariablen auf Projektebene) und variable groups in build definitions (variable Gruppen in Builddefinitionen) entwickelt und priorisiert.

Arbeiten mit sicheren Dateien wie Apple-Zertifikaten

Wir haben eine allgemeine Bibliothek für sichere Dateien hinzugefügt (Abbildung 67).

Secure files library

(Abbildung 67) Bibliothek für sichere Dateien

Verwenden Sie die Bibliothek für sichere Dateien, um Dateien wie Signaturzertifikate, Apple-Bereitstellungsprofile, Android-Keystore-Dateien und SSH-Schlüssel auf dem Server zu speichern, ohne diese Ihrem Quellrepository zu übergeben.

Die Inhalte sicherer Dateien sind verschlüsselt und können nur während des Build- oder Releaseprozesses verwendet werden, indem eine Aufgabe auf diese verweist. Sichere Dateien sind basierend auf den Sicherheitseinstellungen für mehrere Build- und Releasedefinitionen im Teamprojekt verfügbar. Sichere Dateien befolgen das Modell für Bibliotheksicherheit.

Wir haben auch einige Apple-Aufgaben hinzugefügt, die dieses neue Feature nutzen:

Anhalten von Builddefinitionen

Sie können Builddefinition nun anhalten oder deaktivieren. Wenn Sie Änderungen an Ihrer Builddefinition vornehmen möchten, aber bis Sie fertig sind vermieden werden soll, dass neue Builds zur Warteschlange hinzugefügt werden, deaktivieren Sie die Builddefinition. Wenn Sie einen Agent-Computer aktualisieren möchten, können Sie eine Builddefinition anhalten. Dadurch kann VSTS weiterhin neue Buildanforderungen akzeptieren, aber diese bis Sie die Definition fortsetzen in der Warteschlange halten, ohne diese auszuführen.

Unterstützung für die Validierungen von Aufgabeneingaben

Das Eingeben der Parameter in Aufgaben für die Builddefinition kann manchmal fehleranfällig sein. Mit der Validierung von Aufgabeneingaben können Aufgabenautoren sicherstellen, dass geeignete Werte angegeben werden. Validierungsausdrücke folgen einer ähnlichen Ausdruckssyntax wie Aufgabenbedingungen und können neben den allgemeinen Funktionen, die von Aufgabenbedingungen unterstützt werden, alle unterstützten Funktionen verwenden, einschließlich URL, IPv4, E-Mail, Nummernbereich, SHA-1, Länge oder Übereinstimmung.

Weitere Informationen zu den Zielen und der Nutzung finden Sie auf der Seite des Repositorys für VSTS-Aufgaben.

Neuer Editor für Releasedefinitionen

Die Aktualisierungen der Build- und Releasefeatures betreffen nun auch den Editor für Releasedefinitionen. Dieser wurde neu gestaltet und kann dadurch intuitiver bedient werden, außerdem wurden einige Probleme behoben und neue Funktionen hinzugefügt. Eines der leistungsstärksten Features des neuen Editors ist die Möglichkeit, den Fortschritt Ihrer Bereitstellungen für die Umgebungen zu visualisieren. Zusätzlich sind Genehmigungen, Umgebungseigenschaften und Bereitstellungseinstellungen nun kontextbezogen und leicht zu konfigurieren.

Visualisierung der Pipeline

Die Pipeline (Abbildung 68) im Editor stellt eine grafische Ansicht zum Fortschritt der Bereitstellungen in einem Release bereit. Die Artefakte werden von der Release genutzt und für die Umgebungen bereitgestellt. Das Layout und die Verknüpfungen der Umgebungen zeigen nun die Triggereinstellungen an, die für jede Umgebung definiert sind.

Pipeline

(Abbildung 68) Releasepipeline

Kontextbezogene Konfigurationen der Benutzeroberfläche

Artefakte, Releasetrigger, Genehmigungen vor und nach der Bereitstellung, Umgebungseigenschaften und Bereitstellungseinstellungen sind nun kontextbezogen und leicht zu konfigurieren (Abbildung 69).

Release configuration

(Abbildung 69) Releasekonfiguration

Erste Schritte mit Bereitstellungsvorlagen

Alle integrierten Bereitstellungsvorlagen verfügen über Prozessparameter, die Benutzern den Einstieg erleichtern, indem die wichtigsten Parameter bereits angegeben sind, ohne tief in den Aufgabe hineinzugehen (Abbildung 70).

Deployment templates

(Abbildung 70) Bereitstellungsvorlagen

Vereinfachte Verwaltung von Versions- und Umgebungsvariablen

Verwenden Sie die Ansicht Liste, um Release- oder Umgebungsvariablen schnell hinzuzufügen und die Anzeige Raster, um Variablen parallel und bereichsübergreifend zu vergleichen und zu bearbeiten (Abbildung 71). Zusätzlich können Sie die Suche für Filter und Schlüsselwörter verwenden, um die Variablen zu verwalten, mit denen Sie in den beiden Ansichten arbeiten möchten.

Simplified management of variables

(Abbildung 71) Vereinfachte Verwaltung von Variablen

Verbesserter Editor für Aufgaben und Phasen

Alle Verbesserungen des neuen Editors für Builddefinitionen sind nun auch im Editor für Releasedefinitionen verfügbar (Abbildung 72). Sie können nach Aufgaben suchen und diese hinzufügen, indem Sie entweder die Schaltfläche Hinzufügen oder Drag/Drop verwenden. Sie können Aufgaben neu anordnen oder klonen, indem Sie Drag/Drop verwenden.

Task editor

(Abbildung 72) Aufgaben-Editor

Registerkarten für variable Gruppen, Beibehaltung und Optionen

Sie können variable Gruppen nun verknüpfen oder Verknüpfungen zu diesen aufheben (Abbildung 73), Beibehaltungsrichtlinien für einzelne Umgebungen festlegen und Einstellungen auf Ebene von Releasedefinitionen wie z.B. das Format der Releasenummer in der Registerkarte Optionen ändern. Sie können eine Umgebung auch als Bereitstellungsvorlage speichern, Berechtigungen auf Umgebungsebene festlegen und Phasen innerhalb der Registerkarte Aufgaben neu anordnen.

Variable groups

(Abbildung 73) Variable Gruppen

Verwenden Sie Vorgänge auf Umgebungsebene, um Vorlagen zu speichern und die Sicherheit festzulegen (Abbildung 74).

Environment menu

(Abbildung 74) Umgebungsmenü

Weitere Informationen finden Sie in der Dokumentation zum Editor für Releasedefinitionen.

VM-Bereitstellung mithilfe von Bereitstellungsgruppen

Release Management unterstützt nun die stabile Standardbereitstellung auf mehreren Computern. Sie können nun Bereitstellungen auf mehreren Computern orchestrieren und gleitende Updates durchführen, während Sie die Hochverfügbarkeit der Anwendung gewährleisten.

Die agentbasierte Bereitstellungsfunktion basiert auf denselben Build- und Bereitstellungs-Agenten. Anders als beim aktuellen Ansatz, bei dem Sie die Build- und Bereitstellungs-Agenten auf einer Reihe von Proxyservern in einem Agent-Pool installieren und die Bereitstellungen an Remotezielserver übertragen, installieren Sie den Agenten nun direkt auf jedem Ihrer Zielserver und übertragen gleitende Bereitstellungen an diese Server. Sie können den vollständigen Aufgabenkatalog auf Ihren Zielcomputern verwenden.

Eine Bereitstellungsgruppe (Abbildung 75) ist eine logische Gruppe von Zielen (Computern), auf denen jeweils Agents installiert wurden. Bereitstellungsgruppen stellen Ihre physischen Umgebungen dar, zum Beispiel Single-Box-Entwicklung, QA mit mehreren Computern und eine Reihe von Computern für UAT/PROD. Sie geben außerdem den Sicherheitskontext für Ihre physischen Umgebungen an.

Deployment groups

(Abbildung 75) Bereitstellungsgruppen

Sie können diese für jede VM verwenden, auf der Sie unseren Agenten registrieren. Wir haben ebenfalls die Registrierung bei Azure erleichtert, indem wir Unterstützung für die Azure-VM-Erweiterung hinzugefügt haben, die den Agenten automatisch installiert, wenn eine VM gestartet wird. Die Tags auf der Azure-VM werden automatisch geerbt, sobald diese registriert ist.

Sobald Sie über eine Bereitstellungsgruppe verfügen, können Sie ganz einfach konfigurieren, was in dieser Bereitstellungsgruppe ausgeführt werden soll (Abbildung 76). Sie können steuern, was auf welchem Computer ausgeführt wird, indem Sie Tags verwenden. Außerdem können Sie steuern, wie schnell oder langsam das Rollout geschieht.

Configure deployment groups

(Abbildung 76) Konfigurieren von Bereitstellungsgruppen

Wenn die Bereitstellung ausgeführt wird, zeigen die Protokolle den Fortschritt für die gesamte Gruppe von Computern an, die Sie anzielen (Abbildung 77).

Deployment group progress

(Abbildung 77) Fortschritt von Bereitstellungsgruppen

Dieses Feature ist nun in Release Management enthalten. Es sind keine zusätzlichen Lizenzen erforderlich.

Verbesserte Benutzeroberfläche für Bereitstellungsgruppen

Die Aktualisierungen der Build- und Releasefeatures betreffen nun auch die Seite „Bereitstellungsgruppen“. Diese wurde neu gestaltet, um die Bedienung strukturierter und intuitiver zu gestalten (Abbildung 78). Auf der Startseite wird Ihnen die Integrität der Ziele in der Bereitstellungsgruppe angezeigt. Sie können auch die Sicherheit für einzelne Bereitstellungsgruppen verwalten oder Standardberechtigungen in Bereitstellungsgruppen festlegen.

Deployment groups UI

(Abbildung 78) Benutzeroberfläche für Bereitstellungsgruppen

Für ein Ziel innerhalb einer Bereitstellungsgruppe können Sie eine Zusammenfassung, die letzten Bereitstellungen und die Funktionen des Ziels anzeigen (Abbildung 79). Sie können Tags für das Ziel festlegen und steuern, was auf welchem Ziel ausgeführt wird. In zukünftigen Releases wird die Unterstützung von Filtern für Bereitstellungsgruppen hinzugefügt.

Deployment groups UI tags

(Abbildung 79) UI-Tags für Bereitstellungsgruppen

Verweise auf Arbeitsgruppen

Über Aufgabengruppen können Sie eine Reihe von Aufgaben definieren, die Sie zu Ihren Build- oder Releasedefinitionen hinzufügen können (Abbildung 80). Dies ist praktisch, wenn sie dieselben Aufgabengruppen in mehreren Builds oder Releases verwenden möchten. Es gibt nun eine Ansicht für die Builddefinitionen, Releasedefinitionen und Aufgabegruppen, die auf Ihre Aufgabegruppen verweisen, um Sie beim Nachverfolgen der Nutzer einer Aufgabegruppe zu unterstützen (Abbildung 79).

Task group references

(Abbildung 80) Verweise auf Aufgabengruppen

Wenn Sie versuchen, eine Aufgabengruppe zu löschen, auf die immer noch verwiesen wird, wird eine Warnung mit einem Link zu dieser Seite ausgegeben.

Versionskontrolle für Aufgabengruppen

Das Vornehmen von Änderungen an Aufgabengruppen kann riskant sein, denn die Änderung wirkt sich auf alle Definitionen aus, die die Aufgabengruppe verwenden. Durch die Versionskontrolle für Aufgabengruppen können Sie nun Entwurfs- und Vorschauversionen für Ihre Aufgabengruppen erstellen und dennoch stabile Versionen für Ihre wichtigsten Definitionen anbieten, bis Sie für einen Wechsel bereit sind. Nachdem Sie einige Entwürfe und Iterationen erstellt haben, können Sie eine stabile Version veröffentlichen. Falls es sich um bedeutende Änderungen handelt, können Sie während der Veröffentlichung wählen, ob Sie die Aufgabengruppe als Vorschauversion (eine neue Hauptversion) veröffentlichen möchten. Alternativ können Sie diese direkt als aktualisierte stabile Version veröffentlichen (Abbildung 81).

Wenn eine neue Hauptversion (oder Vorschauversion) der Aufgabengruppe verfügbar ist, weist der Editor für Definitionen Sie darauf hin, dass es eine neue Version gibt. Falls es sich bei dieser Hauptversion um eine Vorschauversion handelt, wird ihnen die Nachricht „Probieren Sie es aus“ angezeigt. Wenn die Aufgabengruppe aus einer Vorschauversion stammt, werden die Definitionen, die diese verwendet, automatisch über den Hauptkanal aktualisiert (Abbildung 82).

Save as draft

(Abbildung 81) Speichern von Aufgabengruppen als Entwurf

Publish task group as preview

(Abbildung 82) Veröffentlichen von Aufgabengruppen als Vorschau

Importieren und Exportieren von Aufgabengruppen

Obwohl Aufgabengruppen innerhalb eines Projekts wiederverwendet werden können, kann das Neuerstellen einer Aufgabengruppe in Projekten und Konten Probleme bereiten. Durch das Importieren und Exportieren von Aufgabengruppen (Abbildung 83) können Sie diese nun, genau wie bei den Releasedefinitionen, als JSON-Datei exportieren und dort importieren, wo Sie sie benötigen. Wir haben auch verschachtelte Aufgabengruppen hinzugefügt, die erst erweitert werden, wenn sie exportiert werden.

Export task group

(Abbildung 83) Exportieren von Aufgabengruppen

Unterstützung mehrerer Konfigurationen in serverseitigen (agentenlosen) Aufgaben

Indem Sie variable Multiplikatoren für serverseitige (agentenlose) Aufgaben angeben (Abbildung 84), können Sie in einer Phase nun eine Reihe von identischen Aufgaben mit mehreren, parallel ausgeführten Konfigurationen ausführen.

Multi configuration of agentless tasks

(Abbildung 84) Konfiguration von mehreren agentlosen Aufgaben

Unterstützung von Variablen in Aufgaben für manuellen Eingriff

Die Aufgabe für Manuellen Eingriff (Abbildung 85) unterstützt nun die Verwendung von Variablen innerhalb des Anweisungstexts, der Benutzern angezeigt wird, wenn die Aufgabe ausgeführt wird. Dies geschieht an dem Punkt, an dem der Benutzer die Ausführung des Releaseprozesses fortsetzen oder ablehnen kann. Alle Variablen, die im Release definiert und verfügbar sind, können eingefügt werden. Die Werte werden in den Benachrichtigungen und E-Mails verwendet, die an Benutzer gesendet werden (Abbildung 86).

Manual intervention task

(Abbildung 85) Task für manuellen Eingriff

Manual intevention pending dialog

(Abbildung 86) Dialogfeld „Manueller Eingriff ausstehend“

Steuern von Releases in eine Umgebung basierend auf dem Quellbranch

Eine Releasedefinition kann konfiguriert werden, um eine Bereitstellung automatisch auszulösen, wenn eine neue Release erstellt wird. Dies geschieht normalerweise, nachdem der Build der Quelle erfolgreich ist. Sie sollten jedoch nur Builds von bestimmten Branches der Quelle bereitstellen und nicht jeden erfolgreichen Build.

Sie könnten beispielsweise alle Builds für die Entwicklungs- und Testumgebungen bereitstellen, aber nur bestimmte Builds für die Produktion. Zuvor waren dafür zwei Releasepipelines erforderlich, eine für die Entwicklungs- und Testumgebungen und eine für die Produktionsumgebung.

Release Management unterstützt nun die Verwendung von Artefefaktfiltern für jede Umgebung. Das bedeutet, dass Sie die Releases angeben können, die für jede Umgebung bereitstellt werden, wenn die Bedingungen(z.B. ein erfolgreicher Build oder das Erstellen eines neuen Release) für das Auslösen der Bereitstellung erfüllt sind. Wählen Sie im Abschnitt Trigger des Dialogfelds Bereitstellungsbedingungen (Abbildung 87) der Umgebung die Artefaktbedingungen wie etwa den Quellbranch und Tags für Builds, durch die eine neue Bereitstellung für diese Umgebung ausgelöst wird.

Deployment conditions dialog

(Abbildung 87) Dialogfeld „Bereitstellungsbedingungen“

Zusätzlich enthält die Seite Releasezusammenfassung (Abbildung 88) nun ein Popupelement mit Tipps, das für alle Bereitstellungen mit dem Status „nicht gestartet“ den Grund dafür anzeigt und vorschlägt, wie oder wann die Bereitstellung starten kann.

Release summary tip

(Abbildung 88) Tipps für die Releasezusammenfassung

Releasetrigger für Git-Repositorys als Artefaktquelle

Release Management unterstützt nun das Konfigurieren eines Triggers für Continuous Deployment (Abbildung 89) für Git-Repositorys, die mit einer Releasedefinition in einem der Teamprojekte auf demselben Konto verknüpft sind. Dadurch können Sie ein Release automatisch auslösen, wenn ein neuer Commit an das Repository vorgenommen wird. Sie können auch einen Branch im Git-Repository angeben, für das Commits ein Release auslösen.

Release triggers

(Abbildung 89) Releasetrigger

Releasetrigger: Kontinuierliche Bereitstellung für Änderungen, die mittels Push an ein Git-Repository übertragen werden

Release Management hat schon immer die Funktion bereitgestellt, eine kontinuierliche Bereitstellung zu konfigurieren, wenn ein Build abgeschlossen wird. Nun können Sie die kontinuierliche Bereitstellung jedoch auch für einen Git-Push konfigurieren. Das bedeutet, dass Sie Repositorys von GitHub und Team Foundation als Artefaktquellen mit einer Releasedefinition verknüpfen können. Dann können Releases für nicht aus einem Build generierte Anwendungen wie Node.JS und PHP automatisch ausgeführt werden, da diese keinen Buildvorgang für die kontinuierliche Bereitstellung benötigen.

Branchfilter in Umgebungstriggern

Im neuen Editor für Releasedefinitionen können Sie nun Artefaktbedingungen für eine bestimmte Umgebung angeben. Indem Sie die Artefaktbedingungen verwenden, können Sie präziser steuern, welche Artefakte für eine bestimmte Umgebung bereitgestellt werden sollen. Für eine Produktionsumgebung sollten Sie beispielsweise sicherstellen, dass nur Builds bereitgestellt werden, die aus dem Masterbranch generiert wurden. Dieser Filter muss für alle Artefakte festgelegt werden, die dieses Kriterium erfüllen sollten.

Sie können jedem Artefakt, das mit der Releasedefinition verknüpft ist, mehrere Filter hinzufügen (Abbildung 90). Die Bereitstellung wird für diese Umgebung nur ausgelöst, wenn alle Artefaktbedingungen erfolgreich erfüllt wurden.

Branch filters

(Abbildung 90) Branchfilter

Verbesserungen an serverseitigen Aufgaben

Wir haben zwei Verbesserungen an serverseitigen Aufgaben (Aufgaben, die innerhalb einer Serverphase ausgeführt werden) vorgenommen.

Wir haben eine neue Aufgabe hinzugefügt, die verwendet werden kann, um jede generische HTTP-REST-API (Abbildung 91) als Teil der automatisierten Pipeline aufzurufen. Sie kann beispielsweise verwendet werden, um eine bestimmte Verarbeitung mit einer Azure-Funktion aufzurufen und zu warten, bis diese abgeschlossen ist.

REST API task

(Abbildung 91) REST-API-Aufgabe

Wir haben auch den Abschnitt Steuerungsoptionen (Abbildung 92) zu allen serverseitigen Aufgaben hinzugefügt. Das Verhalten der Aufgabe beinhaltet nun das Festlegen der Optionen Aktiviert, Bei Fehler fortsetzen, Immer ausführen und Timeout.

Task control options

(Abbildung 92) Optionen zur Aufgabensteuerung

Badge für den Releasestatus in Codehub

Wenn Sie wissen wollten, ob ein Commit für die Produktionsumgebung Ihrer Kunden bereitgestellt wurde, müssen Sie zunächst identifizieren, welcher Build den Commit verarbeitet und dann alle Releaseumgebungen überprüfen, für die dieser Build bereitgestellt wurde. Nun ist dieser Vorgang durch wesentlich einfacher, da ein Badge mit dem Bereitstellungsstatus in Codehub integriert wurde, der die Liste der Umgebungen anzeigt, für die Ihr Code bereitgestellt wurde. Für jede Bereitstellung wird der Status an den letzten Commit gesendet, der Teil der Bereitstellung war. Wenn ein Commit für mehrere Releasedefinitionen (mit mehreren Umgebungen) bereitgestellt wird, verfügt jede davon über einen Eintrag im Infoanzeiger, und der Status wird für jede Umgebung angezeigt (Abbildung 93). Dadurch wird die Nachverfolgbarkeit von mittels Commits an Bereitstellungen übertragenem Code verbessert.

Release status badge

(Abbildung 93) Badge für den Releasestatus

Standardmäßig wird beim Erstellen einer Releasedefinition der Bereitstellungsstatus für alle Umgebungen angezeigt. Sie können jedoch selektiv die Umgebungen auswählen, deren Bereitstellungsstatus im Infoanzeiger für den Status angezeigt werden soll (z.B. nur Produktionsumgebungen) (Abbildung 94).

Deployment options dialog

(Abbildung 94) Dialogfeld „Bereitstellungsoptionen“

Verbesserungen am Menü für Builddefinitionen beim Hinzufügen von Artefakt

Beim Hinzufügen von Buildartefakten zu einer Releasedefinition können Sie nun die Definitionen mit den Informationen zu deren Ordnerorganisation anzeigen lassen und das Auswählen der gewünschten Definition so vereinfachen (Abbildung 95). Dadurch wird es leichter, Builddefinitionen zu unterscheiden, die denselben Namen haben, sich aber in unterschiedlichen Ordnern befinden.

Add artifact

(Abbildung 95) Hinzufügen eines Artefakts

Die Liste der Definitionen wird basierend auf den Definitionen gefiltert, die den Filterbegriff enthalten.

Wiederherstellen einer früheren Version Ihrer Releasedefinition

Wenn eine Releasedefinition aktualisiert wird, können Sie aktuell nicht direkt eine frühere Version wiederherstellen. Sie können nur die Versionsgeschichte der Releasedefinitionen nach den Unterschieden der Änderungen durchsuchen und die Releasedefinition dann manuell bearbeiten. Nun können Sie das Feature Definition wiederherstellen verwenden (Abbildung 96), durch das Sie eine frühere Version einer Releasedefinition in der Registerkarte Versionsgeschichte auswählen und wiederherstellen können.

Revert release definition

(Abbildung 96) Wiederherstellen der Releasedefinition

Personalisierte Benachrichtigungen für Releases

Benachrichtigungen für Releases sind nun in die Benachrichtigungseinstellungen von VSTS integriert. Diejenigen, die die Releases verwalten, werden nun automatisch über ausstehende Aktionen (Genehmigungen oder manuelle Eingriffe) und wichtige Bereitstellungsfehler benachrichtigt. Sie können diese Benachrichtigungen deaktivieren, indem Sie zu den Einstellungen Benachrichtigungen im Menü „Profil“ navigieren und die Option Release Subscriptions (Releaseabonnements) deaktivieren. Sie können ebenfalls zusätzliche Benachrichtigungen abonnieren, indem Sie benutzerdefinierte Abonnements erstellen. Administratoren können die Abonnements für Teams und Gruppen über die Einstellung Benachrichtigung in den Einstellungen Team und Konto steuern.

Die Autoren von Releasedefinitionen müssen für Genehmigungen und abgeschlossene Bereitstellungen nicht mehr manuell E-Mails versenden.

Dies ist besonders bei großen Konten mit mehreren an den Releases Beteiligten nützlich sowie für alle anderen Personen außer der genehmigenden Person, dem Ersteller des Releases und dem Besitzer der Umgebung, die benachrichtigt werden möchten (Abbildung 97).

Release notifications

(Abbildung 97) Releasebenachrichtigungen

Weitere Informationen finden Sie im post for managing release notifications (Beitrag zum Verwalten von Releasedefinitionen).

Testen

Entfernen der Unterstützung für Lab-Center und automatisierte Testabläufe in Microsoft Test Manager

Mit der Entwicklung von Build und Release Management werden XAML-Builds in TFS 2018 nicht mehr unterstützt. Daher wird die Unterstützung aktualisiert, um Microsoft Test Manager (MTM) mit TFS verwenden zu können. Das Verwenden des Testcenters bzw. Lab-Centers in MTM für automatisiertes Testen wird ab TFS 2018 nicht mehr von TFS unterstützt. Wenn Sie nicht bereit sind, von XAML-Builds und Lab-Center zu migrieren, sollten Sie kein Upgrade auf TFS 2018 durchführen.

Informationen zur Auswirkung des Upgrades auf TFS 2018 finden Sie nachstehend:

Lab-Center:
Automatisiertes Testen:
Manuelles Testen:

Basierend auf dem Feedback, das wir von den Teams erhalten haben, die explorative Tests durchführen, verbessern wir die Links zur Nachverfolgbarkeit, während wir Fehler, Aufgaben oder Testfälle von der Test & Feedback extension (Test- und Feedback-Erweiterung) einreichen. Fehler und Aufgaben, die beim Durchsuchen der Anforderungen erstellt wurden, werden nun mit demselben Bereichspfad und derselben Iteration wie die Anforderung erstellt, statt die Standardeinstellungen des Teams zu verwenden. Testfälle, die beim Durchsuchen der Anforderungen erstellt wurden, werden nun mit einem Test <-> Getestet von-Link statt mit einem Übergeordnet <-> Untergeordnet-Link verknüpft. Dadurch werden die Testfälle, die Sie erstellen, automatisch zu den anforderungsbasierten Testsammlungen hinzugefügt. Schließlich werden Arbeitselemente, die nicht beim Durchsuchen von Anforderungen erstellt wurden, in den Standarditerationen des Teams statt in der aktuellen Iteration gespeichert, sodass keine neuen Arbeitselemente der aktuellen Iteration hinzugefügt werden, nachdem die Sprintplanung abgeschlossen ist.

Filter für Arbeitselemente für Testfälle in Testplänen und Testsammlungen in Testhub

Zusätzlich zu den Filtern für Testfelder wie Ergebnis, Konfiguration und Tester können Sie nun auch Arbeitselementfelder von Testfällen filtern, z.B. Titel, Status und Zugewiesen zu (Abbildung 98).

Test case filters

(Abbildung 98) Filter für Testfälle

Testen von Trenddiagrammen für Releaseumgebungen und Testläufe

Wir fügen Unterstützung für Releaseumgebungen im Widget Test Result Trend (Trend der Testergebnisse) hinzu (Abbildung 99), sodass Sie den Status der Testumgebungen auf VSTS-Dashboards nachverfolgen können. So wie Sie Testergebnisse mit Build erstellen, können Sie nun auch Trenddiagramme erstellen, die die Erfolgsquote des Tests, die Gesamtanzahl der Tests, bestandene oder fehlgeschlagene Tests und die Testdauer für die Releaseumgebungen anzeigen. Sie können die Diagramme auch nach einem bestimmten Testlauf innerhalb einer Umgebung filtern, indem Sie den Titelfilter Testlauf verwenden.

Test trend chart

(Abbildung 99) Trenddiagramm für Tests

Unterstützung für die Markdown-Formatierung für Testläufe und Kommentare zu Testergebnissen

Wir fügen Unterstützung für das Formatieren von Testläufen und Kommentaren zu Testergebnissen mithilfe der Markdown-Syntax hinzu. Sie können diese Funktion verwenden, um formatierten Text oder Quicklinks zu URLs in Ihren Kommentaren zu erstellen. Sie können Kommentare zu Testergebnissen auf der Seite Ergebniszusammenfassung mit Update-Analyse aktualisieren und Kommentare zu Testläufen auf der Seite Testlaufzusammenfassung mithilfe von Kommentare aktualisieren im Testhub.

Beim Analysieren der Testergebnisse auf der Zusammenfassungsseite des Build oder Release oder im Testhub können Sie nun einen bestehenden Fehler einem fehlgeschlagenen Test zuordnen. Das ist hilfreich, wenn ein Test aus einem bekannten Grund fehlschlägt, der einen bereits gespeicherten Fehler enthält.

Hochladen von Anlagen für Testläufe und Testergebnisse

Sie können nun Dateien wie Screenshots und Protokolldateien als zusätzliche Informationen an Testläufe und Testergebnisse anfügen. Bis zu diesem Zeitpunkt war diese Funktion nur über den MTM-Client (Microsoft Test Manager) verfügbar, und Sie mussten den Kontext zwischen dem Testhub in VSTST/TFS und dem MTM-Client wechseln.

Batchverarbeitung von Tests

Für die Visual Studio-Testaufgabe in der Build- und Releaseverwaltung sind Optionen verfügbar, um das Gruppieren von Tests in Batches für eine effiziente Ausführung zu steuern. Tests können auf zwei Arten gruppiert werden:

  1. Basierend auf der Anzahl von Tests und Agents, die an der Ausführung teilnehmen. Dabei werden Tests in eine Anzahl von Batches mit angegebener Größe gruppiert.
  2. Basierend auf der Ausführungszeit der Tests. Dabei wird die vorherige Ausführungszeit für das Erstellen der Testbatches berücksichtigt, sodass die Ausführungszeit der Batches ungefähr gleich ist (Abbildung 100). Schnell ausgeführte Tests werden zusammengefasst, während Tests mit längerer Ausführungszeit zu einem separaten Batch gehören können. Diese Option kann mit der Einstellung für mehrere Agent-Phasen kombiniert werden, um die gesamte Testzeit auf ein Minimum zu reduzieren.

Test batching

(Abbildung 100) Testen der Batchverarbeitung

Ausführen von Webtests mithilfe der Aufgabe „VSTest“

Indem Sie die Visual Studio-Testaufgabe verwenden, können Webtests, auch als Webleistungstests bekannt, in der CI/CD-Pipeline ausgeführt werden. Webtests können ausgeführt werden, indem der auszuführende Test in der Eingabe der Aufgabenassembly angegeben wird. Jedes Arbeitselement für einen Testfall, das über eine mit einem Webtest verknüpfte „zugehörige Automatisierung“ verfügt, kann auch ausgeführt werden, indem der Testplan bzw. die Testsammlung in der Aufgabe ausgewählt wird (Abbildung 101).

Test selection

(Abbildung 101) Testen der Auswahl

Die Ergebnisse von Webtests sind als Anlage an das Testergebnis verfügbar (Abbildung 102). Dies kann für die Offlineanalyse in Visual Studio heruntergeladen werden.

Test summary

(Abbildung 102) Zusammenfassung der Tests

Diese Funktion ist abhängig von den Änderungen in der Visual Studio-Testplattform und erfordert, dass Visual Studio 2017 Update 4 auf den Build-/Release-Agent installiert ist. Webtests können nicht mit früheren Versionen von Visual Studio ausgeführt werden.

Auf ähnliche Weise können Webtests ausgeführt werden, indem die Aufgabe Funktionstest ausführen verwendet wird. Diese Funktion hängt von den Änderungen im Test-Agent ab, die mit Visual Studio 2017 Update 5 verfügbar sein werden.

Ein Beispiel für deren Verwendung mit Auslastungstests zusammen finden Sie unter Load test your app in the cloud using Visual Studio and VSTS quickstart (Auslastungstest Ihrer App in der Cloud mithilfe von Visual Studio und VSTS-Schnellstart).

Diagrammwidget für Testpläne und Testsammlungen

Zuvor konnten Sie Diagramme für Testpläne und Sammlungen im Testhub erstellen und diese an das Dashboard anheften. Es wurde ein Widget hinzugefügt, das das Erstellen von Diagrammen für Testpläne und Sammlungen aus dem Widgetkatalog auf dem Dashboard ermöglicht. Sie können Diagramme für den Status „Testerstellung“ und den Status „Testausführung“ erstellen. Darüber hinaus ermöglicht Ihnen das Hinzufügen von Diagrammen aus dem Widget das Erstellen größerer Diagramme, falls weitere Daten auf einem Diagramm angezeigt werden sollen (Abbildung 103).

Chart widget

(Abbildung 103) Diagrammwidget

Unterstützung für Screenshots und Anmerkungen für Desktop-Apps mit dem Browser Chrome für manuelle Tests

Die Unterstützung für einen der Top-Vorschläge von Benutzern der manuellen Tests wird hinzufügt: das Erfassen von Screenshots von Desktopanwendungen über den Web Test Runner im Testhub. Bisher mussten Sie den Test Runner im Microsoft Test Manager verwenden, um Screenshots von Desktop-Apps zu erfassen. Sie müssen die Test & Feedback extension (Test- und Feedback-Erweiterung) installieren, um diese Funktion zu verwenden. Es wird Unterstützung für den Browser Chrome und kurz darauf auch für Firefox geboten.

Einstellung der TFS-Erweiterung für SharePoint

TFS 2018 und höhere Versionen unterstützen die TFS-Erweiterung für SharePoint nicht mehr. Darüber hinaus werden die Anzeigen, die zum Konfigurieren der Integration zwischen einem TFS-Server und einem SharePoint-Server verwendet wurden, aus der Team Foundation-Verwaltungskonsole entfernt.

Hinweis

Wenn Sie ein Upgrade auf TFS 2018 von einer vorherigen Version durchführen, die für die Integration von SharePoint konfiguriert ist, müssen Sie die SharePoint-Integration nach dem Upgrade deaktivieren. Andernfalls kommt es zu Fehlern beim Laden Ihrer TFS-SharePoint-Websites.

Wir haben eine Lösung entwickelt, die es Ihnen ermöglicht, die Integration auf dem SharePoint-Server zu deaktivieren. Weitere Informationen finden Sie im Beitrag zur Zukunft Ihrer TFS-/SharePoint-Integration.

Einstellung von Teamräumen

Moderne Entwicklungsteams sind stark abhängig von Zusammenarbeit. Die Benutzer möchten (und müssen) Aktivitäten (Benachrichtigungen) überwachen und sich über diese austauschen (chatten). Vor ein paar Jahren haben wir diesen Trend erkannt und die Teamräume erstellt, um diese Szenarios zu unterstützen. Seit dieser Zeit haben wir jedoch auf dem Markt weitere Lösungen für die Zusammenarbeit entdeckt. Dabei ist insbesondere der Aufstieg von Slack erwähnenswert. Und in jüngerer Zeit ebenfalls die Ankündigung von Microsoft Teams.

Wegen der vielen verfügbaren Lösungen, die sich gut in TFS und Visual Studio Team Services integrieren lassen, haben wir unsere Pläne announced in January (im Januar angekündigt), unser Feature „Teamräume“ von TFS 2018 und Visual Studio Team Services zu entfernen.


Seitenanfang