Team Foundation Server 2017 Update 2: Anmerkungen zu dieser Version

---

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

---

---

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

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

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

---

Veröffentlichungsdatum: 24. Juli 2017

Zusammenfassung der Neuerungen in Team Foundation Server 2017 Update 2

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

• Arbeitselemente verfügen nun über Symbole, die jedem Arbeitselementtyp zugeordnet sind.
• Wir haben Lieferpläne eingeführt.
• Sie können mithilfe der Suche von Arbeitselementen nach Arbeitselementen suchen.
• Es gibt eine neue Benutzeroberfläche für die Konfiguration von Verzweigungsrichtlinien.
• Es gab viele Verbesserungen bei Pull Requests.
• Es sind nun Git-Diagramme zum Visualisieren Ihrer Git-Versionsgeschichte verfügbar.
• Sie können nun Git-Tags hinzufügen und anzeigen.
• Wir haben eine neue Benutzeroberfläche für die Paketverwaltung.
• Es gibt eine neue Oberfläche für den Builddefinition-Editor.
• Verschiedenen Updates bei der Bereitstellung auf Azure Web-Apps.
• Viele Verbesserungen bei der Bereitstellung von Containern.
• Wir haben bedingte Buildaufgaben eingeführt.
• Es sind jetzt Standardbenachrichtigungen vorhanden.

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

• Arbeitselementnachverfolgung
• Versionskontrolle
• Pull Requests
• Paketverwaltung
• Build und Release
• Testen
• Warehouse
• Verwaltung
• Integration in Microsoft Teams

---

Details zu den Neuerungen in TFS 2017 Update 2

Verbesserungen für Arbeitselementverfolgung

Symbole für Arbeitselementtypen

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 Arbeitselementtyps eingeführt. Sie können Ihre Arbeitselementtypen 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) .

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

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

Veraltung des alten Arbeitselementformulars

Im Allgemeinen war das Feedback zum neuen Arbeitselementformular 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 Arbeitselementformular 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.

Arbeitselementsuche

Die Arbeitselementsuche bietet eine schnelle und flexible Suche in Ihren gesamten Arbeitselementen über alle Projekte in einer Auflistung hinweg (Abbildung 4) . Sie können die Engine zur Volltextsuche der Arbeitselementsuche verwenden, um einfach nach Begriffen in allen Arbeitselementfeldern zu suchen und relevante Arbeitselemente effizient zu lokalisieren. Verwenden Sie zeilenbezogene Suchfilter auf einem beliebigen Arbeitselementfeld, um schnell eine Liste von Arbeitselementen 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 Arbeitselementsuche können Sie Folgendes tun:

• Projektübergreifend suchen: Durchsuchen Sie Ihre eigenen Backlogs und die Ihrer Partnerteams. Verwenden Sie projektübergreifende Suchen über alle Arbeitselemente hinweg, um in den gesamten Arbeitselementen Ihrer Organisation zu suchen. Schränken Sie Ihre Suche ein, indem Sie Pfadfilter für Projekte und Bereiche nutzen.
• Alle Arbeitselementfelder gleichzeitig durchsuchen: Finden Sie schnell und einfach relevante Arbeitselemente, indem Sie alle Arbeitselementfelder (einschließlich ERE-Felder) durchsuchen. Verwenden Sie eine Volltextsuche über alle Felder hinweg, um effizient relevante Arbeitselemente zu ermitteln. Die Ausschnittsansicht zeigt an, wo Übereinstimmungen gefunden wurden.
• Bestimmte Felder durchsuchen: Verwenden Sie die schnellen zeilenbezogenen Suchfilter für beliebige Arbeitselementfelder, um sekundenschnell eine Liste von Arbeitselementen 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.
• Die integrierte Arbeitselementnachverfolgung nutzen: Da die Schnittstelle der Arbeitselementsuche in bekannte Steuerelemente im Arbeitshub integriert ist, können Sie Arbeitselemente anzeigen, bearbeiten, kommentieren, teilen und vieles mehr.

Verbesserungen der Versionskontrolle

Neue Benutzeroberfläche für die Konfiguration von Branchrichtlinien

Wir haben die Benutzeroberfläche zur Konfiguration von Branchrichtlinien 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.  

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

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.

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

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

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 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 vorgenommen, um die Ansichts- und Bearbeitungserfahrungen zu verbessern.

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

