Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Entwicklercommunity | Systemanforderungen und Kompatibilität | Lizenzbedingungen | TFS-DevOps-Blog | SHA-1-Hashes | | Neueste Versionshinweise für Visual Studio 2019|
Hinweis
Dies ist nicht die neueste Version von Team Foundation Server. Um die neueste Version herunterzuladen, besuchen Sie bitte die aktuellen Versionshinweise für Team Foundation Server 2018 Update 3. Sie können die Sprache auf dieser Seite ändern, indem Sie in der Seitenfußzeile auf das Globussymbol klicken und die gewünschte Sprache auswählen.
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 Requirements and Compatibility (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 in diesem 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
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
- Code-Zusammenarbeit
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. 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 bietet erstklassigen Support für NuGet 3.x sowie Unterstützung für ältere NuGet 2.x-Clients. Der Paketverwaltungsdienst arbeitet nahtlos mit Ihrer vorhandenen TFS-Infrastruktur, Ihren Teams und Berechtigungen zusammen, sodass es nicht notwendig ist, sich um das Synchronisieren von Identitäten oder das Verwalten von Gruppen an mehreren Stellen zu kümmern. Außerdem lässt er sich einfach in Team Build integrieren, sodass Sie Pakete in kontinuierlichen Integrations-Workflows erstellen und verwenden können.
Weitere Informationen finden Sie in der Übersicht zur 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 eine neue Funktionalität. Außerdem wurden einige wichtige neue Features hinzugefügt:
- Eine umfassende Erfahrung für die Diskussion von Arbeitselementen
- Drag & Drop-Unterstützung für Anlagen
- Verbessertes Verlaufserlebnis (Verlauf und Auditierung)
- 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.
Einer Aufgabe 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.
Weitere Informationen finden Sie unter Einem Arbeitselement folgen.
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 detaillierte Einblicke zu gewinnen (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 Anmerkungen, die hier erscheinen, sind untergeordnete Arbeitselemente (in diesem Beispiel Aufgaben) und die Test-Anmerkung.
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 wie die meisten Benutzer sind, haben Sie sich wahrscheinlich in der Vergangenheit die Finger verbrannt, wenn Sie formatierten Text in dieses Feld kopiert und eingefügt haben, den Sie nicht rückgängig machen (oder löschen) konnten. 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.
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ästchensteuerelement 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, der es Ihnen ermöglicht, Erweiterungen als Pivot-Registerkarte neben den Registerkarten „Board“, „Backlog“ und „Kapazität“ zu schreiben.
Wir haben einen neuen Erweiterungspunkt im Backlog freigegeben. 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 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 (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 (KPIs) verwenden möchten, um die Gesundheit und/oder gegebenenfalls erforderliche Maßnahmen 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 der von uns gelieferten Widgets vergrößerbar zu machen, also schauen Sie für weitere Informationen hier vorbei.
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.
Wir haben die WIT-Diagramm-Widgets anpassbar gemacht. 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-Administrator-Benutzer können jetzt Team-Dashboards 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 den "Mine"-Drehpunkt mit den Branches, die Sie erstellt, zu denen Sie gepusht 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 Ihrer Zweigstelle kennen, können Sie nach diesem suchen, 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 Sicht innerhalb des Erlebnisses ermöglicht.
Überblick
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 früheren Vorschauversionen haben wir die Funktion zum korrekten 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.
Aktualisierungen
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, Gutachter zu Ihren Pull Requests hinzuzufügen oder zu entfernen. Um Ihrem Pull Request einen Gutachter oder eine Gruppe hinzuzufügen, geben Sie im Abschnitt „Reviewer“ einfach 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 Build- und Pull-Request-Rückverfolgbarkeit
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
Bei Pull-Anfragen in VSTS wurde die Funktionalität verbessert, sodass Kommentare an der richtigen Zeile in Dateien angezeigt werden, selbst 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 ist eine Beispieländerung mit einem Kommentar in Zeile 13 (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).
Automatisches Vervollständigen von Pull-Anfragen, die auf Richtlinien warten
Teams, die Branchrichtlinien verwenden, um ihre Branches zu schützen, sollten die neue AutoComplete-Aktion ausprobieren. Oftmals ist der Ersteller eines Pull Requests bereit für die Zusammenführung seines PR, wartet aber darauf, dass ein Build abgeschlossen wird, bevor er auf „Abgeschlossen“ klicken kann. Manchmal wird der Build genehmigt, aber die endgültige Zustimmung eines einzelnen Prüfers steht noch aus. In diesen Fällen ermöglicht die Auto-Complete-Aktion dem Autor, den PR so festzulegen, dass er automatisch abgeschlossen wird, 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).
Sobald die automatische Vervollständigung festgelegt wurde, zeigt der PR ein Banner an, das bestätigt, dass die automatische Vervollständigung eingestellt ist und auf den Abschluss der Richtlinien wartet (Abbildung 31).
Wenn alle Richtlinien erfüllt sind (z.B. der Build abgeschlossen ist oder die endgültige Genehmigung erteilt wird), wird der PR mit den angegebenen Optionen und Kommentaren zusammengeführt. 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-Anfragen
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 eine einfachere Verlaufsgrafik, da erstellte Zwischencommits am Themen-Branch in der resultierenden Commit-Grafik nicht erreichbar sind.
Sie finden weitere Informationen zu Squash-Merge-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 der Builddefinition veröffentlichen. 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 zu dem Pull Request angezeigt, der die Änderungen in den Hauptbranch eingeführt hat (oder bei einem Merge-Commit der Pull Request, der ihn erstellt hat). Wenn Ihre Änderungen den Hauptzweig erreicht haben, wird der Zweiglink angezeigt, der bestätigt, 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).
Beim Erstellen des Repositories eine ReadMe-Datei hinzufügen
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 ReadMe-Datei zu einem Repository hilft nicht nur anderen Benutzern, den Zweck der Codebasis zu verstehen, sondern ermöglicht es 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 der Bauergebnisse zur Angabe 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 hinter den von uns hinzugefügten Abschnitten mit Buildergebnissen angezeigt.
Erstellen bis zur 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 Bauschritte.
Xamarin-Buildaufgaben
Wir haben einige bedeutende Verbesserungen an unser Xamarin-Unterstützung vorgenommen:
- Der Schritt Xamarin.Android unterstützt jetzt Mac und Linux.
- Der Xamarin.iOS-Schritt unterstützt nun das Signieren und Verpacken.
- 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 Zuge dieser Bemühungen stellen wir die Aufgabe ein. 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 verbessert, um diese neuen Aufgaben zu verwenden. 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-Analyse: Probleme in Pull Requests integrieren.
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 viele Definitionen haben, die ein bestimmtes Repository oder einen bestimmten Branch aufbauen, aber nur eine Definition, die die tatsächliche Gesundheit darstellt.
Weitere Informationen finden Sie in der REST-API-Referenz für Build.
Unterstützung von 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):
Auslösen 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 zu einem Ergebnis Build teilweise erfolgreich, wenn ein Task mit dieser Option fehlschlägt.
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.
Es verwendet MSDeploy und eine Dienstendpunktverbindung für den Azure Resource Manager. Verwenden Sie diesen Task, um Azure WebJobs und Azure-API-Apps bereitzustellen, zusätzlich zu auf ASP.NET 4, Node und Python basierenden Web-Apps.
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).
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 (Abbildung 53).
Sie können wählen, die Parameter aus den gekapselten Aufgaben als Konfigurationsvariablen zu extrahieren und den Rest der Aufgabeninformation zu abstrahieren.
Die neue Taskgruppe wird automatisch dem Taskkatalog hinzugefügt und steht bereit, um in andere Release- und Builddefinitionen aufgenommen zu werden.
Ausführliche Informationen finden Sie in der Dokumentation Task Groups (Taskgruppen).
Vorläufiges Löschen von Veröffentlichungen
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 diese Releases wiederherstellen, indem Sie das Kontextmenü öffnen und Wiederherstellen auswählen (Abbildung 54).
Weitere Informationen finden Sie in der Dokumentation Restore deleted releases (Gelöschte Versionen wiederherstellen).
Beibehalten 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.
Verbesserungen bei 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). Jedes Artefakt wird in einen Ordner auf dem Agenten heruntergeladen, der „Quellalias“ heißt. Sie können nun das Quellalias 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.
- 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 – Aufgabe 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 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.
Zusammenfassung der Releasedefinition – Dashboard-Widget
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.
Fördern Sie Releases in 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 in einem Azure Classic-Dienstendpunkt, um eine bestimmte Azure-Cloud anzuvisieren, einschließlich vordefinierter nationaler Clouds wie die Azure China-Cloud, die Azure US Government-Cloud und die Azure German-Cloud.
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 zu den größten Speicherplatzverbrauchern in TFS-Datenbanken zählen, erwarten wir durch dieses Feature eine Reduzierung des Speicherplatzbedarfs für die 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 (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, Testsuites und Testfällen
Konfigurationen zuzuweisen 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 an..., und schon sind Sie startbereit. 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- und 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.
Konfigurieren von Testergebnissen in verschiedenen Test-Suiten
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 ein Fehlerarbeitselement-Formular 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“.
Fortschritt von Ihren Kanban-Karten überprüfen
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
- Ordnen Sie einen Test erneut zu, indem Sie ihn per Drag & Drop von einer User Story zu einer anderen verschieben.
- 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).
Navigieren von der Karte zu einem Testplan oder einer Testsuite
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) führt Sie zum Test-Hub. Dort wird der richtige Testplan geöffnet, und anschließend wird die spezifische Suite ausgewählt, 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
Anhänge zu Testschritten während manueller Tests hinzufügen
Wir haben den Web Test Runner erweitert, sodass Sie nun während manueller Tests Anlagen mit Testschritten hinzufügen können (Abbildung 78). Diese Anhänge mit Schrittergebnissen werden automatisch in allen Bugs, die Sie während der Sitzung erstellen, und danach 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 Runners in Chrome können Sie nun Screenshots erstellen und diese direkt 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. Ähnlich werden die Systeminformationsdaten automatisch gesammelt und als Teil von Fehlerberichten aufgenommen, die Sie vom Webrunner 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 im Web Runner, die entweder von einer Karte auf dem Board oder aus einer anforderungsbasierten Sammlung im Testhub gestartet werden, werden alle neu erfassten Bugs nun automatisch als untergeordnete Elemente der jeweiligen User Story erstellt. Auch wenn Sie eine User Story aus der Erweiterung „Explorative Tests“ erkunden, werden alle neuen von Ihnen erfassten Fehler auch als untergeordnete Elemente der jeweiligen User Story erstellt. Dieses neue Verhalten ermöglicht eine einfachere Rückverfolgbarkeit über Stories und Fehler hinweg. Dies gilt nur, wenn die Einstellung „Arbeiten mit Fehlern“ auf der Konfigurationsseite der allgemeinen Einstellungen auf „Fehler erscheinen nicht in Backlogs oder Boards“ oder „Fehler erscheinen in Backlogs und Boards mit Aufgaben“ festgelegt wird. Für alle anderen Einstellungen der Option „Arbeiten mit Fehlern“ und in bestimmten anderen Szenarien, wie zum Beispiel das Hinzufügen 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 laufenden Testsitzung zuordnen und die Akzeptanzkriterien sowie die Beschreibung direkt in der Erweiterung selbst ansehen. Zusätzlich wird dadurch eine End-to-End-Nachverfolgbarkeit zwischen den Fehlern oder Aufgaben, die Sie im ausgewählten Arbeitselement einreichen, etabliert. Sie können das Arbeitselement entweder direkt von einem Arbeitselement oder aus der Erweiterung heraus untersuchen.
• Direkt im Arbeitselement (Abbildung 81): Starten Sie eine explorative Testsitzung für ein spezifisches Arbeitselement direkt im Produkt, indem Sie im Kontextmenü die Option „Explorative Tests durchführen“ wählen. 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“.
Protokoll der Bildaktionen, Bildschirmaufzeichnungen und Daten zum Laden von Webseiten mit Hilfe von „Test und Feedback“ erfassen.
Bildaktionsprotokoll: Die Erweiterung bietet Ihnen außerdem eine neue Option, mit der Sie die Schritte, die Sie zum Fehler führen, automatisch mit nur einem Mausklick hinzufügen können. 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 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 Hintergrundfunktion 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, einschließlich:
- Die Zusammenfassungsansicht zeigt eine Aufschlüsselung der untersuchten Arbeitselemente, der erstellten Arbeitselemente, der Sitzungsbesitzer sowie die gesamte in diesen Sitzungen verbrachte Zeit (Abbildung 85).
- Die Ansicht „Gruppieren nach“ kann nach untersuchten Arbeitsaufgaben, Sitzungen, Sitzungsinhabern oder keiner von beiden umgestellt 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 Ansicht des Detailbereichs zeigt Informationen basierend auf der Auswahl in der „Gruppieren nach“-Ansicht. Für eine ausgewählte Pivotzeile (z. B. untersuchte Arbeitselemente) können Sie im Detailbereich dessen zusammenfassende Informationen anzeigen. Dazu gehören die Gesamtzahl der Sitzungen, die insgesamt in diesen Sitzungen verbrachte Zeit, die Sitzungsbesitzer, die sie erkundet haben, sowie die erstellten Fehler/Aufgaben/Testfälle mitsamt ihrem Status und ihrer 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 nicht untersuchter Arbeitselemente
Zusätzlich zu der Möglichkeit, die Details aller untersuchten Arbeitselemente in der Ansicht „Letzte explorative Sitzungen“ zu sehen und diese nach allen oder eigenen Sitzungen in einem bestimmten Zeitraum zu filtern, haben wir nun auch die Funktion hinzugefügt, in der gleichen Ansicht eine Liste aller Arbeitselemente anzeigen zu können, die NICHT untersucht wurden (Abbildung 86). Sie beginnen mit der Festlegung einer gemeinsamen Abfrage für Arbeitselemente, die Sie interessieren, und die Session-Seite zeigt eine Liste aller Arbeitselemente aus der Abfrage an, mit einer Aufschlüsselung der untersuchten und nicht untersuchten Elemente im Zusammenfassungsabschnitt. 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.
Durchgängiger Feedback-Ablauf 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 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“ (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 in Form von Rückmeldung zu Antworten, Fehlern oder Aufgaben-Arbeitselementen einzureichen.
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 von Testergebnissen, die in .trx-Dateien erfasst werden, werden extrahiert und als Anlagen zu den Testergebnissen 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.
Test-Trend-Widget 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 dem Umgebungsschwerpunkt, um den Verlauf eines Tests über die verschiedenen Release-Umgebungen hinweg, in denen er abläuft, zu visualisieren.
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 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 (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 Erweiterungen 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 im Jahr 2017 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 dieser Version führen wir eine neue und verbesserte obere Navigationsleiste ein. 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 Möglichkeit gewährt oder verweigert werden, ein Teamprojekt umzubenennen.
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 von anpassbaren Feldern, die in den agilen Werkzeugen verwendet werden. Beispielsweise ist der Typ des Felds „Storypunkte“ „Aufwand“.
- 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 Arbeitsübersicht.
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 Versionen haben Sie einen von mehreren Konfigurationsassistenten für Ihre TFS-Bereitstellung ausgewählt, je nach Ihrem Vorhaben. Der Basis- und Voll-Assistent könnte verwendet werden, um die Konfiguration einer neuen Bereitstellung zu ermöglichen; der Upgrade-Assistent könnte für Produktions- und Vorproduktionsupgrades verwendet werden; und der Assistent für nur die Anwendungsebene könnte für eine Vielzahl von Szenarien verwendet werden, zum Beispiel zum horizontalen Hochskalieren einer vorhandenen Bereitstellung, zum Ersetzen einer Anwendungsebene durch neue Hardware und so weiter. 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.
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 Erweiterungen 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 zu einem 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 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.
<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 von Team Foundation Server/Paketverwaltung werden NuGet-Build- und Releaseaufgaben nicht an Feeds authentifiziert, wenn der Agent als NETZWERKDIENST-Benutzer ausgeführt wird – dies ist die Standardeinstellung, wenn der Build-Agent als Dienst läuft. 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 die Jenkins-Warteschlangenaufgabe als Teil einer TFS-Builddefinition ausgeführt werden, aber nicht als Teil einer Releasedefinition. Diese Funktion wird in einer zukünftigen Version hinzugefügt.
Benutzerdefinierte TFS-Server-Plug-Ins müssen gegen TFS 2017 DLLs neu erstellt 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:
Dieses Problem kann nicht behoben werden. 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:
Eine Umgehungslösung ist derzeit nicht verfügbar. 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.