Team Foundation Server 2017 Update 2 – Versionshinweise

Last Update: 25.09.2017

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

<img src="media/tfs_download_button.png"alt="Die neueste Version von Team Foundation Server herunterladen">

Weitere Formate und Sprachen finden Sie auf der Downloadwebsite.

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


Feedback

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden und es über das Entwicklercommunity-Portal nachverfolgen. Schicken Sie uns Ihre Vorschläge über die Website Visual Studio Team Services – Produktupdates.


Freigabedatum: 24. Juli 2017

Zusammenfassung der Updates in TFS 2017 Update 2

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

Details zu den neuen Funktionen finden Sie durch Anzeigen der Verbesserungen nach Funktionsbereich:


Neues in diesem Release

Verbesserungen für Arbeitselementverfolgung

Symbole für Arbeitsaufgabentypen

Wir haben uns global dafür eingesetzt, dass unsere Produkte für unsere Kunden voll zugänglich sind. Als Teil dieses Engagements haben wir daran gearbeitet, viele Probleme beim Zugriff zu ermitteln und diese anzugehen, egal ob es um Tastaturkürzel oder um visuelles Design und Layout geht.

Die Arbeitselementnachverfolgung basierte auf vielen Benutzeroberflächen einzig und allein auf Farbe, um den Arbeitselementtyp zu übermitteln. Dies ist jedoch für farbenblinde Benutzer oder Personen mit eingeschränktem Sehvermögen ein Problem, die möglicherweise nicht zwischen Elementen aufgrund der Ähnlichkeiten der Farben unterscheiden können. Um die Erfassung des Arbeitselementtyps für all unsere Kunden zu verbessern, haben wir Symbole zur visuellen Sprache des Arbeitsaufgabentyps eingeführt. Sie können Ihre Arbeitsaufgabentypen anpassen, indem Sie aus einer aus einer Auswahl unserer Symbolbibliothek auswählen.

Farbige Balken, die den Typ im Backlog übermitteln und Abfrageraster wurden durch farbige Symbole ersetzt (Abbildung 1).

<img src="media/tfsu2_01-1.png"; alt="Wit icons in query" width="650" height="388" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 1) Farbige Symbole in der Abfrage

Karten auf dem Board enthalten jetzt ein Typsymbol (Abbildung 2).

<img src="media/tfsu2_02-2.png"; alt="Board with icon type" width="600" height="187" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 2) Board mit Symboltyp

Lieferpläne

Lieferpläne ist ein Organisationstool, das Ihnen hilft, die teamübergreifende Sichtbarkeit und die Ausrichtung durch Nachverfolgung des Arbeitsstatus auf einem iterationsbasierten Kalender zu fördern. Sie können Ihren Plan dazu anpassen, beliebige Team- oder Backlogebenen aus allen Projekten im Konto einzuschließen. Des Weiteren können Sie durch Feldkriterien auf Plänen Ihre Ansicht weiter anpassen, wobei Marker die wichtigsten Datumsangaben hervorheben.

Sehen Sie sich die Marketplace-Seite für Lieferpläne an, um weitere Informationen zu erhalten und die Erweiterung zu installieren.

Für Benutzer mit einer FTS-Instanz, die nicht mit dem Internet verbunden ist, sind Lieferpläne direkt über die Option Erweiterungen verwalten im Webzugriff verfügbar, ohne dass sie zum VSTS-Marketplace navigieren müssen. Klicken Sie unter Erweiterungen verwalten auf Lokale Erweiterungen durchsuchen, dann auf Lieferpläne und anschließend auf Installieren. Weitere Informationen finden Sie in der Dokumentation zu vorinstallierten Erweiterungen.

Automatische Verknüpfung von Arbeitselementen zu Builds

Mit dieser neuen Einstellung in der Builddefinition können Sie die Builds zurückverfolgen, die Ihre Arbeit integriert haben, ohne manuell einen Satz von Builds durchsuchen zu müssen. Jedes erfolgreiche Build, das dem Arbeitselement zugeordnet ist, wird automatisch im Abschnitt für Entwicklungen des Arbeitsaufgabenformulars angezeigt.

Um diese Funktion zu aktivieren, schalten Sie die Einstellung unter Optionen in Ihrer Builddefinition ein (Abbildung 3).

<img src="media/tfsu2_03-3.png"; alt="WIT build linking" width="600" height="160" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 3) WIT-Buildverknüpfung

Veraltung des alten Arbeitsaufgabenformulars

Im Allgemeinen war das Feedback zum neuen Arbeitsaufgabenformular positiv, und wir haben es jetzt zu 100 % für unsere gehosteten Konten übernommen. Wir möchten, dass lokalen Kunden der gleiche Wert zu Verfügung steht, der unsere VSTS-Benutzer begeistert hat. Deshalb haben wir die Entscheidung getroffen, das alte Arbeitsaufgabenformular und das alte Erweiterbarkeitsmodell als veraltet zu deklarieren. Weitere Informationen zu unseren Plänen finden Sie auf der Seite zur Verwaltung des Anwendungslebenszyklus von Microsoft.

Arbeitsaufgabensuche

Die Arbeitsaufgabensuche bietet eine schnelle und flexible Suche in Ihren gesamten Arbeitsaufgaben über alle Projekte in einer Auflistung hinweg (Abbildung 4). Sie können das Modul zur Volltextsuche der Arbeitsaufgabensuche verwenden, um einfach nach Begriffen in allen Arbeitsaufgabenfeldern zu suchen und relevante Arbeitsaufgaben effizient zu lokalisieren. Verwenden Sie zeilenbezogene Suchfilter auf einem beliebigen Arbeitsaufgabenfeld, um schnell eine Liste von Arbeitsaufgaben einzugrenzen.

Sobald der Suchdienst in TFS konfiguriert ist, können Sie mit der Suche beginnen, ohne zusätzlich etwas installieren zu müssen. Mithilfe der Arbeitsaufgabensuchen können Sie Folgendes tun:

  • Eine Suche über all Ihre Projekte durchführen: Suchen Sie in Ihren eigenen Backlog und in dem Ihrer Partnerteams. Verwenden Sie projektübergreifende Suchen über alle Arbeitsaufgaben hinweg, um in den gesamten Arbeitsaufgaben Ihrer Organisation zu suchen. Schränken Sie Ihre Suche ein, indem Sie Pfadfilter für Projekte und Bereiche nutzen.
  • Suche über alle Arbeitsaufgabenfelder hinweg: Finden Sie schnell und einfach relevante Arbeitsaufgaben, indem Sie alle Arbeitsaufgabenfelder (einschließlich ERE-Felder) durchsuchen. Verwenden Sie eine Volltextsuche über alle Felder hinweg, um effizient relevante Arbeitsaufgaben zu ermitteln. Die Ausschnittsansicht zeigt an, wo Übereinstimmungen gefunden wurden.
  • Suche in bestimmten Feldern: Verwenden Sie die schnellen zeilenbezogenen Suchfilter auf einem beliebigen Arbeitsaufgabenfeld, um sekundenschnell eine Liste von Arbeitsaufgaben einzugrenzen. Die Dropdownliste mit Vorschlägen hilft Ihnen dabei, die Suche schneller abzuschließen. Beispielsweise findet eine Suche wie AssignedTo:Chris WorkItemType:Bug State:Active alle aktiven Fehler, die einem Benutzer namens Chris zugewiesen sind.
  • Vorteile der Integration mit der Arbeitsaufgabenverfolgung wahrnehmen: Die Schnittstelle der Arbeitsaufgabensuche ist mit bekannten Steuerelementen im Arbeitshub integriert, womit Sie Anzeigen, Bearbeiten, Kommentieren, Teilen und noch viel mehr tun können.

<img src="media/wishero-4.png"; alt="Workitem search" width="800" height="412" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 4) Arbeitsaufgabensuche

Verbesserungen der Versionskontrolle

Neue Benutzeroberfläche für die Konfiguration von Verzweigungsrichtlinien

