Team Foundation Server 2017

Last Update: 04.04.2017

Releasedatum: 16. November 2016

Um die neuesten Updates anzuzeigen, besuchen Sie die englischen Anmerkungen zu dieser Version.

Wir freuen uns, Ihnen heute die Veröffentlichung von Team Foundation Server 2017 bekanntgeben zu können. Diese neue Version enthält unsere neuesten Innovationen und Verbesserungen für Features. Beachten Sie, dass sich die Anforderungen für Team Foundation Server 2017 geändert haben. Weitere Informationen finden Sie auf der Seite Team Foundation Server Requirements and Compatibility (Team Foundation Server – Anforderungen und Kompatibilität). Wenn es sich dabei nicht um die Anmerkungen zum Release handelt, die Sie erwartet haben: Sie sind bei den Anmerkungen zum Release der aktuellsten Version gelandet.

Herunterladen: Team Foundation Server 2017

Weitere Informationen zu verwandten Downloads finden Sie auf der Seite Downloads.

Neues

Bekannte Probleme


Neues

Codesuche

Die Codesuche ermöglicht eine schnelle, flexible und genaue Suche in Ihrem gesamten Code. Wenn Ihre Codebasis immer größer wird und auf zahlreiche Projekte und Repositorys verteilt ist, wird es zunehmend schwieriger, das Gesuchte zu finden. Um die teamübergreifende Zusammenarbeit und Codefreigabe zu maximieren, können Sie mithilfe der Codesuche relevante Informationen in allen Ihren Projekten schnell und effizient finden.

Von der Ermittlung von Beispielen der Implementierung einer API über das Durchsuchen ihrer Definition bis zur Suche nach Fehlertext bietet die Codesuche eine zentrale Lösung für alle Ihre Anforderungen an die Untersuchung und Problembehandlung von Code.

Die Codesuche bietet Folgendes:

  • Eine Suche in einem oder mehreren Projekten
  • Semantische Rangfolge
  • Umfassende Filtermöglichkeiten
  • Zusammenarbeit an Code

Codesuche

Weitere Informationen finden Sie unter Durchsuchen Ihres gesamten Codes.

Paketverwaltung

Mit Paketen können Sie Code für die gesamte Organisation freigeben: Sie können ein großes Produkt zusammensetzen, mehrere Produkte auf Grundlage eines gemeinsam genutzten Frameworks entwickeln oder wiederverwendbare Komponenten und Bibliotheken erstellen und freigeben. Der Paketverwaltungsdienst vereinfacht die Codefreigabe, indem Ihre Pakete gehostet werden, und diese für die von Ihnen ausgewählten Personen freigegeben werden. So stehen die Pakete problemlos für Team Build und Release Management zur Verfügung.

Der Paketverwaltungsdienst beseitigt die Notwendigkeit, einen separaten NuGet-Server oder eine Dateifreigabe zu hosten, da er NuGet-Pakete direkt auf Ihrem Team Foundation-Server hostet. Er verfügt über den besten Support für NuGet 3.x sowie für Legacyclients von NuGet 2.x. Der Paketverwaltungsdienst arbeitet nahtlos mit Ihrer vorhandenen TFS-Infrastruktur, Ihren Teams und Berechtigungen, und deshalb müssen Sie sich nicht um das Synchronisieren von Identitäten kümmern oder um das Verwalten von Gruppen an mehreren Orten usw. Außerdem kann er einfach in Team Build integriert werden und Pakete in fortlaufenden Integrationsworkflows verwenden.

Weitere Informationen finden Sie unter der Paketverwaltung.

Paketverwaltung

Agile-Verbesserungen

Wir haben Team Foundation Server 2017 um neue Features und Funktionen für Arbeitselemente und Kanban-Boards erweitert.

Neues Formular für Arbeitselemente

Das neue Formular für Arbeitsaufgaben hat ein neues Aussehen und Verhalten. Außerdem wurden einige wichtige neue Features hinzugefügt:

  • Eine umfassende Umgebung zur Diskussion über Arbeitsaufgaben
  • Drag & Drop-Unterstützung für Anlagen
  • Verbesserte Verlaufsoberfläche (Verlauf und Überwachung)
  • Verbesserte Code- und Buildintegration
  • Verschiedene Zustandsfarben
  • Responsive Design
Hinweis

Das neue Arbeitselementformular ist nur für neue Sammlungen die Standardeinstellung. Wenn Sie eine vorhandene Sammlung migrieren, müssen Sie das neue Formular für Arbeitselemente aus den Administratoreinstellungen aktivieren. Weitere Informationen finden Sie unter Verwalten des Rollouts des neuen Webformulars.

Neues Formular für Arbeitsaufgaben

Nachverfolgen eines Arbeitselements

Sie können nun eine Benachrichtigung für das Nachverfolgen von Änderungen an einer einzelnen Arbeitsaufgabe einrichten, indem Sie auf dem Formular auf die neue Schaltfläche „Folgen“ klicken. Wenn Sie einer Arbeitsaufgabe folgen, werden Sie immer dann benachrichtigt, wenn sich die Arbeitsaufgabe ändert, so z. B. bei Aktualisierungen von Feldern, Links, Anlagen und Kommentaren.

Folgen einer Arbeitsaufgabe

Weitere Informationen finden Sie unter Folgen einer Arbeitsaufgabe.

Liveupdates von Kanban-Boards

Ihr Kanban-Board ist jetzt live!

Haben Sie F5 gedrückt, um herauszufinden, was im Lauf des Tages auf Ihrem Kanban-Board passiert ist? Klicken Sie auf das Symbol im nachstehenden Screenshot.

Live-Updates von Kanban

Wenn jemand in Ihrem Team eine Arbeitsaufgabe auf dem Board erstellt, geändert oder gelöscht hat, erhalten Sie in Ihrem Board sofort Live-Updates. Auch wenn der Administrator Aktualisierungen auf Board- oder Teamebene vornimmt, z. B. eine neue Spalte hinzufügt oder Fehler im Backlog aktiviert, werden Sie in einer Benachrichtigung aufgefordert, das Layout Ihres Boards zu aktualisieren. Sie brauchen jetzt nichts weiter zu tun, als das Turmsymbol auf Ihrem Kanban-Board zu aktivieren und die Zusammenarbeit mit Ihrem Team zu starten.

Weitere Informationen finden Sie unter Kanban-Grundlagen.

Verbesserungen bei Prüflisten

Wir haben eine Reihe von Verbesserungen an der Funktionsweise von Prüflisten vorgenommen.

Titel von Prüflisten werden nun als Links angezeigt. Sie können auf den Titel klicken, um das Arbeitsaufgabenformular zu öffnen.

Verbesserungen bei Prüflisten

Prüflisten unterstützen jetzt auch Kontextmenüs, über die Sie Prüflistenelemente öffnen, bearbeiten oder löschen können.

Verbesserungen bei Prüflisten (2)

Weitere Informationen finden Sie unter Add task checklists (Hinzufügen von Task-Prüflisten).

Ausführen von Drilldowns im Epic- und Featureboard

Sie haben jetzt die Möglichkeit, in Ihren Epic- und Feature-Boards einen Drilldown auszuführen. Das Prüflistenformat ermöglicht Ihnen das einfache Markieren von Aufgaben als erledigt und bietet eine praktische Übersicht über die abgeschlossen und noch ausstehenden Aufgaben.

Drilldown im Epic- und Feature-Board

Weitere Informationen finden Sie unter Kanban features and epics (Kaban-Features und -Epics).

Aktivieren/Deaktivieren von Boardanmerkungen

Wir bieten Ihnen mehr Kontrolle über die zusätzlichen Informationen, die auf den Karten Ihrer Boards angezeigt werden. Sie können jetzt Anmerkungen auswählen, die Sie auf Ihren Kanban-Karten anzeigen möchten. Deaktivieren Sie einfach eine Anmerkung, wenn sie nicht mehr auf den Karten Ihres Kanban-Boards angezeigt werden soll. Die ersten beiden hier gezeigten Anmerkungen sind untergeordnete Arbeitsaufgaben (Aufgaben in diesem Beispiel) und die Anmerkung „Test“.

Einschalten von Board-Anmerkungen

Weitere Informationen finden Sie unter Customize Cards (Anpassen von Karten).

Befehl „Formatierung löschen“

Wir haben allen umfassenden Textsteuerelementen für Arbeitsaufgaben einen neuen Befehl hinzugefügt, der Ihnen das Löschen sämtlicher Formatierungen aus dem ausgewählten Text ermöglicht. Wenn Sie so sind wie ich, haben Sie sich bestimmt in der Vergangenheit auch beim Kopieren und Einfügen von formatiertem Text in dieses Feld, das Sie nicht rückgängig machen (oder löschen) konnten, die Finger verbrannt. Jetzt können Sie Text einfach markieren und die Symbolleistenschaltfläche „Formatierung löschen“ wählen (oder STRG+LEERTASTE drücken), damit der Text wieder sein Standardformat erhält.

Filtern im Kanban-Board

Personalisieren Sie Ihre Kanban-Boards durch Festlegen von Filtern für Benutzer, Iterationen, Arbeitsaufgabentypen und Tags. Diese Filter bleiben erhalten, sodass Sie Ihr personalisiertes Board auch anzeigen können, wenn Sie auf mehreren Geräten eine Verbindung herstellen.

Filtern im Kanban-Board

Teammitglieder können ihre Boards auch filtern, um den Status eines bestimmten übergeordneten Arbeitselements anzuzeigen. Ein Benutzer kann z.B. User Storys anzeigen, die mit einem Feature verknüpft sind, oder Arbeitselemente für zwei oder mehr Features anzeigen, die sich zu einem Epic verbinden. Dieses Feature ist – ähnlich wie Prüflisten – ein weiterer Schritt hin zu unserem Ziel, Transparenz bis auf die verschiedenen Backlogebenen zu gewährleisten.

Weitere Informationen finden Sie unter Filter Kanban board (Filtern von Kanban-Board).

Standarditerationspfad für neue Arbeitselemente

Wenn Sie auf der Registerkarte „Abfragen“ oder im Dashboardwidget „Neue Arbeitsaufgabe erstellen“ eine neue Arbeitsaufgabe erstellen, wird der Iterationspfad dieser Arbeitsaufgabe stets auf die aktuelle Iteration festgelegt. Dies ist nicht, was sich alle Teams wünschen, weil dies bedeutet, dass Fehler sofort im Task Board angezeigt werden. Dank dieser Verbesserung können Teams den Standarditerationspfad (einen bestimmten oder die aktuelle Iteration) wählen, der für neue Arbeitsaufgaben verwendet werden soll. Navigieren Sie zum Verwaltungsbereich Ihres Teams, um eine Standarditeration zu wählen.

Weitere Informationen finden Sie unter Bereichs-und Iterationspfade.

Kontrollkästchen-Steuerelement

Sie können Ihren Arbeitsaufgaben nun ein Kontrollkästchen-Steuerelement hinzufügen. Dieser neuen (boolesche) Feldtyp hat alle Eigenschaften normaler Felder und kann allen Typen in Ihrem Prozess hinzugefügt werden. Bei Anzeige auf Karten oder in einem Abfrageergebnis wird der Wert als „Wahr/Falsch“ angezeigt.

Kontrollkästchen-Steuerelement

Weitere Informationen finden Sie unter Customize a field (Anpassen eines Felds).

Massenbearbeitung von Tags

Sie können jetzt über das Dialogfeld zur Massenbearbeitung Tags in mehreren Arbeitselementen hinzufügen oder daraus entfernen.

Tags

Weitere Informationen finden Sie unter Hinzufügen von Tags zu Arbeitstasks.

Neue Erweiterungspunkte

Wir haben auf den Seiten „Board“ und „Backlog“ einen neuen Beitragspunkt hinzugefügt, sodass Sie Erweiterungen neben den Registerkarten Board, Backlog und Kapazität als Pivotregisterkarte schreiben können.

Wir haben einen neuen Erweiterungspunkt im Backlog verfügbar gemacht. Extensions können auf den rechten Bereich zielen, in dem sich aktuell Zuordnung und Arbeitsdetails befinden.

Backlog-Erweiterungspunkte

Weitere Informationen zu Erweiterungen finden Sie unter Extension Points (Erweiterungspunkte).

E-Mail-Verbesserungen

