Team Foundation Server 2017: Versionshinweise

---

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

---

---

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

Weitere Informationen zu Team Foundation Server 2017 finden Sie auf der Seite Team Foundation Server – Anforderungen und Kompatibilität.

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

---

Veröffentlichungsdatum: 28. Februar 2018

Dieses Update tilgt die Möglichkeit von XSS-Angriffen (Cross-Site Scripting) und andere Sicherheitsrisiken. Weitere Informationen finden Sie im Blogbeitrag. Es handelt sich um ein vollständiges direktes Upgrade auf TFS 2017.0.1.

Veröffentlichungsdatum: 16. November 2016

Zusammenfassung der Neuerungen in Team Foundation Server 2017

• Codesuche
• Paketverwaltung
• Agile-Verbesserungen
• Verbesserungen bei Dashboards und Widgets
• Verbesserungen für Git
• Verbesserungen für Builds
• Verbesserungen beim Release Management
• Verbesserungen für Tests
• Verbesserungen für den Marketplace
• Verbesserungen für die Verwaltung
• Persönliche Zugriffstoken

Bekannte Probleme

• Bekannte Probleme

---

Details zu den Neuerungen zu den Neuerungen in Team Foundation Server 2017

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

Die Codesuche bietet Folgendes:

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

Ausführliche Informationen finden Suchen für den gesamten Code.

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. Die Paketverwaltung (Abbildung 2) vereinfacht die Codefreigabe, indem Ihre Pakete gehostet 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.

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 Arbeitselemente (Abbildung 3) hat ein neues Aussehen und Verhalten. Außerdem wurden einige wichtige neue Features hinzugefügt:

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

Einem Arbeitselement folgen

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

Ausführliche Informationen finden Folgen eines Arbeitselements.

Live-Updates 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 (Abbildung 5) .

Wenn jemand in Ihrem Team ein Arbeitselement 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 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 (Abbildung 6) . Sie können auf den Titel klicken, um das Arbeitselementformular zu öffnen.

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

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

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

Ein- und Ausschalten von Board-Anmerkungen

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 (Abbildung 9) . 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 Arbeitselemente (Aufgaben in diesem Beispiel) und die Anmerkung „Test“.

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

Befehl „Formatierung löschen“

Wir haben allen umfassenden Textsteuerelementen für Arbeitselemente 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 die meisten Benutzer, 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, Arbeitselementtypen und Tags (Abbildung 10) . Diese Filter bleiben erhalten, sodass Sie Ihr personalisiertes Board auch anzeigen können, wenn Sie auf mehreren Geräten eine Verbindung herstellen.

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 „Neues Arbeitselement erstellen“ ein neues Arbeitselement erstellen, wird der Iterationspfad dieses Arbeitselements 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 Arbeitselemente verwendet werden soll. Navigieren Sie zum Verwaltungsbereich Ihres Teams, um eine Standarditeration zu wählen.

Weitere Informationen finden Sie auf der Seite Customize area and iteration paths (Anpassen von Bereichs- und Iterationspfaden).

Kontrollkästchen-Steuerelement

Sie können Ihrem Arbeitselement nun ein Kontrollkästchen-Steuerelement hinzufügen (Abbildung 11) . 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.

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

Sammelbearbeitung von Tags

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

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

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. Erweiterungen können den rechten Bereich als Ziel setzen, in dem sich aktuell Zuordnungen und Arbeitsdetails befinden (Abbildung 13) .

E-Mail-Verbesserungen

Wir haben die Formatierung und die Nutzbarkeit von Arbeitselementwarnungen, Nachverfolgungen und @mention-E-Mails, die von TFS gesendet werden, erheblich verbessert (Abbildung 14). 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.

Weitere Informationen finden Sie unter Arbeitselementwarnungen.

Arbeitselementvorlagen

Wir haben die Funktion zum Erstellen umfassender Vorlagen für Arbeitselemente direkt zur nativen Weboberfläche hinzugefügt (Abbildung 15) . 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.

