Verbesserte Pullanforderungserfahrung

In diesem Sprint fügen wir eine Reihe von Verbesserungen zur Pullanforderungserfahrung hinzu. Dazu gehören optionale Überprüfungen, die STRG-Klicks zum Öffnen einer neuen Registerkarte, das Hinzufügen von Position zu Anmerkungen und die Verbesserung des Kommentarfilterlayouts ermöglichen.

Ausführliche Informationen finden Sie in der Liste "Features" weiter unten.

Features

Azure Boards

• Entfernen der Regel "Zugewiesen an" für den Arbeitsaufgabentyp "Fehler"

Azure Repos

• Eine Reihe von Verbesserungen an der Pull-Anforderungsoberfläche

Azure Pipelines

• Aktualisieren von Knoten im Azure Pipelines-Agent
• Speichern eines fehlerhaften Agents für die Untersuchung in Skalierungsgruppen-Agents
• Ubuntu-neueste Pipelines werden bald Ubuntu-20.04 verwenden

Azure Boards

Entfernen der Regel "Zugewiesen an" für den Arbeitsaufgabentyp "Fehler"

Es gibt mehrere ausgeblendete Systemregeln für alle verschiedenen Arbeitsaufgabentypen in Agile, Scrum und CMMI. Diese Regeln sind seit über einem Jahrzehnt vorhanden und haben in der Regel ohne Beanstandungen in Ordnung gearbeitet. Es gibt jedoch eine Reihe von Regeln, die ihre Willkommensseite auslaufen. Eine Regel hat insbesondere für neue und bestehende Kunden viel Schmerz verursacht, und wir haben beschlossen, sie zu entfernen. Diese Regel ist im Agile-Prozess für den Arbeitsaufgabentyp "Fehler" vorhanden.

"Set the Assigned value to Created By when state is changed to Resolved"

Wir haben viele Ihr Feedback zu dieser Regel erhalten. Als Reaktion darauf haben wir diese Regel aus dem Arbeitsaufgabentyp "Fehler" im Agile-Prozess entfernt. Diese Änderung wirkt sich auf jedes Projekt aus, indem ein geerbter Agile- oder ein angepasster geerbter Agile-Prozess verwendet wird. Für Kunden, die diese aktuelle Regel mögen und davon abhängen, lesen Sie bitte unseren Blogbeitrag zu den Schritten, die Sie ausführen können, um die Regel mithilfe von benutzerdefinierten Regeln erneut hinzuzufügen.

Azure Repos

Eine Reihe von Verbesserungen an der Pull-Anforderungsoberfläche

Die neue Pull-Anforderungsoberfläche ist seit ein paar Monaten in der Vorschau. Wir haben uns mit Feedback befasst, das wir von vielen von Ihnen erhalten haben. Wir freuen uns, die folgenden Verbesserungen bekanntzugeben, die Ihnen bei der Bereitstellung dieses Sprints angezeigt werden:

Aktivieren der optionalen Überprüfungen

Kunden verwenden optionale Prüfungen, um die Aufmerksamkeit eines Entwicklers auf potenzielle Probleme zu lenken. In der vorherigen Erfahrung war es offensichtlich, wenn diese Prüfungen fehlschlagen. Dies ist jedoch nicht der Fall in der Vorschauumgebung. Ein großes grünes Häkchen für die erforderlichen Kontrollen maskiert die Fehler in optionalen Prüfungen. Benutzer konnten nur feststellen, dass optionale Überprüfungen fehlgeschlagen sind, indem sie das Gremium öffnen. Entwickler tun das nicht oft, wenn kein Hinweis auf ein Problem vorliegt. In dieser Bereitstellung haben wir den Status optionaler Überprüfungen in der Zusammenfassung sichtbarer gemacht.

Strg-Klicks auf Menüelemente

Registerkartenmenüs in einer PR haben strg-klick nicht unterstützt. Benutzer öffnen häufig neue Browserregisterkarten, während sie eine Pull-Anforderung überprüfen. Dies wurde behoben.

Position der [+] Anmerkung

Die Strukturauflistung von Dateien in einer PR zeigt eine Anmerkung [+] an, mit der Autoren und Bearbeiter neue Dateien identifizieren können. Da die Anmerkung hinter den Auslassungspunkten lag, war sie für längere Dateinamen oft nicht sichtbar.

Dropdown für PR-Updates erhalten Zeitangaben wieder

Die Dropdownliste zum Auswählen von Aktualisierungen und Vergleichen von Dateien in einer PR hat ein wichtiges Element in der Vorschauumgebung verloren. Es wurde nicht angezeigt, wann diese Aktualisierung vorgenommen wurde. Dies wurde behoben.

Verbessertes Kommentarfilterlayout

Beim Filtern von Kommentaren auf der Zusammenfassungsseite einer Pullanforderung befand sich die Dropdownliste auf der rechten Seite, der Text wurde jedoch linksbündig ausgerichtet. Dies wurde behoben.

Wir haben im Laufe der nächsten beiden Sprints weitere Verbesserungen geplant.

Azure Pipelines

Aktualisieren von Knoten im Azure Pipelines-Agent

Update von dem, was ursprünglich veröffentlicht wurde: Aufgrund einer Inkompatibilität mit Red Hat Enterprise Linux 6 und Node 14 haben wir die Arbeit an Node 14 angehalten und konzentrieren uns zuerst auf den Zugriff auf Node 10.