Wir haben die Benutzeroberfläche zur Konfiguration von Verzweigungsrichtlinien neu entworfen und einige tolle neue Funktionen hinzugefügt (Abbildung 5). Eine der leistungsstärksten Funktionen ist die Möglichkeit, Richtlinien für Verzweigungsordner zu konfigurieren. Sie können dies von der Ansicht Verzweigungen aus tun, indem Sie einen Verzweigungsordner auswählen und Verzweigungsrichtlinien aus dem Kontextmenü auswählen.

<img src="media/tfsu2_32-5.png"; alt="Configure branch policies" width="500" height="252" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 5) Konfigurieren von Verzweigungsrichtlinien

Dadurch wird die neue Benutzererfahrung für die Richtlinienkonfiguration geöffnet, wo Sie Richtlinien konfigurieren können, die für alle Verzweigungen im Verzweigungsordner gelten (Abbildung 6).

<img src="media/tfsu2_33-6.png"; alt="Policies page" width="700" height="781" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 6) Seite zu Richtlinien

Falls Sie die Buildrichtlinie verwenden, können Sie nun mehrere Builds für eine einzige Verzweigung neu konfigurieren. Es sind auch neue Optionen zum Angeben eines automatischen oder manuellen Triggers vorhanden (Abbildung 7). Manuelle Trigger sind für Dinge wie automatische Testläufe nützlich, die möglicherweise lange dauern. Sie müssen ihn nur wirklich einmal ausführen, bevor Sie den Pull Request abschließen. Die Buildrichtlinie verfügt auch über einen Anzeigenamen, der nützlich ist, wenn Sie mehrere Builds konfigurieren.

<img src="media/tfsu2_34-7.png"; alt="Manual build" width="375" height="539" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 7) Manuelles Build

Sobald wie eine manuell ausgelöste Richtlinie konfiguriert haben, können Sie sie ausführen, indem Sie die Option Build zur Warteschlange hinzufügen im Abschnitt Richtlinien des Pull Requests ausgewählt haben (Abbildung 8).

<img src="media/tfsu2_35-8.png"; alt="Manual build queue" width="400" height="350" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 8) Manuelle Buildwarteschlange

Wir haben für erforderliche Reviewer-Richtlinien (Abbildung 9) die Fähigkeit für Administratoren, eine Notiz anzugeben hinzugefügt, die an die Zeitachse des Pull Request angefügt wird, wenn die Richtlinie angewendet wird (Abbildung 10).

<img src="media/tfsu2_36-9.png"; alt="Required reviewer dialog" width="400" height="387" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 9) Dialogfeld „Erforderlicher Reviewer“

<img src="media/tfsu2_37-10.png"; alt="Required reviewer note" width="700" height="204" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 10) Notiz des erforderlichen Reviewers

Neue Richtlinie für inaktive Kommentare

Stellen Sie sicher, dass alle Kommentare in Ihren Pull Requests mit der neuen Kommentarrichtlinie behandelt werden. Wenn diese Richtlinie aktiviert ist, werden aktive Kommentare den Abschluss des Pull Request blockieren, wobei erzwungen wird, dass alle Kommentare aufgelöst werden. Reviewer, die Kommentare für den Pull Request-Autor schreiben, jedoch den Pull Request optimistisch genehmigen, können sicher sein, dass ein Autor, der eine Zusammenfassung durchführen möchte, keine Kommentare übersieht.

Verbesserungen am Dateihub

Wir haben einige Updates am Dateihub gemacht, um die Ansichts- und Bearbeitungserfahrungen zu verbessern.

Wir haben für die Ansicht Pivots hinzugefügt, mit denen Sie die Infodatei im aktuellen Ordner (Abbildung 11) anzeigen, Markdown-Dateien ansehen, eine Datei mit einer vorherigen Version (Abbildung 12) und die Verantwortung anzeigen können.

<img src="media/tfsu2_14-11.png"; alt="Files viewing" width="550" height="143" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 11) Dateianzeige

<img src="media/tfsu2_15-12.png"; alt="Files compare" width="600" height="133" style="border:2px solid Silver; display: block; margin: auto;">

(Figure 12) Dateivergleich

Für die Bearbeitung können Sie nun vorab Ihre Änderungen anzeigen, einfach einen Kommentar hinzufügen, einen Commit auf eine neue Verzweigung ausführen und Arbeitsaufgaben verknüpfen (Abbildung 13).

<img src="media/tfsu2_16-13.png"; alt="Files editing" width="600" height="87" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 13) Dateibearbeitung

Visualisieren Ihres Git-Repositorys

Während Sie den Commit-Verlauf für Repositorys oder Dateien darstellen, können Sie eine Diagramm sehen. Damit können Sie einfach ein mentales Modell all Ihrer Verzweigungen und Commits für Ihre Git-Repositorys mithilfe des Git-Diagramms erstellen (Abbildung 14). Das Diagramm zeigt all Ihre Commits in topologischer Reihenfolge.

<img src="media/tfsu2_43-14.png"; alt="Git graph" width="800" height="348" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 14) Git-Diagramm

Die Schlüsselelemente des Git-Diagramms enthalten Folgendes (Abbildung 15):

  1. Das Git-Diagramm ist rechtsbündig, deshalb erscheinen Commits, die der Standardverzweigung oder dem ausgewählten Branch zugeordnet sind, auf der rechten Seite, während der Rest des Diagramms auf der linken Seite angezeigt wird.
  2. Zusammenführungs-Commits werden durch graue Punkte dargestellt, die mit dem ersten übergeordneten und dem zweiten übergeordneten Commit verbunden sind.
  3. Normale Commits werden durch blaue Punkte dargestellt.
  4. Wenn der übergeordnete Commit eines Commits nicht im Viewport auf den nächsten 50 Commits sichtbar ist, dann unterbrechen wir die Commit-Verbindung. Sobald Sie auf den Pfeil klicken, wird der Commit mit seinem übergeordneten Commit verbunden.

<img src="media/tfsu2_44-15.png"; alt="Git graph elements" width="800" height="189" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 15) Elemente des Git-Diagramms

Anzeigen von Git-Tags auf Commits

Wenn Ihr Team Git-Tags zum Kennzeichnen eines bestimmten Punkts im Verlauf Ihres Repositorys verwendet hat, zeigen Ihre Commits nun die Tags, die Sie erstellt haben. Sie werden Tags für einen bestimmten Commit in der Ansicht Commitliste und der Seite Details anzeigen können (Abbildung 16).

<img src="media/tfsu2_45-16.png"; alt="Show tags" width="800" height="199" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 16) Tags anzeigen

Hinzufügen von Tags zu Commits

Anstatt Tags auf der Befehlszeile zu erstellen und die Tags an das Repository zu übertragen, können Sie jetzt einfach zu einem Commit wechseln und ein Tag hinzufügen (Abbildung 17). Mit dem Dialogfeld zur Tagerstellung können Sie auch alle anderen Verweise auf dem Repository markieren.

<img src="media/tfsu2_46-17.png"; alt="Create tag details" width="800" height="215" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 17) Tagdetails erstellen

Die Ansicht der Commitliste unterstützt auch ein Kontextmenü (Abbildung 18). Sie müssen nicht mehr auf die Seite Commitdetails gehen, um Tags und neue Verzweigungen zu erstellen (Abbildung 19).

<img src="media/tfsu2_47-18.png"; alt="Create tag history" width="800" height="207" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 18) Tagverlauf erstellen

<img src="media/tfsu2_48-19.png"; alt="Tag branch" width="450" height="306" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 19) Tagbranch

Aktualisierte Changeset- und Shelvesetseiten

Wir haben in TFVC die Changeset- und Shelvesetseiten modernisiert. Beide Seiten sind leichter zugänglich für diejenigen von Ihnen, die nach Hilfstechnologien suchen. Die neuen Seiten verfügen auch über eine neue Kopfzeile, die den Titel des Changesets enthält sowie zusätzliche Informationen über das Changeset, z.B. Details zum Autor (Abbildung 20).

