Team Foundation Server 2018 RC1: Anmerkungen zu dieser Version

Last Update: 25.09.2017

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

Die neueste Version von Team Foundation Server herunterladen

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


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: 30. August 2017

Zusammenfassung: Team Foundation-Updates in TFS 2018 RC1

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

Zusammenfassung: Neues in diesem Release

Features, die mit dieser Version entfernt wurden:


Details: Neues in diesem Release

Arbeitselementverfolgung

Assistent zur Projekterstellung im Web

Wir haben das Erstellen eines Teamprojekts über den Webzugriff verbessert. Dieser enthält nun den Großteil der Features, die auch beim Erstellen eines Teamprojekts im Visual Studio-Client verfügbar sind. 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.

Mobiles Arbeitselementformular

Wir bieten eine vollständige End-to-End-Erfahrung, die ein optimiertes Erscheinungsbild und Verhalten für Arbeitselemente (Abbildung 1) enthält. Es wird ebenfalls eine einfache Möglichkeit geboten, um über Ihr Telefon mit Elementen zu interagieren, die Ihnen zugewiesen sind, denen Sie folgen, die Sie besucht oder kürzlich bearbeitet haben.

Mobile Arbeitselementabfrage

(Abbildung 1) Mobile Arbeitselementabfrage

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

Mobiles Arbeitselementformular

(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

All 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, nach denen Sie suchen.

Filtern einer Abfrage

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

Verborgenes Feld

*(Abbildung 5) Verborgenes 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).

Aktualisieren verborgener Felder

(Abbildung 6) Aktualisieren verborgener Felder 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.

Versionskontrolle

Forks

TFS 2018 fügt Unterstützung für Git-Forks hinzu (Abbildung 7). 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 (Abbildung 7). 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 7) Git-Forks

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 Untersagen der Webbearbeitung von der Seite Dateien zu Einstellungen und dann zu Versionskontrolle (Abbildung 8). 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“.

Deaktivieren der Webbearbeitung

(Abbildung 8) 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 9).

Dialogfeld Webbearbeitung nicht zulässig

(Abbildung 9) Dialogfeld Webbearbeitung nicht zulä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 10).

Veraltete Verzweigungen

(Abbildung 10) Veraltete Verzweigungen

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

Suche nach gelöschten Verzweigungen

(Abbildung 11) Suche nach gelöschten Verzweigungen

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

Wiederherstellen gelöschter Verzweigungen

(Abbildung 12) Wiederherstellen gelöschter Verzweigungen

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, tippen Sie einfach „dev“ in das Suchfeld, und klicken Sie auf Search in branches starting with "dev" (Suche in Branches, die mit „dev“ beginnen) (Abbildung 13).

Suche nach einem Commit

(Abbildung 13) Suche 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 14). 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.

Legende der Pull Requests

(Abbildung 14) 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 Commit-Struktur (Abbildung 15) und (Abbildung 16):

Suchen einer Datei oder eines Ordners

(Abbildung 15) Suchen einer Datei oder eines Ordners

Gefilterte Ansicht

(Abbildung 16) Gefilterte Ansicht in der Commit-Struktur

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

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

Pushes-Seite

(Abbildung 17) Pushes-Seite

Gleichzeitig wurde der Hub Verlauf in Commits umbenannt (Abbildung 18), 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-Seite

(Abbildung 18) Commits-Seite

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 19). Wenn Sie alle Ihre Tags als Releases verwalten, kann ein Benutzer die Seite „Tags“ besuchen, um alle Produktversionen aus der Vogelperspektive zu betrachten.

Anzeigen von Git-Tags

(Abbildung 19) Anzeigen von Git-Tags

Sie können hier leicht zwischen einem einfachen und einem kommentierten Tag unterscheiden, da kommentierte Tags den Tagger und das Erstellungsdatum zusammen mit dem zugeordneten Commit anzeigen, 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 20).

Hinweis: Das Löschen von Tags von Remoterepositorys sollte mit Vorsicht durchgeführt werden.

Löschen von Git-Tags

(Abbildung 20) 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 den 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 21).

Filtern von Git-Tags

(Abbildung 21) 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 22).

Sicherheit von Git-Tags

