Erstellen eines Dashboards ohne Team – Sprint 162 Update

Im Sprint 162 Update von Azure DevOps freuen wir uns, ihnen mitzuteilen, dass Sie ein Dashboard erstellen können, ohne es einem Team zuzuordnen. Das Dashboard ist für alle Personen im Projekt sichtbar, und Sie können entscheiden, wer es bearbeiten/verwalten kann.

Darüber hinaus haben wir die Miniaturansicht des Sprint-Burndowns hinzugefügt. Jetzt können Sie es so konfigurieren, dass Burndown-Diagramme basierend auf Geschichten, Story-Punkten oder nach der Anzahl von Aufgaben erstellt werden.

Sehen Sie sich die Funktionen unten an.

Features

Azure Repos:

• Neue Zielseiten für Webplattform-Konvertierung
• Unterstützung für Kotlin-Sprache

Azure-Pipelines:

• Aktualisierte Benutzeroberfläche für mehrstufige Pipelines
• Die Option "VSTest TestResultsDirectory" ist in der Aufgaben-UI verfügbar.
• Verwenden Sie das extends-Schlüsselwort in Pipelines
• Markdown-Unterstützung in automatisierten Testfehlermeldungen
• Automatische und vom Benutzer angegebene Metadaten aus der Pipeline sammeln
• Aktualisierungen der Benutzeroberfläche für Dienstverbindungen
• VM-Bereitstellungen mit Umgebungen
• Überspringen von Phasen in einer YAML-Pipeline

Berichterstellung:

• Miniaturansicht des Inline-Sprint-Burndowns
• Erstellen eines Dashboards ohne Team

Azure Repos

Neue Landing Pages für die Webplattform-Konvertierung

Wir haben die Benutzeroberfläche der Repos-Zielseiten aktualisiert, um sie modern, schnell und mobil zu gestalten. Hier sind zwei Beispiele für die Seiten, die aktualisiert wurden, wir werden auch weiterhin andere Seiten in zukünftigen Updates aktualisieren.

Weberfahrung:

Mobile Erfahrung:

Unterstützung für Kotlin-Sprache

Wir freuen uns, ihnen mitzuteilen, dass wir jetzt Kotlin-Sprachheraushebungen im Datei-Editor unterstützen. Das Hervorheben verbessert die Lesbarkeit Ihrer Kotlin-Textdatei und hilft Ihnen, schnell nach Fehlern zu suchen. Wir haben dieses Feature basierend auf einem Vorschlag der Developer Communitypriorisiert.

Azure-Pipelines

Aktualisierte Benutzeroberfläche für mehrstufige Pipelines

Eine aktualisierte Version der Benutzeroberfläche für mehrstufige Pipelines ist jetzt standardmäßig verfügbar. Die Erfahrungen mit den mehrstufigen Pipelines bringen Verbesserungen und Benutzerfreundlichkeit in die Portal-UI der Pipeline. Sie können Ihre Pipelines anzeigen und verwalten, indem Sie im linken Menü "Pipelines " auswählen. Darüber hinaus können Sie Drilldowns ausführen und Pipelinedetails anzeigen, Details ausführen, Pipelineanalysen, Auftragsdetails, Protokolle und vieles mehr.

Weitere Informationen zur Benutzererfahrung mit mehrstufigen Pipelines finden Sie in der Dokumentation hier.

VSTest-Option „TestResultsDirectory“ ist auf der Task-Benutzeroberfläche verfügbar

Die VSTest-Aufgabe speichert Testergebnisse und zugeordnete Dateien im ordner $(Agent.TempDirectory)\TestResults. Wir haben der Aufgaben-UI eine Option hinzugefügt, mit der Sie einen anderen Ordner zum Speichern von Testergebnissen konfigurieren können. Jetzt können alle nachfolgenden Aufgaben, die die Dateien an einem bestimmten Speicherort benötigen, diese verwenden.

Verwenden des extends-Schlüsselworts in Pipelines

