Versionshinweise zu Team Foundation Server 2018 Update 2

---

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

---

Hinweis

Wenn Sie auf diese Seite über eine nicht englischen Sprachversion zugreifen und den neuesten Inhalt sehen möchten, besuchen Sie die englischsprachige Seite mit den Anmerkungen zu der Version. Sie können die Sprache auf dieser Seite ändern, indem Sie in der Seitenfußzeile auf das Globussymbol klicken und die gewünschte Sprache auswählen.

---

In diesem Artikel erhalten Sie Informationen zu dem neuesten Release für Team Foundation Server 2018. Klicken Sie zum Herunterladen auf die Schaltfläche.

Weitere Informationen zu Team Foundation Server 2018 finden Sie auf der Seite Team Foundation Server Requirements and Compatibility (Team Foundation Server: Anforderungen und Kompatibilität). Besuchen Sie die Seite visualstudio.com/downloads, um andere TFS 2018-Produkte herunterzuladen.

Das direkte Upgrade auf Team Foundation Sever 2018 Update 2 ist nur ab TFS 2012 und höher möglich. Wenn Sie TFS 2010 oder früher verwenden, müssen Sie vor dem Upgrade auf TFS 2018 Update 2 noch mehrere Zwischenschritte ausführen. Weitere Informationen finden Sie im untenstehenden Diagramm und auf der Seite für die Installation von TFS.

TFS-Upgradematrix

Wichtig

Sie müssen kein Upgrade auf TFS 2018 RTM durchführen, bevor Sie auf TSF 2018 Update 2 upgraden.

---

Veröffentlichungsdatum: 7. Mai 2018

Sie können nun ein Upgrade auf TFS 2018 Update 2 durchführen und weiterhin eine Verbindung zu Ihren XAML-Controllern herstellen und XAML-Builds ausführen. Als die Unterstützung für XAML-Builds in TFS 2018 RTW und Update 1 entfernt wurde, konnten einige Benutzer aufgrund von veralteten XAML-Builds kein Upgrade durchführen. Dieses Problem soll behoben werden. Obwohl TFS 2018 Update 2 XAML-Builds für Ihre veralteten Builds unterstützt, sind XAML-Builds veraltet, und es wird nicht weiter in diese investiert. Deshalb wird die Konvertierung in ein neueres Format für Builddefinitionen empfohlen.

Zusammenfassung: Neues in TFS 2018 Update 2

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

• Anzeigen des Pull Request-Mergecommits
• Pull Request-Bezeichnungen für Reviewer
• Erwähnen eines Pull Requests
• Benachrichtigungen zu Pull Request-Kommentaren enthalten den Threadkontext
• Erweiterbarkeit des Status von Pull Requests
• Benutzerdefinierte Felder und Tagsfilter in Benachrichtigungen zum Nachverfolgen von Arbeitselementen
• Modernisierte Spaltenoptionen
• Unterstützung für den Abfrageoperator NOT IN hinzugefügt
• Query for @MyRecentActivity and @RecentMentions
• Filtern von Plänen
• Releasegates
• Erstellen mit Continuous Integration von GitHub Enterprise
• Verbesserungen von Builds mit mehreren Phasen
• Überspringen von geplanten Builds, wenn sich im Repository nichts geändert hat
• Nahtloses Verwenden öffentlicher Pakete mit Upstreamquellen
• Vermerkdauerrichtlinien in TFS-Feeds
• Filtern in der Paketverwaltung
• Wiki-Suche
• Verweisen auf Arbeitselemente in der Wiki
• Inhaltsvorschau beim Bearbeiten von Wiki-Seiten
• Einfügen von umfangreichem Wiki-Inhalt als HTML
• Profilkarten
• Rundes Profilbild

---

Ausführlicher Überblick: Neues in TFS 2018 Update 2

Weitere Informationen zu diesen Features finden Sie in den entsprechenden Abschnitten:

• Code
• Arbeit
• Build und Release
• Paket
• Test
• Wiki
• Allgemein

Code

Permanente Links zu Code

In der Dateiansicht sehen Sie normalerweise die Version an der Spitze des jeweiligen Branchs. Diese Dateiversion kann sich durch neue Commits ändern. Wenn Sie einen Link aus dieser Ansicht kopieren, kann es sein, dass dieser irgendwann nicht mehr gültig ist, da die URL nur den Namen des Branchs und nicht den Commit-SHA enthält. Jetzt können Sie mühelos die Dateiansicht wechseln, um die URL zu aktualisieren, sodass sie auf den Commit und nicht mehr auf den Branch verweist. Wenn Sie die Y-Taste drücken, wechselt Ihre Ansicht zum Commit an der Spitze des aktuellen Branches. Dann können Sie permanente Links kopieren.

Wiederherstellen eines kürzlich gelöschten Repositorys über die API

Manchmal kommt es zu versehentlichen Löschungen beim Bereinigen alter Repositorys bei der Quellcodeverwaltung. Wenn ein Git-Repository in den letzten 30 Tagen gelöscht wurde, kann es über die REST-API wiederhergestellt werden. Weitere Informationen finden Sie in den Dokumentationen zu Auflistungs- und Wiederherstellungsvorgängen.

SSH: Unterstützen zusätzlicher Verschlüsselungen/Schlüssel und Einstellen der Unterstützung veralteter Verschlüsselungen

Die Liste der unterstützten SSH-Verschlüsselungen wurde aktualisiert, um die Sicherheit und die Kompatibilität zu verbessern. Es wurden zwei neue Verschlüsselungen hinzugefügt und drei als veraltet markiert, was der Entwicklung von OpenSSH entspricht. Die veralteten Verschlüsselungen funktionieren in diesem Release weiterhin. Sie werden in einem kommenden Release entfernt, wenn sie nicht mehr verwendet werden.

Hinzugefügt:

• AES128 CTR
• AES256 CTR

Veraltet:

• AES128
• AES192
• AES256

Vermeiden von Überschreibungen und Schützen der Leistung mit Repositoryeinstellungen

Mit diesem Update stehen zwei neue Repositoryeinstellungen zur Verfügung, die zum problemlosen Ausführen von Git beitragen.

Case enforcement (Groß-/Kleinschreibung erzwingen) ändert den Standardmodus des Servers, bei dem Groß- und Kleinschreibung beachtet wird („File.txt“ und „file.txt“ verweisen auf die gleiche Datei), in einen Windows- und macOS-freundlichen Modus, bei dem „File.txt“ und „file.txt“ dieselbe Datei sind. Diese Einstellung gilt für Dateien, Ordner, Branches und Tags. Außerdem wird dadurch verhindert, dass Mitwirkende versehentlich Unterschiede einführen, die nur auf die Groß- und Kleinschreibung bezogen sind. Es wird empfohlen, das Erzwingen der Groß- und Kleinschreibung zu aktivieren, wenn ein Großteil Ihrer Mitwirkenden mit Windows oder macOS arbeiten.

Mit Limit file sizes (Dateigrößen einschränken) können Sie verhindern, dass neue oder aktualisierte Dateien eine bestimmte von Ihnen festgelegte Dateigröße nicht überschreiten. Je höher die Anzahl an großen Dateien im Verlauf eines Git-Repositorys ist, desto schlechter ist die Leistung beim Klonen und Fetchen. Durch diese Einstellung wird verhindert, dass versehentlich zu große Dateien hinzugefügt werden.

Verbesserte Filterfunktion für Commits mit mehr als 1.000 geänderten Dateien

Das Suchen nach einer Datei in Commits oder Pull Requests, in denen mehr als 1.000 Dateien geändert wurden, war bis jetzt ineffizient. Sie mussten mehrmals auf den Link Mehr laden klicken, um die für Sie relevante Datei zu finden. Wenn Sie jetzt in der Strukturansicht Inhalte filtern, wird die Suche dateiübergreifend im Commit durchgeführt. Früher wurden nur die oberen 1.000 geladenen Dateien durchsucht. Für Commits, die mehr als 1.000 geänderte Dateien enthalten, wurde die Leistung der Commitdetailseite verbessert.

Suchen von Commits, die aufgrund eines erzwungenen Pushvorgangs verloren wurden

Sie können „Git force push“ durchführen und einen Remoteverweis aktualisieren, auch wenn dieser kein Vorgänger des lokalen Verweises ist. Dadurch können Commits bei anderen Benutzern verloren gehen, und es kann sehr schwer sein, den Grund zu finden. In der neuen Ansicht „Pushes“ haben wir erzwungene Pushes hervorgehoben, damit Probleme mit fehlenden Commits besser behoben werden können.

Wenn Sie auf „Push erzwingen“ klicken, werden Sie zum entfernten Commit weitergeleitet.

Verantwortungsverlauf

Die Ansicht Blame (Verantwortung) ist sehr praktisch, wenn Sie herausfinden möchten, wer die letzte Codezeile geändert hat. Allerdings kann es manchmal notwendig sein, herauszufinden, wer die vorherigen Änderungen an einer Codezeile vorgenommen hat. Hier kommt Ihnen die neueste Verbesserung an „Verantwortung“ zugute: Verantwortung vor diesem Commit anzeigen. Wie der Name schon sagt, können Sie dadurch zur Version vor der Version zurückgehen, in der eine bestimmte Zeile geändert wurde, und sich die Informationen zur Verantwortung für diese Version ansehen. Sie können immer weiter nach hinten springen und sich jede Version der Datei ansehen, die vor der Änderung der ausgewählten Codezeile vorhanden war.

Umschalten des Zeilenumbruchs und von Leerräumen in Vergleichsansichten