Weitere Informationen finden Sie unter Arbeitselementvorlagen.

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 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 (Abbildung 16) . Das neue Design bringt verbesserte Suchfunktionen und wurde entsprechend dem Design unserer Fenster für die Konfiguration von Widgets neu gestaltet.

Weitere Informationen finden Sie im Widgetkatalog.

Änderungen an Widgets

Das Widget „Abfragekachel“ unterstützt nun bis zu zehn bedingte Regeln und bietet auswählbare Farben (Abbildung 17) . Dies ist äußerst praktisch, wenn Sie diese Kacheln als Leistungskennzahlen (Key Performance Indicator, KPI) verwenden möchten, um die Integrität und/oder eine ggf. erforderliche Aktion zu bestimmen.

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 „Neues Arbeitselement“ ermöglicht nun das Auswählen des standardmäßigen Arbeitselementtyps, 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.

Wir haben das Widget „Teammitglieder“ aktualisiert, um Ihnen das Hinzufügen eines Mitglieds zu Ihrem Team zu vereinfachen (Abbildung 18) .

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

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

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 denen Sie Pushvorgänge vorgenommen oder die Sie favorisiert haben (Abbildung 20) . 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.

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 (Abbildung 21) . Wir haben den Header umstrukturiert, sodass er alle kritischen Status und Aktionen zusammenfasst und den Zugriff aus jeder Ansicht der Oberfläche ermöglicht.

Übersicht

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

Dateien

Die wichtigste neue Funktion in dieser Version ist die Möglichkeit, die in der Vergangenheit an einem Pull Request vorgenommenen Änderungen anzuzeigen (Abbildung 23) . 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.

Updates

Die neue Ansicht „Aktualisierungen“ zeigt, wie sich PRs über einen Zeitraum verändern (Abbildung 24) . 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.

Kommentare jetzt mit Markdown und Emoji

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

Hinzufügen und Entfernen von Reviewern 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 Reviewer zu entfernen, zeigen Sie im Abschnitt „Reviewer“ auf die entsprechende Kachel, und klicken Sie auf das X, um ihn zu entfernen (Abbildung 26) .

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

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

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

Teams, die Branchrichtlinien verwenden, um ihre Branches zu schützen, sollten die neue AutoComplete-Aktion ausprobieren. Oftmals ist der Autor eines Pull Requests zu einem Merge seines PR 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 (Abbildung 29) .

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

Nachdem die automatische Vervollständigung festgelegt wurde, zeigt der PR ein Banner zur Bestätigung an. Sie wartet auf den Abschluss der Richtlinien (Abbildung 31) .