(Abbildung 22) 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 23). 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.

Abgeschlossene verknüpfte Arbeitselemente

(Abbildung 23) Abgeschlossene 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 24). Die neue Einstellung ist eine Option in der Richtlinie und benötigt eine Mindestanzahl von Reviewern.

Einstellung zum Zurücksetzen von Stimmen

(Abbildung 24) Einstellung zum Zurücksetzen von 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 25).

Zurücksetzen von Stimmen auf der Zeitachse

(Abbildung 25) Zurücksetzen von Stimmen auf 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 26).

Suchen von Dateien oder Ordnern in Pull Requests

(Abbildung 26) 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 27).

Ergebnisse suchen

(Abbildung 27) Ergebnisse suchen

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 28). Sie können auch nur nach den Diskussionen filtern, an denen Sie teilgenommen haben.

Filtern von PR-Kommentaren

(Abbildung 28) 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 29).

Anzeigen ursprünglicher Unterschiede

(Abbildung 29) Anzeigen ursprünglicher 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 30).

Update-Badge

(Abbildung 30) Update-Badge

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

Verbergen von Kommentaren

(Abbildung 31) Verbergen von Kommentaren

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

Reduzierte Kommentare

(Abbildung 32) 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 33) erleichtern es, einen Kommentar einzusehen, ohne den gesamten Thread anzeigen zu lassen.

QuickInfo für reduzierte Kommentare

(Abbildung 33) 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 34).

Symbolleiste für die Aufgabenliste

(Abbildung 34) Symbolleiste für die Aufgabenliste

Sobald Sie eine Aufgabenliste hinzugefügt haben (Abbildung 35), 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).

Aufgabenliste

(Abbildung 35) 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 36). 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.

Pull Request-Kommentare mit Gefällt mir markieren

(Abbildung 36) Pull Request-Kommentare mit Gefällt mir markieren

Verbesserter Workflow beim Genehmigen mit Vorschlägen

Durch das Verwenden der Option Automatische Vervollständigung (Abbildung 37) 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.

Abbrechen des Dialogfelds für automatische Vervollständigung

(Abbildung 37) Abbrechen des Dialogfelds für automatische Vervollständigung

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

Filtern der Pfade für Benachrichtigungen

(Abbildung 38) Filtern der Pfade für Benachrichtigungen

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

Verbesserte E-Mail-Vorlage

(Abbildung 39) Verbesserte E-Mail-Vorlage

Bei den meisten Benachrichtigungen beinhaltet die Handlungsaufforderung (Abbildung 40) 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.

E-Mail-Handlungsaufforderung

(Abbildung 40) E-Mail-Handlungsaufforderung

Erweiterbarkeit des Status von Pull Requests

Das Verwenden von Branchrichtlinien ist eine gute Möglichkeit, um die Qualität Ihres Codes zu verbessern. Diese Richtlinien sind jedoch begrenzt auf die Integrationen, die nativ von VSTS bereitgestellt werden. Durch das Verwenden der neuen PR-Status-API und der entsprechenden Branchrichtlinie können Dienste von Drittanbietern am PR-Workflow genauso teilnehmen wie native VSTS-Features.

Wenn ein Dienst einen Pull Request in der Status-API veröffentlicht, erscheint dieser sofort in der Ansicht PR-Details im neuen Abschnitt Status (Abbildung 41). Der Abschnitt „Status“ zeigt die Beschreibung an und erstellt einen Link zu der URL, die vom Dienst bereitgestellt wurde. Statuseinträge unterstützen ebenfalls ein Aktionsmenü (...), das erweiterbar ist, um neue Aktionen durch Web-Erweiterungen hinzuzufügen.

Abschnitt für den PR-Status

(Abbildung 41) Abschnitt für den PR-Status

Der Status allein blockiert den Abschluss eines PR nicht. Hier kommt die Richtlinie ins Spiel. Sobald der PR-Status veröffentlicht wurde, kann eine Richtlinie konfiguriert werden. Es ist eine neue Branchrichtlinie verfügbar, um Genehmigung von externen Diensten anzufordern. Klicken Sie auf + Add service (+ Dienst hinzufügen), um den Vorgang zu starten (Abbildung 42).