Wir haben die Formatierung und die Nutzbarkeit von Arbeitselementwarnungen, Nachverfolgungen und @mention-E-Mails, die von TFS gesendet werden, erheblich verbessert. E-Mail-Nachrichten enthalten jetzt einen konsistenten Header, einen klaren Handlungsaufruf und eine verbesserte Formatierung, um dafür zu sorgen, dass die Informationen in der E-Mail einfacher zu nutzen und zu verstehen sind. Darüber hinaus sind alle diese E-Mails so ausgelegt, dass sie auf mobilen Geräten gut lesbar sind.

E-Mail-Verbesserungen

Weitere Informationen finden Sie unter Work item alerts (Arbeitstaskbenachrichtigungen).

Arbeitselementvorlagen

Wir haben die Funktion zum Erstellen umfassender Vorlagen für Arbeitsaufgaben direkt zur nativen Weboberfläche hinzugefügt. Diese Funktionalität war bisher im Web stark eingeschränkt und in dieser neuen Form nur mithilfe eines Visual Studio Power Tools verfügbar. Teams können jetzt einen Satz Vorlagen erstellen, um häufig verwendete Felder schnell zu ändern.

Arbeitsaufgabenvorlagen

Weitere Informationen finden Sie unter Arbeitstaskvorlagen.

Keine Unterstützung mehr für Project Server-Integration

In Team Foundation Server 2017 und höheren Versionen wird die Project Server-Integration nicht mehr unterstützt. Wenn Sie eine TFS-Datenbank aktualisieren, für die Project Server-Integration konfiguriert ist, erhalten Sie ab RC2 die folgende Warnung:

Wir haben festgestellt, dass Sie für diese Datenbank Project Server-Integration konfiguriert haben. In Team Foundation Server „2017“ und höheren Versionen wird die Project Server-Integration nicht mehr unterstützt.

Nach der Aktualisierung ist die Project Server-Integration nicht mehr funktional.

Zukünftig werden Lösungen für die Integration von Partnern angeboten.

Weitere Informationen zu dieser Änderung finden Sie im folgenden Thema: Synchronisieren von TFS mit Project Server.

Verbesserungen bei Dashboards und Widgets

Team Foundation Server 2017 bietet Verbesserungen bei zahlreichen Widgets, wie z.B. der Abfragekachel und „Pull Request“.

Überarbeiteter Widgetkatalog

Wir haben unseren Widgetkatalog für die wachsende Menge von Widgets überarbeitet, der nun auch einen besseren Gesamteindruck bietet. Das neue Design bringt verbesserte Suchfunktionen und wurde entsprechend dem Design unserer Fenster für die Konfiguration von Widgets neu gestaltet.

Widgetkatalog

Weitere Informationen finden Sie im Widgetkatalog.

Änderungen an Widgets

Das Widget „Abfragekachel“ unterstützt nun bis zu 10 bedingte Regeln und bietet auswählbare Farben. Dies ist äußerst praktisch, wenn Sie diese Kacheln als KPIs verwenden möchten, um die Integrität und/oder eine ggf. erforderliche Aktion zu bestimmen.

Änderungen an Dashboards

Das Widget „Pull Request“ unterstützt jetzt verschiedene Größen, was Benutzern das Steuern der Höhe des Widgets ermöglicht. Wir arbeiten daran, die meisten Widgets mit veränderbarer Größe zu versehen. Weitere Infos dazu finden Sie hier.

Das Widget „Neue Arbeitsaufgabe“ ermöglicht nun das Auswählen des standardmäßigen Arbeitsaufgabentyps, sodass Sie nicht immer wieder in der Dropdownliste den Typ auswählen müssen, den Sie am meisten verwenden.

Die Größe der Widgets für WIT-Diagramme kann jetzt geändert werden. So können die Benutzer eine erweiterte Ansicht jedes WIT-Diagramms auf dem Dashboard anzeigen – unabhängig von der ursprünglichen Größe des Diagramms.

Das Widget „Teammitglieder“ wurde aktualisiert, um Ihnen das Hinzufügen eines Mitglieds zu Ihrem Team zu vereinfachen.

Änderungen an Widgets

Teams können jetzt die Größe des Widgets „Abfrageergebnisse“ auf dem Dashboard konfigurieren, sodass mehr Ergebnisse angezeigt werden können.

Das Sprint-Übersichtswidget wurde neu gestaltet und macht es Teams nun leichter, zu sehen, ob sie im Plan liegen.

Das Mir zugewiesen-Widget unterstützt Benutzer bei der Verwaltung der ihnen zugewiesenen Arbeit, ohne den Dashboardkontext zu verlassen. Durch Bereitstellung eines dedizierten Widgets für diesen Zweck können Teamadministratoren ihren Dashboards diese Funktionalität mit 16 Mausklicks weniger, ohne Kontextwechsel und ohne erforderliche Tastatureingaben hinzufügen. Benutzer können die ihnen zugewiesene Arbeit jetzt innerhalb des Widgetkontexts anzeigen, sortieren, filtern und verwalten.

Mir zugewiesen

REST-APIs für Dashboards

Sie können nun REST-APIs verwenden, um Informationen in einem Dashboard programmgesteuert hinzuzufügen, zu löschen und abzurufen. Die APIs ermöglichen auch das Hinzufügen, Entfernen, Aktualisieren, Ersetzen und Abrufen von Informationen zu einem Widget oder einer Liste von Widgets auf einem Dashboard. Die Dokumentation finden Sie in der Visual Studio-Onlinedokumentation.

Zulässige Dashboards

Nicht als Administratoren festgelegte Benutzer können jetzt Teamdashboards erstellen und verwalten. Teamadministratoren können die Berechtigungen von nicht als Administratoren festgelegten Benutzern mithilfe des Dashboard-Managers einschränken.

Weitere Informationen finden Sie unter Dashboards.

Verbesserungen für Git

Für Team Foundation Server 2017 wurden einige wesentliche Änderungen an Git vorgenommen. Dazu zählen eine Neugestaltung der Seite „Branches“ und die neue Option „Squash Merge“.

Neu gestaltete Seite „Branches“

Die Seite „Branches“ wurde vollständig neu gestaltet. Sie enthält das Pivot „Mine“ mit den Branches, die Sie erstellt, in die Sie Pushübertragungen vorgenommen oder die Sie favorisiert haben. Jede Branch zeigt den Build- und Pull Request-Status sowie andere Befehle wie „Löschen“. Wenn ein Branchname einen Schrägstrich enthält, wie z. B. „features/jeremy/fix-bug“, erfolgt die Anzeige als Struktur, sodass das Durchsuchen einer langen Liste von Branches vereinfacht wird. Wenn Sie den Namen der Branch kennen, können Sie diesen in die Suchfunktion eingeben, um ihn schnell zu finden.

Neu gestaltete Seite „Branches“

Weitere Informationen zu Branches finden Sie unter Manage branches (Verwaltung von Branches).

Neues Benutzererlebnis für Pull Requests

Die Pull Request-Benutzererfahrung hat in dieser Version einige größere Updates erfahren, mit denen sehr leistungsfähige Diff-Funktionen, eine neue Funktion zur Kommentierung und eine stark überarbeitete Benutzeroberfläche eingeführt werden.

Weitere Informationen finden Sie unter Review code with Pull Requests (Überprüfen von Code mit Pull Requests).

Neu gestaltete Benutzeroberfläche

Beim Öffnen eines Pull Requests fallen die neue Oberfläche und das geänderte Verhalten sofort auf. Wir haben den Header umstrukturiert, sodass er alle kritischen Status und Aktionen zusammenfasst und den Zugriff aus jeder Ansicht der Oberfläche ermöglicht.

Pull Request-Header

Übersicht

In der Übersicht ist die PR-Beschreibung nun hervorgehoben, wodurch es leichter denn je wird, Feedback zu geben. In Ereignissen und Kommentaren werden die neuesten Elemente jetzt zuoberst angezeigt, um Reviewern das Auffinden der neuesten Änderungen und Kommentare zu erleichtern. Richtlinien, Arbeitsaufgaben und Reviewer werden alle im Detail und in geänderter Struktur angegeben und sind jetzt klarer und präziser.

Pull Request-Übersicht

Dateien

Die wichtigste neue Funktion in dieser Version ist die Möglichkeit, die in der Vergangenheit an einem Pull Request vorgenommenen Änderungen anzuzeigen. In vorhergegangenen Vorschauversionen haben wir die Funktion zum ordnungsgemäßen Nachverfolgen von Kommentaren eingeführt, wenn ein PR durch Änderungen aktualisiert wird. Allerdings lässt sich nicht immer eindeutig ersehen, was zwischen den Aktualisierungen geschehen ist. In der Dateiansicht können Sie jetzt genau sehen, was bei jedem Push von neuem Code in Ihren PR geändert wurde. Das ist sehr nützlich, wenn Sie zu Codeabschnitten Feedback gegeben haben und nun sehen möchten, wie der Code im einzelnen geändert wurde, unabhängig von allen anderen Änderungen im Review.

Pull Request-Dateien

Updates

Die neue Ansicht „Aktualisierungen“ wird verwendet, um die Änderungen des PRs über einen Zeitraum anzuzeigen. Während Sie in der Ansicht „Dateien“ sehen, wie sich die Dateien im Lauf der Zeit geändert haben, sehen Sie in der Ansicht „Aktualisierungen“ die mit jeder Aktualisierung hinzugefügten Commits. Sollte es je zu einem erzwungenen Push kommen, zeigt die Ansicht „Aktualisierungen“ auch weiterhin die vergangenen Aktualisierungen im Verlauf an.

Pull Request-Aktualisierungen

Kommentare jetzt mit Markdown und Emoji

In allen Diskussionen können Sie den ganzen Leistungsumfang von Markdown nutzen, einschließlich Formatierung, Code mit Syntaxhervoerhebung, Links, Bilder und Emoji. Die Steuerelemente zur Kommentierung weisen jetzt auch ein benutzerfreundlicheres Bearbeitungsverhalten auf und ermöglichen das gleichzeitige Bearbeiten (und anschließende Speichern) mehrerer Kommentare.

Pull Request-Kommentare

Hinzufügen und Entfernen von Bearbeitern in Pull Requests

Es ist jetzt einfacher, für Ihre Pull Requests Bearbeiter hinzuzufügen oder zu entfernen. Um Ihrem Pull Request einen Bearbeiter oder eine Gruppe hinzuzufügen, geben Sie einfach im Abschnitt „Bearbeiter“ den Namen in das Suchfeld ein. Um einen Bearbeiter zu entfernen, zeigen Sie im Abschnitt „Bearbeiter“ auf die entsprechende Kachel, und klicken Sie auf das X, um ihn zu entfernen.

Hinzufügen von Bearbeitern in Pull Requests

Verbesserte Rückverfolgbarkeit zwischen Builds und Pull Requests

Die Rückverfolgbarkeit zwischen Builds und Pull Requests wurde verbessert, sodass es nun einfacher ist, von einem Pull Request zu einem Build und wieder zurück zu navigieren. In der Detailansicht eines Builds, der durch einen Pull Request ausgelöst wurde, zeigt die Quelle nun einen Link zum Pull Request, der den Build in die Warteschlange gestellt hat. In der Ansicht „Builddefinitionen“ wird für Builds, die von einem Pull Request ausgelöst wurden, in der Spalte „Ausgelöst von“ ein Link zum Pull Request angezeigt. Im Build-Explorer werden schließlich Pull Requests in der Spalte „Quelle“ angezeigt.

Kommentarnachverfolgung für Pull Requests

Pull Requests in VSTS wurden verbessert und zeigen jetzt Kommentare in Dateien in der richtigen Zeile, auch wenn diese Dateien seit dem Hinzufügen der Kommentare geändert wurden. Bisher wurden Kommentare immer in der Zeile der Datei angezeigt, in der sie ursprünglich hinzugefügt wurden, auch wenn sich der Dateiinhalt geändert hat. Anders gesagt: Ein Kommentar in Zeile 10 wurde immer in Zeile 10 angezeigt. Dank der neuesten Verbesserungen folgen Kommentare jetzt dem Code und werden dort angezeigt, wo es die Benutzer erwarten: Wenn ein Kommentar ursprünglich in Zeile 10 hinzugefügt wurde und danach am Anfang der Datei zwei Zeilen eingefügt wurden, wird der Kommentar jetzt in Zeile 12 angezeigt.

Hier finden Sie ein Beispiel mit einem Kommentar, der ursprünglich in Zeile 13 eingefügt wurde.

Kommentarnachverfolgung

Nachdem der Code geändert und die Zeile mit dem ursprünglichen Kommentar von 13 auf 14 verschoben wurde, wird der Kommentar jetzt an der erwarteten Stelle angezeigt: in Zeile 14.