<img src="media/tfsu2_41-20.png"; alt="Changeset page" width="800" height="317" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 20) Changesetseite

Die Seiten für Changesets und Shelvesets hosten jeweils das neue Markdown-Diskussionssteuerelement (Abbildung 21), das Ihnen erlaubt, Kommentare in Markdown einzugeben, @mention Benutzer zu erwähnen, Arbeitsaufgaben mit # zuzuordnen und Dateien und Images einfach anzufügen.

<img src="media/tfsu2_42-21.png"; alt="Changeset discussion" width="650" height="506" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 21) Changesetdiskussion

Verbessertes Filtern nach Commits

Sie können die Ergebnisse des Commit-Verlaufs (Abbildung 22) nun mithilfe erweiterter Filteroptionen filtern. Sie können Commits nach

  • vollständigem Verlauf
  • vollständigem Verlauf mit vereinfachten Merges
  • übergeordnetem Commit
  • einfachem Verlauf (dies ist die Standardfiltereinstellungen) filtern.

<img src="media/tfsu2_49-22.png"; alt="Improved commit filtering" width="800" height="151" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 22) Verbessertes Filtern nach Commits

Importieren von Repositorys von TFVC zu Git

Sie können Code von Ihren TFVC-Repositorys zu Git-Repositorys im gleichen Konto migrieren. Um mit der Migration zu beginnen, wählen Sie aus der Repositoryauswahl-Dropdownliste Repository importieren aus (Abbildung 23).

<img src="media/tfsu2_50.png"; alt="Repository selector drop-down" width="239" height="312" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 23) Repositoryauswahl-Dropdownliste

Einzelne Ordner oder Verzweigungen können in das Git-Repository importiert werden. Alternativ kann das gesamte TFVC-Repository (minus Verzweigungen) importiert werden (Abbildung 24). Sie können auch bis zu 180 Tage Verlauf importieren.

<img src="media/tfsu2_51.png"; alt="Import repo complete" width="437" height="462" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 24) Importieren des Repositorys abschließen

Git LFS-Dateisperrung

Wir haben die Funktion Git LFS-Dateisperrung hinzugefügt. Teams, die mit großen und nicht vergleichbaren Dateien arbeiten, können dadurch vermeiden, Arbeit zu verlieren, wenn zwei Personen oder mehr versuchen, gleichzeitig dieselbe Datei zu bearbeiten. Bevor jemand beginnen kann, die Datei zu bearbeiten, wird eine Sperre angewendet, die den Server benachrichtigt. Wenn jemand anderes nun versucht, eine Sperre anzuwenden, weist der Server die Anforderung zurück, und die zweite Person weiß dadurch, dass jemand anderes schon an dieser Datei arbeitet. Bitte führen Sie ein Upgrade auf Git LFS 2.1 oder höher durch, um diese Funktion zu verwenden.

Git-Commitkommentare verwenden das neue Diskussionssteuerelement

Einfache Kommentare, die auf Git-Commits verblieben sind, wurden aktualisiert, damit sie das neue Diskussionssteuerelement verwenden. In diesen Kommentaren wird dadurch Unterstützung für Markdown bereitgestellt und alle Funktionen zur Codekommentierung werden im Internet für Git und TFVC abgerundet, um die neueste Erfahrung zu nutzen.

Neue Strukturansicht-Steuerelemente

Die Ansicht „Pull Request-Dateien“, Git-Commitdetails, Git-Pushdetails, TFVC Shelveset-Details, TFVC Changeset-Details, TFVC Changesets-Hub und Git-Verlaufshub wurden mit einem neuen Strukturansicht-Steuerelement aktualisiert (Abbildung 25). Die Strukturansicht verfügt über einige Verbesserungen der Nutzbarkeit. Zunächst haben wir die Ansicht verändert, die nun eine komprimierte Strukturansicht darstellt, die automatisch leere Ordnerknoten reduziert, wodurch die Anzahl der Dateien, die sich in der Ansicht befinden, maximiert wird.

Die Struktur zeigt auch Kommentare auf einer kompakteren Weise. Dateien mit Kommentaren zeigen ein untergeordnetes Element für jede Kommentardiskussion, und der Avatar weist den Benutzer, der die Diskussion erstellt hat, darauf hin. Neue Kommentardiskussionen und Diskussionen mit Antworten werden durch den blauen Punkt angezeigt, und die Anzahl der Antworten werden mit einer Anzahl zusammengefasst.

<img src="media/tfsu2_40.png"; alt="New tree view" width="448" height="634" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 25) Neue Strukturansicht

Pull Request-Verbesserungen

Verbesserte CTAs für PR-Autoren und -Reviewer

Für Teams, die Verzweigungsrichtlinien verwenden, kann es manchmal schwierig sein, genau zu wissen, welche Aktion erforderlich ist, wenn ein Pull Request angezeigt wird. Wenn der wichtigste Aktionsaufruf die Schaltfläche Abgeschlossen ist, bedeutet dass, dass er abgeschlossen werden kann? Mithilfe von Informationen über die Person, die die Seite und den Status konfigurierter Verzweigungsrichtlinien ansieht, stellt die PR-Ansicht nun den Aktionsaufruf dar, der für den Benutzer am ehesten Sinn macht.

Wenn Richtlinien konfiguriert aber noch nicht übergeben wurden, wird die Schaltfläche Abschluss (Abbildung 26) nun den Gebrauch der Funktion Automatische Vervollständigung empfehlen. Es ist unwahrscheinlich, dass Sie den PR erfolgreich abschließen können, wenn Richtlinien blockieren, deshalb bieten wir die Option an, die den PR abschließt, wenn diese Richtlinien letztendlich erfolgreich sind.

<img src="media/tfsu2_62.png"; alt=" Auto-complete feature" width="502" height="65" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 26) Funktion zur automatischen Vervollständigung

Für Reviewer ist es wahrscheinlicher, dass Sie einen PR eher genehmigen als abschließen möchten. Reviewer sehen also die Schaltfläche Genehmigen (Abbildung 27), die als wichtigste CTA gekennzeichnet ist, falls Sie noch keine Genehmigung gegeben haben.

<img src="media/tfsu2_20.png"; alt="CTA approve" width="566" height="65" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 27) Genehmigung von CTA

Sobald der PR genehmigt ist, sehen Reviewer, dass die Schaltfläche Abgeschlossen (oder Automatische Vervollständigung) als CTA für die Fälle gekennzeichnet ist, in denen ein Reviewer auch die Person ist, die den PR abschließt.

Kommentare mit Handlungsbedarf

In einem PR mit mehr als ein paar Kommentare kann es schwer sein, alle Konversationen zu verfolgen. Damit Sie Kommentare besser verwalten können, haben wir den Prozess zum Auflösen von Elementen, die mit einer Anzahl von Verbesserungen behandelt wurden, vereinfacht:

  • In der Kopfzeile jedes PR sehen Sie nun eine Anzahl der Kommentare, die gelöst wurden (Abbildung 28).

<img src="media/tfsu2_22.png"; alt="PR header" width="800" height="61" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 28) PR-Kopfzeile

  • Wenn ein Kommentar behandelt wurde, können Sie es mit einem einzigen Klick auflösen (Abbildung 29).

<img src="media/tfsu2_24-29.png"; alt="Resolve button" width="600" height="165" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 29) Schaltfläche „Auflösen“

  • Wenn während der Auflösung noch Kommentare hinzugefügt werden müssen, können Sie mit einer einzigen Geste antworten und auflösen (Abbildung 30).

<img src="media/tfsu2_25-30.png"; alt="Reply and resolve" width="600" height="258" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 30) Antworten und Auflösen

  • Da Kommentare aufgelöst werden, sehen Sie, dass die Anzahl nach oben geht, bis alles behandelt wurde (Abbildung 31).

<img src="media/tfsu2_26-31.png"; alt="Comment count address rate" width="600" height="42" style="border:2px solid Silver; display: block; margin: auto;">