In der Dateivergleichsansicht stehen zwei neue Features zur Verfügung: Zeilenumbruch umschalten und Leerzeichen umschalten. Mit dem ersten Feature können Sie die Zeilenumbruchseinstellung in einer Vergleichsansicht anwenden. Dies ist besonders beim Prüfen von PRs nützlich, die Dateien ohne regelmäßige Zeilenumbrüche enthalten (z.B. Markdown-Dateien). Die Option zum Umschalten von Leerräumen ist hilfreich, wenn sich in einer Zeile oder in einer Datei nur Leerräume geändert haben. Durch das Umschalten dieser Option werden in der Vergleichsansicht alle Leerräume angezeigt und hervorgehoben (Punkte für Leerzeichen, Pfeile für Tabstopps usw.).

Klicken Sie auf das Zahnrad für die Editor-Einstellungen im Pull Request-Editor oder in der Vergleichsansicht, um diese Einstellungen zu verwalten. Wählen Sie in der Dateiansicht die Option Benutzereinstellungen im Kontextmenü.

Wählen Sie Editor-Features aus, z.B. Leerraum anzeigen und vergleichen, Zeilenumbruch aktivieren, Codefaltung aktivieren und Minikarte anzeigen.

Die Codefaltung (auch als „Gliederung“ bezeichnet) wird auch für die Webansicht aktiviert. Wenn die Codefaltung aktiviert ist, klicken Sie auf die Minuszeichen, um die Codeabschnitte zu reduzieren, und klicken Sie auf die Pluszeichen, um reduzierte Abschnitte zu erweitern. Wenn Sie F1 drücken, öffnet sich eine Optionsauswahl zum dateiübergreifenden Falten verschiedener Einrückgrade, sodass große Dateien leichter gelesen und geprüft werden können.

Nachverfolgen von Codepushes an ein Git-Repository an Builds und Releases

Sie können sich den Build- und Releasestatus von Mergecommits unter Pushes ansehen. Wenn Sie auf den Status neben dem Push klicken, sehen Sie den Build oder das Release, in dem sich der Push befindet. Dort erkennen Sie, ob der Push erfolgreich war.

Gerendertes Markdown in E-Mail-Benachrichtigungen

Markdown eignet sich hervorragend zum umfangreichen Hinzufügen von Formatierungen, Links und Bildern in den Beschreibungen und Kommentaren von PRs. E-Mail-Benachrichtigungen für PRs zeigen jetzt gerendertes Markdown statt Rohinhalt an, sodass sie leicht lesbar sind.

Inlinebilder werden noch nicht inline gerendert (sie werden nur als Links angezeigt), aber daran arbeiten wir aktuell.

Ausführen von TFVC-Befehlen über den Windows-Explorer

Die TFVC-Windows-Shellerweiterung, die eine einfache, in den Windows-Datei-Explorer integrierte Versionskontrolle ermöglicht, unterstützt jetzt TFS 2018. Durch dieses Tool erhalten Sie direkt über das Windows-Explorer-Kontextmenü schnellen Zugriff auf viele TFVS-Befehle.

Das Tool, das Teil von TFS Power Tools war, wurde als eigenständiges Tool auf dem Visual Studio Marketplace veröffentlicht.

Festlegen, wer zu Pull Requests beitragen kann

Früher konnte jeder, der ein Git-Repository anzeigen konnte, auch dessen Pull Requests bearbeiten. Wir haben eine neue Berechtigung hinzugefügt: Zu Pull Requests beitragen. Diese steuert, wer Pull Requests bearbeiten und diese kommentieren kann. Alle Benutzer und Gruppen, die vorher Leseberechtigung hatten, erhalten standardmäßig auch diese Berechtigung. Durch das Einführen dieser Berechtigung können Administratoren flexibler arbeiten und den Zugriff einschränken. Wenn es erforderlich ist, dass die Gruppe Leser tatsächlich nur lesen darf, können Sie die Berechtigung Zu Pull Requests beitragen verweigern.

Weitere Informationen finden Sie in der Schnellstart-Dokumentation zum Festlegen von Repositoryberechtigungen.

Benachrichtigungen zu Pull Request-Kommentaren enthalten den Threadkontext

Häufig sind Antworten auf Pull Request-Kommentare recht kurz und informieren lediglich darüber, dass eine Änderung vorgenommen wurde oder werden soll. Dies ist beim Anzeigen der Kommentare in der Webansicht kein Problem. Wenn Sie jedoch einen Kommentar in einer E-Mail-Benachrichtigung lesen, geht der Kontext des ursprünglichen Kommentars verloren. Ein einfaches „I‘ll fix it“ (Ich kümmere mich darum) hat ohne Kontext keine Bedeutung.

Wenn ein PR-Kommentar beantwortet wird, enthalten die E-Mails nun auch die vorherigen Antworten im Text der E-Mail. Dadurch können alle am Thread Beteiligten direkt in ihrem Posteingang den gesamten Kontext des Kommentars sehen und müssen nicht extra die Webansicht öffnen.

Einstellungen zum Abschließen von Arbeitselementen

Das Feature zum Abschließen von Arbeitselementen beim Abschließen von PRs verfügt jetzt über eine neue Repositoryeinstellung zum Steuern des Standardverhaltens. Die neue Einstellung Benutzereinstellungen zum Abschließen von Arbeitselementen mit Pull Requests speichern ist standardmäßig aktiviert und behält beim Abschließen weiterer Pull Requests im Repository den letzten Zustand des Benutzers bei. Wenn die neue Einstellung deaktiviert ist, ist Verknüpfte Arbeitselemente nach dem Mergen abschließen standardmäßig für alle Pull Requests im Repository deaktiviert. Benutzer können immer noch verknüpfte Arbeitselemente beim Abschließen von PRs verändern, aber dafür müssen sie sich aktiv entscheiden.

Erweiterbarkeit des Status von Pull Requests

Das Verwenden von Branchrichtlinien ist eine gute Möglichkeit, um die Qualität Ihres Codes zu verbessern. Diese Richtlinien sind jedoch begrenzt auf die Integrationen, die nativ von TFS bereitgestellt werden. Durch das Verwenden der neuen Status-API für Pull Requests und der entsprechenden Branchrichtlinie können Dienste von Drittanbietern genauso am Pull Request-Workflow teilnehmen wie native TFS-Features.

Wenn ein Dienst einen Pull Request in der Status-API veröffentlicht, erscheint dieser sofort in der Ansicht PR details (PR-Details) im neuen Abschnitt Status. Der Abschnitt „Status“ zeigt die Beschreibung an und erstellt einen Link zu der URL, die vom Dienst bereitgestellt wurde. Statuseinträge unterstützen ebenfalls ein Aktionsmenü (...), das erweiterbar ist, um neue Aktionen durch Weberweiterungen hinzuzufügen.

Der Status allein blockiert den Abschluss eines Pull Requests nicht. Hier kommt die Richtlinie ins Spiel. Sobald der PR-Status veröffentlicht wurde, kann eine Richtlinie konfiguriert werden. Es ist eine neue Branchrichtlinie verfügbar, um Genehmigung von externen Diensten anzufordern. Klicken Sie auf +Add service (+ Dienst hinzufügen), um den Vorgang zu starten.

Klicken Sie im Dialogfeld auf den Dienst in der Liste, der den Status veröffentlicht, und wählen Sie die gewünschten Richtlinienoptionen aus.

Sobald die Richtlinie aktiv ist, wird der Status im Abschnitt Policies (Richtlinien) und gegebenenfalls unter Required (Erforderlich) oder Optional angezeigt und der Abschluss des PR wird gegebenenfalls erzwungen.