Neue Richtlinie hinzufügen

(Abbildung 42) PR: Neue Richtlinie hinzufügen

Klicken Sie im Dialogfeld auf den Dienst in der Liste, der den Status veröffentlicht, und wählen Sie die gewünschten Richtlinienoptionen aus (Abbildung 43).

Festlegen von Statusrichtlinien

(Abbildung 43) PR: Festlegen von Statusrichtlinien

Sobald die Richtlinie aktiv ist, wird der Status im Abschnitt Policies (Richtlinien) und gegebenenfalls unter Required (Erforderlich) oder Optional angezeigt und der Abschluss des PR wird gegebenenfalls erzwungen.

Weitere Informationen zur Status-API und Möglichkeiten, diese selbst zu testen, finden Sie in der documentation (Dokumentation und in den samples (Beispielen).

Wiki

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

Wiki-Seite

(Abbildung 44) 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 45) Wiki-Titel

    (Abbildung 45) PR: Wiki-Titel

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

HTML-Tags des Wiki

(Abbildung 46) PR: HTML-Tags des Wiki

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

Größe von Bildern ändern

(Abbildung 47) PR: Größe von Bildern ändern

  • Ein leistungsfähiger Bereich zur Seitenverwaltung, der es ermöglicht, Seiten neu anzuordnen, neu zuzuordnen und zu verwalten.
  • Filtern von Seiten nach Titeln auf großen Wikis (Abbildung 48)

Wiki-Menü

(Abbildung 48) 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 Revert (Wiederherstellen) klicken (Abbildung 49).

Wiki-Schaltfläche zum Wiederherstellen

(Abbildung 49) PR: Wiki-Schaltfläche zum Wiederherstellen

Erstellen einer Wiki-Seite aus einem fehlerhaften Link Während der Erstellung des Wikis erstellen manche Benutzer für eine Wiki-Seite ein Inhaltsverzeichnis, das nicht vorhandene Links enthält (Abbildung 50). Infolgedessen würden Benutzer auf diese Links klicken, um die eigentlichen Seiten zu erstellen. Früher haben wir dieses Szenario behandelt, indem eine Warnung angezeigt wurde, die darauf hinweist, dass der Link fehlerhaft ist oder die Seite nicht existiert. Mittlerweile behandeln wir dies als das gängige Szenario für Wiki, indem wir Ihnen stattdessen ermöglichen, diese Seiten zu erstellen.

Erstellen einer Wiki-Seite

(Abbildung 50) PR: Erstellen einer Wiki-Seite

Die Wiki extension (Wiki-Erweiterung) auf dem Marketplace ist nun veraltet. Wenn Sie ein bestehender Benutzer der Wiki-Erweiterungen sind, 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 50). Das Format ist: <tfsserverurl>/<project|team>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package.

Paket-URL

(Abbildung 51) PR: Paket-URL

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

Verbergen gelöschter Pakete

(Abbildung 52) Verbergen 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 53), die relative Datumsangaben enthält, sodass Sie kürzlich aktualisierte Pakete leicht finden können.

Spalte für letzte Übertragung mittels Push

(Abbildung 53) Spalte für letzte Übertragung mittels Push

Maven-Pakete

Ab sofort werden Maven-Artefakte in TFS 2018 unterstützt (Abbildung 54). 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-Pakete

(Abbildung 54) 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 55).

NuGet-Aufgabe

(Abbildung 55) NuGet-Aufgabe

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 das Veröffentlichen haben wir das Abrufen von Anmeldeinformationen vereinfacht, sodass die Anmeldeinformationen für Registrierungen, die in der „.NPMRC“-Datei Ihres Projekts aufgelistet sind, sicher in einem service endpoint (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 die Maven-Aufgabe aktualisiert, sodass Sie einfacher mit VSTS- und TFS-Feeds arbeiten können (Abbildung 56).

dotnet-Aufgabe

(Abbildung 56) dotnet-Aufgabe

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

Verwendbare Feeds

(Abbildung 57) Verwendbare Feeds

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

Feed-Auswahl

(Abbildung 58) 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 Veraltungsplans für XAML-Builds finden Sie in this blog post (diesem Blogbeitrag).

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 59 und Abbildung 60).