In dieser Version haben wir unseren Wechsel von Node 6 und zu einer unterstützten Node-Version als bevorzugte Laufzeit für Azure Pipelines-Aufgaben begonnen. Wir haben den ersten Batch der sofort einsatzbereiten Aufgaben aktualisiert, die auf Node 10 ausgeführt werden. Diese Änderung markiert den Anfang eines Prozesses, um Node 6 standardmäßig aus dem Agent zu entfernen. Node 6 hat den langfristigen Support beendet und wird häufig von automatisierten Scannern als Sicherheitsrisiko gekennzeichnet. Obwohl wir glauben, dass unsere Verwendung von Node 6 den meisten potenziellen Fehlern unterliegt, ist es dennoch wichtig, dass wir Aufgaben auf eine unterstützte Laufzeit übertragen. Im Kalenderjahr 2021 planen wir, mit dem Versand einer Version des Agents ohne Node 6 zu beginnen.

Wenn Sie eine der Aufgaben mit Node 10-fähigen Verwenden, aktualisiert sich Ihre selbst gehosteten Agents selbst, um die neuen Versionen von Aufgaben auszuführen. Abgesehen davon sollte es für die meisten Kunden keine Auswirkungen geben. Wenn Sie hingegen der Autor von Aufgaben sind, sollten Sie mit der Aktualisierung beginnen, die auf Knoten 10 ausgeführt werden soll. In Ihrem task.json, unter execution, können Sie von Node zu Node10. Wenn Sie ältere Serverversionen unterstützen müssen, können Sie Ihren Node Einstiegspunkt verlassen. Instanzen von Azure DevOps, die den Node 10-Handler verstehen, wählen sie standardmäßig aus, und diejenigen, die nicht auf Ihre Node 6-Implementierung zurückgreifen.

Speichern eines fehlerhaften Agents für die Untersuchung in Skalierungsgruppen-Agents

Wenn Sie Skalierungssatz-Agents verwenden, verwaltet Azure Pipelines die Skalierung nach oben und unten von Agentinstanzen. Wenn Azure Pipelines einen fehlerhaften virtuellen Computer im Skalierungssatz erkennt, protokolliert es das Problem auf der Benutzeroberfläche für die Pooldiagnose und versucht, den virtuellen Computer zu löschen. Es gibt viele Gründe, warum eine VM fehlerhaft sein kann: Die Netzwerkkonfiguration des Skalierungssatzes hat möglicherweise verhindert, dass die Azure Pipelines-Erweiterung den neuesten Agent herunterlädt, ihre benutzerdefinierte Skripterweiterung ist möglicherweise fehlgeschlagen, oder das Vm-Image des Skalierungssatzes hat möglicherweise einen ausstehenden Neustart oder ausstehende Windows-Updates.

Durch das Löschen fehlerhafter VMs behält Azure Pipelines Ihren Agentpool für die Ausführung von CI/CD-Aufträgen optimiert. In einigen Fällen können Sie die Seite "Azure Pipelines Diagnose" (siehe oben) oder die Seite "Azure Diagnose" verwenden, um dieses Problem zu debuggen. In vielen Fällen besteht jedoch die beste Möglichkeit zum Diagnostizieren des Problems darin, sich bei der VM anzumelden und die Agentprotokolle und Ereignisanzeigeprotokolle zu überprüfen. Derzeit ist dies nicht einfach, da die fehlerhafte VM automatisch gelöscht wird.

Mit dieser Version haben wir die Diagnose von fehlerhaften VMs verbessert, indem Wir Ihnen die Möglichkeit bieten, einen fehlerhaften Agent für die Untersuchung zu speichern.

Wenn ein fehlerhafter Agent gespeichert wird, können Sie eine Verbindung mit dem virtuellen Computer herstellen, debuggen und alle benötigten Protokolle abrufen. Wenn Sie fertig sind, können Sie den Agent und den zugehörigen virtuellen Computer freigeben. Weitere Informationen finden Sie im Abschnitt zur Problembehandlung bei fehlerhaften Agents.

ubuntu-latest Pipelines werden bald Ubuntu-20.04 verwenden

Ubuntu 20.04 wird bald die Standardversion für die ubuntu-latest Bezeichnung in Azure Pipelines sein. Diese Änderung wird über einen Zeitraum von mehreren Wochen ab dem 30. November eingeführt.

Wenn Probleme mit Ihren Ubuntu-Pipelines auftreten:

• Datei eines Problems im Repository für virtuelle Umgebungen
• Wechseln Sie zurück zu Ubuntu 18.04, indem Sie sie als vmImage in Ihrer Pipeline angebenubuntu-18.04. Wir werden Ubuntu 18.04 weiterhin unterstützen.

Beachten Sie, dass und ubuntu-20.04 kann sich ubuntu-18.04 sowohl in vorinstallierten Tools als auch in den Standardversionen von Tools unterscheiden. Informationen zu allen Unterschieden finden Sie unter https://github.com/actions/virtual-environments/issues/1816.

Nächste Schritte

Wechseln Sie zu Azure DevOps, und sehen Sie sich an.

Senden von Feedback

Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Vielen Dank,

Matt Cooper