>

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 Arbeitselemente verknüpfen (Abbildung 13) .

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.

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. Mergecommits 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 Commitverbindung. Sobald Sie auf den Pfeil klicken, wird der Commit mit seinem übergeordneten Commit verbunden.

Anzeigen von Git-Tags für 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 können Tags für einen bestimmten Commit in der Ansicht Commitliste und der Seite Details anzeigen (Abbildung 16) .

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.

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

Aktualisierte Changeset- und Shelvesetseiten

Wir haben in TFVC die Changeset- und Shelvesetseiten modernisiert. Beide Seiten sind für diejenigen von Ihnen leichter zugänglich, die nach Hilfstechnologien verwenden. 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) .

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, Arbeitselemente mit # zuzuordnen und Dateien und Images einfach anzufügen.

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.

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

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.  

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.

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.

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.

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

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

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

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

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

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 Topic-Branch vor Abschluss Ihres PR ausführen.  Reviewers verfügen nicht über genügend Informationen, um zu wissen, was genau passiert ist.

Pull Request-Filtern anhand Personen

Es ist jetzt 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. 

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

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

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.

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.

Wir werden in einem zukünftigen Release 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.  

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.

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.

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

Wir haben an der Aufgabe NuGet-Installer (jetzt NuGet-Wiederherstellung) wichtige Aktualisierungen vorgenommen und eine neue NuGet-Aufgabe hinzugefügt: NuGet-Befehl. Insbesondere verwenden die Aufgaben NuGet-Befehl und NuGet-Wiederherstellung 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) .

Build- und Releaseverbesserungen

Neuer Editor für Builddefinition

Wir haben unseren Builddefinition-Editor neu gestaltet, um eine intuitivere Erfahrung zu bieten, einige kritische Probleme zu beheben und neue Funktionen hinzuzufügen. Wir hoffen, dass die Verwendung von Vorlagen, das Hinzufügen von Aufgaben und die Änderung von Einstellungen für Sie jetzt einfacher ist. Darüber hinaus können Sie jetzt Prozessparameter benutzen, um die wichtigsten Datenbestandteile einfacher 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) .

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

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.

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.

Mehrere Versionen von Erweiterungsaufgaben

Erweiterungsautoren können nun Erweiterungen mit mehreren Versionen einer bestimmten Aufgabe erstellen, wodurch sie Patches für jede Hauptversion, die sie in der Produktion haben, ausliefern können.

Weitere Informationen finden Sie unter Referenz zum Erstellen benutzerdefinierter Buildaufgaben innerhalb von Erweiterungen.

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 ein Problem aufgetreten ist, bieten wir Ihnen nun vier integrierte Möglichkeiten, mit denen Sie eine laufende Aufgabe steuern können (Abbildung 46) .

Zur Erhöhung der Flexibilität, z.B. eine Aufgabe, die nur für bestimmte Branches 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: Führen Sie zum Bereitstellen, Konfigurieren oder Aktualisieren Ihres Kubernetes-Clusters im Azure Container Service „kubectl“-Befehle aus.
• 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 Remotebasisverzeichnis eines Benutzers zu vereinfachen.   Außerdem können im Build/Release durch die neue Option Fehler auftreten, 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. Dieses Feature wird in der Zukunft verbessert, damit Passphrasen und andere Funktionen unterstützt werden können.

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.

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.

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

Pipelinewarteschlange

Wir sind jetzt vom Agent-basierten zum Pipeline-basierten Preismodell übergegangen. In diesem neuen Modell können Benutzer so viele Builds oder Releases gleichzeitig ausführen, wie durch die Anzahl der in ihrem Konto konfigurierten Pipelines angegeben. Zusätzliche Builds und Releases, die diesen Grenzwert überschreiten, werden in die Warteschlange gestellt und warten auf die Fertigstellung früherer Builds und Releases. Das Feature Pipelinewarteschlange bietet Benutzern dahingehend mehr Transparenz, wo sich ihre Builds oder Releases befinden.

Beim Starten der Pipelinewarteschlange werden folgende Informationen angezeigt:

1. Builds und Releases, die auf die Ausführung einer Pipeline warten, und ihre Position in der Warteschlange. 2. Builds und Releases, die derzeit mithilfe der verfügbaren Pipelines ausgeführt werden.

Während Ihr Build/Release auf eine Pipeline wartet, können Sie diese Ansicht auch direkt von der Build/Release-Protokollseite aus aufrufen und ihre aktuelle Position in der Pipelinewarteschlange und andere Details finden.