*(Abbildung 31) Rate der Verarbeitung der Kommentaranzahl *

  • Der Filter in der Übersicht wurde verbessert, damit das Filtern nach verschiedenen Kommentarstatus ermöglicht wird und die Anzahl von Kommentaren für jede Filteroption angezeigt werden kann (Abbildung 32).

<img src="media/tfsu2_23.png"; alt="Filter improvements" width="225" height="241" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 32) Filterverbesserungen

Ansicht „Updates“ zeigt Rebase und erzwungenen Push

In der Pull Request-Detailansicht wurde die Registerkarte Updates verbessert, damit sie anzeigt, wenn ein erzwungener Push aufgetreten ist und ob sich der grundlegende Commit geändert hat (Abbildung 33). Diese beiden Funktionen sind sehr nützlich, wenn Sie ein Rebase auf Änderungen in Ihren Topicverzweigungen vor Abschluss Ihres PR ausführen. Reviewers verfügen nicht über genügend Informationen, um zu wissen, was genau passiert ist.

<img src="media/tfsu2_30-33.png"; alt="Updates views" width="700" height="344" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 33) Ansicht „Updates“

Pull Request-Filtern anhand Personen

Es ist jetzt viel einfacher, Pull Requests zu finden. Wir haben neue Filteroptionen hinzugefügt, mit denen Sie PR, die von einem bestimmten Autor erstellt oder einem bestimmten Reviewer zugewiesen sind, finden können (Abbildung 34). Wählen Sie einfach einen Benutzer aus dem Filter für Autoren oder Reviewer aus, und die Liste wird aktualisiert, damit nur die PRs angezeigt werden, die mit dem Filter übereinstimmen.

<img src="media/tfsu2_29-34.png"; alt="Filtering by people" width="700" height="126" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 34) Filtern anhand Personen

Erforderliche Gründe beim Umgehen von Pull Request-Richtlinien

Wenn Sie eine Pull Request-Richtlinie umgehen, müssen Sie einen Grund dafür angeben. Im Dialogfeld Pull Request abschließen sehen Sie ein neues Feld, das Grund heißt, falls eine Umgehung vorgenommen wird (Abbildung 35).

<img src="media/tfsu2_38-35.png"; alt="Bypass dialog" width="450" height="425" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 35) Dialogfeld zur Umgehung

Nachdem Sie den Grund eingegeben und den Pull Request abgeschlossen haben, wird die Benachrichtigung in der Übersicht angezeigt (Abbildung 36)

<img src="media/tfsu2_39-36.png"; alt="Bypass message" width="700" height="54" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 36) Umgehungsmeldung

Freigeben von Pull Requests für Teams

Die Aktion Pull Request freigeben ist eine praktische Möglichkeit, Reviewer zu benachrichtigen (Abbildung 37). In dieser Version haben wir Unterstützung für Teams und Gruppen hinzugefügt, damit Sie jeden in nur einem Schritt benachrichtigen können, der im Pull Request involviert war.

<img src="media/tfsu2_17-37.png"; alt="Share PR with teams" width="500" height="457" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 37) PR für Teams freigeben

Pull Request-Verbesserungen für Teams

Wenn Sie ein Mitglied mehrerer Teams sind, sehen Sie jetzt aller PRs, die den Teams zugewiesen sind, die in der Übersicht Meine Pull Requests aufgeführt sind (Abbildung 38). Dadurch wird die Ansicht Meine Pull Requests zu einem Punkt, der notwendig ist, um alle PRs anzuzeigen.

<img src="media/tfsu2_18-38.png"; alt="PR improvements for teams" width="800" height="383" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 38) PR-Verbesserungen für Teams

Wir werden in einer zukünftigen Version Teams zum Pull Requests-Hub unter Code hinzufügen, damit es einfacher wird, alle PRs für ein einziges Projekt anzuzeigen.

Standardbenachrichtigungen für Pull Request-Kommentare

Bleiben Sie mit Kommentarbenachrichtigungen immer auf dem neuesten Stand, was die Konversationen in Ihren PRs angeht (Abbildung 39). Sie werden für PRs, die Sie erstellt haben, jedes Mal benachrichtigt, wenn ein Benutzer eine Kommentardiskussion hinzufügt oder auf eine bereits vorhandene Diskussion antwortet. Wenn Sie den PR eines anderen Benutzers kommentieren, werden Sie über alle zukünftigen Kommentardiskussionen, die Sie erstellen oder auf die Sie antworten, informiert.

<img src="media/tfsu2_19-39.png"; alt="Default PR notifications" width="450" height="299" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 39) PR-Standardbenachrichtigungen

Diese Benachrichtigungen sind als Teil der Standardabonnements verfügbar und sind auf der Einstelllungenseite Benachrichtigungen konfigurierbar.

Verbesserungen bei der Paketverwaltung

Aktualisierte Benutzerfreundlichkeit für die Paketverwaltung

Wir haben die Benutzerfreundlichkeit der Paketverwaltung verbessert, damit es einfacher für Sie wird, von Benutzern gemeldete bekannte Probleme zu behandeln und Platz für zukünftige Lebenszyklusfeatures für Pakete zu schaffen (Abbildung 40). Weitere Informationen zu dem Update finden Sie auf der Seite zur aktualisierten Benutzerfreundlichkeit.

<img src="media/tfsu2_04-40.png"; alt="Package Management" width="700" height="238" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 40) Paketverwaltung

Die Paketverwaltung für npm-Infodateien und die Schaltfläche „Herunterladen“ hinzu

Sie sehen nun die Infodatei für alle npm-Pakete, die eine „README.md“ im Paket enthält (Abbildung 41). Infodateien können Ihrem Team dabei helfen, Wissen über Ihre Pakete zu dokumentieren und zu teilen.

Sie können auch alle npm-Pakete mit der Herunterladen-Schaltfläche in der Befehlsleiste herunterladen.

<img src="media/tfsu2_05.png"; alt="Package Management npm README " width="800" height="426" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 41) Paketverwaltungs-npm-Infodatei

Buildaufgaben für die NuGet-Wiederherstellung und den NuGet-Befehl

Wir haben an der NuGet-Installer-Aufgabe (jetzt NuGet-Wiederherstellung) wichtige Aktualisierungen vorgenommen und eine neue NuGet-Aufgabe hinzugefügt: NuGet-Befehl. Insbesondere verwenden die NuGet-Befehls- und NuGet-Wiederherstellungsaufgabe nun standardmäßig nuget.exe 4.0.0.

Die NuGet-Wiederherstellung ist nun für das häufigste Szenario zum Wiederherstellen eines Pakets vor dem Visual Studio-Buildschritts optimiert. Sie besitzt auch eine bessere Unterstützung für kleine Projekte, die sich einen NuGet-Feed teilen: Sie können nun einen Team Services-Feed auswählen und diesen zu Ihrer automatisch generierten NuGet.Config-Datei hinzufügen.

Für komplexere NuGet-Vorgänge bietet die NuGet-Befehlsaufgabe die Flexibilität, einen beliebigen Befehl sowie einen Satz von Argumenten anzugeben (Abbildung 42).

<img src="media/tfsu2_06-42.png"; alt="NuGet command" width="600" height="374" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 42) NuGet-Befehl

Erstellen und Freigeben von Verbesserungen

Editor für neue Builddefinition

Wir haben unseren Builddefinition-Editor neu entworfen, um eine intuitivere Erfahrung zu bieten, einige kritische Probleme zu beheben und neue Funktionen hinzuzufügen. Wir hoffen, dass Sie die Verwendung von Vorlagen, das Hinzufügen von Aufgaben und die Änderung von Einstellungen einfach finden. Sie können jetzt auch Prozessparameter benutzen, um es einfacher zu machen, die wichtigsten Datenbestandteile anzugeben, ohne zu tief in Ihre Aufgaben hineingehen zu müssen.

Suche nach einer Vorlage

Suchen Sie nach der gewünschten Vorlage, und fügen Sie sie dann hinzu, oder starten Sie mit einem leeren Prozess (Abbildung 43).

