Versionshinweise zu Team Foundation Server 2018

---

Entwicklercommunity | Systemanforderungen und Kompatibilität | Lizenzbedingungen | TFS-DevOps-Blog | SHA-1-Hashes | Neueste Versionshinweise für Visual Studio 2019

---

---

In diesem Artikel erhalten Sie Informationen zu Team Foundation Server 2018. Klicken Sie zum Herunterladen auf die Schaltfläche.

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). Besuchen Sie die Seite visualstudio.com/downloads, um andere TFS 2018-Produkte herunterzuladen.

Weitere Informationen finden Sie auf der Seite für die Installation von TFS.

---

Veröffentlichungsdatum: 15. November 2017

Zusammenfassung: Neues in TFS 2018

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

• Wir haben den Projekterstellungs-Assistenten und den Prozessvorlagen-Manager im Web verbessert.
• Sie können nun den Header des Arbeitselementformulars anpassen.
• Wir haben das mobile Arbeitselementformular optimiert.
• Wir haben Unterstützung für Git forks (Git-Forks) hinzugefügt.
• Sie können große Git-Repositorys mit GVFS verwalten.
• Sie können Git-Tags anzeigen, filtern, löschen und Sicherheitseinstellungen für diese festlegen.
• Wir haben Folgendes zur Webcodebearbeitung hinzugefügt: eine Minikarte von Dateien, das Zuordnen von Klammern und das Umschalten von Leerräumen.
• Wir haben viele Verbesserungen an Pull Requests vorgenommen.
• Sie können nun ein neues und verbessertes Wiki nutzen.
• Wir haben Unterstützung für Maven-Pakete hinzugefügt.
• Sie können Builddefinitionen importieren und exportieren und diese anhalten.
• Der neue Editor für Releasedefinitionen verfügt standardmäßig über Opt-in.
• Sie können mithilfe von virtuellen Computern Bereitstellungen durchführen.
• Wir haben die improved exploratory testing traceability (Nachverfolgbarkeit für explorative Tests verbessert).
• Wir haben die Testbatchverarbeitung hinzugefügt.
• Sie können jetzt ein Diagrammwidget für Testpläne und Testsammlungen anzeigen.

Neues in TFS 2018: Video

XAML-Build

Der XAML-Build wurde ursprünglich als aus TFS 2018 RTW und Update 1 entfernt aufgeführt. Jedoch konnten dann viele Kunden kein Upgrade mehr durchführen oder mussten sich an den Support wenden, um den XAML-Build wieder zu aktivieren, nachdem das Upgrade abgeschlossen war. In TFS 2018 Update 2 ist der XAML-Build zwar aktiviert, er ist jedoch als veraltet gekennzeichnet. Das bedeutet, dass nicht weiter in den XAML-Build investiert wird, und Microsoft Test Manager (MTM) unterstützt nicht länger die Verwendung von XAML-Builds. Es wird empfohlen, eine Konvertierung in eines der neueren Builddefinitionsformate durchzuführen. Sie können möglicherweise weiterhin Ihre XAML-Controller verbinden und XAML-Builds mit TFS 2018 Update 2 ausführen. Weitere Informationen

Features, die in TFS 2018 RTW entfernt wurden

• Die Unterstützung für Lab-Center und automatisierte Testabläufe in Microsoft Test Manager wurde entfernt.
• Wir unterstützen die TFS-Erweiterung für SharePoint nicht mehr.
• Wir haben das Feature Teamraum entfernt.

---

Ausführlicher Überblick: Neues in TFS 2018

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.

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.

Mobiles Arbeitselementformular

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

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

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.

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.

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 leeres Feld, sobald es verborgen war, 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.

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

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.

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.

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 Internet 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:

In TFVC geben Sie einen Ordnernamen an und checken diesen Ordner 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.

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.

Klammernabgleich

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

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.

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.

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

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

Suche nach einem gelöschten Branch und Neuerstellung desselben

Wenn Sie einen Branch versehentlich vom Server gelöscht haben, 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).

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

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 In Branches suchen, die mit „dev“ beginnen (Abbildung 19).

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.

Filtern der Strukturansicht in Code

Sie müssen nun nicht mehr durch alle Dateien scrollen, die ein Commit modifiziert haben könnte, 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):

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 „Branchupdates“ 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.

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.

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, eine Übersicht über alle Produktreleases zu erhalten.

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

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

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

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

