Erstellen eines Dashboard ohne Team – Sprint 162 Update

Im Sprint 162 Update von Azure DevOps freuen wir uns, ihnen mitteilen zu können, dass Sie eine Dashboard erstellen können, ohne sie einem Team zuzuordnen. Die Dashboard ist für jeden im Projekt sichtbar, und Sie können entscheiden, wer sie bearbeiten/verwalten kann.

Darüber hinaus haben wir die Miniaturansicht des Sprint-Burndowns hinzugefügt. Jetzt können Sie es basierend auf Geschichten, Storypunkten oder der Anzahl der Aufgaben für burndown konfigurieren.

Weitere Informationen finden Sie in der Liste features unten.

Features

Azure Repos:

• Neue Zielseiten für die Webplattformkonvertierung
• Unterstützung für die Sprache Kotlin

Azure Pipelines:

• Benutzeroberfläche für mehrstufige Pipelines aktualisiert
• VSTest TestResultsDirectory-Option ist auf der Aufgabenoberfläche verfügbar.
• Verwenden von erweiterten Schlüsselwort (keyword) in Pipelines
• Markdownunterstützung in automatisierten Testfehlermeldungen
• Sammeln automatischer und benutzerdefinierter Metadaten aus der Pipeline
• Benutzeroberfläche für Updates zu Dienstverbindungen
• VM-Bereitstellungen mit Umgebungen
• Überspringen von Phasen in einer YAML-Pipeline

Berichterstellung:

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

Azure Repos

Neue Zielseiten für die Webplattformkonvertierung

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

Weberfahrung:

Mobile Benutzeroberfläche:

Unterstützung für die Sprache Kotlin

Wir freuen uns, ihnen mitteilen zu können, dass wir jetzt die Kotlin-Sprachmarkierung im Datei-Editor unterstützen. Die Hervorhebung verbessert die Lesbarkeit Ihrer Kotlin-Textdatei und hilft Ihnen, schnell zu überprüfen, um Fehler zu finden. Wir haben dieses Feature basierend auf einem Vorschlag aus dem Entwicklercommunity priorisiert.

Azure Pipelines

Benutzeroberfläche für mehrstufige Pipelines aktualisiert

Eine aktualisierte Version der Benutzeroberfläche für mehrstufige Pipelines ist jetzt standardmäßig verfügbar. Die mehrstufige Pipeline-Benutzeroberfläche bietet Verbesserungen und Benutzerfreundlichkeit für die Benutzeroberfläche des Pipelineportals. Sie können Ihre Pipelines anzeigen und verwalten, indem Sie im menü auf der linken Seite Pipelines auswählen. Darüber hinaus können Sie Einen Drilldown durchführen und Pipelinedetails anzeigen, Details ausführen, Pipelineanalysen, Auftragsdetails, Protokolle und vieles mehr anzeigen.

Weitere Informationen zur Benutzeroberfläche für mehrstufige Pipelines finden Sie in der Dokumentation.

VSTest TestResultsDirectory-Option ist auf der Aufgabenoberfläche verfügbar.

Der VSTest-Task speichert Testergebnisse und zugeordnete Dateien im $(Agent.TempDirectory)\TestResults Ordner. Wir haben der Task-Benutzeroberfläche 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 von erweiterten Schlüsselwort (keyword) in Pipelines

Derzeit können Pipelines in Vorlagen integriert werden, um die Wiederverwendung zu fördern und die Boilerplate zu reduzieren. Die Gesamtstruktur der Pipeline wurde weiterhin durch die YAML-Stammdatei definiert. Mit diesem Update haben wir eine strukturiertere Möglichkeit zur Verwendung von Pipelinevorlagen hinzugefügt. Eine YAML-Stammdatei kann jetzt die Schlüsselwort (keyword)-Erweiterung verwenden, um anzugeben, dass die Standard Pipelinestruktur in einer anderen Datei gefunden werden kann. Dadurch haben Sie die Kontrolle darüber, welche Segmente erweitert oder geändert werden können und welche Segmente behoben werden. Außerdem haben wir Pipelineparameter mit Datentypen erweitert, um die Hooks, die Sie bereitstellen können, deutlich zu machen.

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

# 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 automatisierten Testfehlermeldungen

Wir haben Markdownunterstützung für Fehlermeldungen für automatisierte Tests hinzugefügt. Jetzt können Sie problemlos Fehlermeldungen für Testausführung und Testergebnisse formatieren, um die Lesbarkeit zu verbessern und die Problembehandlung bei Testfehlern in Azure Pipelines zu vereinfachen. Die unterstützte Markdownsyntax finden Sie hier.