<img src="media/tfsu2_09-43.png"; alt="Build template search" width="600" height="248" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 43) Suche nach Bildvorlagen

Schnelles Auffinden und Hinzufügen einer Aufgabe

Suchen Sie nach der Aufgabe, die Sie verwenden möchten, und fügen Sie sie dann nach der aktuell ausgewählten Aufgabe auf der linken Seite hinzu, nachdem Sie sie gefunden haben. Ziehen und platzieren Sie die Aufgabe alternativ nach Ihren Vorstellungen (Abbildung 44).

<img src="media/tfsu2_10-44.png"; alt="Build task search" width="600" height="473" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 44) Suche nach der Buildaufgabe

Sie können auch durch Drag & Drop eine Aufgabe verschieben oder diesen Vorgang bei gedrückter STRG-TASTE durchführen, um die Aufgabe zu kopieren.

Verwenden Sie Prozessparameter, um wichtige Argumente an Ihre Aufgaben zu übergeben

Sie können nun Prozessparameter (Abbildung 45) verwenden, um es den Personen, die Ihre Builddefinition oder -Vorlage verwenden, zu vereinfachen, die wichtigsten Datenbestandteile anzugeben, ohne zu Tief in die Aufgabe hineinzugehen.

<img src="media/tfsu2_11-45.png"; alt="Process parameters" width="600" height="467" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 45) Prozessparameter

Wenn Sie einen neuen Build aus einigen der integrierten Vorlagen erstellen (z.B. Visual Studio und Maven), sehen Sie Beispiele, wie diese funktionieren.

Der neue Editor enthält einige weitere Verbesserungen, z.B. erhalten Sie schnelleren Zugriff auf Ihre Quelleneinstellungen.

Eine exemplarische Vorgehensweise zum Erstellen der ersten Builddefinition mithilfe des neuen Editors finden Sie unter CI/CD for newbies (CI/CD für Anfänger).

Weitere Informationen finden Sie auf der Seite zur Benutzererfahrung 2017.

Bedingte Buildaufgaben

Wenn Sie mehr Kontrolle über Ihre Buildaufgaben haben möchten, z.B. eine Aufgabe zum Aufräumen oder zum Senden einer Nachricht, nachdem etwas schief gelaufen ist, bieten wir Ihnen nun vier integrierte Möglichkeiten, mit denen Sie steuern können, wann eine Aufgabe ausgeführt wird (Abbildung 46).

<img src="media/tfsu2_07-46.png"; alt="Conditional build tasks" width="600" height="300" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 46) Bedingte Buildaufgaben

Zur Erhöhung der Flexibilität, z.B. eine Aufgabe, die nur für bestimmte Verzweigungen mit bestimmten Triggern unter bestimmten Bedingungen ausgeführt wird, können Sie Ihre eigenen benutzerdefinierten Bedingungen ausdrücken:

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

Weitere Informationen finden Sie auf der Seite Specify conditions for running a task (Angeben von Bedingungen zum Ausführen einer Aufgabe).

Integrierte Aufgaben zum Erstellen und Bereitstellen von containerbasierten Anwendungen

Mit dieser Version haben wir standardmäßig das Meiste aus den Aufgaben in unserer Docker-Erweiterung in das Produkt übernommen, diese verbessert und eine Reihe neuer Aufgaben und Vorlagen eingeführt, um Containerszenarios zu vereinfachen.

  • Docker: Erstellen Sie Docker-Images, übertragen Sie sie mithilfe von Push, oder führen Sie einen Docker-Befehl aus. Diese Aufgabe kann mit Docker oder Azure Container Registry verwendet werden. Sie können nun unsere integrierte Dienstprinzipalauthentifizierung mit ACR verwenden, damit die Verwendung noch einfacher wird.
  • Docker-Compose: Erstellen Sie Docker-Anwendungen mit mehreren Containern, übertragen Sie sie mithilfe von Push, oder führen Sie sie aus Diese Aufgabe kann mit Docker oder Azure Container Registry verwendet werden.
  • Kubernetes: Stellen Sie Ihren Kubernetes-Cluster in Azure Container Service bereit, konfigurieren Sie ihn oder aktualisieren Sie ihn, indem Sie kubectl-Befehle ausführen.
  • Service Fabric: Stellen Sie Container für einen Service Fabric-Cluster bereit. Service Fabric ist jetzt die beste Wahl für das Ausführen von Windows-Containern in der Cloud.

Updates zu Azure-Web-App-Bereitstellungen

Es wurden zahlreiche Verbesserungen für Azure-Web-Apps vorgenommen:

  • Die Azure App Service-Bereitstellungsaufgabe unterstützt die Bereitstellung von Java WAR-Dateien, Node.js, Python und PHP-Anwendungen.
  • Die Azure App Service-Bereitstellungsaufgabe unterstützt die Bereitstellung in Azure-Web-App für Linux mithilfe von Containern.
  • Continuous Delivery des Azure-Portals wurde erweitert und unterstützt jetzt Node-Anwendungen.
  • Die Azure App Service-Verwaltungsaufgabe wurde zu „Starten“, „Anhalten“, „Neustart“ oder „Austauschen von Slots“ für einen Azure App Service-Dienst hinzugefügt. Darüber hinaus wird die Installation von Websiteerweiterungen unterstützt, was die Installation der erforderlichen PHP- oder Python-Version oder die Installation von IIS Manager oder Application Insights ermöglicht.

In der neuesten Version der Azure-Befehlszeilenschnittstelle wurde für die Konfiguration von CI/CD auch die CI/CD-Unterstützung neu eingeführt. Im Folgenden ein Beispiel:

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

.NET Core-Aufgaben unterstützen Projektdateien

Mit dem aktuellen Update erweitern wir .NET Core-Aufgaben zur Unterstützung von „*.csproj“-Dateien zusätzlich zu „project.json“-Dateien. Sie können nun Visual Studio 2017 auf Ihren Build-Agents zum Erstellen von .NET Core-Anwendungen mithilfe von CSPROJ-Dateien verwenden.

Verbesserungen für die SSH-Bereitstellung

Die Build- und Releaseaufgabe Dateien über SSH kopieren unterstützt jetzt Tilden (~) im Zielpfad, um das Kopieren von Dateien in ein remotes Basisverzeichnis eines Benutzers zu vereinfachen. Außerdem ermöglicht eine neue Option auch, dass Build und Release fehlschlagen, wenn keine Dateien zum Kopieren gefunden werden.

Die Build- und Releaseaufgabe unterstützt nun die Ausführung von Skripts mit Windows-Zeilenenden auf remoten Linux- oder macOS-Computern.

Installieren eines SSH-Schlüssels während eines Build oder Release

Eine neue Vorschauaufgabe, Install SSH Key (Preview) (Installieren des SSH-Schlüssels (Preview)) installiert einen SSH-Schlüssel vor einem Build- oder Releasedienst und entfernt ihn vom Agent, wenn Build oder Release abgeschlossen ist. Der installierte Schlüssel kann zum Abrufen von Code aus einem Git-Repository oder aus Untermodulen, zum Ausführen von Bereitstellungsskripts oder für andere Aktivitäten verwendet werden, die eine SSH-Authentifizierung erfordern. Dies wird in der Zukunft verbessert, damit Passphrasen und andere Funktionen verbessert werden.

Die Aufgaben schlagen fehl, wenn Visual Studio 2017 zwar angegeben, aber auf dem Agent nicht vorhanden ist

Die Aufgaben von Visual Studio Build und MSBuild lassen zu, dass Sie eine bestimmte Version von Visual Studio auswählen. Bis jetzt haben diese Aufgaben automatisch die nächste verfügbare Version ausgewählt, wenn die Version Visual Studio 2017 nicht verfügbar war.

Diese Verhalten wird nun geändert. Jetzt schlägt das Build fehl, wenn Sie Visual Studio 2017 auswählen, diese Version jedoch nicht auf dem Agent verfügbar ist.