Kommentarnachverfolgung

Verwenden der AutoComplete-Aktion für Anfragen, die auf Richtlinien warten

Teams, die Branchrichtlinien verwenden (https://www.visualstudio.com/en-us/docs/git/branch-policies), um ihre Branches zu schützen, werden sich für die neue AutoComplete-Aktion interessieren. Oftmals ist der Autor eines Pull Requests zu einem Merge seines Pull Requests bereit, wartet aber auf den Abschluss eines Builds, bevor er auf „Abgeschlossen“ klicken kann. In anderen Fällen wird der Build abgenommen, die endgültige Genehmigung eines einzelnen Reviewers steht aber noch aus. In diesen Fällen ermöglicht die AutoComplete-Aktion dem Autor, für den PR den automatischen Abschluss festzulegen, sobald alle Richtlinien genehmigt wurden.

AutoComplete

Genau wie beim manuellen Abschließen hat der Autor die Möglichkeit, die Nachricht des Mergecommits anzupassen und die geeigneten Mergeoptionen auszuwählen.

Autodialog

Nachdem AutoComplete festgelegt wurde, zeigt der PR ein Banner zur Bestätigung an, dass AutoComplete festgelegt wurde und auf den Abschluss der Richtlinien wartet.

Autobox

Wenn allen Richtlinien entsprochen wurde (z. B. indem der Build abgeschlossen oder die endgültige Genehmigung erteilt wurde), wird der PR mit den angegebenen Optionen und Kommentaren gemergt. Wenn beim Build ein Fehler auftritt oder der Reviewer die Genehmigung nicht erteilt, bleibt der PR erwartungsgemäß aktiv, bis die Richtlinien erfüllt werden.

Squash Merge von Pull Requests

Wenn Sie einen Pull Request abschließen, haben Sie die eine Option namens „Squash Merge“. Diese neue Option erzeugt einen einzelnen Commit mit den Änderungen aus der Topic-Branch, die auf die Zielbranch angewendet werden. Der wichtigste Unterschied zwischen einem herkömmlichen Merge und einem Squash Merge ist, dass der Squash Merge Commit nur einen übergeordneten Commit hat. Dadurch ergibt sich ein einfacheres Verlaufsdiagramm, da am Topic-Branch erfolge Zwischencommits im resultierenden Commitdiagramm nicht erreichbar sind.

Squash Merge von Pull Requests

Sie finden weitere Informationen zur Squash merge pull requests (Squash Merge von Pull Requests).

Nachverfolgbarkeit von Commits

Der Buildstatus (Erfolg oder Fehler) ist jetzt in den Ansichten „Code-Explorer“ und „Commit-Details“ deutlich erkennbar. Weitere Details sind nur einen Mausklick entfernt, damit Sie immer wissen, ob die Änderungen im Commit den Build bestanden haben oder nicht. Sie können auch anpassen, welche Builds den Status in den Repositoryoptionen für die Builddefinition melden. Darüber hinaus bieten die neuesten Änderungen an der Ansicht „Commit-Details“ detailliertere Informationen zu Ihren Änderungen. Wenn Sie Pull Requests zum Zusammenführen Ihrer Änderungen verwenden, wird der Link zum Pull Request angezeigt, der die Änderung in den Hauptbranch eingeführt hat (oder bei einem Mergecommit der Pull Request, der sie erstellt hat). Wenn Ihre Änderungen den Hauptbranch erreicht haben, wird der Branchlink angezeigt, um zu bestätigen, dass die Änderungen einbezogen wurden.

Rückverfolgbarkeit von Commits

Anzeigen von Git LFS-Dateien im Web

Wenn Sie bereits mit großen Dateien (Audio, Video, Datasets usw.) in Git arbeiten, wissen Sie, dass Git Large File Storage (LFS) diese Dateien innerhalb von Git durch Zeiger ersetzt, während der Dateiinhalt auf einem Remoteserver gespeichert wird. Dies ermöglicht es Ihnen, den vollständigen Inhalt dieser großen Dateien anzuzeigen, indem Sie einfach in Ihrem Repository auf die Datei klicken.

Weitere Informationen finden Sie unter Manage large files with Git (Verwalten von großen Dateien mit Git).

Geben Sie Codeverweise mithilfe von Codelinks einfach frei. Markieren Sie dazu Text in einer Datei, und klicken Sie auf das Linksymbol. Dadurch wird ein Link zum ausgewählten Code kopiert. Wenn sich jemand diesen Link ansieht, hat der von Ihnen markierte Code einen goldenen Hintergrund. Dies funktioniert auch, wenn Zeilen teilweise markiert werden.

Senden von Links zu Code

Status-API

Erfolge und Fehler bei Builds sind jetzt in den Ansichten „Code-Explorer“ und „Commit-Details“ deutlich erkennbar. Weitere Details sind nur einen Mausklick entfernt, sodass Sie immer wissen, ob die Änderungen im Commit den Build bestanden haben oder nicht. Sie können auch anpassen, welche Builds den Buildstatus in den Repositoryoptionen für die Builddefinition melden.

Status-API

Dateitypsymbole

Sie sehen neue Dateisymbole entsprechend der Erweiterung der jeweiligen Datei in den Ansichten „Explorer“, „Pull Requests“, „Commitdetails“, „Shelveset“, „Changeset“ oder jeder anderen Ansicht, die eine Liste von Dateien anzeigt.

TFVC

Git

Hinzufügen einer Infodatei während der Repositoryerstellung

Der Erstellungsvorgang für neue Git-Repositorys wurde verbessert und bietet Benutzern jetzt die Möglichkeit, eine Infodatei hinzuzufügen. Das Hinzufügen einer Infodatei zu einem Repository hilft nicht nur anderen Benutzern dabei, den Zweck der Codebasis zu verstehen, sondern ermöglicht Ihnen auch, das Repository sofort zu klonen.

Repository erstellen

Verbesserungen für Builds

In dieser Version haben wir u. a. die Größe der Protokolle erhöht, Java-Buildvorlagen hinzugefügt und unsere Xamarin-Unterstützung verbessert.

Neu gestaltete Registerkarte für Buildwarteschlangen

Wir haben ein neues Design für die Seite „Builds in Warteschlange“ implementiert, das eine längere Liste von aktuell laufenden und in die Warteschlange eingestellten Builds in einer intuitiver zu erfassenden Weise anzeigt.

Buildwarteschlange-Registerkarte

Weitere Informationen finden Sie unter Administer your build system (Verwalten Ihrer Buildsysteme).

Ermöglichen von Erweiterungen von Buildergebnissen zum Angeben von Reihenfolge und Spalte

Über Erweiterungen im Abschnitt „Buildergebnisse“ können Sie nun die Spalte und die Reihenfolge angeben, in der sie angezeigt werden. Die Ergebnisansicht hat zwei Spalten, und alle Erweiterungen erfolgen standardmäßig an der ersten Spalte. Hinweis: Alle Erweiterungen von Drittanbietern werden hinter den von uns hinzugefügten Abschnitten mit Buildergebnissen angezeigt.

Buildreihenfolge und Spalte

Build bis Zeilennummer

Jetzt können Sie von einem Buildfehler zur Codezeile springen, die ihn verursacht hat. Wenn ich den letzten Fehler im primären Build untersuche, den wir intern als Pull Request-Richtlinie verwenden, sehe ich Folgendes:

Build bis Zeilennummer

Build bis Zeilennummer

Buildprotokollansicht unterstützt wesentlich größere Protokolle

Die bisherige Protokollansicht unterstützte nur Protokolle mit bis zu 10.000 Zeilen. Die neue Ansicht basiert auf dem Monaco-Editor, der in Visual Studio Code verwendet wird, und unterstützt Protokolle mit bis zu 150.000 Zeilen.

Java-Buildvorlagen

Wir haben Java-Entwicklern den Einstieg in Builds noch weiter erleichtert, indem wir Buildvorlagen für Ant, Maven und Gradle hinzugefügt haben.

Java-Buildvorlagen

Weitere Informationen zu Vorlagen finden Sie unter Buildschritte.

Xamarin-Buildaufgaben

Wir haben einige bedeutende Verbesserungen an unser Xamarin-Unterstützung vorgenommen:

Der Schritt „Xamarin-Lizenz“ ist nicht mehr erforderlich und wurde aus den Buildvorlagen entfernt. Im Rahmen dieser Änderung markieren wir die Aufgabe außerdem als veraltet. Alle Builddefinitionen, die diese Aufgabe verwenden, sollten entsprechend aktualisiert werden und diese Aufgabe entfernen, um Unterbrechungen zu vermeiden, wenn die Aufgabe schließlich entfernt wird.

Schließlich wurden die Xamarin-Builddefinitionsvorlagen verbessert, um diese neuen Aufgaben verwenden zu können. Erstellen Ihrer Xamarin-App.

Integration von Docker für Build und Release Management

Nutzen Sie die cloudbasierten Buildfunktionen, um Ihre Docker-Images zu erstellen und im Rahmen Ihres Continuous Integration-Workflows auf den Docker Hub hochzuladen. Stellen Sie anschließend diese Images im Rahmen des Release Managements auf verschiedenen Docker-Hosts bereit. Die Marketplace-Erweiterung fügt alle erforderlichen Arten von Dienstendpunkten und Tasks hinzu, die Sie für die Arbeit mit Docker benötigen.

Docker

SonarQube-Ergebnisse in der Pull Request-Ansicht

Wenn der Build, der zum Zusammenführen eines Pull Requests ausgeführt wird, SonarQube MSBuild-Aufgaben enthält, sehen Sie jetzt neue Codeanalyseprobleme als Diskussionskommentare im Pull Request. Dies funktioniert für alle Sprachen, für die auf dem SonarQube-Server ein Plug-In installiert ist. Weitere Informationen finden Sie im Blogbeitrag SonarQube Code Analysis issues integration into Pull Requests.

SonarQube in Pull Requests

Konfigurieren der Berichterstellung zur Status-API für eine Builddefinition

Sie können jetzt auswählen, welche Builddefinitionen ihren Status zurück an die Git-Status-API melden. Dies ist besonders nützlich, wenn Sie über viele Definitionen zum Erstellen eines bestimmten Repositorys oder einer bestimmten Branch verfügen, aber nur eine haben, die den tatsächlichen Zustand darstellt.

Weitere Informationen finden Sie in der REST-API-Referenz für Build.

Unterstützung für Build vNext in Teamräumen

Es war schon immer möglich, Benachrichtigungen bezüglich XAML-Builds im Teamraum hinzuzufügen. Ab diesem Sprint können Benutzer auch Benachrichtigungen zu Buildabschlüssen in Build vNext zu empfangen.

Aktivieren von Pfadfiltern für Git-CI-Trigger

CI-Trigger für gehostete Git-Repositorys können bestimmte Pfade einschließen oder ausschließen. So können Sie eine Builddefinition konfigurieren, die nur ausgeführt wird, wenn sich Dateien in bestimmten Pfaden geändert haben.

Git-CI-Trigger

Verbesserungen beim Release Management

Nach der Einführung des integrierten webbasierten Release Managements in Team Foundation Server 2015 haben wir in dieser Version eine Reihe von Verbesserungen vorgenommen.

Klonen, Exportieren und Importieren von Releasedefinitionen

Wir haben die Möglichkeit hinzugefügt, Releasedefinitionen im Release-Hub zu klonen, zu exportieren und zu importieren, ohne dass eine Installation einer Erweiterung nötig ist.

Klonen und Exportieren von Befehlen auf der Seite mit der Releaseübersicht

Weitere Informationen finden Sie unter Clone, export, and import a release definition (Klonen, Exportieren und Importieren einer Releasedefinition)

In der Releasezusammenfassung angezeigte Testergebnisse

Auf der Seite „Releasezusammenfassung“ haben wir einen Beitragspunkt für einen externen Dienst aktiviert, um umgebungsspezifische Informationen anzuzeigen.

In Team Services wird diese Funktionalität verwendet, um eine Zusammenfassung der Testergebnisse anzuzeigen, wenn Tests als Teil einer Releaseumgebung ausgeführt werden.

In der Releasezusammenfassung angezeigte Testergebnisse

Weitere Informationen finden Sie unter Understand the summary view of a release (Verstehen der Zusammenfassungsansicht eines Releases)

Übergeben von OAuth-Token an Skripts

Wenn Sie ein benutzerdefiniertes PowerShell-Skript ausführen müssen, das die REST-APIs auf Team Services aufruft, um vielleicht einen Arbeitstask zu erstellen oder ein Build nach Informationen abzufragen, müssen Sie das OAuth-Token im Skript übergeben.

Eine neue Option beim Konfigurieren einer Umgebung erlaubt Skripts, als Tasks in der Umgebung ausgeführt zu werden, um auf das aktuelle OAuth-Token zuzugreifen.

Übergeben von OAuth-Token an Skripts

Weitere Informationen finden Sie unter Environment general options (Allgemeine Umgebungsoptionen)

Dies ist ein einfaches Beispiel, das zeigt, wie Sie eine Builddefinition erhalten:

Ein Beispielskript, das erfolgreiche OAuth-Token verwendet.

Trigger bei teilweise erfolgreichen Bereitstellungen

Build- und Releaseaufgaben verfügen über die Option Bei Fehler fortsetzen in den Parametern für die Steuerungsoptionen für jeden Task.

In einer Builddefinition führt dies zum Ergebnis Buildvorgang teilweise erfolgreich, wenn bei einem Task ein Fehler auftritt, für den diese Option festgelegt ist.

Das gleiche Verhalten ist jetzt auch in Releasedefinitionen verfügbar. Wenn bei einem Task ein Fehler auftritt, wird das Ergebnis für das Release insgesamt als „Release teilweise erfolgreich“ angezeigt.

Releaseübersicht mit teilweise erfolgreichen Releases in orange

Standardmäßig löst ein teilweise erfolgreiches Release nicht automatisch ein Release für eine nachfolgende Umgebung aus, auch wenn dieses Verhalten in den Bereitstellungsoptionen für die Umgebung festgelegt ist.

Es kann jedoch in jeder Releaseumgebung eine neue Option festgelegt werden, die das Release Management anweist, ein Release in einer nachfolgenden Umgebung auszulösen, wenn das vorherige Release teilweise erfolgreich war.

Festlegen der Option zum Auslösen nach einem teilweise erfolgreichen Release

Weitere Informationen finden Sie unter Environment deployment triggers (Trigger für die Bereitstellung der Umgebung)

Direktes Nutzen von in GitHub gespeicherten Artefakten

In manchen Fällen möchten Sie Artefakte, die in einem Versionskontrollsystem gespeichert sind, direkt nutzen, ohne sie einem Buildprozess übergeben zu müssen, so wie in diesem Thema beschrieben.

Dies ist jetzt möglich, wenn Ihr Code in einem GitHub-Repository gespeichert ist.

Verknüpfen von Code in einem GitHub-Repository mit einer Releasedefinition

Weitere Informationen finden Sie unter TFVC, Git, and GitHub sources (TFVC-, Git- und GitHub-Quellen).

Bereitstellung von Webanwendungen mit ARM

Eine neue Version des Azure-Web-App-Bereitstellungstasks ist verfügbar und heißt AzureRM Web App Deployment.

AzureRM Web App Deployment verwendet MSDeploy und eine Verbindung eines Azure Resource Manager-Dienstenpunkts. Verwenden Sie diesen Task, um auf Grundlage von ASP.NET 4-, Node- und Python-Apps Azure WebJobs-Aufträge und Azure-API-Apps bereitzustellen.

Der Task unterstützt auch allgemeine Optionen für die Veröffentlichung wie z.B. die Möglichkeit, App-Daten beizubehalten, eine App offline zu schalten und zusätzliche Dateien am Ziel zu entfernen.

Weitere Funktionen, z.B. die Konfiguration von Transformationen, erscheinen möglicherweise in demnächst veröffentlichten Versionen.

Bereitstellung von Webanwendungen mit ARM

Aufgabengruppen

Mit einer Taskgruppe können Sie eine Sequenz von Tasks, die schon in einem Build definiert ist, oder eine Releasedefinition in einem einzigen wiederverwendbaren Task einschließen, die einem Build oder einer Releasedefinition hinzugefügt werden kann, so wie jeder andere Task auch.

Sie können auch die Parameter aus dem gekapselten Task als Konfigurationsvariablen extrahieren und den Rest der Taskinformationen abstrahieren.

Die neue Taskgruppe wird automatisch dem Taskkatalog hinzugefügt und kann daraufhin andere Versionen und Builddefinitionen hinzufügen.

Verknüpfen von Code in einem GitHub-Repository mit einer Releasedefinition

Ausführliche Informationen finden Sie unter Task Groups (Taskgruppen).

Vorläufiges Löschen von Releases

Wenn Sie ein Release löschen, oder es automatisch von einer Beibehaltungsrichtlinie gelöscht wird, wird das Release aus den Listen für Übersicht und Details entfernt.

Es wird jedoch in der Releasedefinition über einen Zeitraum (in der Regel 14 Tage) beibehalten, bevor es dauerhaft gelöscht wird.

Während dieses Zeitraums wird es in der Registerkarte Gelöscht der Übersicht und der Liste mit den Details angezeigt.

Sie können alle Releases entfernen, indem Sie das Kontextmenü aufrufen, und Wiederherstellen auswählen.

Wiederherstellen von Versionen

Weitere Informationen finden Sie unter Restore deleted releases (Gelöschte Versionen wiederherstellen)

Wiederherstellen von Releases und Builds für jede Umgebung

Die Beibehaltungsrichtlinie für Releases für eine Releasedefinition legt fest, wie lange ein Release und der mit ihm verknüpfte Build wiederhergestellt werden.

Standardmäßig wird ein Release für 60 Tage beibehalten – Releases, die während dieses Zeitraums nicht bereitgestellt oder verändert wurden, werden automatisch gelöscht.

Möglicherweise möchten Sie jedoch mehrere Releases wiederherstellen, die in bestimmten Umgebungen bereitgestellt wurden, wie in Ihrer Produktumgebung, oder sie länger wiederherstellen als jene, die gerade erst in anderen Umgebungen bereitgestellt wurden, wie z.B. in der Testumgebung, der Stagingumgebung und der Qualitätssicherungsumgebung.

Sie können auch den Build wiederherstellen, der mit einem Release für den gleichen Zeitraum wie das Release verknüpft ist, um sicherzustellen, dass die Artefakte verfügbar sind, wenn Sie dieses Release wiederherstellen müssen.

Beibehalten von Versionen

Weitere Informationen finden Sie unter Release and build retention (Release- und Buildwiederherstellung)

Verbesserungen in verknüpften Artefakten

Zwei neue Features erleichtern die Arbeit mit Artefakten und Artefaktquellen:

  • Sie können mehrere Artefaktquellen mit einer Releasedefinition verknüpfen. Jedes der Artefakte wird in einen Ordner auf den Agent heruntergeladen, der „Alias der Datenquelle“ heißt. Sie können nun den Alias der Datenquelle eines verknüpften Artefakts bearbeiten. Wenn Sie z.B. den Namen der Builddefinition ändern, können Sie den Alias der Datenquelle ändern, um den Namen der Builddefinition widerzuspiegeln.

    Beibehalten von Versionen

    Weitere Informationen finden Sie unter Artifact source alias (Artefakt des Aliases der Datenquelle)

  • Eine Reihe der Variablen des Formats Build.* (z.B. Build.BuildId und Build.BuildNumber) werden für den Gebrauch in Taskparametern verfügbar gemacht. Wenn mehrere Quellen einem Release zugeordnet sind, werden diese Variablen mit den Werten aus der Artefaktquelle, die Sie als primäre Quelle angegeben haben, aufgefüllt. Weitere Informationen finden Sie unter Artifact variables (Artefaktvariablen).

Bereitstellung – Task für manuellen Eingriff

Jetzt können Sie die Ausführung während der Bereitstellung in eine Umgebung anhalten.

Durch das Einschließen eines Tasks des manuellen Eingriffs in eine Umgebung können sie eine Bereitstellung zeitweise anhalten, manuelle Schritte durchführen und anschließend weitere automatisierte Schritte fortsetzen.

Sie können die Bereitstellung auch ablehnen und verhindern, dass weitere Schritte nach einem manuellen Eingriff ausgeführt werden.

Beibehalten von Versionen

Weitere Informationen finden Sie unter Manual Intervention (Manuelle Eingriffe)

Taskskripts für die SQL-Datenbankbereitstellung

Der Task der Azure SQL-Datenbankbereitstellung wurde erweitert, um SQL-Skripts für eine Azure SQL-Datenbank auszuführen. Die Skripts können als Datei oder inline innerhalb des Tasks bereitgestellt werden.

Beibehalten von Versionen

Übersicht über die Releasedefinition – Dashboardwidget

Heften Sie eine Releasedefinition an das Dashboard an – eine einfache Möglichkeit, Ihrem gesamten Team eine Übersicht über die Releases für diese Definition zu bieten.

Weitere Informationen finden Sie unter Hinzufügen von Releaseinformationen zum Dashboard.

Bereitstellen von Releases an eine Umgebung zu einem bestimmten Zeitpunkt

Möchten Sie alle Produktionsbereitstellungen um Mitternacht durchführen? Sie können eine Bedingung in einer Umgebung konfigurieren, die eine erfolgreiche Bereitstellung (oder nur die jüngste) von einer anderen Umgebung auswählt und zum angegebenen Zeitpunkt bereitstellt.

Planen der Veröffentlichung in einer Umgebung

Bereitstellung basierend auf Bedingungen in mehreren Umgebungen

Bis zur vorigen Version konnten Sie parallele Bereitstellungen (verzweigte Bereitstellungen) ausführen, aber Sie konnten die Bereitstellung in einer Umgebung nicht basierend auf dem Status mehrerer Umgebungen (verknüpfte Bereitstellungen) starten. Das ist jetzt möglich.

Weitere Informationen finden Sie unter Parallele verzweigte und verknüpfte Bereitstellungen.

REST-APIs für das Release Management

Sie können die REST-APIs für den Release Management-Dienst verwenden, um Releasedefinitionen und Releases zu erstellen und eine Vielzahl von Aspekten bei der Bereitstellung eines Releases zu verwalten.

Weitere Informationen finden Sie in der API-Referenzdokumentation. Einige einfache Beispiele, in denen die APIs verwendet werden, finden Sie in diesem Blogbeitrag: Using ReleaseManagement REST APIs (in englischer Sprache).

Integration von Service Hooks

Senden Sie Benachrichtigungen, wenn neue Releases erstellt wurden, Bereitstellungen gestartet oder abgeschlossen wurden oder Genehmigungen ausstehen oder abgeschlossen wurden. Über eine Integration in Drittanbietertools wie z.B. Slack lässt sich der Empfang solcher Nachrichten implementieren.

Bereitstellung in nationalen Azure-Clouds

Verwenden Sie die neue Umgebungseinstellung auf einem Dienstenpunkt im klassischen Azure-Portal, einschließlich vordefinierter nationaler Clouds wie z.B. die Azure China-Cloud, die Azure US Government-Cloud und die Azure German-Cloud.

Bereitstellung in nationalen Azure-Clouds

Weitere Informationen finden Sie unter Azure Classic service endpoint (Dienstendpunkt im klassischen Azure-Portal).

Verbesserungen für Tests

In Team Foundation Server 2017 wurden wichtige Verbesserungen für Tests hinzugefügt.

Aktualisiertes Speicherschema für Testergebnisse

In dieser Version migrieren wir die Testergebnisartefakte in ein neues kompaktes und effizientes Speicherschema. Da Testergebnisse ziemlich den meisten Speicherplatz in TFS-Datenbanken belegen, erwarten wir uns von diesem Feature eine geringere Speicherplatzbelegung durch TFS-Datenbanken. Für Kunden, die für eine frühere Version ein Upgrade durchführen, werden Testergebnisse während des TFS-Upgrades in das neue Schema migriert. Dieses Upgrade führt je nach Umfang der Testergebnisdaten in Ihren Datenbanken möglicherweise zu langen Upgradezeiten. Es ist ratsam, die Testaufbewahrungsrichtlinie zu konfigurieren und zu warten, bis die Richtlinie greift und den Speicherplatz reduziert, der von Testergebnissen belegt wird, damit das TFS-Upgrade schneller erfolgt. Nach der Installation von TFS, aber noch vor dem Upgrade der TFS-Instanz, können Sie das TFSConfig.exe-Tool verwenden, um Testergebnisse zu bereinigen. Weitere Informationen finden Sie in der Hilfe zu TFSConfig.exe. Wenn Sie nicht über genügend Flexibilität verfügen, um vor dem Upgrade die Testaufbewahrung zu konfigurieren oder die Testergebnisse zu bereinigen, planen Sie das Zeitfenster für das Upgrade entsprechend ein. Unter Aufbewahrung von Testergebnisdaten mit Team Foundation Server 2015 finden Sie weitere Beispiele zum Konfigurieren der Testaufbewahrungsrichtlinie.

Verbesserungen am Testhub

Testkonfigurationsverwaltung im Testhub

Die Testkonfigurationsverwaltung kann jetzt auf der Webbenutzeroberfläche erfolgen, da wir im Testhub die neue Registerkarte „Konfigurationen“ hinzugefügt haben. Sie können jetzt Testkonfigurationen erstellen und verwalten und Konfigurationsvariablen im Testhub testen.

Hub „Konfigurationen“

Weitere Informationen finden Sie unter Erstellen von Konfigurationen und Konfigurationsvariablen.

Zuweisen von Konfigurationen zu Testplänen, Testsammlungen und Testfällen

Das Zuweisen von Konfigurationen ist jetzt einfacher. Sie können Testkonfigurationen direkt im Testhub einem Testplan, einer Testsammlung oder Testfällen zuweisen. Klicken Sie mit der rechten Maustaste auf ein Element, wählen Sie ...Konfigurationen zuordnen, und schon kann es losgehen. Sie können im Testhub auch nach Konfigurationen filtern.

Zuweisen von Konfigurationen

Konfigurationsfilter

Weitere Informationen finden Sie unter Zuweisen von Konfigurationen zu Testplänen und Testsammlungen.

Anzeigen von Testplan-/Testsammlungsspalten im Bereich „Testergebnisse“

Wir haben dem Bereich „Testergebnisse“ neue Spalten hinzugefügt, die den Testplan und die Testsammlung zeigen, in dem/der die Testergebnisse erzielt wurden. Diese Spalten bieten zur detaillierten Untersuchung Ihrer Testergebnisse benötigte Kontextinformationen.

Bereich „Testergebnisse“

Sortieren von Tests im Testhub und auf Karten

Sie können nun im Testhub manuelle Tests unabhängig vom Typ der Sammlung sortieren, in der sie enthalten sind, d. h. in statischen, anforderungsbasierten oder abfragebasierten Sammlungen. Sie können einen oder mehrere Tests einfach ziehen und ablegen oder das Kontextmenü verwenden, um Tests neu zu sortieren. Sobald die Sortierung abgeschlossen ist, können Sie die Tests nach dem Feld „Reihenfolge“ sortieren und sie im Web Test Runner in dieser Reihenfolge ausführen. Sie können die Tests auch direkt auf einer User Story-Karte im Kanban-Board sortieren. Damit ist eine der lange ausstehenden User Voice-Anforderungen (mit 495 Stimmen) für manuelle Tests erfüllt.

Sortieren von Tests

Sortieren von Tests auf der Karte

Sortieren von Testsammlungen im Testhub

Testteams können die Testsammlungen jetzt gemäß ihren Anforderungen sortieren – vor Einführung dieser Funktion wurden die Sammlungen nur alphabetisch sortiert. Jetzt können Sammlungen mithilfe der Drag&Drop-Funktion im Testhub innerhalb gleichgeordneter Sammlungen neu sortiert oder in eine andere Sammlung in der Hierarchie verschoben werden. Dies erfüllt diese User Voice-Anforderung im Rahmen der manuellen Verwaltung von Tests/Testfällen.

Sortieren von Testsammlungen

Suchen nach Benutzern beim Zuweisen von Testern

Im Rahmen der Einführung neuer Steuerelemente zur Auswahl von Identitäten in den verschiedenen Hubs haben wir für den Testhub auch die Option aktiviert, beim Zuweisen von Benutzern zu einem oder mehreren Tests nach Benutzern zu suchen. Dies ist besonders nützlich in Szenarien, in denen viele Teammitglieder vorhanden sind, das Kontextmenü aber nur eine begrenzte Anzahl von Einträgen anzeigt.

Suchen von Benutzern

Zuweisen von Benutzern

Auswählen eines Builds zum Testen

Sie können jetzt den Build auswählen, mit dem Sie testen möchten, und dann unter Verwendung von „Mit Optionen ausführen“ im Testhub den Webrunner starten. Jeder während der Ausführung protokollierte Fehler wird automatisch dem ausgewählten Build zugeordnet. Darüber hinaus wird die Testausgabe für diesen bestimmten Build veröffentlicht.

Build auswählen

Starten des Microsoft Test Runner-Clients aus dem Testhub mit Datensammlern

Sie können jetzt die Datensammler und den Build auswählen, die bzw. der mit dem Testlauf verknüpft werden soll. Dann können Sie den Microsoft Test Runner 2017-Client effizient aus dem Testhub starten, ohne die Datensammler im Microsoft Test Manager-Client konfigurieren zu müssen. Microsoft Test Runner wird gestartet, ohne dass die vollständige Microsoft Test Manager-Shell geöffnet wird, und wird nach Abschluss der Testausführung geschlossen.

Ausführen mit Optionen

Weitere Informationen finden Sie unter Ausführen von Tests für Desktop-Apps.

Auswählen von Datensammlern und Starten des Explorativen Runner-Clients auf dem Testhub

Sie können jetzt die Datensammler auswählen und den Explorativen Runner 2017 (Client) effizient aus dem Testhub starten, ohne die Datensammler im Microsoft Test Manager-Client konfigurieren zu müssen. Rufen Sie für eine anforderungsbasierte Sammlung im Kontextmenü „Mit Optionen ausführen“ auf, und wählen Sie den Exploratoriven Runner und die benötigten Datensammler aus. Der Explorative Runner wird in ähnlicher Weise wie der Microsoft Test Runner gestartet, wie oben beschrieben.

Ausführen mit Optionen – XT

Übergreifendes Konfigurieren von Testergebnissen über verschiedene Testsammlungen

Wir haben jetzt die Möglichkeit hinzugefügt, das Verhalten bei Testergebnissen für Tests zu konfigurieren, die in verschiedenen Testsammlungen unter dem gleichen Testplan verwendet werden. Wenn diese Option aktiviert ist und Sie das Ergebnis für einen Test festlegen (indem Sie ihn entweder im Testhub, im Webrunner, Microsoft Test Runner oder auf Karten des Kanban-Board als Erfolgreich/Fehler/Blockiert kennzeichnen), wird dieses Ergebnis an alle anderen Tests weitergegeben, die in gleicher Konfiguration unter dem gleichen Testplan ausgeführt werden. Die Benutzer können die Option „Testergebnisse konfigurieren“ für einen bestimmten Testplan entweder im Testplan-Kontextmenü des Testhubs oder auf der Testseite des Kanban-Boards im Konfigurationsdialogfeld für allgemeine Einstellungen festlegen. Diese Option ist standardmäßig deaktiviert, und Sie müssen sie explizit aktivieren, damit sie wirksam wird.

Konfigurieren von Testergebnissen

Überprüfen von Fehlern von Arbeitstasks

Sie können nun einen Fehler überprüfen, indem Sie die Tests erneut ausführen, die den Fehler erkannt haben. Sie können die Option „Überprüfen“ aus dem Kontextmenü für das Formular für ein Problemarbeitselement aufrufen, um den relevanten Testfall im Webrunner zu starten. Führen Sie die Überprüfung mit dem Webrunner durch, und aktualisieren Sie das Problemarbeitselement direkt innerhalb des Webrunners.

Fehler überprüfen

REST-APIs zum Klonen von Testplänen/Testsammlungen

Wir haben REST-APIs zum Klonen von Testplänen und Testsammlungen hinzugefügt. Sie finden diese auf unserer Team Services-Website zur Integration im Abschnitt „Testverwaltung“.

Fortschritt von Tests auf Ihren Kanban-Karten

Sie können jetzt direkt über die Stories im Kanban-Board Testfälle hinzufügen, anzeigen und mit diesen interagieren. Verwenden Sie die neue Menüoption Test hinzufügen, um einen verknüpften Testfall zu erstellen, und überwachen Sie dann die Entwicklung des Status direkt auf der Karte.

Inlinetests

Mit dieser neuen Funktion können Sie jetzt direkt auf einer Karte Ihres Boards die folgenden Aktionen ausführen:

  • Hinzufügen von Tests
  • Öffnen von Tests
  • Neuzuordnen des übergeordneten Elements eines Tests per Drag & Drop zwischen zwei User Stories
  • Kopieren desselben Tests in eine andere User Story per STRG+Drag & Drop (für Szenarien, in denen der gleiche Testfall mehrere User Stories testet).
  • Aktualisieren Sie den Teststatus, indem dieser schnell als Erfolgreich/Fehler usw. markiert wird.
  • Führen Sie den Test aus, indem Sie ihn im Web Test Runner starten, um einzelnen Schritten den Status „Erfolgreich“ oder „Fehler“ zuweisen, Fehler zu erfassen usw.
  • Zeigen Sie eine Übersicht über den Rollupstatus an, die angibt, wie viele Tests bestanden wurden und wie viele für die Story verbleiben.

Wenn Sie erweiterte Testverwaltungsfunktionen benötigen (wie Zuweisen von Testern und Konfigurationen, zentralisierte Parameter, Exportieren von Testergebnissen usw.), können Sie zum Testhub wechseln und mit der Nutzung der standardmäßigen testplan- bzw. anforderungsbasierten Sammlungen beginnen, die für Sie automatisch erstellt wurden. Weitere Informationen finden Sie unter Add, run, and update inline tests (Hinzufügen, Ausführen und Aktualisieren von Inlinetests).

Direktes Wechseln von einer Karte zu einem Testplan bzw. einer Testsammlung

Sie können den zugrunde liegenden Testplan bzw. die Testsammlung, in dem/der die Tests erstellt werden, jetzt direkt von einer Karte auf dem Kanban-Board aus wechseln. Ein Klick auf diesen Link bringt Sie zum Testhub, öffnet den richtigen Testplan und wählt dann die Sammlung aus, die diese Inlinetests steuert.

Direktes Wechseln zu einem Plan bzw. einer Sammlung

Testseite in der allgemeinen Einstellungskonfiguration auf dem Kanban-Board

Mit der neuen Testseite im Dialogfeld mit der allgemeinen Einstellungskonfiguration auf dem Kanban-Board können Sie jetzt steuern, in welchem Testplan die Inlinetests erstellt werden. Bisher werden alle auf einer Karte erstellten Tests automatisch einem neu erstellten Testplan hinzugefügt, wenn noch keine Testpläne vorhanden sind, die dem Bereich und den Iterationspfaden der Karte entsprechen. Jetzt können Sie dieses Verhalten überschreiben, indem Sie einen vorhandenen Plan Ihrer Wahl konfigurieren – alle Tests werden dann ab diesem Zeitpunkt dem ausgewählten Testplan hinzugefügt. Beachten Sie, dass diese Funktionalität nur verwendet werden kann, wenn Testanmerkungen aktiviert sind.

Allgemeine Einstellungen

Verbesserungen beim Webrunner

Hinzufügen von Anlagen mit Testschritten während manueller Tests

Wir haben den Web Test Runner erweitert, sodass Sie nun während manueller Tests Anlagen mit Testschritten hinzufügen können. Diese Anlagen mit Schrittergebnissen werden automatisch in allen Fehlern, die Sie in der Sitzung erfassen, und anschließend im Bereich „Testergebnisse“ angezeigt.

Anlagen mit Testschritten

Unterstützung von Screenshots, Bildaktionsprotokollen, Bildschirmaufzeichnungen und Systeminfo in Web Runner (im Browser Chrome)

Bei Verwenden des Web Test Runners in Chrome können Sie nun Screenshots erstellen und inline mit Anmerkungen versehen. Sie können auch bei Bedarf Bildschirmaufzeichnungen nicht nur der Web-Apps, sondern auch Ihrer Desktop-Apps erfassen. Diese Screenshots und Bildschirmaufzeichnungen werden automatisch dem aktuellen Testschritt hinzugefügt. Sie können jetzt zusätzlich zu Screenshots und Screenaufzeichnungen auch ein bedarfsgesteuertes Bildaktionsprotokoll Ihrer Web-Apps erfassen. Sie müssen das Browserfenster angeben, in dem die Aktionen erfasst werden sollen – alle Aktionen in diesem Fenster (sowohl in vorhandenen als auch in neu geöffneten Registerkarten in diesem Fenster) und in untergeordneten Browserfenstern werden automatisch erfasst und mit den Testschritten korreliert, die im Webrunner getestet werden. Diese Screenshots, Screenaufzeichnungen und Bildaktionsprotokolle werden dann zu den Fehlern hinzugefügt, die während der Ausführung protokolliert werden, und an das aktuelle Testergebnis angefügt. Gleichermaßen werden die Systeminformationsdaten automatisch gesammelt und als Teil von Fehlern hinzugefügt, die Sie im Web Test Runner erfassen. All diese Funktionen nutzen die Fähigkeiten der Chrome-basierten Erweiterung „Test & Feedback“.

Webrunner-Screenshots

Weitere Informationen finden Sie unter Sammeln von Diagnosedaten während der Tests.

Als untergeordnete Elemente erfasste Fehler – Web Runner/Erweiterung „Test & Feedback“

Beim Ausführen von Tests in Web Runner, die entweder auf einer Karte im Board oder in einer anforderungsbasierten Sammlung im Testhub gestartet werden, werden neue erfasste Fehler nun automatisch als untergeordnetes Element der jeweiligen User Story erstellt. Auch wenn Sie eine User Story in der Erweiterung „Explorative Tests“ untersuchen, werden neue erfasste Fehler nun auch als untergeordnetes Element der jeweiligen User Story erstellt. Dieses neue Verhalten ermöglicht eine bessere Rückverfolgbarkeit in Stories und Fehlern. Dies gilt nur wenn die Einstellung „Arbeiten mit Fehlern“ auf der Seite der allgemeinen Einstellungen auf „Bugs do not appear on backlogs or board“ (Fehler erscheinen nicht in Backlogs oder Boards) oder „Bugs appear on the backlogs and boards with tasks“ (Fehler erscheinen in Backlogs und Boards mit Tasks) festgelegt wird. Für alle anderen Einstellungen für „Arbeiten mit Fehlern“ und in bestimmten anderen Szenarios, z.B. Hinzufügen von Informationen zu einem vorhandenen Fehler, für den bereits ein übergeordnetes Element definiert ist, wird stattdessen ein verwandter Link erstellt.

Aktualisieren vorhandener Fehler über den Webrunner

Sie können zusätzlich zum Erstellen neuer Fehler im Webrunner auch einen vorhandenen Fehler aktualisieren. Alle erfassten Diagnosedaten, Reproduktionsschritte und Links zur Nachverfolgung aus der aktuellen Sitzung werden automatisch dem vorhandenen Fehler hinzugefügt.

Hinzufügen zu vorhandenem Fehler

Verbesserungen zur Erweiterung „Test & Feedback“

Die browserbasierte Erweiterung „Test & Feedback“ kann vom Visual Studio Marketplace installiert werden. Es werden jeweils Visual Studio Team Services und Team Foundation Server (2015 oder höher) unterstützt.

Untersuchen von Arbeitselementen.

Führen Sie explorative Tests für ein bestimmtes Arbeitselement durch. Dadurch können Sie das ausgewählte Arbeitselement ihrer aktuell stattfindenden Testsitzung zuordnen und Akzeptanzkriterien und Beschreibung aus der Erweiterung selbst anzeigen. Ferner wird dadurch eine End-to-End-Nachverfolgbarkeit zwischen den abgelegten Fehlern oder Tasks und dem ausgewählten Arbeitselement etabliert. Das Arbeitselement kann entweder direkt im Arbeitselement oder in der Erweiterung untersucht werden:

• Direkt im Arbeitselement Starten Sie eine Sitzung zum Ausführen explorativer Tests für einen bestimmten Arbeitstask direkt innerhalb des Produkts mithilfe der Option „Explorative Tests“ im Kontextmenü. Wir haben allen Karten, Rastern und dem Testhub Einstiegspunkte hinzugefügt.

• Innerhalb der Erweiterung Suchen Sie innerhalb der XT-Sitzung nach einem Arbeitselement, und ordnen Sie es dann der aktuell ausgeführten Sitzung zu.

Explorative Tests auf der Karte

Explorative Tests von der Erweiterung

Weitere Informationen finden Sie unter Durchsuchen von Arbeitstasks mit der Erweiterung „Test & Feedback“.

Erfassen des Bildaktionsprotokolls, Bildschirmaufzeichnungen und Daten zum Laden von Webseiten mithilfe von „Test & Feedback“

Bildaktionsprotokoll: Die Erweiterung bietet Ihnen außerdem eine neue Option zum Hinzufügen von Schritten, die zum Fehler geführt haben, und zwar automatisch mit nur einem Mausklick. Aktivieren Sie die Option „Bildaktionsprotokoll einschließen“ zum Erfassen der Maus-, Tastatur- oder Toucheingabeaktionen, und fügen Sie den entsprechenden Text und Bilder direkt in den Fehler oder den Task ein.

Bildschirmaufzeichnung als Video: Sie können mit der Erweiterung auch bei Bedarf Bildschirmaufzeichnungen erfassen. Diese Bildschirmaufzeichnungen können nicht nur von den Web-Apps, sondern auch von Ihren Desktop-Apps erfasst werden. Sie können die Erweiterung konfigurieren, um die Bildschirmaufzeichnung automatisch anzuhalten und sie einem Fehler anzufügen, der mithilfe der Seite „Optionen“ der Erweiterung erfasst wird.

Daten zum Laden von Webseiten: Wir haben der Erweiterung eine neue Funktion zum Erfassen von Hintergrundaktionen hinzugefügt: die Erfassung von Daten zum Laden von Webseiten. Ähnlich wie das Bildaktionsprotokoll, das die Aktionen in einer Web-App, die untersucht wird, im Hintergrund in Form von Bildern aufzeichnet, erfasst die Funktionalität „Laden von Seiten“ automatisch Details zum Ladevorgang einer Webseite. Sie müssen sich nicht mehr darauf verlassen, ob ein Webseitenladevorgang subjektiv als langsam wahrgenommen wird, sondern können die Geschwindigkeit jetzt objektiv im Fehler quantifizieren. Sobald der Fehler protokolliert wurde, wird dem Fehler zusätzlich zur Kachelansicht ein detaillierter Bericht angefügt, der dem Entwickler bei der Untersuchung helfen kann.

Explorative Tests – Bildaktionsprotokoll

Erstellen von Testfällen basierend auf Daten im Bildaktionsprotokoll

Sie können jetzt während der explorativen Testsitzung Testfälle erstellen, wobei die Testschritte mit Bildern automatisch für Sie ausgefüllt werden. Die Gleichzeitigkeit von Testentwurf und Testausführung bildet die Grundlage für echte explorative Tests, was mit dieser neuen Funktion Realität wird. Sie können den erfassten Text bearbeiten, das erwartete Ergebnis hinzufügen, nicht relevante Zeilen auschecken und für anstehende Testläufe speichern.

Explorative Tests – Erstellen von Testfällen

Weitere Informationen finden Sie unter Erstellen von Testfällen auf Daten im Bildaktionsprotokoll.

Explorative Tests – Sitzungseinblicke

Sie können jetzt mithilfe der Erweiterung „Test & Feedback“ die abgeschlossenen explorativen Testsitzungen, entweder auf Team- oder individueller Ebene, für einen bestimmten Zeitraum anzeigen. Sie gelangen zu dieser Übersichtsseite, indem Sie in Web Access in der Gruppe „Testhub“ im Hub „Läufe“ auf den Link „Letzte explorative Sitzungen“ klicken. In dieser neuen Ansicht können Sie sich sinnvolle Einblicke verschaffen:

  • Die Zusammenfassungsansicht zeigt der Aufschlüsselung der erstellten und untersuchten Arbeitsaufgaben und der Sitzungsbesitzer sowie die gesamte mit diesen Sitzungen verbrachte Zeit.
  • Die Ansicht „Gruppieren nach“ kann entweder nach untersuchten Arbeitsaufgaben, Sitzungen, Sitzungsbesitzern oder gar nicht pivotiert werden. Für alle Pivots können Sie entweder die Liste aller erstellten Arbeitsaufgaben (Fehler, Aufgaben, Testfälle) anzeigen oder die Liste auf einen bestimmten Arbeitsaufgabentyp beschränken.
  • Die Detailbereichsansicht, in der Informationen basierend auf der Auswahl in der Ansicht „Gruppieren nach“ gezeigt werden. Für eine ausgewählte Pivotzeile (z. B. untersuchte Arbeitsaufgaben) können Sie im Detailbereich zusammenfassende Informationen anzeigen, beispielsweise die Gesamtanzahl von Sitzungen, die insgesamt in diesen Sitzungen verbrachte Zeit, die Sitzungsbesitzer sowie die dazugehörigen Fehler/Aufgaben/Testfälle sowie deren Status und Priorität. Bei einer ausgewählten Arbeitsaufgabenzeile können Sie deren Arbeitsaufgabenformular inline anzeigen und die gewünschten Änderungen vornehmen.

Explorative Tests – Sitzungseinblicke

Weitere Informationen finden Sie unter Einblicke in Ihre explorativen Testsitzungen.

Explorative Testsitzungen: Anzeigen nicht untersuchter Arbeitselemente

Sie können nicht nur die Details aller untersuchten Arbeitselemente in der Ansicht „Letzte explorative Sitzungen“ anzeigen und nach alle oder eigenen Sitzungen in einem bestimmten Zeitraum filtern. Jetzt können Sie in der gleichen Ansicht auch eine Liste aller Arbeitselemente anzeigen, die NICHT untersucht wurden. Sie geben eine freigegebene Abfrage für Arbeitselemente an, an denen Sie interessiert sind, und die Sitzungsseite zeigt eine Liste aller Arbeitselemente aus der Abfrage an, einschließlich einer detaillierten Übersicht über die untersuchten und nicht untersuchten Elemente im Abschnitt „Zusammenfassung“. Darüber hinaus können Sie durch Pivotieren der Gruppe „Nicht untersuchtes Arbeitselement“ die Liste derjenigen Elemente anzeigen, die noch nicht untersucht wurden. Dies ist extrem nützlich, um nachzuverfolgen, wie viele Storys noch nicht untersucht oder einem Bug Bash unterzogen wurden.

Anzeigen von nicht untersuchten WITs

End-to-End-Feedbackflow von Projektbeteiligten
Feedbackanforderung

Benutzer mit Einstiegszugriffsebene können nun Feedback für laufende oder abgeschlossene Features/Storys von Projektbeteiligten anfordern, indem Sie die Feedbackoption im Menü „Arbeitstask“ verwenden. Daraufhin wird das Formular zur Feedbackanforderung geöffnet, in dem Sie die Projektbeteiligten auswählen können, von denen Sie Feedback erhalten möchten. Optional können Sie Anweisungen für die Produktbereiche angeben, für die Sie Feedback erhalten möchten. So werden verschiedene E-Mails an die betroffenen Projektbeteiligten versendet, zusammen mit den bereitgestellten Anweisungen, falls Sie welche definiert haben.

Feedbackflow für explorative Tests

Weitere Informationen finden Sie unter Anfordern von Feedback von Projektbeteiligten mithilfe der Erweiterung „Test & Feedback“.

Feedback geben

Projektbeteiligte können auf die Feedbackanforderung antworten, indem sie auf den Link zum Bereitstellen von Feedback in der erhaltenen E-Mail klicken. Dadurch wird automatisch die Erweiterung „Test & Feedback“ (vorher: Extension für exploratives Testen) mit den ausgewählten Feedbackanforderungen konfiguriert (Sie werden aufgefordert, die Erweiterung zu installieren, falls dies noch nicht erfolgt ist). Projektbeteiligte können dann die gesamten Aufzeichnungsfunktionen der Erweiterung verwenden, um ihre Ergebnisse zu erfassen und ihr Feedback in der Form einer Feedbackantwort, eines Bugs oder eines Task-Arbeitselements zu senden. Darüber hinaus können die Projektbeteiligten auf die Seite „Feedbackanforderungen“ navigieren, um alle Feedbackanforderungen anzuzeigen, die sie erhalten haben. Sie können aus der Liste die Feedbackanforderungen auswählen, für die sie Feedback senden möchten und ihre „ausstehenden Feedbackanforderungen“ verwalten, indem sie sie als abgeschlossen markieren, oder sie ablehnen. Außerdem können sie zwischen verschiedenen Feedbackanforderungstypen wechseln, indem sie auf das gewünschte Optionsfeld klicken.

Feedbackflow für explorative Tests

Feedbackflow für explorative Tests

Weitere Informationen finden Sie unter Bereitstellen von Feedback mit der Erweiterung „Test & Feedback“.

Freiwilliges Feedback

Zusätzlich zum oben genannten angeforderten Feedback, können Projektbeteiligte die Erweiterung auch verwenden, um freiwilliges Feedback zu senden. Sie können die Erweiterung öffnen, den Modus „Verbunden“ auf der Seite der Verbindungseinstellungen auswählen, und sich mit dem Konto und dem Projekt/Team verbinden, für das sie gerne Feedback bereitstellen möchten. Sie können dann die Erweiterung verwenden, um ihre Ergebnisse zu erfassen und ihr Feedback im Feedbackformular für Antworten/Fehler/Arbeitselemente für einen Task absenden.

Feedbackflow für explorative Tests

Weitere Informationen finden Sie unter Bereitstellen von freiwilligem Feedback mit der Erweiterung „Test & Feedback“.

Verbesserungen bei automatisierten Tests

Konsolenprotokolle und Testdauer auf der Registerkarte „Tests“ in der Build- und Releasezusammenfassung

Konsolenprotokolle für Testergebnisse, die in TRX-Dateien erfasst werden, werden extrahiert und als Testergebnisanlagen veröffentlicht. Sie haben die Möglichkeit, sie in der Registerkarte „Tests“ für die Vorschau anzuzeigen und müssen nicht die TRX-Datei herunterladen, um Protokolle anzuzeigen.

Konsolenprotokolle und Dauer

Testtrendwidget für Builds

Wir haben dem Widgetkatalog das neue Widget „Testergebnistrend“ hinzugefügt. Mithilfe dieses Widgets können Sie dem Dashboard ein Diagramm des Testergebnistrends für die letzten bis zu 30 Builds für eine Builddefinition hinzufügen. Mithilfe des Widgets „Konfigurationsoptionen“ können Sie das Diagramm anpassen und Pivots hinzufügen, wie z. B. Anzahl bestandener Tests, Anzahl nicht bestandener Tests, Gesamtanzahl von Tests, Durchlaufprozentsatz und Testdauer.

AttachFileHandler14-800px

Übersicht über Teststatus in der Releaseumgebung

Es ist eine empfohlene Vorgehensweise, Releaseumgebungen zu verwenden, um Anwendungen bereitstellen und zu testen. Mit diesem Release haben wir die Erfolgsquote für Tests in Releaseumgebungen in den Abschnitt „Umgebungen“ der Zusammenfassungsseite für Releases integriert. Der Screenshot zeigt: Wenn in einer Umgebung ein Fehler auftritt, können Sie anhand der Spalte „Tests“ schnell Rückschlüsse ziehen, ob dieser durch Testfehler verursacht wurde. Sie können auf die Erfolgsquote klicken, um zur Registerkarte „Tests“ zu navigieren und die fehlerhaften Tests für diese Umgebung zu untersuchen.

AttachFileHandler8

Automatisierter Testverlauf für Branches und Releaseumgebungen

Einzelne Tests werden häufig in mehreren Branches, Umgebungen und Konfigurationen ausgeführt. Wenn bei einem solchen Test ein Fehler auftritt, ist es wichtig herauszufinden, ob der Fehler sich auf Entwicklungsbranches wie den Masterbranch beschränkt oder ob Fehler sich auch auf Releasebranches auswirken, die für die Bereitstellung in Produktionsumgebungen zuständig sind. Sie können den Verlauf eines Tests jetzt über verschiedene getestete Branches hinweg visualisieren, indem Sie die Registerkarte „Verlauf“ auf der Seite mit der Ergebniszusammenfassung anzeigen. Auf ähnliche Weise gruppieren Sie nach Umgebungspivot, um den Verlauf eines Tests über die verschiedenen Releaseumgebungen hinweg zu visualisieren, in denen er ausgeführt wird.

AttachFileHandler9-800px

Rückverfolgbarkeit mit fortlaufenden Tests

Benutzer können jetzt die Qualität ihrer Anforderungen direkt auf ihrem Dashboard nachverfolgen. Wir haben bereits eine Lösung für die Anforderungsqualität für unsere geplanten Testbenutzer und erweitern diese jetzt auf diejenigen unserer Benutzer, die fortlaufende Tests verfolgen. Benutzer können automatisierte Tests mit den Anforderungen verknüpfen und dann Dashboardwidgets verwenden, um die Qualität der für sie interessanten Anforderungen nachzuverfolgen. Die Qualitätsdaten werden aus dem Build oder dem Release abgerufen.

Widget für die Anforderungsqualität

Remotetests – Verteilen von Tests basierend auf der Anzahl von Computern

Tests können jetzt mithilfe des Tasks „Funktionstests ausführen“ aus einer Assembly auf Remotecomputer verteilt werden. In TFS 2015 konnten Sie Tests nur auf Assemblyebene verteilen. Diese Funktion kann mithilfe des Kontrollkästchens im Task aktiviert werden, wie unten gezeigt.

Taskeinstellung

Automatisierte Tests für SCVMM und VMware

Benutzer können Testcomputer dynamisch mit Azure in der Cloud oder lokal mithilfe von SCVMM oder VMware einrichten und diese Computer zur verteilten Testausführung verwenden. Benutzer können eine der Computerbereitstellungsaufgaben – für Azure, SCVMM oder VMWare – verwenden, gefolgt von der Aufgabe „Funktionstests ausführen“, um Tests auszuführen.

SonarQube-Analyse in Maven- und Gradle-Aufgaben

Sie können jetzt eine SonarQube-Analyse in der Maven- und Gradle-Buildaufgabe auslösen, indem Sie „SonarQube-Analyse ausführen“ aktivieren und den Endpunkt, den SonarQube-Projektnamen, den Projektschlüssel und die Version bereitstellen.

AttachFileHandler1

Sie erhalten jetzt außerdem einen Link zu dem SonarQube-Projekt. Sie können eine vollständige Analyse anfordern, um die Details zu den Quality Gates anzuzeigen, und sich zum Abbruch des Builds entscheiden, wenn sie nicht erfüllt werden.

AttachFileHandler1

Weitere Informationen finden Sie unter The Gradle build task now supports SonarQube analysis (Der Gradle-Buildtask unterstützt jetzt SonarQube-Analysen).

Verbesserungen für den Marketplace

Administratoren der Projektsammlung können jetzt aus einer Team Foundation Server-Instanz zum Visual Studio Marketplace navigieren und kostenlose Erweiterungen in einer Teamprojektsammlung installieren. Die Erweiterungen werden automatisch vom Visual Studio Marketplace heruntergeladen, auf die Team Foundation Server-Instanz heruntergeladen und in der ausgewählten Teamprojektsammlung installiert.

Installieren der kostenlosen Erweiterung

Erwerben und installieren von kostenpflichtigen Erweiterungen

Administratoren der Projektsammlung können jetzt aus einer Team Foundation Server-Instanz zum Visual Studio Marketplace navigieren, kostenpflichtige Extensions erwerben und sie in einer ausgewählten Teamprojektsammlung installieren. Der Administrator kann Extensions mit einem Azure-Abonnement bezahlen und die Anzahl der Benutzer auswählen, denen diese Extensions zugewiesen werden sollen. Diese Extensions werden automatisch aus dem Visual Studio Marketplace heruntergeladen, auf die Team Foundation Server-Instanz hochgeladen und in der ausgewählten Teamprojektsammlung installiert.

Erwerben der kostenpflichtigen Erweiterung

Weitere Informationen finden Sie unter Get extensions for Team Foundation Server (Extensions für Team Foundation Server).

Verbesserungen für die Verwaltung

Windows-Authentifizierung

In früheren Versionen mussten Sie sich zwischen NTLM- und Negotiate-Sicherungsunterstützungsanbietern für die Windows-Authentifizierung entscheiden, wenn Sie eine TFS-Bereitstellung in einem Domänenverband konfiguriert haben. 2017 wurde diese Einstellung aus dem Konfigurationsmenü entfernt. Wenn Sie weiterhin die NTLM-Authentifizierung verwenden möchten, müssen Sie keine Maßnahmen ergreifen. Wenn Sie vorher die Kerberos-Authentifizierung verwendet haben und diese auch weiterhin verwenden möchten, müssen Sie nichts weiter tun. TFS 2017 konfiguriert nun immer die Negotiate- und NTLM-Sicherheitsunterstützungsanbieter in dieser Reihenfolge. Bei dieser Konfiguration wird die Kerberos-Authentifizierung verwendet, wann immer dies möglich ist, und bietet optimierte Sicherheit. Wenn Kerberos nicht genutzt werden kann, wird die NTLM-Authentifizierung verwendet. Wir haben ausführliche Tests durchgeführt, um sicherzustellen, dass es keinen Einfluss auf vorhandene TFS-Bereitstellungen hat, die die NTLM-Authentifizierung aufgrund dieser Änderung verwenden.

Ein modernes Navigationserlebnis

In diesem Release stellen wir eine neue und verbesserte obere Navigationsleiste vor. Diese neue Navigation hat zwei primäre Ziele:

  • Verbessern der Effizienz bei der Navigation über verschiedene Produktbereiche hinweg, indem Sie mit nur einem Klick auf jeden Hub zugreifen können.
  • Moderneres Erscheinungsbild und verbesserte Benutzerfreundlichkeit des Produkts.

Da dies eine tiefgreifende Veränderung für unsere Benutzer darstellt und das Feature weiterhin in Bearbeitung ist, haben wir entschieden, die neue Navigationsoberfläche standardmäßig zu deaktivieren. Wenn Sie die neue Oberfläche ausprobieren möchten, klicken Sie im Administrationsbereich der Team Foundation Server-Systemsteuerung auf „Neue Navigation aktivieren“. Beachten Sie, dass dadurch die neue Oberfläche für alle Benutzer des Servers aktiviert wird.

Berechtigung zum Umbenennen von Teamprojekten

Die Berechtigung, die steuert, welche Benutzer ein Teamprojekt umbenennen dürfen, hat sich geändert. Zuvor konnten Benutzer mit der Berechtigung „Projektebeneninformationen bearbeiten“ ein Teamprojekt umbenennen. Nun kann Benutzern über die neue Berechtigung „Teamprojekt umbenennen“ die entsprechende Berechtigung erteilt werden.

Administratoreinstellungen – Arbeitshub

Auf der Seite „Administratoreinstellungen“ haben wir einen neuen Arbeitshub hinzugefügt, in dem allgemeine Einstellungen, Iterationen und Bereiche auf einer einzelnen Registerkarte zusammengeführt sind. Dank dieser Änderung erkennen Benutzern deutliche Unterschiede zwischen Einstellungen auf Projektebene und Teameinstellungen. In den Teameinstellungen sehen Benutzer nur Bereiche und Iterationen, die für ihr Team relevant sind. Auf Projektebene ermöglicht die Seite „Einstellungen“ Administratoren das Verwalten von Bereichen und Iterationen für das gesamte Projekt. Darüber hinaus wurde für Projektbereichspfade eine neue Spalte namens „Teams“ hinzugefügt, damit Administratoren einfach und schnell erkennen können, welche Teams einen bestimmten Bereichspfad ausgewählt haben.

Administrator – Arbeitshub

REST-APIs für die Prozesskonfiguration

Diese öffentliche API ermöglicht Benutzern das Abrufen der Prozesskonfiguration eines bestimmten Projekts. Die Prozesskonfiguration enthält die folgenden Einstellungen:

  • TypeFields: Abstraktionen anpassbare Felder, die in den Agile-Tools verwendet werden. Beispielsweise ist „Aufwand“ der Typ des Felds „Storypunkte“.
  • Backlogdefinitionen: Bestimmen, welche Arbeitsaufgabentypen in den Backlogs enthalten sind. Dies ist eine häufig angeforderte API von Kunden, die Erweiterungen erstellen. Mithilfe dieser Daten weiß eine Erweiterung, wie prozessspezifische Felder zu nutzen sind, um in den Agile-Tools allgemeine Szenarien zu ermöglichen (z. B. Ändern der Aktivität oder des Aufwands einer Arbeitsaufgabe, Kenntnis darüber, welche Arbeitsaufgaben auf einer bestimmten Backlogebene enthalten sind, oder Bestimmen, ob Teams anhand des Bereichspfads oder eines benutzerdefinierten Felds bestimmt werden). Weitere Informationen finden Sie unter Work.

Neues Benutzererlebnis für Administratoren mit präfixbasierter Suche in AD

Team Foundation Server 2017 führt neue Funktionen zum Verwalten von Gruppen und Gruppenmitgliedschaften ein. Sie können in Benutzern/Gruppen in Active Directory oder auf lokalen Computern mithilfe präfixbasierter Suchkriterien nach Namen von Benutzern bzw. Gruppen suchen. Geben Sie z.B. „John D“ und „samaccountname“ ein (Beispiel: „businessdomain\johbdnd“) ein, und es wird die Kontaktkarte eines Benutzers oder einer Benutzergruppe angezeigt.

Benutzersicherheitseinstellungen

Sie können Ihre persönlichen Zugriffstoken und SSH auf der neuen Oberfläche „Meine Sicherheit“ verwalten. Benutzer, die bisher „Mein Profil“ für die Verwaltung von SSH verwendet haben, müssen ihre öffentlichen SSH-Schlüssel jetzt in den Benutzersicherheitseinstellungen verwalten.

Meine Sicherheit

Meine Sicherheit

Einheitlicher Konfigurations-Assistent

In vorherigen Releases mussten Sie, je nachdem, was Sie erledigen wollten, einen der vielen Konfigurations-Assistenten für Ihre TFS-Bereitstellung auswählen: Die Assistenten für grundlegende oder vollständige Bereitstellungen dienten zum Konfigurieren einer neuen Bereitstellung. Mit dem Upgrade-Assistenten konnten Sie Upgrades vor und während der Produktion einrichten. Der Assistent nur für die Anwendungsebene konnte für eine Vielzahl von Szenarien eingesetzt werden, z.B. zum horizontalen Hochskalieren einer vorhandenen Bereitstellung, zum Ersetzen einer Anwendungsebene durch neue Hardware usw. In TFS 2017 wurden all diese Szenarios zu einem einzigen Serverkonfigurations-Assistenten vereinheitlicht, der Sie anhand einfacher Entscheidungen durch jedes einzelne Szenario führt. Darüber hinaus automatisieren erweiterte Konfigurationen wie z.B. das Ausführen von Upgrades vor der Produktion und das Klonen von vorhandenen Bereitstellungen jetzt Aktionen, die zuvor über tfsconfig.exe ausgeführt wurden. Hierzu gehören das Ändern von Server-IDs, das Neuzuordnen von Datenbank-Verbindungszeichenfolgen und das Entfernen von Verweisen auf externe Abhängigkeiten (diese Aktionen wurden über tfsconfig.exe PrepareClone ausgeführt).

Neue Zugriffsebene

Mit der neuen Visual Studio Enterprise-Gruppe im Zugriffsebenen-Administratorportal in Team Foundation Server können Sie jetzt schnell feststellen, wer über ein Visual Studio Enterprise-Abonnement verfügt. Nach der Identifikation erhalten diese Benutzer ohne Zusatzkosten Vollzugriff auf alle TFS-Erstanbieterextensions, die aus dem Visual Studio Marketplace installiert wurden.

Persönliche Zugriffstoken

Sie können jetzt Verbindungen zu beliebigen Team Foundation Server-Instanzen nicht nur über SSH, sondern auch mithilfe eines persönlichen Zugriffstokens herstellen. Dies ist hilfreich, wenn Sie unter Linux oder Mac entwickeln und Automatisierungstools und Git verwenden möchten. Sie können Ihre persönlichen Zugriffstoken über die Seite mit den Einstellungen der Benutzersicherheit verwalten.

Persönliche Zugriffstoken

Bekannte Probleme

Dies ist eine vollständige Liste der bekannten Probleme in diesem Release.

Für Team Foundation Server 2017 sind keine Power Tools vorhanden

  • Problem:

    Es wurden keine Power Tools für TFS 2017 veröffentlicht.

  • Problemumgehung:

    Wir freuen uns, Ihnen mitteilen zu können, die der Großteil der vorherigen Power Tools in TFS 2017 integriert wurde. Der Prozessvorlagen-Editor wurde nicht integriert, jedoch werden wir ein Prozessvorlagen-Editor-Tool für TFS 2017 zur Visual Studio Gallery hinzufügen, kurz nachdem TFS 2017 verfügbar gemacht wurde. Sobald dieses Tool veröffentlicht wird, finden Sie an dieser Stelle den Link dafür.

Aktualisierung der Extensions für benutzerdefinierte Steuerelemente

Fehler beim Importieren der Definition des Arbeitselementtyps

  • Problem:

    Kunden, bei denen eine Erweiterung für eine Arbeitselementseite installiert ist und die eine Definition eines Arbeitselementtyps exportieren und anschließend wieder importieren, wird folgender Fehler angezeigt: „The ‘LayoutMode’ attribute is not declared“ (Das Attribut „Layoutmodus“ ist nicht deklariert).

  • Problemumgehung:

    Es ist ein zusätzliches LayoutMode-Attribut im PageContribution-Element erhältlich, und zwar jedes Mal, wenn Sie eine Definition eines Arbeitselementtyps exportieren. Suchen Sie vor dem Importieren der Definition nach dem PageContribution-Modus, und entfernen Sie das LayoutMode-Attribut. Entfernen Sie z.B. LayoutMode="FirstColumnWide".

Kunden sollten ein Update auf Git LFS, Version 1.3.1 oder höher, ausführen

  • Problem:

    Git LFS-Versionen vor 1.3.1 werden in kommenden Releases nicht unterstützt.

  • Problemumgehung:

    Kunden, die Git LFS verwenden, wird dringend empfohlen, ein Update auf Git LFS, Version 1.3.1 oder höher, auszuführen. Ältere Versionen des LFS-Clients sind mit den Änderungen an der Authentifizierung in dieser Version von TFS nicht kompatibel. Um Kunden Zeit für die Migration zu geben, haben wir eine kurzfristige Problemumgehung für RTW implementiert. Die Problemumgehung wird in Update 1 entfernt, und von diesem Zeitpunkt an funktionieren Git LFS-Clients vor Version 1.3.1 nicht mehr.

NuGet Restore findet Pakete nicht, die in nuget.org vorhanden sind.

  • Problem:

    Beim Verwenden von NuGet 3.4.3 oder höher stellt die NuGet Restore-Aufgabe keine Pakete von NuGet.org wieder her, sofern die Quelle in NuGet.Config nicht explizit angegeben ist.

  • Problemumgehung:

    Achten Sie darauf, dass NuGet.org in NuGet-Config vorhanden ist.


NuGet-Build- und Releasetasks werden nicht authentifiziert.

  • Problem:

    Bei der Verwendung der Team Foundation Server/Paketverwaltung werden NuGet-Build- und Releaseaufgeben nicht bei Feeds authentifiziert, wenn der Agent als NETZWERKDIENST-Benutzer ausgeführt wird – dies ist die Standardeinstellung bei Ausführung des Build-Agents als Dienst. Dies hat den Grund, dass NuGet-Versionen vor Version 3.5 die Anmeldeinformationen des Benutzerkontos verwenden, das den Build-Agent ausführt, nicht die von der Buildaufgabe bereitgestellten Anmeldeinformationen.

  • Problemumgehung:

    Um NuGet-Build-/Releaseaufgaben mit TFS-Feeds und einem Agent zu verwenden, der als NETZWERKDIENST ausgeführt wird, müssen Sie NuGet 3.5 oder höher verwenden.

NuGet Build- und Releaseaufgaben verwenden die Anmeldeinformationen des Agents

  • Problem:

    NuGet-Versionen vor Version 3.5 verwenden die Anmeldeinformationen des Benutzerkontos , das den Build-Agent ausführt, nicht die von der Buildaufgabe bereitgestellten Anmeldeinformationen. Dies kann zu unerwartetem Zugriff oder keinem Zugriff auf Feeds führen.

  • Problemumgehung:

    Verwenden Sie NuGet 3.5 oder höher für TFS-Build-Agents.

Externe Erweiterungen werden nicht automatisch aktualisiert, wenn Sie TFS upgraden.

  • Problem:

    Wenn Sie eine Erweiterung von Visual Studio Marketplace heruntergeladen haben, sie auf der Installation von TFS 2015 veröffentlicht haben und anschließend ein Upgrade auf TFS 2017 durchgeführt haben, wird die Erweiterung nicht automatisch aktualisiert, wenn neue Versionen der Erweiterung auf Marketplace veröffentlicht werden.

  • Problemumgehung:

    Deinstallieren Sie nach der Aktualisierung auf TFS 2017 die Erweiterungen, die Sie in TFS 2015 installiert haben. Installieren Sie anschließend die neueste Erweiterung erneut. In TFS 2017 haben wir eine Funktion hinzugefügt, die automatisch einmal pro Tag nach aktualisierten externen Erweiterungen sucht und für diese ein Upgrade durchführt.

Der Jenkins-Warteschlangentask kann nicht in Releasedefinitionen ausgeführt werden

  • Problem:

    Bei der Ausführung des Jenkins-Warteschlangentasks in einer Releasedefinition erhalten Kunden einen „500“-Serverfehler.

  • Problemumgehung:

    Derzeit kann der Jenkins-Warteschlangentask als Teil einer TFS-Builddefintion ausgeführt werden, jedoch können keine Releasedefinitionen ausgeführt werden. Diese Funktion wird in einer zukünftigen Version hinzugefügt.

Benutzerdefinierte TFS-Server-Plug-Ins müssen mit TFS 2017 DLLs wiederhergestellt werden.

  • Problem:

    Benutzerdefinierte TFS-Server-Plug-Ins funktionieren nicht nach dem Upgrade auf TFS 2017.

  • Problemumgehung:

    Erstellen Sie Ihre benutzerdefinierten Plug-Ins für die TFS-2017 Assemblys neu.

Das Serverobjektmodell für benutzerdefinierte TFS-Server-Plug-Ins wurde seit TFS 2015 RTM geändert.

  • Problem:

    Benutzerdefinierte TFS-Server-Plug-Ins können nicht kompiliert werden.

  • Problemumgehung:

    Passen Sie den Quellcode, wie in diesem Blogbeitrag beschrieben, an.

Beim Verwenden von Administratoraktionen wird eine Ausnahme ausgelöst

  • Problem:

    Wenn Team-Administratoren auf der Seite Warnungsverwaltung die Suchoption Benachrichtigungen für einen bestimmten Benutzer finden verwenden, um Abonnements für ein Team zu suchen, wird möglicherweise eine Ausnahme ausgelöst.

  • Problemumgehung:

    • Option 1: Klicken Sie auf den Knoten Alle Warnungen, und legen Sie den Filter Alle "Meine Teams"-Warnungen auf „Anzeigen“ fest. Dadurch werden alle Warnungen für alle Gruppen angezeigt, auf die der Benutzer Zugriff hat.

    • Option 2: Falls es sich bei der Gruppe um ein Team handelt, suchen Sie nicht anhand des Teamnamens, sondern wechseln Sie auf die Seite Warnungsverwaltung, um Abonnements zu verwalten.

Problem beim Verwenden von Tasks zum Ausführen von Funktionstests in Team Build/Release Management

  • Problem:

    Das Ausführen von Funktionstests in Team Build/Release Management mithilfe der Tasks „Visual Studio Test Agent-Bereitstellung“ und „Funktionstests ausführen“ aus dem Taskkatalog verwendet zurzeit Agents für Visual Studio 2015 Update 3 und kann nur zum Ausführen von Tests verwendet werden, die mit Visual Studio 2013 und Visual Studio 2015 erstellt wurden. Dieses Tasks können nicht zum Ausführen von Tests verwendet werden, die mit Visual Studio 2017 RC erstellt wurden. Weitere Informationen finden Sie in diesem Blogbeitrag.

  • Problemumgehung:

    Es gibt keine Problemumgehung. Unterstützung für die Verwendung von Test Agent 2017 sowie zum Ausführen von Tests, die mit Visual Studio 2017 erstellt wurden, wird im Zeitrahmen von TFS 2017 Update 1 hinzugefügt.

Erweiterungen werden nicht automatisch aktualisiert

  • Problem:

    Wenn Sie eine frühere Version von TFS upgraden, um TFS 2017 zu erreichen, und TFS 2017 im verbundenen Modus ausgeführt wird, dann werden Ihre Erweiterungen nicht automatisch aktualisiert wie sie es sollten.

  • Problemumgehung:

    Zurzeit gibt es keine Problemumgehung. Wir haben das Problem behoben. Das automatische Updateverhalten erreichen Sie über TFS 2017 Update 2. Wenn Sie aus irgendeinem Grund nicht auf Update 2 warten können, dann erreichen Sie uns über den Support-Kanal, und wir stellen die Lösung früher bereit.

Wenn Probleme auftreten, die Sie am Bereitstellen in einer Produktionsumgebung („Go-Live“) hindern, wenden Sie sich an den Microsoft-Produktsupport. (nur englischsprachig) während der US-Bürozeiten (Mo–Fr 06:00–18:00 PST). Die Antwortzeit beträgt einen Arbeitstag.