Derzeit können Pipelines in Vorlagen aufgeteilt werden, die Wiederverwendung fördern und die Bausteine reduzieren. Die Gesamtstruktur der Pipeline wurde noch durch die YaML-Stammdatei definiert. Mit diesem Update haben wir eine strukturiertere Methode zur Verwendung von Pipelinevorlagen hinzugefügt. Eine YAML-Stammdatei kann nun das Schlüsselwort extends verwenden, um anzugeben, dass die Pipeline-Hauptstruktur in einer anderen Datei gefunden werden kann. Dadurch können Sie steuern, welche Segmente erweitert oder geändert werden können und welche Segmente behoben sind. Außerdem haben wir die Pipelineparameter mit Datentypen verbessert, um die bereitstellbaren Hooks klarer zu definieren.

In diesem Beispiel wird veranschaulicht, wie Sie einfache Hooks bereitstellen können, die von einem Pipelineautor genutzt werden können. Die Vorlage führt immer einen Build aus, kann optional zusätzliche Schritte durchführen, die von der Pipeline bereitgestellt werden, und dann einen optionalen Testschritt ausführen.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Markdownunterstützung in Fehlermeldungen für automatisierte Tests

Wir haben Markdown-Unterstützung zu Fehlermeldungen für automatisierte Tests hinzugefügt. Jetzt können Sie Fehlermeldungen sowohl für testausführungs- als auch für Testergebnisse problemlos formatieren, um die Lesbarkeit zu verbessern und die Problembehandlung bei Testfehlern in Azure Pipelines zu vereinfachen. Die unterstützte Markdown-Syntax finden Sie hier.

Automatische und vom Benutzer angegebene Metadaten aus der Pipeline sammeln

Jetzt können Sie die automatische und vom Benutzer angegebene Metadatensammlung aus Pipelineaufgaben aktivieren. Mithilfe von Metadaten können Sie Artefaktrichtlinien für eine Umgebung erzwingen, indem Sie die Artefaktüberprüfungausführen.

Aktualisierungen der Benutzeroberfläche für Dienstverbindungen

Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Dienstverbindungen zu verwalten. Diese Updates machen die Dienstverbindung modern und konsistent mit der Richtung von Azure DevOps. Die neue Benutzeroberfläche für Dienstverbindungen wurde in diesem Jahr als Vorschaufeature eingeführt. Vielen Dank an alle, die die neue Erfahrung ausprobiert haben und uns ihr wertvolles Feedback gegeben haben.

Zusammen mit der Aktualisierung der Benutzeroberfläche haben wir auch zwei Funktionen hinzugefügt, die für die Nutzung von Dienstverbindungen in YAML-Pipelines von entscheidender Bedeutung sind: Pipelineautorisierungen und Genehmigungen und Überprüfungen.

Die neue Benutzeroberfläche wird standardmäßig mit diesem Update aktiviert. Sie haben weiterhin die Möglichkeit, von der Vorschau abzumelden.

VM-Bereitstellungen mit Umgebungen

Eine der am häufigsten angeforderten Features in Umgebungen war VM-Bereitstellungen. Mit diesem Update aktivieren wir die Ressource "Virtueller Computer" in Umgebungen. Sie können jetzt Bereitstellungen auf mehreren Computern koordinieren und Roll- Updates mithilfe von YAML-Pipelines durchführen. Sie können den Agenten auch direkt auf jedem Ihrer Zielserver installieren und die Rollbereitstellung auf diesen Servern vorantreiben. Darüber hinaus können Sie den vollständigen Aufgabenkatalog auf Ihren Zielcomputern verwenden.

Eine rollierende Bereitstellung ersetzt Instanzen der vorherigen Version einer Anwendung durch Instanzen der neuen Version der Anwendung auf einem rollierenden Satz von Maschinen in jeder Iteration.