Sammeln automatischer und benutzerdefinierter Metadaten aus der Pipeline

Jetzt können Sie die automatische und benutzerdefinierte Metadatensammlung aus Pipelinetasks aktivieren. Mithilfe von Metadaten können Sie eine Artefaktrichtlinie in einer Umgebung erzwingen, indem Sie die Artefaktprüfung auswerten.

Benutzeroberfläche für Updates zu 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. Anfang dieses Jahres haben wir die neue Benutzeroberfläche für Dienstverbindungen als Vorschaufeature eingeführt. Vielen Dank an alle, die die neue Erfahrung ausprobiert haben und uns ihr wertvolles Feedback gegeben haben.

Neben 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 mit diesem Update standardmäßig aktiviert . Sie haben weiterhin die Möglichkeit, die Vorschau abzuwählen.

VM-Bereitstellungen mit Umgebungen

Eines der am häufigsten angeforderten Features in Umgebungen waren VM-Bereitstellungen. Mit diesem Update aktivieren wir die Vm-Ressource in Umgebungen. Sie können Bereitstellungen jetzt auf mehreren Computern orchestrieren und fortlaufende Updates mithilfe von YAML-Pipelines durchführen. Sie können den Agent auch direkt auf jedem Ihrer Zielserver installieren und die rollierende Bereitstellung 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 einer Gruppe von Computern (rolling set) in jeder Iteration.

Beispielsweise werden unter Rollbereitstellung bis zu fünf Ziele in jeder Iteration aktualisiert. maxParallel bestimmt die Anzahl der Ziele, die parallel bereitgestellt werden können. Die Auswahl entspricht der Anzahl der Ziele, die jederzeit verfügbar bleiben müssen, mit Ausnahme der Ziele, für die bereitgestellt wird. Hiermit werden auch die Erfolgs- und Fehlerbedingungen während der Bereitstellung bestimmt.

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, sollten Sie manchmal einige Phasen in Ihrer Pipeline überspringen. Für instance, wenn Sie keine Bereitstellung in der Produktion durchführen möchten oder wenn Sie die Bereitstellung in einigen Umgebungen in der Produktion überspringen möchten. Sie können dies jetzt mit Ihren YAML-Pipelines tun.

Der aktualisierte Ausführungspipelinebereich zeigt eine Liste der Phasen aus der YAML-Datei an, und Sie haben die Möglichkeit, eine oder mehrere dieser Phasen zu überspringen. Sie müssen beim Überspringen von Phasen Vorsicht walten lassen. Wenn ihre erste Phase für instance bestimmte Artefakte erzeugt, die für nachfolgende Phasen benötigt werden, sollten Sie die erste Phase nicht überspringen. Der Ausführungsbereich zeigt eine allgemeine Warnung an, wenn Sie Phasen überspringen, die nachgelagerte Abhängigkeiten aufweisen. Es bleibt Ihnen überlassen, ob es sich bei diesen Abhängigkeiten um echte Artefaktabhängigkeiten handelt oder ob sie nur für die Sequenzierung von Bereitstellungen vorhanden sind.

Das Überspringen einer Phase entspricht dem erneuten Verdrahten der Abhängigkeiten zwischen den Phasen. Alle unmittelbar nachgelagerten Abhängigkeiten der übersprungenen Phase hängen vom Upstream übergeordneten Der übersprungenen Phase ab. Wenn bei der Ausführung ein Fehler auftritt und Sie versuchen, eine fehlgeschlagene Phase erneut auszuführen, weist auch dieser Versuch das gleiche Übersprungverhalten auf. Um zu ändern, welche Phasen übersprungen werden, müssen Sie eine neue Ausführung starten.

Berichterstellung

Miniaturansicht des Inline-Sprint-Burndowns

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

Wenn Sie auf die Miniaturansicht klicken, wird sofort eine größere Version des Diagramms mit der Option angezeigt, den vollständigen Bericht auf der Registerkarte Analyse anzuzeigen. Alle Änderungen, die am vollständigen Bericht vorgenommen werden, werden im Im Header angezeigten Diagramm widergespiegelt. So können Sie es jetzt basierend auf Geschichten, Storypunkten oder der Anzahl der Aufgaben als Burndown konfigurieren, anstatt nur die verbleibende Menge an Arbeit.

Erstellen eines Dashboard ohne Team

Sie können jetzt eine Dashboard erstellen, ohne sie einem Team zuzuordnen. Wählen Sie beim Erstellen eines Dashboard den Projektdashboardtyp aus.

Ein Projektdashboard ähnelt einem Teamdashboard, es ist jedoch nicht einem Team zugeordnet, 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

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

Senden von 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