Wir haben diese Änderung aus den folgenden Gründen vorgenommen:

  • Neuere App-Typen, z.B. .NET Core, kompilieren nicht mit anderen Buildtools. Sie benötigen explizit Visual Studio 2017 oder höher.

  • Wenn Sie genau dieselbe Version von Visual Studio verwenden, erhalten Sie konsistentere und vorhersehbarere Ergebnisse.

  • Wann immer Buildaufgaben einen Fallback durchführen, erhalten Sie möglicherweise Kompilierungsfehler, die schwierig zu verstehen sind.

Tipp

Stellen Sie sicher, dass Sie eine Warteschlange verwenden, die mit einem Pool verbunden ist, der über Agents mit Visual Studio 2017 verfügt und keine Agents hat, die nur frühere Versionen von Visual Studio besitzen.

Automatische Bereinigung des Arbeitsbereichs durch privaten Agent

Sie können nun einen Agentpool konfigurieren, um von Zeit zu Zeit langsam arbeitende Verzeichnisse und Repositorys zu bereinigen (Abbildung 47). Der Pool löscht z.B. Arbeitsbereiche, die von gelöschten Build- und Releasedefinitionen zurückgelassen wurden.

<img src="media/tfsu2_08-47.png"; alt="Agent maintenance" width="600" height="386" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 47) Agent-Wartung

Die Verwendung dieser Option sollte verhindern, dass Ihre privaten Build- und Release-Agents nicht mehr genügend Speicherplatz haben. Die Wartung erfolgt pro Agent (nicht pro Computer). Wenn Sie mehrere Agents auf einem einzelnen Computer besitzen, können daher weiterhin Speicherplatzprobleme auftreten.

Build-Agent-Upgradestatus

Wenn ein Agent aktualisiert wird, gibt er nun den Status des Upgrades in der Warteschlange und dem Pool-Verwaltungsportal an.

Auswahl von privaten Agents auf Computern, die nicht in Gebrauch sind

Das System verwendet jetzt den Computernamen als Faktor, wenn ein Build oder ein Release einem privaten Agent zugeteilt wird. Daher wird das System bei der Zuweisung des Auftrags einen Agent auf einem Computer im Leerlauf über einen Agent auf einem ausgelasteten Computer bevorzugen.

iOS DevOps-Erweiterungen

Die Apple App Store-Erweiterung unterstützt jetzt für externe Tester zweistufige Verifizierungs- (zweistufige Authentifizierung) und Freigabebuilds (Abbildung 48).

<img src="media/tfsu2_12-48.png"; alt="Apple App Store connection" width="450" height="292" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 48) Apple App Store-Verbindung

Apple-Zertifikat installieren (Vorschau) ist eine neue Buildaufgabe, die ein P12-Signaturzertifikat auf dem Agent für den Gebrauch durch einen nachfolgenden Xcode- oder Xamarin.iOS-Build installiert.

Apple-Profil installieren(Vorschau) ist eine neue Buildaufgabe für das Installieren von Bereitstellungsprofilen auf dem Agent für den Gebrauch durch einen nachfolgenden Xcode- oder Xamarin.iOS-Build.

Buildaufgaben von MSBuild, Xamarin.Android und Xamarin.iOS unterstützen jetzt die Erstellung mit dem Visual Studio für Mac-Toolset.

Java-Code Coverage-Erweiterungen

Die Buildaufgabe Code Coverage-Ergebnisse veröffentlichen meldet die Cobertura- oder JaCoCo-Code Coverage als Teil des Builds. Sie unterstützt jetzt die Angabe von Platzhaltern und Minimatch-Mustern in den Feldern Zusammenfassungsdatei und Berichtsverzeichnis, wobei die Felder und Verzeichnisse auf der Grundlage einzelner Builds für Pfade, die sich zwischen Builds verändern, aufgelöst werden können.

Maven- und SonarQube-Verbesserungen

Mit der Maven-Buildaufgabe können Sie jetzt ein SonarQube-Projekt für Analyseergebnisse für solche Fälle erstellen, in denen es nicht mit dem übereinstimmt, was in der pom.xml-Datei von Maven angegeben ist.

Verbesserte Jenkins-Integration

Die Build- und Releaseaufgabe des Jenkins-Warteschlangenauftrags unterstützt jetzt die Ausführung von Jenkins-Multibranch Pipeline-Aufgaben, während die Ausgabe der Jenkins-Konsole in Team Services dargestellt wird (Abbildung 49). Pipelineergebnisse werden in der Team Services-Buildzusammenfassung veröffentlicht.

<img src="media/tfsu2_13.png"; alt="Improved Jenkins integration" width="336" height="314" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 49) Verbesserte Jenkins-Integration

Bereitstellung der Skalierungsgruppe des virtuellen Azure-Computers

Ein allgemeines Muster, das für die Bereitstellung verwendet wird, wird für die Erstellung und die anschließende Bereitstellung eines vollständigen Images eines Computers für jede Version der Anwendung verwendet. Um dies zu vereinfachen, gibt es jetzt eine neue Aufgabe: Unveränderliches Image eines Computers erstellen. Diese Aufgabe verwendet Packer, um ein Image für einen Computer nach der Bereitstellung von Anwendungen und allen erforderlichen Voraussetzungen zu generieren. Die Aufgabe nimmt entweder das Bereitstellungsskript oder die Packer-Bereitstellungsvorlage, um das Image des Computer zu erstellen und es in einem Azure-Speicherkonto zu speichern. Dieses Image kann dann für die Bereitstellung von Skalierungsgruppen virtueller Azure-Computer verwendet werden, die gut mit diesem Typ der unveränderlichen Imagebereitstellung funktionieren.

Überschreiben von Vorlagenparametern in Azure-Ressourcengruppenbereitstellungen

Derzeit wählen Benutzer in Aufgaben von Azure-Ressourcengruppenbereitstellungen die Dateien „template.json“ und „parameters.json“ aus und stellen Parameterwerte für die Außerkraftsetzung in einem Textfeld anhand einer bestimmten Syntax bereit. Diese Variante wurde nun verbessert, damit die Vorlagenparameter in einem Raster gerendert werden, wodurch sie bearbeitet und außer Kraft gesetzt werden können (Abbildung 50). Sie können auf dieses Feature zugreifen, indem Sie auf ... neben dem Feld „Parameter außer Kraft setzen“ klicken. Es wird ein Dialogfeld mit den Vorlagenparametern und deren Standardwerte sowie erlaubte Werte geöffnet (falls in den Vorlagen- und .json-Parameterdateien definiert). Diese Funktion erfordert, dass CORS-Regeln in der Quelle aktiviert sind. Wenn Vorlagen- und .json-Parameterdateien im Azure Storage-Blob zu finden sind, beziehen Sie sich auf die Dokumentation der Azure-Speicherdienste, um CORS zu aktivieren.

<img src="media/tfsu2_56-50.png"; alt="Azure RG parameters" width="625" height="524" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 50) Azure RG-Parameter

Mehrere Releasetrigger mit Verzweigungs- und Tagfiltern

Die Releaseverwaltung unterstützt jetzt die Einrichtung von CD-Triggern auf mehreren Artefaktquellen des Typs „Build“. Wenn sie hinzugefügt werden, wird ein neues Release automatisch erstellt, wenn eine neue Artekfaktversion für eine der angegebenen Artefaktquellen verfügbar ist. Sie können auch die Quellverzweigung angeben, aus der der neue Build kommen sll, um ein Release auszulösen. Darüber hinaus können Tagfilter darauf festgelegt werden, weiterhin die Builds zu filtern, die ein Release auslösen sollen.

Festlegen der Standardeinstellungen für Artefaktquellen in einem Release

Benutzer können die Standardversion des Artefakts in einem Release definieren, wenn Sie eine Artefaktquelle in einer Definition verknüpfen (Abbildung 51). Wenn ein Release automatisch erstellt wird, wird die Standardversion für alle Artefaktquellen bereitgestellt.