Beim Verknüpfen von Arbeitselementen mit Ihren 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 Pull Requests 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 Pull Request abgeschlossen wurde. Dies wird automatisch für Sie ausgeführt.

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.

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

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

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

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.

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

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

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

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

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.

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

Sobald Sie eine Aufgabenliste hinzugefügt haben (Abbildung 41), können Sie einfach die Kontrollkästchen aktivieren, 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).

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.

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.

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

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

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

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.

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.

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

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

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

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

• Offline updates (Offline-Updates) für die Hauptbenutzer des 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).

Erstellen einer Wikiseite anhand eines fehlerhaften Links

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.

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 im Artikel zum Migrieren bestehender 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.

Sie können nun gelöschte Paketversionen (Abbildung 56) von allen Feedbenutzern ausblenden und so durchgestrichene Pakete vermeiden.

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.

Maven-Pakete

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

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 einigen im Folgenden 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, der 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-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, funktioniert die neue npm-Buildaufgabe reibungslos. 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-Agent 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 die Maven-Aufgabe aktualisiert, sodass Sie einfacher mit VSTS- und TFS-Feeds arbeiten können (Abbildung 60).

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. Hierzu gehören folgende Elemente:

1. dotnet unterstützt nun authentifizierte Paketquellen wie die Paketverwaltung, 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 „publish“ 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 veröffentlicht, den dotnet-Tool-Installer, der 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.

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

Build und Release

XAML-Builds

Mit TFS 2015 haben wir ein webbasiertes, plattformübergreifendes Buildsystem eingeführt. XAML-Builds werden in TFS 2018 RTW oder Update 1 nicht unterstützt. Wir haben XAML-Builds in TFS 2018 Update 2 jedoch erneut aktiviert. 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, führen Sie ein Upgrade auf TFS 2018 Update 2 durch.

Wenn Sie ein Upgrade auf TFS 2018 RTW oder Update 1 durchführen, können Sie folgende Aktionen durchführen:

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

• Sie können abgeschlossene XAML-Builds anzeigen lassen, aber Sie können keine neuen der Warteschlange hinzufügen.

• In TFS 2018 gibt es keine neue Version des XAML-Buildcontrollers bzw. -Build-Agents.

Wenn Sie ein Upgrade auf TFS 2018 Update 2 durchführen:

• Wenn sich noch irgendwelche XAML-Builddaten in Ihrer Teamprojektsammlung befinden, wird Ihnen die Warnung angezeigt, dass die XAML-Buildfeatures veraltet sind.

• Sie müssen Visual Studio oder Team Explorer 2017 verwenden, um XAML-Builddefinitionen zu bearbeiten oder um neue XAML-Builds in die Warteschlange aufzunehmen.

• Wenn Sie neue XAML-Build-Agents erstellen müssen, müssen Sie diese mithilfe des TFS 2015-Build-Agent-Installers installieren.

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. Das war eine der zehn häufigsten Anfragen auf UserVoice.

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

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.

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.

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.

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

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:

• Utility: Install Apple Certificate (Hilfsprogramm: Installieren von Apple-Zertifikaten)

• Utility: Install Apple Provisioning Profile (Hilfsprogramm: Installieren des Apple-Bereitstellungsprofils)

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.

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

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

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

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

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.

Registerkarten für variable Gruppen, Beibehaltung und Optionen

Sie können jetzt verknüpfungen/aufheben mit Variablengruppen (Abbildung 73), Aufbewahrungsrichtlinie für einzelne Umgebungen festlegen und Einstellungen auf Freigabedefinitionsebene ändern, z. B. freigabenummernformat auf der Registerkarte "Optionen ". Sie können eine Umgebung auch als Bereitstellungsvorlage speichern, Berechtigungen auf Umgebungsebene festlegen und Phasen auf der Registerkarte "Aufgaben " neu anordnen.

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

Bereitstellung virtueller Computer 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, z. B. Single-Box Dev, Multi-Machine QA und eine Farm von Computern für UAT/Prod. Sie geben auch den Sicherheitskontext für Ihre physischen Umgebungen an.