Wenn allen Richtlinien erfüllt werden (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“ (Abbildung 32) . 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.

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

Rückverfolgbarkeit von Commits

Der Buildstatus (Erfolg oder Fehler) ist jetzt in den Ansichten „Code-Explorer“ und „Commit-Details“ deutlich erkennbar (Abbildung 33) . 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 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.

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

Erstellen und Senden von Links zu bestimmten Codeabschnitten

Geben Sie Codeverweise mithilfe von Codelinks einfach frei (Abbildung 34) . 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.

Status-API

Erfolge und Fehler bei Builds sind jetzt in den Ansichten „Code-Explorer“ und „Commit-Details“ deutlich erkennbar (Abbildung 35) . 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.

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

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

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

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 (Abbildung 39) . Die Ergebnisansicht hat zwei Spalten, und alle Erweiterungen erfolgen standardmäßig an der ersten Spalte. Hinweis: Alle Erweiterungen von Drittanbietern werden nach den von uns bereitgestellten Abschnitten mit Buildergebnissen angezeigt.

Build bis Zeilennummer

Jetzt können Sie von einem Buildfehler zur Codezeile springen, die ihn verursacht hat. Wenn Sie sich den letzten Fehler im primären Build anschauen, der intern als Pull Request-Richtlinie verwendet wird, sehen Sie Folgendes (Abbildung 40) :

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

Weitere Informationen zu Vorlagen finden Sie unter Buildschritte.

Xamarin-Buildaufgaben

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

• Der Schritt Xamarin.Android unterstützt jetzt Mac und Linux.
• Der Schritt Xamarin.iOS Schritt unterstützt jetzt das Signieren und Packen.
• Xamarin Test Cloud-Ergebnisse können auf der Zusammenfassungsseite des Builds angezeigt werden.
• Der Schritt Xamarin-Komponente wiederherstellen wurde hinzugefügt.
• Der Schritt NuGet-Installer unterstützt jetzt Mac OS.

Der Schritt „Xamarin-Lizenz“ ist nicht mehr erforderlich und wurde aus den Buildvorlagen entfernt. Im Rahmen dieser Änderung markieren wir die Aufgabe 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 haben wir die Xamarin-Builddefinitionsvorlagen, 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 (Abbildung 42) . 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.

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

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

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

Es wurde 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 (Abbildung 45) .

Weitere Informationen finden Sie in der Dokumentation 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 Funktion verwendet, um eine Zusammenfassung der Testergebnisse anzuzeigen, wenn Tests als Teil einer Releaseumgebung ausgeführt werden (Abbildung 46) .

Weitere Informationen finden Sie in der Dokumentation 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 ein Arbeitselement 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 (Abbildung 47) .

Weitere Informationen finden Sie in der Dokumentation Environment general options (Allgemeine Umgebungsoptionen).

Dies ist ein einfaches Beispiel, das zeigt, wie Sie eine Builddefinition erhalten (Abbildung 48) :

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

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

Weitere Informationen finden Sie in der Dokumentation 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 (Abbildung 51) .

Weitere Informationen finden Sie in der Dokumentation 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 (Abbildung 52) .

Taskgruppen

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

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.

Ausführliche Informationen finden Sie in der Dokumentation 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 (Abbildung 54).

Weitere Informationen finden Sie in der Dokumentation 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 verknüpfte Build beibehalten werden.

Standardmäßig wird ein Release für 60 Tage beibehalten. Releases, die in dieser Zeit nicht bereitgestellt oder geä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 (Abbildung 55) .

Weitere Informationen finden Sie in der Dokumentation 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 (Abbildung 56) . Jede Artefakt 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.

Weitere Details finden Sie in der Dokumentation zum [Artefaktquellenalias](/vsts/pipelines/release/artifacts?preserve-view=true&view=vsts#source-alias).

• 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 in der Dokumentation 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 (Abbildung 57) .

Weitere Informationen finden Sie in der Dokumentation Manual Intervention (Manuelle Eingriffe).

Taskskripts für die SQL-Datenbankbereitstellung

Der Task der Azure SQL-Datenbankbereitstellung(Abbildung 58) 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.

Ü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 in der Dokumentation 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 (Abbildung 59) .

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 in der Dokumentation 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.

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

Weitere Informationen finden Sie in der Dokumentation 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 empfiehlt sich, die zu konfigurieren und zu warten, bis die Richtlinie aktiviert ist, und den von testergebnissen verwendeten Speicher zu reduzieren, damit das TFS-Upgrade schneller erfolgt. Nach der Installation von TFS, aber vor dem Upgrade des TFS-instance können Sie das TFSConfig.exe Tool verwenden, um Testergebnisse zu sauber. 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. Weitere Beispiele zum Konfigurieren einer Testaufbewahrungsrichtlinie mit Team Foundation Server 2015 .

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 (Abbildung 61) . Sie können jetzt Testkonfigurationen erstellen und verwalten und Konfigurationsvariablen im Testhub testen.

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

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

Sortieren von Tests im Testhub und auf Karten

Sie können nun im Testhub (Abbildung 65) 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 (Abbildung 66) .

Sortieren von Testsammlungen im Testhub

Testteams können Testsammlungen jetzt gemäß ihren Anforderungen sortieren. Bisher 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 (Abbildung 67) .

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 (Abbildung 68) . Dies ist besonders nützlich in Szenarios, in denen viele Teammitglieder vorhanden sind, das Kontextmenü aber nur eine begrenzte Anzahl von Einträgen anzeigt *(Abbildung 69).

Auswählen eines Builds zum Testen

Sie können jetzt den Build auswählen, mit dem Sie testen möchten, und dann mit „Mit Optionen ausführen“ im Testhub den Webrunner starten (Abbildung 70) . 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.

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 (Abbildung 71) verknüpft werden soll. Dann können Sie 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.

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

Auswählen von Datensammlern und Starten des Exploratory 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“ (Abbildung 72) auf, und wählen Sie Exploratory Runner und die benötigten Datensammler aus. Der Explorative Runner wird in ähnlicher Weise wie der Microsoft Test Runner gestartet, wie oben beschrieben.

Übergreifendes Konfigurieren von Testergebnissen über verschiedene Testsammlungen

Es wurde die Möglichkeit hinzugefügt, das Verhalten bei Testergebnissen für Tests zu konfigurieren, die in verschiedenen Testsammlungen unter dem gleichen Testplan verwendet werden (Abbildung 73) . 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.

Überprüfen von Fehlern eines Arbeitselements

Sie können nun einen Fehler überprüfen, indem Sie die Tests erneut ausführen, die den Fehler erkannt haben (Abbildung 74) . 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.

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

Testen des Status 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 (Abbildung 75) .

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 (Abbildung 76) bringt Sie zum Testhub, öffnet den richtigen Testplan und wählt dann die Sammlung aus, die diese Inlinetests steuert.

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 (Abbildung 77) . 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 Testplan Ihrer Wahl konfigurieren – alle Tests werden dann dem ausgewählten Testplan hinzugefügt. Beachten Sie, dass diese Funktionalität nur verwendet werden kann, wenn Testanmerkungen aktiviert sind.

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 (Abbildung 78) . Diese Anlagen mit Schrittergebnissen werden automatisch in allen Fehlern, die Sie in der Sitzung erfassen, und anschließend im Bereich „Testergebnisse“ angezeigt.

Unterstützung für Screenshots, Bildaktionsprotokolle, Bildschirmaufzeichnungen und Systeminformationen in Webrunner (wenn Sie den Browser Chrome verwenden)

Beim Verwenden des Web Test Runners in Chrome können Sie nun Screenshots erstellen und in der gleichen Zeile mit Anmerkungen versehen (Abbildung 79) . 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“.

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

Als untergeordnete Elemente erfasste Fehler – Webrunner/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 „Fehler erscheinen nicht in Backlogs oder Boards“ oder „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 (Abbildung 80) . Alle erfassten Diagnosedaten, Reproduktionsschritte und Links zur Nachverfolgung aus der aktuellen Sitzung werden automatisch dem vorhandenen Fehler hinzugefügt.

Verbesserungen der 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 (Abbildung 81) . Dadurch können Sie das ausgewählte Arbeitselement ihrer aktuell stattfindenden Testsitzung zuordnen und Akzeptanzkriterien und die Beschreibung aus der Erweiterung selbst anzeigen. Ferner wird dadurch eine End-to-End-Nachverfolgbarkeit zwischen den abgelegten Fehlern oder Tasks im ausgewählten Arbeitselement etabliert. Das Arbeitselement kann entweder direkt im Arbeitselement oder in der Erweiterung untersucht werden:

• Direkt im Arbeitselement (Abbildung 81): 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.

• In der Erweiterung (Abbildung 82): Suchen Sie innerhalb der XT-Sitzung nach einem Arbeitselement, und ordnen Sie es dann der aktuell ausgeführten Sitzung zu.

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

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

Bildaktionsprotokoll: Die Erweiterung bietet Ihnen eine neue Option zum Hinzufügen von Schritten, die Sie zum Fehler führen, und zwar automatisch mit nur einem Klick. Aktivieren Sie die Option „Bildaktionsprotokoll einschließen“ (Abbildung 83) 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 bei Bedarf auch 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 Daten im Hintergrund 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.

Erstellen von Testfällen basierend auf Daten im Bildaktionsprotokoll

Wenn Sie während der explorativen Testsitzung Testfälle erstellen, werden die Testschritte mit Bildern automatisch für Sie ausgefüllt (Abbildung 84) . 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.

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 Arbeitselemente und der Sitzungsbesitzer sowie die gesamte mit diesen Sitzungen verbrachte Zeit (Abbildung 85) .
• 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 Arbeitselemente (Fehler, Aufgaben, Testfälle) anzeigen oder die Liste auf einen bestimmten Arbeitselementtyp 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 Arbeitselemente) 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 Arbeitselementzeile können Sie das zugehörigen Arbeitselementformular inline anzeigen und die gewünschten Änderungen vornehmen.

Weitere Informationen finden Sie unter Einblicke in Ihre explorativen Testsitzungen.

Explorative Testsitzungen: Anzeigen von nicht untersuchten Arbeitselementen

Sie können nicht nur die Details aller untersuchten Arbeitselemente in der Ansicht „Letzte explorative Sitzungen“ anzeigen und nach allen 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 (Abbildung 86) . 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.

End-to-End-Feedbackflow von Projektbeteiligten

Feedbackanforderung

Benutzer mit Basiszugriffsebene können nun Feedback für laufende oder abgeschlossene Features/Storys von Projektbeteiligten anfordern, indem Sie die Feedbackoption im Menü „Arbeitselement“ verwenden (Abbildung 87) . 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.

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

Feedback bereitstellen

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“ (Abbildung 88) 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 (Abbildung 89) .

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

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

Testtrendwidget für Builds

Wir haben dem Widgetkatalog das neue Widget „Testergebnistrend“ hinzugefügt (Abbildung 92) . 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.

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

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

Rückverfolgbarkeit mit fortlaufenden Tests

Benutzer können jetzt die Qualität ihrer Anforderungen direkt auf ihrem Dashboard nachverfolgen (Abbildung 95) . 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.

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 (Abbildung 96) . In TFS 2015 konnten Sie Tests nur auf Assemblyebene verteilen. Diese Funktion kann mithilfe des Kontrollkästchens im Task aktiviert werden, wie unten gezeigt.

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

Sie erhalten jetzt außerdem einen Link zu dem SonarQube-Projekt (Abbildung 98) . 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.

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

Verbesserungen für 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 (Abbildung 99) .

Erwerben und installieren von kostenpflichtigen Erweiterungen

Administratoren der Projektsammlung können jetzt aus einer Team Foundation Server-Instanz zum Visual Studio Marketplace navigieren, kostenpflichtige Erweiterugen erwerben und sie in einer ausgewählten Teamprojektsammlung installieren (Abbildung 100) . 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.

Weitere Informationen finden Sie in der Dokumentation 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 (Abbildung 101) , 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.

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 Arbeitselementtypen 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 eines Arbeitselements, Kenntnis darüber, welche Arbeitselemente 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 (Abbildung 102) . 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 (Abbildung 103) .

Einheitlicher Konfigurations-Assistent

In früheren Releases haben Sie einen von mehreren Konfigurationsassistenten für Ihre TFS-Bereitstellung ausgewählt, je nachdem, was Sie versucht haben. 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 (Abbildung 104) . 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.

---

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. Leider wurde der Prozessvorlagen-Editor nicht integriert; Sie können ihn aber im Visual Studio Marketplace erhalten.

Aktualisierung der Extensions für benutzerdefinierte Steuerelemente

• Problem:

  Das Schema für Felder auf dem Arbeitselementformular hat sich geändert. Die Dokumentation für Erweiterungen für benutzerdefinierte Steuerelemente hat sich ebenfalls geändert.

• Problemumgehung:

  Informationen finden Sie in der neuen Dokumentation: Hinzufügen eines benutzerdefinierten Steuerelements zum Arbeitselementformular.

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: „Das LayoutMode-Attribut 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.

  <packageSources><add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3">
  </packageSources>

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 des Teams, 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.

Sehen Sie sich die von Benutzern gemeldeten Probleme zu Team Foundation Server 2017 an.

---

Vorschläge und Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Feature vorschlagen oder ein Problem melden und es über die Entwicklercommunity nachverfolgen und Ratschläge zu Stack Overflow erhalten.

---

Seitenanfang