<img src="media/tfsu2_58-51.png"; alt="Default artifact version" width="450" height="410" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 51) Standardversion der Artefakte

Trennung von Aufgaben für die Bereitstellung von anfordernden und genehmigenden Personen

Zuvor konnten Besitzer von Umgebungen die Ersteller von Releases daran hindern, Bereitstellungen des Release für eine Umgebung zu genehmigen. Sie können jedoch die Bereitstellung des Release, das von einem anderen Benutzer erstellt wurde, manuell starten und es selbst genehmigen.

Wir haben nun diese Lücke gefüllt, indem wir den Ersteller der Bereitstellung als separate Benutzerrolle für Bereitstellungen berücksichtigt haben. Entweder kann der Ersteller des Release oder der Ersteller der Bereitstellung von der Genehmigung der Bereitstellung ausgeschlossen werden.

Genehmigungen für die Releaseebene

Sie können sich nun dafür entscheiden, Bereitstellungen, die automatisch nach einer erfolgreichen Bereitstellung zu einer anderen Umgebung ausgelöst wurden, automatisch zu genehmigen (Abbildung 52). Das Genehmigen einer Kette von Bereitstellungen (die die gleichen genehmigenden Personen haben) kann einmalig geschehen, wenn Sie sich dazu entscheiden, nicht jede Bereitstellung zu genehmigen.

Nehmen wir an, dass Sie zwei Umgebungen besitzen, Entwicklung und Tests, für die die zuvor bereitgestellten genehmigenden Personen auf „userA“ und „userB“ festgelegt wurden und beide die Bereitstellung genehmigen mussten. Wenn die Richtlinie für die Testumgebung wie unten festgelegt wird, ist es während der Bereitstellungszeit für userA und userB ausreichend, nur die Entwicklungsumgebung zu genehmigen. Die Bereitstellung für die Testumgebung wird automatisch genehmigt. Wenn die Bereitstellung für Test manuell ausgelöst wurde, sind vor der Bereitstellung die Genehmigungen erforderlich, damit die richtigen Genehmigungen sichergestellt werden können.

<img src="media/tfsu2_57.png"; alt="Release level approvals" width="650" height="534" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 52) Genehmigungen auf Releaseebene

Bereitstellung in der Azure Government-Cloud

Kunden mit Azure-Abonnements in Government-Clouds können jetzt den Azure Resource Manager-Dienstendpunkt konfigurieren, um nationale Clouds anzuvisieren.

Dadurch können Sie nun Release Management zur Bereitstellung beliebiger Anwendungen für Azure-Ressourcen verwenden, die in Government-Clouds mithilfe der gleichen Bereitstellungsaufgaben gehostet werden (Abbildung 53).

<img src="media/tfsu2_55-53.png"; alt="Government cloud" width="500" height="507" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 53) Government-Cloud

Festlegen der maximalen Anzahl paralleler Bereitstellungen

Diese Funktion gibt Ihnen die Kontrolle darüber, wie mehrere ausstehende Releases in eine vorhandene Umgebung bereitgestellt werden (Abbildung 54). Wenn Ihre Releasepipeline beispielsweise die Überprüfung von Builds in einer QA-Umgebung ausführt, und die Rate der Buildgenerierung schneller als die Rate des Abschlusses der Bereitstellungen ist, können Sie mehrere Agents und genauso viele Builds konfigurieren, die dann parallel validiert werden. Das heißt, dass jeder generierte Build validiert wird. Die Wartezeit hängt von der Anzahl der verfügbaren Agents ab. Mit dieser Funktion können Sie Validierungen optimieren, indem Sie sie auf den aktuellsten Builds parallel ausführen und die älteren Bereitstellungsanfragen löschen.

<img src="media/tfsu2_60-54.png"; alt="Parallel deployments" width="600" height="441" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 54) Parallele Bereitstellungen

Timeout-Erweiterungen für die Aufgabe für manuellen Eingriff

Die Aufgabe Manueller Eingriff kann jetzt automatisch abgelehnt oder wieder aufgenommen werden, wenn sie für das angegebene Zeitlimit oder für 60 Tage aussteht, je nachdem, was zuerst zutrifft. Der Timeoutwert kann im Abschnitt „Steueroptionen“ der Aufgabe angegeben werden.

Release Management-Parallelausführung

Release Management unterstützt jetzt eine Option für die parallele Ausführung für eine Phase (Abbildung 55). Wählen sie diese Option, um eine Phase mithilfe einer der Optionen „mehrfache Konfiguration“ oder „mehrfache Agenten“ als Phasenvervielfacher zu verteilen.

<img src="media/tfsu2_61-55.png"; alt="Parallel execution support" width="600" height="146" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 55) Unterstützung für die parallele Ausführung

Multikonfiguration: Wählen Sie diese Option aus, um die Phase für jeden Multikonfigurationswert auszuführen. Wenn Sie z.B. eine Bereitstellung auf zwei verschiedenen geografischen Orten zur gleichen Zeit durchführen möchten, führt die Verwendung einer „ReleasePlatform“-Variable, die auf der Registerkarte „Variablen“ mit den Werten „east-US, west-US“ definiert ist, die Phase parallel mit einem Wert „east-US“ und einem anderen „west-US“-Wert aus. Multi-Agent: Wählen Sie diese Option, um die Phase mit einer oder mehreren Aufgaben auf mehreren Agents parallel auszuführen.

Web-App-Bereitstellungsverlauf im Azure-Portal

Release Management aktualisiert jetzt die Bereitstellungsprotokolle von Azure App Service, wenn eine Bereitstellung mithilfe der App Service-Bereitstellungsaufgaben durchgeführt wird. Sie können den Bereitstellungsverlauf im Azure-Portal anzeigen, indem Sie die Option Fortlaufende Bereitstellung auf dem Blatt App Service auswählen.

Verbesserungen für Tests

Ausführen von Tests mithilfe von Agent-Phasen

Mithilfe der Visual Studio-Testaufgabe können Sie jetzt automatisierte Tests mithilfe von Agent-Phasen ausführen (Abbildung 56).

Es gibt jetzt einen einheitliche Automation-Agent für Build, Release und Test. Dies hat folgende Vorteile:

  1. Sie können einen Agent-Pool für Ihre Testanforderungen nutzen.
  2. Führen Sie Tests in unterschiedlichen Modi mithilfe derselben Visual Studio-Testaufgabe basierend auf Ihren Bedürfnissen aus. Dies können Sie mit einer Ausführung basierend auf einem einzigen Agent, einer verteilten Testausführungen basierend auf mehreren Agents oder eine Ausführung mit mehreren Konfigurationen, z.B. auf unterschiedlichen Browsern tun.

<img src="media/tfsu2_53-56.png"; alt="Run tests using Agent Phases " width="600" height="434" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 56) Tests mithilfe von Agent-Phasen ausführen

Weitere Informationen finden Sie in diesem Microsoft Application Lifecycle Management-Post.

Auslösen von automatisierten Tests bei Bedarf

Der Test-Hub unterstützt nun das Auslösen automatisierter Testfälle von Testplänen und Testsammlungen (Abbildung 57). Für die Ausführung automatischer Tests aus dem Test-Hub benötigen Sie eine Einrichtung, die der planmäßigen Ausführung von Tests in Releaseumgebungen ähnelt. Sie müssen eine Umgebung in der Releasedefinition mithilfe der Vorlage Run automated tests from test plans (Automatisierte Tests aus Testplänen ausführen) einrichten und die Testpläne zuordnen, um die automatisierten Tests auszuführen. In der Dokumentation finden Sie eine ausführliche Anleitung zum Einrichten von Umgebungen und Ausführen automatisierte Tests aus dem Test-Hub.

<img src="media/tfsu2_54.png"; alt="On-demand automated tests trigger" width="721" height="408" style="border:2px solid Silver; display: block; margin: auto;">

*(Abbildung 57) Bedarfsabhängige automatisierte Testauslöser *

Warehouseverbesserungen