Ein Beispiel: Bei einem Rollout von Bereitstellungsupdates werden in jeder Iteration bis zu fünf Ziele aktualisiert. maxParallel bestimmt die Anzahl der Ziele, die parallel bereitgestellt werden können. Die Auswahl berücksichtigt die Anzahl der Ziele, die jederzeit verfügbar bleiben müssen, abzüglich der Ziele, auf die bereitgestellt wird. Es wird auch verwendet, um die Erfolgs- und Fehlerbedingungen während der Bereitstellung zu bestimmen.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTraffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Überspringen von Phasen in einer YAML-Pipeline

Wenn Sie eine manuelle Ausführung starten, möchten Sie vielleicht manchmal einige Phasen in Ihrer Pipeline überspringen. Wenn Sie beispielsweise nicht für die Produktion bereitstellen möchten oder die Bereitstellung in einigen Umgebungen in der Produktion überspringen möchten. Sie können dies jetzt mit Ihren YAML-Pipelines tun.

Der Bereich für die aktualisierte Ausführungspipeline enthält eine Liste der Phasen aus der YAML-Datei, und Sie haben die Möglichkeit, eine oder mehrere dieser Phasen zu überspringen. Beim Überspringen von Stadien müssen Sie Vorsicht walten lassen. Wenn ihre erste Phase beispielsweise bestimmte Artefakte erzeugt, die für nachfolgende Phasen erforderlich sind, sollten Sie die erste Phase nicht überspringen. Im Ausführungsbereich wird eine allgemeine Warnung angezeigt, wenn Sie Phasen überspringen, die über nachgeschaltete Abhängigkeiten verfügen. Es bleibt Ihnen überlassen, ob diese Abhängigkeiten echte Artefaktabhängigkeiten sind oder ob sie nur für die Sequenzierung von Bereitstellungen vorhanden sind.

Das Überspringen einer Stufe entspricht dem Neuverwirren der Abhängigkeiten zwischen Phasen. Alle unmittelbaren nachgelagerten Abhängigkeiten der übersprungenen Stufe werden abhängig gemacht vom übergeordneten Element der übersprungenen Stufe. Wenn die Ausführung fehlschlägt und Sie versuchen, eine fehlgeschlagene Phase erneut auszuführen, wird auch dieser Versuch das gleiche Überspringverhalten aufweisen. Um zu ändern, welche Phasen übersprungen werden, müssen Sie eine neue Ausführung starten.

Berichterstattung

Miniaturansicht für Inline-Sprint-Burndown

Der Sprint Burndown ist zurück! Vor einigen Sprints haben wir den Sprint-Burndown im Kontext aus den Headern von Sprint Burndown und Taskboard entfernt. Basierend auf Ihrem Feedback haben wir die Sprint-Burndown-Miniaturansicht verbessert und wieder eingeführt.

Wenn Sie auf die Miniaturansicht klicken, wird sofort eine größere Version des Diagramms mit einer Option angezeigt, um den vollständigen Bericht auf der Registerkarte "Analyse" anzuzeigen. Alle Änderungen, die am vollständigen Bericht vorgenommen wurden, werden in dem diagramm widergespiegelt, das in der Kopfzeile angezeigt wird. Daher können Sie es jetzt so konfigurieren, dass der Burndown anhand von Stories, Storypunkten oder der Anzahl der Aufgaben erfolgt, anstatt nur basierend auf der verbleibenden Arbeitsmenge.

Erstellen eines Dashboards ohne Team

Sie können jetzt ein Dashboard erstellen, ohne es einem Team zuzuordnen. Wählen Sie beim Erstellen eines Dashboards den Projektdashboard- Typ aus.

Ein Projektdashboard ist wie ein Teamdashboard, mit der Ausnahme, dass es keinem Team zugeordnet ist, und Sie können entscheiden, wer das Dashboard bearbeiten/verwalten kann. Genau wie ein Teamdashboard ist es für jeden im Projekt sichtbar.

Alle Azure DevOps-Widgets, die einen Teamkontext erfordern, wurden aktualisiert, damit Sie ein Team in ihrer Konfiguration auswählen können. Sie können diese Widgets zu Project Dashboards hinzufügen und das gewünschte Team auswählen.

Nächste Schritte

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.

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

Vielen Dank,

Jeff Beehler