Verbesserte Planungsflexibilität mit erweiterter Sprintboardfilterung

In diesem Sprint können Sie jetzt das Sprintboard und den Sprint-Backlog nach zusätzlichen Feldern filtern, einschließlich benutzerdefinierter Felder, die sie in Einklang mit der Filtererfahrung bringen, die bereits im Produktrücklauf und in Boards verfügbar ist.

In Azure Pipelines haben wir eine präzisere Steuerung der Kommentaranforderungen für PR-Validierungsausführungen aus GitHub-Forks, einen neuen Phasenindex für die schnellere Navigation in komplexen CD-Pipelines und die Option hinzugefügt, angehaltene Ausführungen beim erneuten Aktivieren einer Pipeline abzubrechen.

Weitere Informationen finden Sie in den Versionshinweisen.

Azure Boards

Azure Pipelines

Wiki

Azure Boards

Sprint-Boards und Backlogs nach zusätzlichen Feldern filtern

Nach der Einführung zusätzlicher Filter für Boards und Backlogs haben wir nun einen langjährigen Wunsch aus der Entwickler-Community umgesetzt und diese Funktion auch auf Sprint-Boards und Sprint-Backlogs erweitert.

Teams können jetzt zusätzliche Felder, einschließlich benutzerdefinierter Felder, verwenden, um Sprintboards und Backlogs zu filtern, wodurch es einfacher ist, die richtige Arbeit während der Sprintplanung und -ausführung zu finden und zu konzentrieren. Diese Erweiterung greift eine stark nachgefragte Funktion auf, die ursprünglich in der Azure DevOps Entwicklercommunity eingebracht wurde.

Filtern von Sprintboards und Backlogs nach zusätzlichen Feldern

Azure Pipelines

Detailliertere Kommentaranforderung für die Ausführung der PR-Validierung wird aus GitHub Repositorys ausgeführt.

Um Ihre Pipelines vor nicht autorisierter Verwendung zu schützen, können Sie vor der Ausführung von PR-Validierungsläufen Kommentare von Teammitgliedern oder Mitwirkenden verlangen.

Vor diesem Sprint galt die Anforderung eines Kommentars für PRs sowohl aus dem Repository selbst als auch aus geforkten Repositorys. Um den Prozess zu beschleunigen, können Sie festlegen, dass Kommentare von Teammitgliedern nur für PR-Validierungsläufe erforderlich sind, die aus geforkten Repositorys stammen. Alas, das war nicht möglich.

Ab diesem Sprint können Sie Kommentaranforderungen unabhängig voneinander pro PR-Quelle konfigurieren. Im folgenden Beispiel sind Kommentare nur für PRs erforderlich, die aus Repository-Forks stammen.

Präzisere Kommentaranforderung für PR-Validierungsläufe

Schnellere Navigation zwischen Pipeline-Phasen

Das Navigieren in komplexen CD-Pipelines ist mühsam. Solche Pipelines können zehn oder sogar Hunderte von Stufen haben. Die Kenntnis des Zustands jeder Stufe wird schwieriger, wenn die Pipeline voranschreitet, da spätere Phasen nicht auf den Bildschirm passen.

Beginnend mit diesem Sprint zeigt Azure Pipelines einen Phasenindex auf der linken Seite der Stufenkarte an, wodurch es einfacher ist, zu der phase zu navigieren, an der Sie interessiert sind.

Stellen Sie sich vor, Sie hätten eine Pipeline mit 32 Stufen, die ringförmig angeordnet sind. Die Phasen im letzten Ring passen möglicherweise nicht auf den Bildschirm. Möglicherweise müssen Sie nach unten und rechts scrollen, um zur letzten Phase zu gelangen.

Pipeline-Stufen ohne Seitenleiste

Mit der Seitenleiste für die Stufen wird die Navigation erleichtert. Sie können vertikal zu der Phase scrollen, an der Sie interessiert sind, und darauf klicken, um dorthin zu wechseln.

Pipeline-Stufen mit Seitenleiste

Pipeline aktivieren und angehaltene Läufe abbrechen

Das Aktivieren einer angehaltenen oder deaktivierten Pipeline kann zu Rechenressourcenverschwendung führen, wenn eine große Anzahl von Pipelineläufen fortgesetzt wird.

Wenn Sie eine Pipeline aktivieren, haben Sie ab diesem Sprint die Möglichkeit, die Pipeline zu aktivieren, aber die angehaltenen Ausführungen abzubrechen. Die Option zum Aktivieren der Pipeline und Fortsetzen der Ausführung ist weiterhin verfügbar.

Aktivieren der Pipeline und Abbrechen von angehaltenen Ausführungen

Wiki

Standard-Mermaid-Syntax in Markdown-Editoren

Mermaid-Diagramme in Azure DevOps Markdown unterstützen nun die standardmäßige syntax für eingezäunten Codeblocks (```mermaid), zusätzlich zur vorhandenen syntax ::: mermaid. Diese Änderung verringert die Notwendigkeit, unterschiedliche Markdown-Formate über Tools hinweg zu verwalten und die Erstellung von Wiki-Seiten, Pullanforderungen und Arbeitsaufgaben zu vereinfachen, die Mermaid-Diagramme enthalten.

Inhalte, die mit der standardsyntax ```mermaid in GitHub, VS Code oder anderen Markdown-Editoren erstellt wurden, werden jetzt ohne Konvertierung konsistent in Azure DevOps gerendert. Vorhandene Diagramme, die die ::: mermaid Syntax verwenden, funktionieren weiterhin.

Diese Änderung befasst sich mit einem langjährigen Entwicklercommunity Vorschlag.

Nächste Schritte

Note

Diese Features werden in den nächsten zwei bis drei Wochen eingeführt. Gehen Sie zu Azure DevOps und schauen Sie sich an.

So geben Sie Feedback

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

Vorschlag erstellen

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