Exportieren von Build-Definitionen

(Abbildung 59) Exportieren von Build-Definitionen

Importieren von Build-Definitionen

(Abbildung 60) Importieren von Build-Definitionen

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

Badge für veraltete Aufgaben

(Abbildung 61) Badge für veraltete Aufgaben

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

Beschreibung für veraltete Aufgaben

(Abbildung 62) 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 secure files library (Bibliothek für sichere Dateien) hinzugefügt (Abbildung 63).

Bibliothek für sichere Dateien

(Abbildung 63) 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:

Neuer Editor für Releasedefinitionen

Standardmäßige Übernahme: Der neue Editor für Releasedefinitionen wurde standardmäßig für alle Benutzer übernommen. Sie oder Ihre TFS-Administratoren haben dennoch die Option, diesen zu deaktivieren, indem Sie zur Option Vorschaufeatures in Ihrem Profilmenü navigieren. Weitere Informationen finden Sie unter Preview features (Vorschaufeatures).

Die Aktualisierungen der Build- und Releasefeatures betreffen nach dem Editor für Builddefinitionen nun auch den Editor für Releasedefinitionen. Dieser wurde neu gestaltet und ist nun übersichtlicher und intuitiver zu bedienen. Außerdem wurden einige Probleme behoben und neue Funktionen hinzugefügt. Eines der leistungsstärksten Features des neuen Editors ist die Möglichkeit, ein mentales Modell zu erstellen oder den Fortschritt Ihrer Bereitstellungen für die Umgebungen zu visualisieren. Zusätzlich sind Genehmigungen, Umgebung und Bereitstellungseinstellungen nun kontextbezogen und leicht zu konfigurieren (Abbildung 65).

Visualisierung der Pipeline

Die Pipeline (Abbildung 64) 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 64) Releasepipeline

Kontextbezogene Konfigurationen der UI

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

Releasekonfiguration

(Abbildung 65) Releasekonfiguration

Erste Schritte mit Bereitstellungsvorlagen

Die Liste der Standardvorlagen und benutzerdefinierten Vorlagen wird angezeigt, wenn eine neue Umgebung erstellt wird, um die ersten Schritte zu erleichtern (Abbildung 66).

Bereitstellungsvorlagen

(Abbildung 66) Bereitstellungsvorlagen

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 67). 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 67) Task-Editor

Registerkarten für variable Gruppen, Beibehaltung und Optionen

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

Variable Gruppen

(Abbildung 68) Variable Gruppen

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

Umgebungsmenü

(Abbildung 69) Umgebungsmenü

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 70) ist eine logische Gruppe von Zielen (Computern), auf denen jeweils Agenten 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.

Bereitstellungsgruppen

(Abbildung 70) 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 eine 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 71). 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.

Konfigurieren von Bereitstellungsgruppen

(Abbildung 71) 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 72).

Fortschritt der Bereitstellungsgruppe

(Abbildung 72) Fortschritt der Bereitstellungsgruppe

Dieses Feature ist nun in Release Management enthalten. Es werden keine zusätzlichen Lizenzen benötigt, um es zu benutzen.

Verweise auf Arbeitsgruppen

Über Aufgabengruppen können Sie eine Reihe von Aufgaben definieren, die Sie zu Ihren Build- oder Releasedefinitionen hinzufügen können. 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 die Aufgabengruppen, die auf Ihre Aufgabengruppen verweisen, um Sie beim Nachverfolgen der Consumer einer Aufgabengruppe zu unterstützen (Abbildung 73).

Verweise von Aufgabengruppen

(Abbildung 73) Verweise von 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 74).

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

Als Entwurf speichern

(Abbildung 74) Aufgabengruppe als Entwurf speichern

Aufgabengruppe als Vorschauversion veröffentlichen

(Abbildung 75) Aufgabengruppe als Vorschauversion veröffentlichen

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

Exportieren von Aufgabengruppen

(Abbildung 76) Exportieren von Aufgabengruppen

Unterstützung mehrerer Konfigurationen in serverseitigen (agentenlosen) Aufgaben

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

Mehrere Konfigurationen für agentenlose Aufgaben