Sie können diese für jeden virtuellen Computer verwenden,für den Sie unseren Agent registrieren. Wir haben ebenfalls die Registrierung bei Azure erleichtert, indem wir Unterstützung für die Azure-VM-Erweiterung hinzugefügt haben, die den Agent automatisch installiert, wenn ein virtueller Computer gestartet wird. Die Tags auf dem virtuellen Azure-Computer werden automatisch geerbt, sobald dieser 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.

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

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.

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.

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

Wenn Sie versuchen, eine Aufgabengruppe zu löschen, auf die 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 verwenden, automatisch über den Hauptkanal aktualisiert (Abbildung 82).

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.

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.

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

Die Aufgabe Manueller Eingriff(Abbildung 85) unterstützt nun die Verwendung von Variablen innerhalb des Anweisungstexts, der Benutzern beim Ausführen der Aufgabe angezeigt 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).

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

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.

Releasetrigger für Git-Repositorys als Artefaktquelle

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

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

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 eine generische HTTP-REST-API (Abbildung 91) als Teil der automatisierten Pipeline aufruft. Sie kann beispielsweise verwendet werden, um eine bestimmte Verarbeitung mit einer Azure-Funktion aufzurufen und zu warten, bis diese abgeschlossen ist.

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.

Badge für den Releasestatus in Codehub

Wenn Sie wissen wollen, ob ein Commit für die Produktionsumgebung Ihrer Kunden bereitgestellt wurde, müssen Sie zunächst den Build identifizieren, der den Commit nutzt, und dann alle Releaseumgebungen überprüfen, in denen 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 im letzten Commit veröffentlicht, 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 Badge, und der Status wird für jede Umgebung angezeigt (Abbildung 93). Dadurch wird die Nachverfolgbarkeit von mittels Commits an Bereitstellungen übertragenem Code verbessert.

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

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.

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.

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 Releasebeteiligten nützlich sowie für alle anderen Personen außer der genehmigenden Person, dem Ersteller des Releases und dem Besitzer der Umgebung, die ggf. benachrichtigt werden möchten (Abbildung 97).

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:

• Nicht mehr unterstützt:
  • Testcontroller können nicht mit TFS registriert werden, um Laborumgebungen zu erstellen und zu verwalten.
  • Bestehende Testcontroller, die mit TFS registriert sind, wechseln in den Offlinemodus und bestehende Laborumgebungen werden als „Nicht bereit“ angezeigt.
• Empfohlene Alternative:
  • Sie können sich mithilfe der SCVMM-TFS-Erweiterung mit Ihrem SCVMM-Server verbinden und virtuelle Computer erstellen und verwalten, auf denen Ihre Workflows ausgeführt werden. Weitere Informationen finden Sie unter How to perform Lab management operations in Build and Release (Vorgehensweise: Durchführen von Lab Management-Vorgängen in Builds und Releases).

Automatisiertes Testen:

• Nicht mehr unterstützt:
  • Automatisierte Testworkflows, die auf Testcontrollern und Laborumgebungen wie dem Workflow für XAML-Builds, -Bereitstellungen und -Tests basieren oder solche, die automatisierte Tests mithilfe von MTM aus einem Testplan ausführen, werden nicht mehr unterstützt.
• Empfohlene Alternativen:
  • Sie können run automated tests in Build and Release (automatisierte Tests in Builds und Releases ausführen).
  • Sie können run automated tests from a test plan using the Test hub (automatisierte Tests mithilfe des Testhub aus einem Testplan ausführen).

Manuelles Testen:

• Alle manuellen Testszenarios werden weiterhin vollständig unterstützt. Während manuelle Tests in TFS 2018 mithilfe von MTM ausgeführt werden können, ist dies mit Laborumgebungen nicht möglich.
• Für alle manuellen Testszenarios strongly recommend using the Test hub (empfehlen wir die Verwendung des Testhub) im TFS-Webzugriff.

Verbesserungen bei der Nachverfolgbarkeit von explorativen Tests für Links zu Arbeitselementen, Iterationen und Bereichspfaden

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 erstellten Testfälle 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).

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.

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.

Hinzufügen eines Links zu einem bestehenden Fehler für einen fehlgeschlagenen Test

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.

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

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.

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.

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

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.

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.

---

Sind Sie zufrieden?

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.

---

Seitenanfang