Weitere Informationen zur Status-API und Möglichkeiten, diese selbst zu testen, finden Sie in der documentation (Dokumentation und in den samples (Beispielen).

Mergeereignisse für Pull Request-Service Hooks

Erweiterungen, in denen Pull Request-Service Hooks eingesetzt werden, verfügen nun über weitere Details und Filteroptionen für Mergeereignisse. Jedes Mal, wenn ein Merge durchgeführt wird, wird das Ereignis unabhängig davon ausgelöst, ob der Merge erfolgreich war oder nicht. Wenn bei einem Mergeversuch ein Fehler auftritt, werden Angaben zu den Gründen des Fehlers gemacht.

Verbesserte Fehlermeldungen für Arbeitselemente, die mit einem PR abgeschlossen werden

Wenn Sie Arbeitselemente mit einem Pull Request abschließen möchten, kann es sein, dass die verknüpften Arbeitselemente nicht abgeschlossen werden können. Es kann z.B. sein, dass ein Feld erforderlich ist, für das der Benutzer eine Eingabe vornehmen muss, bevor der Zustand gewechselt werden kann. Wir haben den Prozess verbessert, mit dem Sie darüber informiert werden, dass das Abschließen eines Arbeitselements blockiert wird, sodass Sie sofort reagieren und Änderungen vornehmen können.

Erwähnen eines Pull Requests

Sie können jetzt einen Pull Request in den PR-Kommentaren und Arbeitselementdiskussionen erwähnen. Das Erwähnen eines PR ist so ähnlich wie das Erwähnen eines Arbeitselements. Allerdings wird ein Ausrufezeichen ! statt eines Hashzeichens # verwendet.

Wenn Sie einen Pull Request erwähnen möchten, geben Sie ein ! ein. Dann können Sie einen Pull Request interaktiv aus der Liste Ihrer zuletzt bearbeiteten Pull Requests auswählen. Geben Sie Schlüsselwörter ein, um die Liste der Vorschläge zu filtern, oder geben Sie die ID des Pull Requests ein, den Sie erwähnen möchten. Wenn ein Pull Request erwähnt wurde, wird er in der gleichen Zeile mit der ID und dem vollständigen Titel gerendert. Außerdem wird ein Link zur Detailseite des Pull Requests erzeugt.

Pull Request-Bezeichnungen für Reviewer

Manchmal ist es wichtig, den Reviewern zusätzliche Angaben zu einem Pull Request zu übermitteln. Möglicherweise befindet der PR sich noch in der Bearbeitung, oder er ist ein Hotfix für ein kommendes Release, weshalb Sie zusätzliche Informationen im Titel anfügen, z.B. ein vorangestelltes „[WIP]“ (Work in Progress, Noch in Bearbeitung) oder ein hinten angestelltes „DO NOT MERGE“ (Nicht mergen). Mit Bezeichnungen können Sie jetzt PRs mit weiteren Informationen versehen, die für wichtige Angaben und zum Organisieren von PRs verwendet werden können.

Pull Request-Kommentare folgen benannten Dateien

Manchmal werden Dateien umbenannt oder verschoben, während ein PR aktiv ist. Wenn diese umbenannten Dateien kommentiert wurden, zeigte die neueste Ansicht des Codes früher die Kommentare nicht an. Wir haben das Nachverfolgen von Kommentaren verbessert, um auch umbenannte Dateien nachverfolgen zu können, sodass Kommentare in den neuesten Versionen der umbenannten oder verschobenen Dateien angezeigt werden.

Anzeigen des Pull Request-Mergecommits

PR-Vergleichsansichten heben Änderungen am Quellbranch hervor. Wenn jedoch der Zielbranch geändert wird, kann es sein, dass die Vergleichsansicht anders als erwartet aussieht. Jetzt ist ein neuer Befehl verfügbar, um die Unterschiede des „Vorschau“-Mergecommits des Pull Requests anzuzeigen: Mergecommit anzeigen. Dieser Mergecommit wird erstellt, um auf Mergekonflikte zu prüfen und um mit einem PR-Build verwendet zu werden. Er zeigt, wie der Mergecommit aussehen wird, wenn der PR abgeschlossen wird. Wenn die Vergleichsansicht einige Änderungen des Zielbranchs nicht widerspiegelt, kann die Mergecommitvergleichsansicht nützlich sein, um die letzten Änderungen im Quell- und Zielbranch anzuzeigen.

Ein weiterer praktischer Befehl neben Mergecommit anzeigen ist der Befehl Mergevorgang erneut starten (der im gleichen Befehlsmenü zur Verfügung steht). Wenn sich der Zielbranch seit der ersten Erstellung des Pull Requests geändert hat, wird durch das Ausführen dieses Befehls ein neuer Vorschaumergecommit erstellt, sodass die Vergleichsansicht des Mergecommits aktualisiert wird.

Zuletzt eingesetzte Reviewer

Wenn Sie Ihren Code häufig von den gleichen Reviewern prüfen lassen, können Sie nun noch leichter Reviewer hinzufügen. Wenn Sie Ihrem PR Reviewer hinzufügen, wird automatisch eine Liste der zuletzt eingesetzten Reviewer angezeigt, wenn Sie das Feld zum Festlegen eines Reviewers auswählen. Sie müssen nicht mehr nach einem Namen suchen. Wählen Sie diese wie gewohnt aus.

Anzeigen der ausstehenden Richtlinienkriterien für das automatische Vervollständigen von Pull Requests

Die automatische Vervollständigung ist ein praktisches Feature für Teams mit Branchrichtlinien. Wenn aber optionale Richtlinien verwendet werden, kann möglicherweise schwer festgestellt werden, was das Abschließen eines Pull Requests verhindert. Wenn Sie die automatische Vervollständigung für alle PRs festlegen, wird im Aufruffeld eine genaue Liste der Richtlinienkriterien angezeigt, die das Abschließen verhindern. Sobald Anforderungen erfüllt werden, werden die entsprechenden Elemente aus der Liste entfernt, bis es keine ausstehenden Anforderungen mehr gibt, und der PR wird zusammengeführt.

Besprechen von Berechnungen in Pull Requests

Müssen Sie eine Gleichung oder einen mathematischen Ausdruck in Ihren PR-Kommentar einfügen? Sie können jetzt in den Kommentaren KaTeX-Funktionen einfügen und das sowohl bei Inline- als auch bei Blockkommentaren. Weitere Informationen finden Sie in der Liste der unterstützten Funktionen.

Pull Request-Vorschläge für Forks

Immer wenn ein Topic-Branch in einem Repository aktualisiert wird, wird ein „Vorschlag“ zum Erstellen eines neuen Pull Requests für den Topic-Branch angezeigt. Das kann zum Erstellen neuer Pull Requests sehr praktisch sein. Diese Funktion wurde auch für verzweigte Repositorys aktiviert. Wenn Sie einen Branch in einem Fork aktualisieren, sehen Sie den Vorschlag zum Erstellen eines neuen Pull Requests, wenn Sie das nächste Mal den Hub Code für den Fork oder das Upstreamrepository besuchen. Wenn Sie „Pull Request erstellen“ auswählen, werden Sie zum Erstellungsprozess eines Pull Requests weitergeleitet. Dabei sind die Quell- und Zielbranches und -repositorys vorausgewählt.

Pfadfilter für PR-Richtlinien

Häufig enthält ein einziges Repository Code, der durch mehrere Continuous Integration-Pipelines (CI) erstellt wurde, um den Build zu überprüfen und Tests auszuführen. Die integrierte Buildrichtlinie unterstützt jetzt eine Option zum Filtern von Pfaden, mit der mehrere PR-Builds leicht konfiguriert werden können, die für jeden PR angefordert und ausgelöst werden können. Geben Sie einen Pfad an, der für jeden Build erforderlich ist, und legen Sie die Optionen zum Auslösen und Erfordern wie gewünscht fest.

Zusätzlich zu den Buildrichtlinien stehen die Pfadfilteroptionen auch für Statusrichtlinien zur Verfügung. Dadurch können benutzerdefinierte Richtlinien oder Drittanbieterrichtlinien bestimmte Pfade für das Erzwingen von Richtlinien konfigurieren.

Arbeit

Tastenkombinationen im Arbeitselementformular

Weisen Sie sich selbst ein Arbeitselement zu (ALT+I), wechseln Sie zur Diskussion (STRG+ALT+D), und kopieren Sie einen Quicklink zum Arbeitselement mit der Tastenkombinationen (UMSCHALT+ALT+C). Geben Sie zur Anzeige der vollständigen Liste der neuen Verknüpfungen „?“ ein, wobei ein Arbeitselementformular geöffnet sein muss, oder nutzen Sie die folgende Tabelle.

Modernisierte Spaltenoptionen

Das Dialogfeld Spaltenoptionen, über das die Spalten des Arbeitselementrasters in den Hubs Backlog, Anfragen und Test konfiguriert werden, verfügt jetzt über ein neues Bereichsdesign. Führen Sie eine Suche durch, um ein Feld zu finden, und ziehen die Spalten an die von Ihnen gewünschten Stellen, oder entfernen Sie nicht länger benötigte Spalten.

Informationen zur letzten Ausführung einer Abfrage

Wenn die Struktur freigegebener Abfragen Ihres Projekts wächst, kann es schwierig sein, zu bestimmen, ob eine Abfrage nicht mehr verwendet wird und gelöscht werden kann. Um Ihnen das Verwalten Ihrer freigegebenen Abfragen zu erleichtern, haben wir zwei neue Metadaten zu den Abfrage-REST-APIs hinzugefügt: „Last executed by“ (Zuletzt ausgeführt von) und „Last executed date“ (Zuletzt ausgeführt am). So können Sie Bereinigungsskripts schreiben, die veraltete Abfragen löschen.

HTML-Tags aus Arbeitselementrastern entfernt

Als Reaktion auf Kundenfeedback haben wir das Verhalten von Textfeldern mit mehreren Zeilen in der Ergebnisansicht der Arbeitselementabfragen in der Web-, Excel- und Visual Studio-IDE aktualisiert und die HTML-Formatierung entfernt. Wenn diese einer Abfrage als Spalte hinzugefügt werden, werden Textfelder mit mehreren Zeilen jetzt als Nur-Text angezeigt. Hier sehen Sie ein Beispiel für ein Feature mit HTML in der Beschreibung:

In der Vergangenheit hätten Abfrageergebnisse etwas wie das Folgende gerendert: <div><b><u>Customer Value</u>....

Unterstützung für den Abfrageoperator NOT IN hinzugefügt

Felder, die den Abfrageoperator IN unterstützen, unterstützen jetzt auch NOT IN. Sie können Abfragen für Arbeitselemente schreiben, die sich „Nicht in“ in einer Liste von IDs, „Nicht in“ einer Liste von Zuständen befinden und so weiter, und das alles, ohne viele OR-Klauseln erstellen zu müssen.

Abfragen für @MyRecentActivity und @RecentMentions

Wir haben zwei neue Abfragemakros für das ID-Feld hinzugefügt, sodass Sie für Sie relevante Arbeitselemente finden können. Sie können sich mit @RecentMentions ansehen, in welchen Arbeitselementen Sie in den letzten 30 Tagen erwähnt wurden, und mit @MyRecentActivity, welche Arbeitselemente Sie zuletzt angesehen oder bearbeitet haben.

Benutzerdefinierte Felder und Tagsfilter in Benachrichtigungen zum Nachverfolgen von Arbeitselementen

Sie können jetzt Benachrichtigungen mit Bedingungen in benutzerdefinierten Feldern und Tags nicht nur dann festlegen, wenn diese sich ändern, sondern auch, wenn bestimmte Werte festgestellt werden. So konnten die Benachrichtigungen für Arbeitselemente optimiert werden.

Unterstützung von „Mentioned“ (Erwähnungen) unter „Eigene Arbeitselemente“

Wir haben die neue Navigationssteuerung Mentioned (Erwähnungen) auf der Seite Eigene Arbeitselemente hinzugefügt. In diesem Reiter können Sie sich ansehen, in welchen Arbeitselementen Sie in den letzten 30 Tagen erwähnt wurden. Durch diese neue Ansicht können Sie schnell auf Elemente reagieren, die Ihr Eingreifen erfordern, und bei relevanten Unterhaltungen auf dem Laufenden bleiben.

Dieser Reiter steht auch für mobilen Zugriff zur Verfügung, sodass die mobile Version und die Desktopversion einheitlich sind.

Filtern von Plänen

Die Erweiterung Lieferpläne verwendet nun unsere allgemeine Filterkomponente und ist mit unseren Rasterfilteroberflächen für Arbeitselemente und Boards konsistent. Dieses Filtersteuerelement bringt eine verbesserte Benutzerfreundlichkeit und eine konsistente Oberfläche für alle Teammitglieder mit sich.

Aktualisierte Navigation durch Pläne

Für viele Benutzer sind nur einige wenige Pläne besonders relevant, weshalb sie die Favoriten für einen schnellen Zugriff verwenden. Zunächst haben wir den Hub Pläne aktualisiert, sodass er nun zu den zuletzt besuchten Plänen navigiert und nicht zur Verzeichnisseite. Wenn Sie sich dort befinden, können Sie die Favoritenauswahl verwenden, um schnell zu einem anderen Plan zu wechseln, oder verwenden Sie die Breadcrumb-Leiste, um zurück zur Verzeichnisseite zu navigieren.

Erweitern/Reduzieren von Elementen auf dem Task Board

Sie können jetzt alle Elemente auf dem Sprint-Task Board mit einem einzigen Klick erweitern oder reduzieren.

Erteilen der Berechtigung zum Umgehen von Regeln für bestimmte Benutzer

Beim Migrieren von Arbeitselementen aus einer anderen Quelle möchten Organisationen oft die ursprünglichen Eigenschaften des Arbeitselements beibehalten. Sie können z.B. einen Fehler erstellen, um das Datum der ursprünglichen Erstellung und den ursprünglichen Ersteller beizubehalten.

Die API zum Aktualisieren eines Arbeitselements verfügt über ein Flag zum Umgehen einer Regel, um dieses Szenario zu ermöglichen. Bisher musste die Identität, von der die API-Anforderung stammt, ein Mitglied der Gruppe „Projektauflistungsadministratoren“ sein. Es wurde eine Berechtigung auf Projektebene zum Ausführen der API mit dem Flag zum Umgehen dieser Regel hinzugefügt.

Build and Release

XAML-Builds

Mit TFS 2015 haben wir ein webbasiertes, plattformübergreifendes Buildsystem eingeführt. XAML-Builds werden in TFS 2018 RTW oder Update 1 nicht unterstützt. Wir haben XAML-Builds in TFS 2018 Update 2 jedoch erneut aktiviert. Wir empfehlen Ihnen, migrate your XAML builds (Ihre XAML-Builds zu migrieren).

Wenn Sie ein Upgrade auf TFS 2018 Update 2 durchführen:

• Wenn sich noch irgendwelche XAML-Builddaten in Ihrer Teamprojektsammlung befinden, wird Ihnen die Warnung angezeigt, dass die XAML-Buildfeatures veraltet sind.

• Sie müssen VS 2017 oder Team Explorer 2017 verwenden, um XAML-Builddefinitionen zu bearbeiten oder um neue XAML-Builds in die Warteschlange aufzunehmen.

• Wenn Sie neue XAML-Build-Agents erstellen müssen, müssen Sie diese mithilfe des TFS 2015-Build-Agent-Installers installieren.

Eine Erläuterung unseres Plans, wie XAML-Builds veralten, finden Sie im Blogbeitrag Evolving TFS/Team Services build automation capabilities.

Verbesserungen von Builds mit mehreren Phasen

Es ist bereits seit Längerem möglich, Phasen zum Organisieren der Schritte zum Erstellen und zum Ausrichten auf unterschiedliche Agents mithilfe verschiedener Anforderungen für jede Phase zu verwenden. Wir haben mehrere Funktionen zum Erstellen von Phasen hinzugefügt. Sie können nun folgende Aktionen durchführen:

• Eine andere Agent-Warteschlange für jede Phase angeben. Das bedeutet, dass Sie z.B. Folgendes tun können:

  • Eine Phase eines Builds auf einem macOS-Agent und eine andere Phase auf einem Windows-Agent ausführen. Ein gutes Beispiel dafür, wie nützlich diese Aktion sein kann, finden Sie in diesem Connect(); 2017-Video: CI/CD DevOps Pipeline for mobile apps and services (CI/CD DevOps-Pipeline für mobile Apps und Dienste).
  • Buildschritte in einem Build-Agent-Pool und Testschritte in einem Test-Agent-Pool ausführen

• Tests schneller ausführen, indem Sie sie gleichzeitig ausführen. Jede Phase, für die die Parallelität als „Multi-Agent“ konfiguriert ist und die einen „VSTest“-Task enthält, parallelisiert nun automatisch die Testausführung für die konfigurierte Anzahl von Agents.

• Skripts erlauben oder verweigern, um in jeder Phase auf das OAuth-Token zuzugreifen. Das bedeutet, dass Sie z.B. erlauben können, dass Skripts, die in Ihrer Erstellungsphase ausgeführt werden, mit VSTS über REST-APIs kommunizieren. Sie können in derselben Builddefinition auch die Skripts blockieren, die in Ihrer Testphase ausgeführt werden.

• Phasen nur unter bestimmten Bedingungen ausführen. Sie können beispielsweise eine Phase konfigurieren, die nur ausgeführt wird, wenn vorherige Phasen erfolgreich ausgeführt wurden, oder nur, wenn Sie Code im Mainbranch kompilieren.

Weitere Informationen finden Sie unter Phases in Build and Release Management (Phasen in der Build- und Releaseverwaltung).

Überspringen von geplanten Builds, wenn sich im Repository nichts geändert hat

Es wurde häufig angefragt, angeben zu können, dass ein geplanter Build nicht ausgeführt werden soll, wenn keine Änderungen am Code vorgenommen wurden. Das ist jetzt möglich. Sie können dieses Verhalten nun mithilfe einer Option auf dem Zeitplan steuern. Standardmäßig planen wir keinen neuen Build, wenn Ihr letzter geplanter Build (aus demselben Zeitplan) erfolgreich war und keine weiteren Änderungen in Ihrem Repository eingecheckt wurden.

Erstellen mit Continuous Integration von GitHub Enterprise

Sie verfügen nun über eine verbesserte Integration zum Ausführen von Continuous Integration-Builds, wenn Sie GitHub Enterprise für die Versionskontrolle verwenden. Zuvor konnten Sie Codeänderungen nur mithilfe des externen Git-Connectors abrufen. Dies konnte zu einer Erhöhung der Serverlast und zu Verzögerungen vor dem Auslösen eines Builds führen. Mit dem offiziellen Support von GitHub Enterprise werden jetzt CI-Teambuilds sofort ausgelöst. Zusätzlich dazu kann die Verbindung mithilfe unterschiedlicher Authentifizierungsmethoden wie LDAP oder integrierten Konten konfiguriert werden.

Sichere Dateien können während des Builds oder des Releases für Agents heruntergeladen werden.

Der neue Task Download Secure File (Sichere Datei herunterladen) unterstützt das Herunterladen (auf Agent-Computer) von verschlüsselten Dateien aus der Bibliothek VSTS Secure Files (Sichere VSTS-Dateien). Sobald die Datei heruntergeladen wurde, wird sie entschlüsselt und auf dem Datenträger des Agents gespeichert. Wenn der Build bzw. der Release abgeschlossen ist, wird die Datei vom Datenträger des Agents gelöscht. Dadurch kann Ihr Build oder Ihr Release vertrauliche Dateien wie Zertifikate oder private Schlüssel verwenden, die andernfalls in VSTS sicher verschlüsselt und gespeichert werden. Weitere Informationen finden Sie in der Dokumentation zu sicheren Dateien.

Installation von Apple-Bereitstellungsprofilen aus Quellrepositorys

Der Task Apple-Bereitstellungsprofil installieren unterstützt bereits das Installieren von Bereitstellungsprofilen (auf Agent-Computern), die in der Bibliothek VSTS Secure Files gespeichert sind. Bereitstellungsprofile werden von Xcode zum Signieren und Packen von Apple-Apps für iOS, macOS, tvOS und watchOS verwendet. Jetzt können Bereitstellungsprofile aus Quellrepositorys installiert werden. Das Verwenden der Secure Files-Bibliothek wird zwar bereits für eine erhöhte Sicherheit dieser Dateien empfohlen, aber diese Verbesserung geht auf Bereitstellungsprofile ein, die bereits in der Quellcodeverwaltung gespeichert wurden.

Rückverfolgen von GitHub-Quellen auf Builds mithilfe von Buildtags

Builds von GitHub oder GitHub Enterprise sind bereits mit dem relevanten Commit verknüpft. Es ist jedoch genauso wichtig, einen Commit auf den Build zurückführen zu können, der ihn erstellt hat. Dies ist nun durch das Aktivieren von Quelltagging in TFS möglich. Wählen Sie bei der Auswahl eines GitHub-Repositorys in einer Builddefinition den Typ des Builds aus, den Sie markieren möchten, und das Tagformat.

Dann werden in Ihrem GitHub- oder GitHub Enterprise-Repository Buildtags angezeigt.

Sie können während Builds und Releases bestimmte Java Development Kits (JDKs) installieren.

Es ist möglich, dass zum Erstellen gewisser Java-Projekte bestimmte JDKs erforderlich sind, die nicht auf Agent-Computern verfügbar sind. Es kann sein, dass Projekte z.B. ältere oder andere Versionen von IBM, Oracle oder Open-Source-JDKs erfordern. Der Task Installer des Java-Tools lädt das für Ihr Projekt erforderliche JDK während eines Builds oder Releases herunter und installiert dieses. Die Umgebungsvariable JAVA_HOME wird entsprechend der Dauer des Builds oder Releases festgelegt. Für den Installer des Java-Tools können bestimmte JDKs mithilfe einer Dateifreigabe, eines Quellcoderepositorys oder mithilfe von Azure Blob Storage verfügbar gemacht werden.

Verbesserte Xcode-Buildkonfiguration

Der Xcode-Task wurde auf eine neue Hauptversion (4.*) aktualisiert. Dadurch wurde die Konfiguration des Erstellens, Testens und Packens von Xcode verbessert. Wenn Ihr Xcode-Projekt über ein einziges, freigegebenes Schema verfügt, wird es automatisch verwendet. Es wurde zusätzliche Inlinehilfe hinzugefügt. Veraltete Features wie das Xcrun-Packen wurden aus den Eigenschaften des Xcode-Tasks entfernt. Vorhandene Build- und Releasedefinitionen müssen angepasst werden, um die aktuelle 4.*-Version des Xcode-Tasks verwenden zu können. Wenn Sie für neue Definitionen die veralteten Funktionen einer vorherigen Version des Xcode-Tasks benötigen, können Sie diese Version in Ihrer Definition auswählen.

Releasegates

Die ständige Überwachung ist ein wesentlicher Teil von DevOps-Pipelines. Nach der Bereitstellung sicherzustellen, dass die App im Release fehlerfrei funktioniert, ist genauso wichtig wie der Erfolg der Bereitstellung selbst. Unternehmen setzen unterschiedliche Tools zum automatischen Erkennen der App-Integrität in der Produktion und zum Erfassen von von Kunden gemeldeten Problemen ein. Bis jetzt mussten Genehmiger die Integrität einer App manuell auf allen Systemen überprüfen, bevor das Release höher gestuft werden konnte. Die Releaseverwaltung unterstützt jetzt die Integration ständiger Überwachung in die Releasepipeline. Verwenden Sie diese Funktion, um sicherzustellen, dass das System alle Integritätssignale der App wiederholt abfragt, bis alle fehlerfrei sind. Erst dann sollte mit dem Release fortgefahren werden.

Beginnen Sie in der Releasedefinition mit der Definition von Gates für vor und nach der Bereitstellung. Jedes Gate kann mindestens ein Integritätssignal überwachen, das mit einem Überwachungssystem der App verknüpft ist. Integrierte Gates stehen für „Azure-Überwachungswarnungen (Application Insight)“ und „Arbeitselemente“ zur Verfügung. Sie können durch die Flexibilität von Azure Functions eine Integration mit anderen Systemen durchführen.

Zur Laufzeit entnimmt das Release Stichproben und erfasst Integritätssignale aller Gates. Das Sampling wird nach jedem Intervall erneut durchgeführt, bis die Signale aller Gates im gleichen Intervall fehlerfrei sind.

Erste Stichproben der Überwachungssysteme sind möglicherweise nicht genau, da zur neuen Bereitstellung noch nicht genügend Informationen vorliegen. Die Option „Verzögerung vor der Auswertung“ stellt sicher, dass das Release während dieser Phase nicht fortfährt, auch wenn alle Stichproben fehlerfrei sind.

Während des Samplings von Gates werden weder Agents noch Pipelines verwendet. Weitere Informationen finden Sie in der Dokumentation zu Releasegates.

Selektive Bereitstellung auf Grundlage des Artefakts, das ein Release auslöst

Mehrere Artefaktquellen können einer Releasedefinition hinzugefügt und so konfiguriert werden, dass Sie ein Release auslösen. Ein neues Release wird erstellt, wenn ein neuer Build für eine der Quellen verfügbar ist. Der Bereitstellungsprozess wird unabhängig von der auslösenden Quelle immer gleich durchgeführt. Sie können den Bereitstellungsprozess jetzt auf Grundlage der auslösenden Quelle anpassen. Für automatisch ausgelöste Releases wird die Releasevariable Release.TriggeringArtifact.Alias jetzt aufgefüllt, um die Artefaktquelle anzugeben, die das Release ausgelöst hat. Dies kann bei Taskbedingungen, Phasenbedingungen und Taskparametern verwendet werden, um den Prozess dynamisch anzupassen. Diese Funktion kann praktisch sein, wenn Sie Artefakte, die sich je nach Umgebung unterscheiden, bereitstellen müssen.

Verwalten entitätsspezifischer Sicherheit

Vor diesem Update wurden die Sicherheitszugriffsrollen bei der rollenbasierten Sicherheit für Benutzer oder Gruppen auf Hubebene für Bereitstellungsgruppen, Variablengruppen, Agent-Warteschlangen oder Dienstendpunkte festgelegt. Jetzt können Sie die Vererbung für eine bestimme Entität aktivieren oder deaktivieren, sodass die Sicherheit genau Ihren Wünschen entspricht.

Genehmigen mehrerer Umgebungen

Das Verwalten der Genehmigungen für Releases wurde vereinfacht. Bei Pipelines, deren parallel bereitgestellte Umgebungen von derselben Person genehmigt werden müssen, muss die genehmigende Person auf jede Genehmigung einzeln reagieren. Mit diesem Feature können Sie nun mehrere ausstehende Genehmigungen gleichzeitig abschließen.

Erweiterbarkeit von Releasevorlagen

Mit Releasevorlagen können Sie eine Baseline erstellen, die Ihnen den Einstieg in das Definieren des Releaseprozesses erleichtert. Davor konnten Sie neue Vorlagen in Ihr Konto hochladen. Jetzt können Autoren Releasevorlagen auch in Ihre Erweiterungen einbeziehen. Ein Beispiel dafür finden Sie im GitHub-Repository.

Bedingt Releasetasks und -phasen

Ähnlich wie bedingte Buildtasks können Sie jetzt auch einen Task oder eine Phase nur dann ausführen, wenn bestimmte Bedingungen erfüllt werden. Dies hilft Ihnen beim Entwerfen von Rollbackszenarios.

Wenn die integrierten Bedingungen Ihre Bedürfnisse nicht erfüllen, oder wenn Sie präzisere Steuerungsmöglichkeiten über den Zeitpunkt der Ausführung des Tasks oder der Phase benötigen, können Sie benutzerdefinierte Bedingungen definieren. Geben Sie die Bedingungen als geschachtelte Funktionen an. Der Agent beginnt bei der Auswertung mit der innersten Funktion und arbeitet sich dann nach außen vor. Das Endergebnis ist ein Boolescher Wert, der bestimmt, ob der Task ausgeführt werden soll.

Anforderungsverlauf für Dienstendpunkte

Dienstendpunkte ermöglichen die Verbindung mit externen und Remotediensten zum Ausführen von Tasks für einen Build oder eine Bereitstellung. Die Endpunkte werden im Projektumfang konfiguriert und für mehrere Build- und Releasedefinitionen freigegeben. Besitzer von Dienstendpunkten können jetzt eine konsolidierte Ansicht von Builds und Bereitstellungen mit einem Endpunkt abrufen, sodass die Überwachung und Governance verbessert werden kann.

Standardeigenschaften für Git- und GitHub-Artefakttypen können jetzt bearbeitet werden

Sie können jetzt die Standardeinstellungen von Git- und GitHub-Artefakttypen auch nach der Verknüpfung des Artefakts bearbeiten. Das ist besonders praktisch in Szenarios, in denen der Branch der stabilen Version des Artefakts geändert wurde und dieser Branch in kommenden Continuous Delivery-Releases verwendet werden soll, um neuere Versionen des Artefakts abzurufen.

Manuelle Massenbereitstellung von Umgebungen über die Releaseansicht

Sie können jetzt einen Bereitstellungsvorgang in mehreren Umgebungen eines Releases gleichzeitig manuell auslösen. So können Sie mehrere Umgebungen in einem Release auswählen, bei denen Konfigurationen oder Bereitstellungen fehlgeschlagen sind, und die erneute Bereitstellung in allen Umgebungen gleichzeitig durchführen.

Jenkins-Unterstützung für Pipelines mit mehreren Branches und Verknüpfen von Aufgaben, die in Ordnern organisiert sind

Jetzt können Sie Jenkins-Projekte noch besser einsetzen.

Sie können jetzt Jenkins-Pipelineprojekte mit mehreren Branches als Artefaktquellen in Releasedefinitionen verwenden.

Darüber hinaus können Jenkins-Projekte jetzt verwendet werden, wenn Sie auf Ordnerebene organisiert sind (in der Vergangenheit konnten Sie Jenkins-Projekte nur vom Stammordner eines Jenkins-Servers aus als Artefakte verknüpfen). Die Liste der Jenkins-Projekte wird neben den Ordnerpfaden in der Liste der Quellen angezeigt, aus der Sie das Projekt auswählen, dass als Artefaktquelle fungieren soll.

Docker Hub oder Azure Container Registry als Artefaktquelle

Durch dieses Feature können Releases Images verwenden, die in einer Docker Hub-Registrierung oder in Azure Container Registry (ACR) gespeichert sind. Dies ist der erste Schritt auf dem Weg zur Unterstützung von Szenarios wie dem Rollout von Änderungen nach Region mithilfe von Georeplikationsfeatures von ACR oder das Bereitstellen in einer Umgebung (z.B. einer Produktionsumgebung) von einer Containerregistrierung aus, die nur Images für die Produktionsumgebung enthält.

Sie können jetzt Docker Hub oder ACR als Artefakte über + Hinzufügen unter „Artefakte“ in einer Releasedefinition hinzufügen. Aktuell muss das Release noch manuell oder von einem anderen Artefakt ausgelöst werden. Wir arbeiten im Moment an einem Trigger, der auf einem Push eines neuen Images an die Registrierung basiert.

Standardartefaktversionen

Es gibt jetzt mehrere Standardversionsoptionen beim Verknüpfen eines Versionskontrollartefakts mit einer Releasedefinition. Sie können einen bestimmten Commit oder ein bestimmtes Changeset konfigurieren oder festlegen, dass die aktuelle Version aus dem Standardbranch ausgewählt wird. Normalerweise legen Sie fest, dass die aktuelle Version ausgewählt wird, aber diese Funktion ist besonders in Umgebungen praktisch, in denen eine goldene Artefaktversion für alle kommenden Continuous Deployments angegeben werden muss.

Verbesserungen bei Releasetriggerbranches

Sie können jetzt einen Releasetriggerfilter auf Grundlage des Standardbranchs in der Builddefinition konfigurieren. Dies ist besonders praktisch, wenn Ihr Standardbuildbranch sich mit jedem Sprint ändert und die Releasetriggerfilter für alle Releasedefinitionen aktualisiert werden müssen. Jetzt müssen Sie nur noch den Standardbranch einer Builddefinition ändern, und dann verwenden alle Releasedefinitionen automatisch diesen Branch. Wenn Ihr Team z.B. Releasebranches für jede Sprintreleasenutzlast erstellt, können Sie diese in der Builddefinition aktualisieren, sodass sie auf einen neuen Sprintreleasebranch zeigt. Das Release übernimmt diese anschließend automatisch.

Releasetrigger für ein Paketverwaltungsartefakt

Sie können jetzt einen Trigger in dem Artefakt Paketverwaltung in der Releasedefinition festlegen, sodass ein neues Release automatisch erstellt wird, wenn eine neue Version des Pakets veröffentlicht wurde. Weitere Informationen finden Sie in der Dokumentation zu Triggern in der Releaseverwaltung.

Festlegen einer Variablengruppe für bestimmte Bereiche

Vor diesem Update waren die Variablen, die eine Variablengruppe zum Zeitpunkt des Hinzufügens zu einer Releasedefinition enthalten hat, für alle Umgebungen im Release verfügbar. Sie verfügen jetzt über die nötige Flexibilität, um Variablengruppen stattdessen auf bestimmte Umgebungen auszurichten. Dadurch stehen sie ausschließlich einer Umgebung des jeweiligen Releases zur Verfügung. Dies ist besonders bei externen Diensten wie z.B. einem SMTP-E-Mail-Dienst nützlich, die sich von Umgebung zu Umgebung unterscheiden.

Automatische Veröffentlichung über Azure Container Registry oder Docker Hub

Beim Bereitstellen von containerisierten Apps wird das Containerimage zunächst per Push an eine Containerregistrierung übermittelt. Danach kann das Containerimage in einer Web-App für Container oder in einem Kubernetes-Cluster bereitgestellt werden. Sie können jetzt das automatische Erstellen von Releases bei Updates des in Docker Hub oder Azure Container Registry gespeicherten Images aktivieren, indem Sie diese als Artefaktquelle hinzufügen.

Angeben einer Standardversion von Jenkins-Artefakten

Wenn ein Release mit mehreren Artefakten automatisch ausgelöst wird, werden die in der Releasedefinition gespeicherten Standardversionen für alle Artefakte verwendet. Vor diesem Update hatten Jenkins-Artefakte keine Einstellung für die Standardversion, sodass Sie auch keinen Continuous Deployment-Trigger für ein Release mit Jenkins als sekundärem Artefakt festlegen konnten.

Jetzt können Sie eine Standardversion für Jenkins-Artefakte mit Ihnen bereits bekannten Optionen erstellen:

• Latest
• Zum Zeitpunkt der Releaseerstellung angeben
• Bestimmte Version

Beisteuern von Releasegates von Erweiterungen aus

Releasegates ermöglichen das Hinzufügen von informationsgesteuerten Genehmigungen zu Releasepipelines. Vor oder nach der Bereitstellung werden mehrere Integritätssignale erfasst, um zu bestimmen, ob das Release auf die nächste Ebene höher gestuft werden soll. Es werden mehrere integrierte Gates zur Verfügung gestellt. Bis jetzt wurde „Invoke Azure function“ (Azure-Funktion aufrufen) als Integrationsmöglichkeit mit anderen Diensten empfohlen. Jetzt ist es noch einfacher, andere Dienste zu integrieren und Gates über die Marketplace-Erweiterung hinzuzufügen. Sie können jetzt benutzerdefinierte Gatetasks beisteuern und Releasedefinitionsautoren einen verbesserten Prozess zur Gatekonfiguration bieten.

Weitere Informationen finden Sie im Artikel zum Erstellen von Gatetasks.

Skalierbare Bereitstellungen für virtuelle Computer mit Bereitstellungsgruppen

Bereitstellungsgruppen, die robuste und sofort verfügbare Bereitstellung auf mehreren Computern bieten, sind jetzt allgemein verfügbar. Mit Bereitstellungsgruppen können Sie Bereitstellungen auf mehreren Servern orchestrieren und gleitende Updates durchführen, während Sie die Hochverfügbarkeit Ihrer Anwendung gewährleisten. Sie können auch lokal auf Servern oder virtuellen Computern in Azure oder einer beliebigen Cloud bereitstellen und verfügen zusätzlich über End-to-End-Rückverfolgbarkeit bereitgestellter Artefaktversionen auf Serverebene.

Die agentbasierte Bereitstellungsfunktion basiert auf denselben Build- und Bereitstellungs-Agenten, die bereits verfügbar sind. Sie können den vollständigen Aufgabenkatalog auf Ihren Zielcomputern in der Bereitstellungsgruppenphase verwenden. Aus Sicht der Erweiterbarkeit können Sie auch die REST-APIs für Bereitstellungsgruppen und Ziele für den programmgesteuerten Zugriff verwenden.

Paket

Nahtloses Verwenden öffentlicher Pakete mit Upstreamquellen

Jetzt sind Upstreamquellen für nuget.org und npmjs.com verfügbar. Dadurch können Sie u.a. Pakete aus Upstreamquellen verwalten, als veraltet markieren, löschen, ihre Veröffentlichung zurückziehen und ihre Auflistung aufheben sowie jedes von Ihnen verwendete Upstreampaket speichern.

Beibehaltungsrichtlinien in TFS-Feeds

Bis jetzt gab es in TFS-Paketfeeds keine Möglichkeit, ältere, nicht verwendete Paketversionen zu bereinigen. Für Benutzer, die häufig Pakete veröffentlichen, konnte dies zu langsameren Feedabfragen im NuGet-Paket-Manager und in anderen Clients führen, bis einige Versionen manuell gelöscht wurden.

Wir haben Beibehaltungsrichtlinien in TFS-Feeds hinzugefügt. Durch Beibehaltungsrichtlinien wird automatisch die älteste Version eines Pakets gelöscht, sobald der Schwellenwert für die Vermerkdauer erreicht wurde. Pakete, die auf Ansichten hoch gestuft wurden, werden unbegrenzt beibehalten, sodass Sie Versionen schützen können, die in der Produktion verwendet werden oder in Ihrem Unternehmen weit verbreitet sind.

Bearbeiten Sie zum Aktivieren von Beibehaltungsrichtlinien Ihren Feed, und geben Sie einen Wert unter Maximale Anzahl von Versionen pro Paket im Bereich Beibehaltungsrichtlinien ein.

Filter in der Paketverwaltung

Der Bereich Pakete wurde aktualisiert und verfügt jetzt über unser Standardseitenlayout, Befehlsleisten-Steuerelemente und die neue Standardfilterleiste.

Teilen von Paketen mithilfe eines Badges

In der Open-Source-Community ist es üblich, einen Badge zu verwenden, der eine Verknüpfung mit der aktuellen Version eines Pakets in der Infodatei Ihres Repositorys herstellt. Jetzt können sie Badges für Pakete in Ihrem Feed erstellen. Aktivieren Sie die Option Enable Package Badges (Paketbadges aktivieren) in den Feedeinstellungen, wählen Sie ein Paket aus, und klicken Sie auf Create badge (Badge erstellen). Sie können die Badge-URL direkt kopieren oder ein vorgeneriertes Markdown kopieren, das den Badge mit der Detailsseite Ihres Pakets verknüpft.

Vorherige Paketversionen haben jetzt ihre eigene Seite

Wir haben viel Feedback zur aktualisierten Paketverwaltung erhalten, bei der die Liste der vorherigen Paketversionen in eine Breadcrumb-Leiste auf der Detailseite des Pakets verschoben wurde. Wir haben den neuen Reiter Versions (Versionen) hinzugefügt, über den Sie mehr Informationen zu vorherigen Versionen erhalten und die Versionsnummern leichter kopieren und einen Link zu einer älteren Version abrufen können.

Anzeigen der Qualität einer Paketversion in der Paketliste

In der Paketliste sehen Sie nun die Ansicht oder die Ansichten jeder Paketversion, um schnell ihre Qualität einschätzen zu können. In der Dokumentation zu Releaseansichten finden Sie weitere Informationen.

Gulp, Yarn und andere authentifizierte Feedunterstützung

Nach diesem Update funktioniert der npm-Task problemlos mit authentifizierten npm-Feeds (in der Paketverwaltung oder in externen Registrierungen wie npm Enterprise und Artifactory). Vor diesem Update war es eine Herausforderung, ein Aufgabenausführungstool wie Gulp oder einen alternativen npm-Client wie Yarn zu verwenden, wenn der Task keine authentifizierten Feeds unterstützt hat. Wir haben den neuen Buildtask npm Authenticate hinzugefügt, der Ihrer NPMRC-Datei Anmeldeinformationen hinzufügt, sodass Tasks authentifizierte Feeds erfolgreich verwenden können.

Die Standardberechtigungen des Paketfeeds enthalten jetzt die Gruppe Projektadministratoren

In der Vergangenheit wurde der Ersteller eines Feeds als einziger Feedbesitzer festgelegt. Wenn dieser Benutzer nun das Team gewechselt oder die Organisation verlassen hat, konnte dies zu Schwierigkeiten bei der Verwaltung in großen Unternehmen führen. Um diesen Single Point of Failure zu umgehen, wird beim Erstellen eines Feeds der aktuelle Projektkontext eines Benutzers verwendet, um die Gruppe Projektadministratoren abzurufen und sie auch zum Besitzer des Feeds zu machen. Genauso wie mit jeder anderen Berechtigung können Sie die Gruppe entfernen und die Feedberechtigungen über die Feedeinstellungen anpassen.

Wiederverwenden und Wiederherstellen von Paketen

Das Löschen nicht verwendeter Pakete hält die Paketliste übersichtlich. Manchmal werden Pakete jedoch versehentlich gelöscht. Jetzt können Sie gelöschte Pakete aus dem Papierkorb wiederherstellen. Gelöschte Pakete werden 30 Tage lang im Papierkorb aufbewahrt, sodass Sie genügend Zeit für eine Wiederherstellung haben.

Verlinken eines Pakets

Zwar war es bisher möglich, die URL eines Pakets über den Hub Pakete zu teilen, aber dies war häufig schwierig, da Sie ein Projekt in die URL einbeziehen mussten, was nicht für jeden möglich war, der den Link verwendet hat. Durch dieses Update können Sie jetzt Pakete mit einer URL teilen, die automatisch ein Projekt auswählt, auf das der Empfänger zugreifen kann.

Das URL Format ist: „https://<TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package“

Alle Parameter außer „<TFSserverURL>“ sind optional. Wenn Sie ein Paket angeben, müssen Sie allerdings auch den Protokolltyp angeben.

Test

Für die Visual Studio-Testaufgabe ist keine Vollversion von Visual Studio erforderlich.

Der Task Visual Studio Test in Build/Release erfordert zum Ausführen von Tests Visual Studio auf dem Agent. Statt Visual Studio zum Ausführen von Tests in Produktionsumgebungen oder zum Verteilen von Tests auf mehreren Agents zu installieren, verwenden Sie den neuen Task Installer für die Visual Studio Test-Platform. Dieser Task ruft die Testplattform von nuget.org ab und fügt sie zum Toolscache hinzu. Der Installertask erfüllt die VSTest-Anforderung, und ein nachfolgender Visual Studio Test-Task in der Definition kann ausgeführt werden, ohne dass eine Vollversion von Visual Studio auf dem Agent installiert werden muss.

Fügen Sie den Installertask über den Taskkatalog ihrer Definition hinzu.

Konfigurieren Sie den nachfolgenden Task Visual Studio Test so, dass er die vom Installer installierten Komponenten verwendet.

Hinweis

Einschränkungen: Das Test Platform-Paket von NuGet unterstützt aktuell noch nicht das Ausführen von Tests der programmierten Benutzeroberfläche. Das Unterstützen von Tests der programmierten UI wurde hinten angestellt. Das Test Platform-Paket von NuGet ist plattformübergreifend, der VSTest-Task unterstützt aktuell jedoch noch nicht die Ausführung von .NET Core-Tests. Verwenden Sie zum Ausführen von .NET Core-Tests den „dot net“-Task.

Die Aufgaben „Run Functional Tests“ und „Deploy Test Agent“ sind jetzt veraltet

Letztes Jahr haben wir mit der Vereinheitlichung von Agents in Builds, Releases und Tests begonnen. Dadurch sollte auf mehrere Problemfelder in Verbindung mit WinRM-basierten Deploy Test Agent- und Run Functional Tests-Aufgaben (Bereitstellen von Test-Agents und Ausführen von Funktionstests) eingegangen werden. Zudem können Sie den Visual Studio Test-Task (VSTest) für alle Ausgaben rund um Tests verwenden, u.a. die folgenden:

• Komponententests
• Funktionstests (für die Benutzeroberfläche und Nicht-Benutzeroberfläche)
• MSTest-basierte Tests
• Tests, die auf Drittanbieterframeworks basieren
• Assemblybasierte Testspezifikation oder das Ausführen von Tests mit Testplan/Testsammlung
• das Ausführen eines einzelnen Agent-Tests sowie das Verteilen von Tests auf mehreren Agents

Durch den Ansatz zum Vereinheitlichen von Agents können Administratoren alle Computer, die für CI/CD verwendet werden, einheitlich verwalten.

Für diese Funktion wurden einige andere wichtige Änderungen vorgenommen, u.a. die folgenden:

• Sie können UI-Tests für Agents konfigurieren.
• Durch den Installer für die Visual Studio Test-Platform kann der VSTest-Task ohne vorinstalliertes Visual Studio ausgeführt werden.
• Sowohl Build- als auch Releasedefinitionen können mit mehreren Phasen erstellt werden und verschiedene Agent-Warteschlangen für jede Phase nutzen.
• Automatisierte Testfälle können mit dem VSTest-Task über den Testhub ausgeführt werden.

Durch diese Änderungen können diese beiden Tasks jetzt als veraltet markiert werden. Vorhandene Definitionen, die diese Tasks verwenden, funktionieren auch weiterhin. Es wird empfohlen, ab jetzt den VSTest-Task zu verwenden, der mit der Zeit weiter verbessert wird.

Filtern von großen Testergebnissen

Mit der Zeit sammeln sich Testobjekte an, was dazu führen kann, dass große Anwendungen auf tausende von Tests anwachsen können. In Teams ist es wichtig, leicht durch große Mengen an Testergebnissen navigieren zu können, um beim Identifizieren von Testfehlern, den Grundursachen oder dem Zuweisen von Verantwortung für Probleme effizient arbeiten zu können. Dazu haben wir drei neue Filter auf der Registerkarte Tests in Build und Release hinzugefügt: Testname, Container (DLLS) und Besitzer (Containerbesitzer).

Darüber hinaus bietet der vorhandene Filter Ergebnis jetzt die Möglichkeit, mehrere Ergebnisse zu filtern. Die verschiedenen Filterkriterien sind ihrem Wesen nach kumulativ. Wenn ein Benutzer das Ergebnis seiner Tests nach einer Änderung anzeigen möchte, für die er gerade ein Commit ausgeführt hat, kann er nach Container (DLL-Name), Besitzer (DLL-Besitzer) oder Testname bzw. allen filtern, um die relevanten Ergebnisse zu erhalten.

Identifizieren unzuverlässiger Tests

Manchmal sind Tests unzuverlässig – sie schlagen bei einer Ausführen fehl und werden bei der nächsten erfolgreich abgeschlossen, ohne dass Änderungen vorgenommen wurden. Unzuverlässige Tests können frustrierend sein und das Vertrauen in die Effektivität negativ beeinflussen, sodass Fehler ignoriert und übersehen werden. Mit diesem Update haben wir den ersten Bestandteil für die Lösung des Problems mit unzuverlässigen Tests bereitgestellt. Sie können jetzt festlegen, dass der Visual Studio Test-Task fehlgeschlagene Tests erneut ausführt. Die Testergebnisse geben dann an, welche Tests zunächst fehlgeschlagen sind und dann erfolgreich abgeschlossen wurden, als sie erneut ausgeführt wurden. Unterstützung für das erneute Ausführen von datengesteuerten Tests und Testreihen wird auch bald hinzugefügt.

Der Visual Studio Test-Task kann so konfiguriert werden, dass er die Höchstzahl an erneuten Ausführungen von fehlgeschlagenen Tests und einen Schwellenwert in Prozent für fehlgeschlagene Tests (d.h., dass Tests z.B. nur erneut ausgeführt werden, wenn weniger als 20 % aller Tests fehlgeschlagen sind) angibt, um das erneute Ausführen von Tests bei einem hohen Anteil an fehlgeschlagenen Tests zu verhindern.

Sie können auf der Registerkarte Tests unter Build und Release nach Testergebnissen mit dem Ergebnis „Passed on rerun“ (Bei der zweiten Ausführung erfolgreich) filtern, um die Tests zu bestimmen, die unzuverlässig waren. Dies zeigt aktuell den letzten Versuch eines Tests, der beim erneuten Ausführen erfolgreich war. Die Ansicht „Summary“ (Zusammenfassung) wurde angepasst und zeigt jetzt „Passed on rerun (n/m)“ (Bei der zweiten Ausführung erfolgreich) unter „Total tests“ (Test gesamt) an, wobei n die Zahl an erfolgreichen Tests bei der erneuten Ausführung ist und m die Zahl aller erfolgreichen Tests. In den nächsten Sprints wird auch eine Hierarchieansicht aller Versuche hinzugefügt.

Vorschauverbesserungen und Unterstützung für unterschiedliche Protokolltypen, die vom Visual Studio Test-Task erzeugt werden

Wir haben den VSTest-Task verbessert, sodass er Protokolle veröffentlicht, die von unterschiedlichen Protokollanweisungen generiert werden, die der Standardausgabe und den Standardfehlern fehlgeschlagener Tests entsprechen. Wir haben außerdem die Qualität der Vorschau verbessert, sodass sie jetzt das Anzeigen von Text- und Protokolldateiformaten unterstützt. Darüber hinaus gibt es Funktionen zum Durchsuchen der Protokolldateien.

Wiki

Wiki-Suche

Sie können nach Ihren beliebtesten Wiki-Seiten mithilfe des Titels oder des Inhalts sowie mithilfe von Code oder Arbeitselementen suchen. Weitere Informationen zur Wiki-Suche erhalten Sie auf dem DevOps-Blog von Microsoft.

Drucken von Wiki-Seiten

Die Wiki kann für unterschiedliche Inhalte verwendet werden. Manchmal kann es praktisch ein, Inhalt aus der Wiki auszudrucken, um sich in der Freizeit weiter zu informieren, um per Hand Notizen und Anmerkungen zu machen, oder um Personen, die nicht an Ihrem VSTS-Projekt beteiligt sind, eine ausgedruckte Version zur Verfügung zu stellen. Öffnen Sie dazu einfach das Kontextmenü einer Seite, und klicken Sie dann auf Seite drucken.

Hinweis

Dieses Feature wird aktuell nicht in Firefox unterstützt.

Mitwirken an Wiki-Seiten durch Verwenden von Tastenkombinationen

Jetzt können Sie Tastenkombinationen verwenden, um gängige Aktionen zum Bearbeiten und Anzeigen in der Wiki durchzuführen. Dafür benötigen Sie nur Ihre Tastatur.

Wenn Sie sich auf einer Seite befinden, können Sie eine Unterseite hinzufügen, bearbeiten oder erstellen. Dazu können Sie die folgenden Kombinationen verwenden:

Wenn Sie eine Seite bearbeiten, können Sie diese ganz schnell speichern, speichern und schließen oder einfach nur schließen.

Diese Kombinationen stehen zusätzlich zu den Standardtastenkombinationen zum Bearbeiten zur Verfügung (wie STRG+B für fett, STRG+I für kursiv, STRG+K fürs Verknüpfen usw.). Weitere Informationen finden Sie in der Liste aller Tastenkombinationen.

Rendern von umfangreichem Markdown in Coderepositorymarkdown

Sie können jetzt umfangreiche README.MD-Dateien in den Code-Repositorys erstellen. Das Markdownrendering von MD-Dateien in Coderepositorys unterstützt jetzt HTML-Tags, Blockzitate, Emojis, Größenänderung von Bildern und mathematische Formeln. Das Markdownrendering stimmt in der Wiki und in MD-Dateien in Code überein.

Die Wiki unterstützt mathematische Formeln

Wenn Ihre Anwendung sich mit mathematischen Formeln und Gleichungen befasst, können Sie diese jetzt auch mit dem LaTeX-Format in der Wiki einfügen.

Verweisen auf Arbeitselemente in der Wiki

Sie können jetzt auf Arbeitselemente auf Wiki-Seiten verweisen. Drücken Sie auf „#“, um eine Liste der zuletzt geöffneten Arbeitselemente abzurufen. Wählen Sie das gewünschte Arbeitselement aus. Dies ist besonders praktisch beim Schreiben von Versionsanmerkungen, Epics, Spezifikationen oder anderen Seiten, auf denen auf ein Arbeitselement verwiesen werden muss.

Verknüpfen von Arbeitselementen und Wiki-Seiten

Sie können jetzt Arbeitselemente und Wiki-Seiten miteinander verknüpfen. Sie können Arbeitselemente mit dem Wiki verknüpfen, um Epics-Seiten und Versionshinweisen zu erstellen und Inhalt zu planen, der Ihnen beim Nachverfolgen der Arbeitselemente hilft, die mit einer Wiki-Seite verknüpft sind, und um zu überprüfen, zu welchem Prozentsatz Ihre Epics-Seite bereits vollständig ist.

Verknüpfte Arbeitselemente werden dann auf der Wiki-Seite angezeigt.

Über den neuen Linktyp „Wiki page“ (Wiki-Seite) können Sie ein Arbeitselement mit einer Wiki-Seite verknüpfen.

STRG+S zum Speichern der Wiki-Seite

Wir haben Feedback erhalten, dass Benutzer eine Wiki-Seite schneller und einfacher speichern wollten. Sie können eine Seite jetzt einfach mit der Tastenkombination STRG+S speichern. Dann wird eine Standardüberarbeitungsmeldung angezeigt, und Sie können weiter arbeiten. Wenn Sie eine eigene Überarbeitungsmeldung hinzufügen möchten, klicken Sie einfach auf das Chevron neben der Schaltfläche zum Speichern.

Einfügen von umfangreichem Wiki-Inhalt als HTML

Sie können jetzt umfangreichen Text aus jeder browserbasierten Anwendung (z.B. Confluence, OneNote, SharePoint und MediaWiki) im Markdown-Editor der Wiki einfügen. Das ist besonders für Benutzer mit umfangreichem Inhalt (wie z.B. komplexen Tabellen) nützlich, die diesen in der Wiki zur Verfügung stellen möchten. Kopieren Sie den Inhalt einfach, und fügen Sie ihn als HTML ein.

Verschieben von Seiten in der Wiki mit der Tastatur

Vor diesem Update konnten Benutzer in der Wiki Seiten nicht mit der Tastatur neu an- oder unterordnen. Dies war für Benutzer, die das Arbeiten mit Tastenkombinationen bevorzugen, unpraktisch. Sie können Seiten jetzt mit STRG+NACH-OBEN-TASTE oder STRG+NACH-UNTEN-TASTE neu anordnen. Sie können Seiten auch über Seite verschieben im Kontextmenü einer Seite neu unterordnen. Wählen Sie dort die neue übergeordnete Seite aus.

Hervorheben von gefiltertem Text

Beim Filtern im Navigationsbereich in der Wiki wird die gesamte Seitenhierarchie angezeigt. Wenn Sie z.B. nach einer Seite mit dem Titel „foobar“ filtern, zeigt der Navigationsbereich auch alle übergeordneten Seiten an. Es führt möglicherweise zu Verwirrung, wenn Seiten, die nicht dem Titel „foobar“ entsprechen, in den Filterergebnissen angezeigt werden. Beim Filtern im Wiki wird nun der gesuchte Text hervorgehoben, um genau anzuzeigen, welche Titel gefiltert wurden.

Das Verhalten anderer Codenavigationsbereiche ist ähnlich, z.B. auch der Dateinavigationsbereich in Pull Requests, Commits, Changesets und Shelvesets.

Inhaltsvorschau beim Bearbeiten von Wiki-Seiten

Analysen haben ergeben, dass Benutzer fast immer mehrmals eine Vorschau der Wiki-Seite anzeigen lassen, während sie den Inhalt bearbeiten. Bei jedem Seitenbearbeitungsvorgang klicken Benutzer durchschnittlich 1-2 mal auf Vorschau. Das führt zu einem langsamen und nicht optimalen Bearbeitungsprozess, der besonders für Benutzer, die sich gerade erst mit Markdown vertraut machen, zeitaufwendig sein kann. Jetzt sehen Sie eine Vorschau Ihrer Seite, während Sie Änderungen vornehmen.

Allgemein

Profilkarten

Es gibt in TFS mehrere Bereiche, in denen Informationen zu einer bestimmten Person angezeigt werden, u.a. die Ersteller von Pull Requests und Arbeitselemente, die einer bestimmten Person zugewiesen sind. Allerdings werden nur sehr wenige Informationen zu der Person angezeigt, sodass Sie häufig wenig Kontextinformationen erhalten. Die neue Profilkarte ersetzt die bisherige Profilkarte in TFS. Mit der aktualisierten Profilkarte können Sie mit Benutzern über Ihr TFS-Konto interagieren und mehr über diese erfahren. Durch die Integration Ihrer Standard-E-Mail-Adresse und eines Chatclients können Azure AD-Benutzer (Azure Active Directory) E-Mails versenden und Chats direkt über Profilkarten starten. AD-Benutzer sehen auch die Organisationshierarchie auf der Profilkarte. Profilkarten können auf der Startseite eines Projekts im Bereich „Teammitglieder“, in der Versionskontrolle, in Arbeitselementen und im Wiki-Bereich aktiviert werden, indem Sie auf das Visitenkartensymbol, das Profilbild oder den Benutzernamen in den Kommentaren klicken.

Rundes Profilbild

Jetzt sind runde Profilbilder verfügbar. Alle Profilbilder werden nun nicht mehr quadratisch, sondern kreisförmig angezeigt. Als Beispiel sehen Sie hier den Pull Request für diese Änderung (achten Sie auf das runde Profilbild).

Projekttags

Sie können Projekte jetzt mit wichtigen Schlüsselwörtern, sogenannten Tags, versehen. Tags können (von Administratoren) problemlos auf der Projektstartseite hinzugefügt und gelöscht werden, sodass die Benutzer einen schnellen Überblick über Zweck und Umfang des Projekts erhalten. Wir haben noch einige Pläne für den Einsatz von Projekttags. Wir werden Sie hier auf dem Laufenden halten.

Neuanordnen von Favoritengruppen

Sie können jetzt unter My favorites (Eigene Favoriten) die Gruppen mit den Tasten NACH-OBEN und NACH-UNTEN in jedem Gruppenheader neu anordnen.

---

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