(Abbildung 77) Mehrere Konfigurationen für agentenlose Aufgaben

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

Die Aufgabe für Manueller Eingriff (Abbildung 78)unterstützt nun die Verwendung von Variablen innerhalb des Anweisungstext, 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 in den E-Mails verwendet, die an Benutzer gesendet werden (Abbildung 79).

Manuelles Eingreifentask

(Abbildung 78) Aufgabe für manuelles Eingreifen

Dialogfeld für ausstehende manuelle Eingriffe

(Abbildung 79) Dialogfeld für ausstehende manuelle Eingriffe

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

Dialogfeld für Bereitstellungsbedingungen

(Abbildung 80) Dialogfeld für Bereitstellungsbedingungen

Zusätzlich enthält die Seite Releasezusammenfassung (Abbildung 81) 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.

Tipps für die Releasezusammenfassung

(Abbildung 81) 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 82) 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.

Releasetrigger

(Abbildung 82) 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.

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 83) 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-Aufgabe

(Abbildung 83) REST-API-Aufgabe

Wir haben auch den Abschnitt Steuerungsoptionen (Abbildung 84) 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.

Optionen zur Aufgabensteuerung

(Abbildung 84) 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 85). Dadurch wird die Nachverfolgbarkeit von mittels Commits an Bereitstellungen übertragenem Code verbessert.

Badge für den Releasestatus

(Abbildung 85) 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 86).

Dialogfeld für Bereitstellungsoptionen

(Abbildung 86) Dialogfeld für 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 87). Dadurch wird es leichter, Builddefinitionen zu unterscheiden, die denselben Namen haben, sich aber in unterschiedlichen Ordnern befinden.

Artefakt hinzufügen

(Abbildung 87) Artefakt hinzufügen

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 88), durch das Sie eine frühere Version einer Releasedefinition in der Registerkarte Versionsgeschichte auswählen und wiederherstellen können.

Releasedefinition wiederherstellen

(Abbildung 88) Releasedefinition wiederherstellen

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.

Ein Upgrade auf TFS 2018 hat folgende Auswirkungen:

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

Filter für Testfälle

(Abbildung 89) 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 90), 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.

Trenddiagramm für Tests

(Abbildung 90) 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.

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 werden zukünftig keine Server-zu-Server-Integration mehr unterstützen. Außerdem werden wir das Verwenden von öffentlichen APIs und erweiterbaren Frameworks integrieren.

Wenn Sie einen Server aktualisieren, bei dem die Integration von TFS bzw. SharePoint konfiguriert wurde, können Sie die von uns bereitgestellte Lösung nutzen und ein Upgrade weg von der Server-zu-Server-Integration durchführen. Ihre TFS-SharePoint-Websites werden nach dem Upgrade weiterhin angezeigt, aber die Integrationsfeatures werden deaktiviert. Weitere Informationen und Anweisungen finden Sie here (hier).

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.


Bekannte Probleme

Der Datenbankimportdienst von TFS unterstützt keine RC-Versionen

Der Datenbankimportdienst von TFS für Visual Studio Team Services unterstützt keine Importe aus RC-Versionen von TFS. Wenn Sie vorhaben, Ihre Auflistungsdatenbank mit diesem Dienst in Team Services zu importieren, ist es essentiell, dass Sie Ihre Produktionsdatenbank nicht auf die RC-Version aktualisieren. Wenn Sie das Upgrade durchführen, müssen Sie warten und auf die RTW-Version dieser Version aktualisieren oder eine Sicherungskopie Ihrer Datenbank aus einer vorherigen TFS-Version wiederherstellen, um diese zu importieren.

Aufgaben von Visual Studio Test (Version 1) können in Build und Release keine Tests mithilfe von Visual Studio 2017 Update 3 ausführen.

Die Aufgabe von Visual Studio Test (Version 1) kann in Build und Release keine Tests mithilfe von Visual Studio 2017 Update 3 ausführen. Die Aufgabe schlägt mit der Meldung „Der Speicherort von ‚vstest.console.exe‘ kann nicht ermittelt werden“ fehl. Die Problembehebung besteht darin, Version 2 der Aufgabe von Visual Studio Test zu verwenden.