Leistungsverbesserungen bei der Verarbeitung von Cubes in Analysis Services

Wir haben Leistungsverbesserungen der Ansicht vDimWorkItemTreeOverlay vorgenommen, die verwendet wird, um die Dimension Arbeitsaufgabenstruktur-Hierarchie auf Grundlage der Links zu erstellen. Auch wenn es von den „System.LinkTypes.Hierarchy“-Links abhängig ist, haben wir beobachtet, dass die Verarbeitungsdauer auch von anderen Links beeinträchtigt wurde (z.B. System.LinkTypes.Related). Wir haben die Ansicht optimiert, sodass sie zusätzliche Linktypen überspringt, womit die Menge an gelesenen Daten eingeschränkt wird. Diese Änderung senkt die Verarbeitungszeit für bestimmte Warehouses deutlich.

Schemaabgleich mit Beachtung der Groß- und Kleinschreibung

Das Schema der Warehousedatenbank wird durch das Mergen von Feldern aus den angehängten Auflistungsdatenbank während des Schemaabgleichsprozesses erstellt. Früher wurde in allen Vergleichen die Groß- und Kleinschreibung beachtet, und Administratoren mussten sicherstellen, dass es eine genaue Entsprechung in den Feldverweisnamen gab. Dies hat zu Problemen geführt, wenn es geringfügige Abweichungen bei der Groß- und Kleinschreibung gab. Ab dieser Version verzeiht der Prozess solche Abweichungen eher.

Verbesserungen für die Verwaltung

Kombinierte E-Mail-Empfänger für Benachrichtigungen

Empfänger für die dieselbe E-Mail-Benachrichtigung sind nun zusammen in der „An...“-Zeile enthalten und erhalten eine E-Mail. Zuvor wurden einzelne E-Mails an jeden Empfänger gesendet. Dadurch wurde es schwierig, zu erkennen, wer die Benachrichtigung noch erhalten hat, und eine Konversation über das Ereignis per E-Mail einzurichten. Diese Funktion gilt sowohl für Standard- als auch Team-Abonnements, die mehrere Empfänger ansprechen können. Beispielsweise erhalten alle Reviewer eines Pull Request jetzt eine einzelne E-Mail, wenn eine Änderung an dem Pull Request vorgenommen wird.

Erfahren Sie mehr über das Kombinieren von E-Mail-Empfängern.

Standardbenachrichtigungen

Benutzer und Teams werden jetzt automatisch per E-Mail benachrichtigt, wenn Aktivitäten im Konto vorhanden sind, die direkt für sie relevant sind, z.B.:

  • Wenn einem Benutzer eine Arbeitsaufgabe zugewiesen wird
  • Wenn ein Benutzer oder Team als Reviewer eines Pull Request hinzugefügt wird
  • Wenn ein Benutzer oder Team Reviewer auf einem Pull Request ist, der aktualisiert wird
  • Wenn ein anderer Benutzer in einen Kommentar auf den Pull Request reagiert
  • Wenn ein von einem Benutzer angeforderter Build abgeschlossen wird
  • Wenn eine Erweiterung installiert oder angefordert wird (nur Administratoren)

Benutzer können diese Abonnements kündigen, indem sie zur Einstellung Benachrichtigung unter dem Benutzerprofilmenü wechseln und dann die entsprechende(n) Einstellung(en) deaktivieren.

Ein Kontoadministrator kann eine oder mehrere dieser automatischen Abonnements durch Navigieren zum Hub der Auflistungsebene Benachrichtigungen unter dem Zahnradsymbol für die Einstellungen deaktivieren. Jedes dieser Abonnements kann durch klicken auf Deaktivieren unter der Aktion „...“ deaktiviert werden. Sobald ein Abonnement deaktiviert ist, wird es nicht mehr für Benutzer auf ihrer persönlichen Seite für Benachrichtigungseinstellungen angezeigt.

Weitere Informationen zu Standardbenachrichtigungen.

Berechtigungen für die Erweiterungsverwaltung

Ein Administrator kann anderen Benutzern und Gruppen jetzt Berechtigung erteilen, um Erweiterungen für die Auflistung zu erhalten (Abbildung 58). Zuvor konnten nur Auflistungsadministratoren (z.B. Mitglieder der Gruppe „Projektauflistungsadministratoren“) die Erweiterungsanforderung überprüfen und Erweiterungen installieren oder deinstallieren.

Um diese Berechtigung zu gewähren, kann ein Administrator zum Erweiterungsadministrator-Hub wechseln, indem er das Marketplace-Menü öffnet, „Erweiterungen verwalten“ auswählt und dann auf die Schaltfläche „Sicherheit“ klickt.

<img src="media/tfsu2_52-58.png"; alt="Extension management permissions" width="650" height="290" style="border:2px solid Silver; display: block; margin: auto;">

(Abbildung 58) Berechtigungen der Erweiterungsverwaltung

Erhalten von Benachrichtigungen wenn Erweiterungen installiert werden, Aufmerksamkeit erfordern, und mehr

Administratoren oder Personen, die die Fähigkeit zur Verwaltung von Erweiterungen haben, werden nun automatisch benachrichtigt, wenn eine Erweiterung installiert, deinstalliert, aktiviert oder deaktiviert wird oder Aufmerksamkeit erfordert. Dies ist vor allem hilfreich bei größeren Bereitstellungen, bei denen mehrere Personen die Verantwortung innehaben, die Erweiterungen zu verwalten. Administratoren können diese Benachrichtigungen durch Navigieren zur Einstellung Benachrichtigung unter dem Menü „Profil“ ausschalten, wo sie die entsprechende Einstellung deaktivieren müssen.

Administratoren können auch benutzerdefinierte Abonnements für Ereignisse in Zusammenhang mit Erweiterungen definieren. Beispielsweise kann ein Administrator benachrichtigt werden, sobald eine Erweiterung aktualisiert wird.

Benutzer können jetzt auch automatische Benachrichtigungen über Ihre Erweiterungsanforderungen deaktivieren.

Zulassen, dass TFS-Administratoren Abonnenten zur erweiterten Zugriffsebene hinzufügen

Die Zugriffsebene Erweitert wird aus zukünftigen Versionen von Team Foundation Server entfernt. Bis dies erfolgt, verfügen jedoch TFS-Administratoren über die Möglichkeit, MSDN-Plattform- und Visual Studio Test Professional-Abonnenten der Zugriffsebene Erweitert mit Update 2 hinzuzufügen.

Visual Studio Enterprise-Abonnenten sollten der Visual Studio Enterprise-Zugriffsebene anstatt der Ebene Erweitert hinzugefügt werden. Wenn Sie die Test Manager-Erweiterung gekauft haben, verwalten Sie diese weiter im Benutzer-Hub innerhalb des Teamprojekts, von dem Sie diese gekauft haben.

Integration in Microsoft Teams

Unternehmen, die Microsoft Teams für die Zusammenarbeit verwenden, sehen nun Aktivität ihrer TFS-Projekte in den Kanälen ihrer Teams. So sind die Teams beim Arbeiten in Microsoft Teams immer auf dem neuesten Stand bei Änderungen wichtiger Arbeitselemente, Pull Requests, Builds und Releases usw. Weitere Informationen finden Sie in unserer Dokumentation.


Bekannte Probleme

Arbeitsaufgabenformulare rendern nicht vollständig im Web

Bekannte Probleme

TFS Version RC2 statt der endgültigen Version

  • Problem:

    Nachdem Herunterladen und Installieren von TFS 2017 Update 2 vor dem 1. August 2017 haben Sie eine RC2-Version.

  • Problemumgehung:

    Grund dafür war ein zeitweiliges Problem mit den Installationslinks, dass am 1. August 2017 behoben wurde. Laden Sie TFS 2017 Update 2 erneut herunter, und installieren Sie die endgültige Version.


The Developer Community Portal Hinweise zu Team Foundation Server 2017 finden Sie unter den von Benutzern gemeldeten Problemen.


Seitenanfang