Release-Aktion in Buildzusammenfassung

Wir unterstützen jetzt eine Release-Aktion, die auf der Aktionsleiste der Build-Zusammenfassung verfügbar ist, sodass es für Sie einfach ist, ein Release für einen Build zu erstellen.

Sicherheit für variable Gruppen

Die Sicherheit für variable Gruppen wird jetzt durch eine Reihe von Rollen wie Ersteller und Administrator geregelt.

Standardmäßig sind die nachfolgenden Rollen zugeordnet.

• Rolle „Ersteller“ zu Mitwirkende
• Rolle „Administrator“ zu Projektauflistungsadministratoren, Projektadministratoren, Buildadministratoren und Releaseadministratoren
• Rolle „Leser“ zu „Gültige Projektbenutzer“

Die Voreinstellungen können für alle Variablengruppen oder für eine bestimmte Gruppe überschrieben werden.

iOS DevOps-Erweiterungen

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

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.

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 neben dem Feld „Parameter außer Kraft setzen“ auf ... klicken. So werden ein Dialogfeld mit den Vorlagenparametern und deren Standardwerten und zulässigen Werten geöffnet (sofern in den Vorlagen- und JSON-Parameterdateien definiert). Dieses Feature erfordert, dass CORS-Regeln in der Quelle aktiviert sind. Sofern die Vorlagen- und JSON-Parameterdateien im Azure Storage Blob enthalten sind, informieren Sie sich in der Dokumentation zu Azure-Speicherdiensten, wie Sie CORS aktivieren.

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.

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.

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

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 das Release Management und dieselben Bereitstellungsaufgaben nutzen, um Anwendungen auf Azure-Ressourcen bereitzustellen, die in Government-Clouds gehostet werden (Abbildung 53) .

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.

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.  Sie können den Timeoutwert im Abschnitt „Steueroptionen“ angeben. 

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.

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 aus, um die Phase mit einer oder mehreren Aufgaben auf mehreren Agents parallel auszuführen.

Web-App-Bereitstellungsverlauf im Azure-Portal

Die Releaseverwaltung 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.

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.

Warehouseverbesserungen

Leistungsverbesserungen bei der Verarbeitung von Cubes in Analysis Services

Wir haben Leistungsverbesserungen an der Ansicht vDimWorkItemTreeOverlay vorgenommen, die verwendet wird, um die Dimension Arbeitselementstruktur-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 ein Arbeitselement zugewiesen wird.
• ein Benutzer oder Team als Reviewer eines Pull Request hinzugefügt wird.
• ein Benutzer oder Team Reviewer auf einem Pull Request ist, der aktualisiert wird.
• ein anderer Benutzer in einen Kommentar auf den Pull Request reagiert.
• ein von einem Benutzer angeforderter Build abgeschlossen wird.
• eine Erweiterung installiert oder angefordert wird (nur Administratoren).

Benutzer können diese Abonnements kündigen, indem sie im Benutzerprofilmenü zu den Benachrichtigungseinstellungen wechseln und dann die entsprechenden Einstellungen 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.

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 TFS-Administratoren jedoch ü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 die 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

Arbeitselementformulare rendern nicht vollständig im Web

• Problem:

  Wenn Sie ein benutzerdefiniertes Steuerelement verfügen, z.B. das mehrwertige Steuerelement, das für den Visual Studio-Client, jedoch nicht für den Web-Client installiert wurde, rendern Arbeitselementformulare nicht im Web.

• Problemumgehung:

  Sie müssen Ihr Steuerelement auf die aktuellste Version bringen. Es ist erforderlich, ein Weblayout hinzuzufügen, das das fehlende Steuerelement nicht enthält. Sie finden das neueste mehrwertige Steuerelement für das TFS 2017 Update auf der Seite Custom Controls for TFS Work Item Tracking (Benutzerdefinierte Steuerelemente für die Nachverfolgung von TFS-Arbeitselementen). Weitere Informationen zum Layout finden Sie unter All FORM XML elements reference (TFS 2015) (Verweis für alle FORM XML-Elemente (TFS 2015)).

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.

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

---

Feedback und Vorschläge

Wir freuen uns auf Ihr Feedback! Sie können ein Problem melden und es über das Entwicklercommunity-Portal nachverfolgen und Ratschläge zu Stack Overflow (Stapelüberlauf) erhalten.

---

Seitenanfang