Verwalten organization Abrechnung in Azure DevOps – Sprint 150 Update

Im Sprint 150-Update von Azure DevOps haben wir die Möglichkeit hinzugefügt, die Abrechnung für Ihre organization in unserem Portal zu verwalten.

Auf der neuen Registerkarte Abrechnung können Sie das Azure-Abonnement auswählen, das Sie für die Abrechnung verwenden, und für weitere Benutzer bezahlen. Sie müssen nicht mehr zum Visual Studio Marketplace oder zum Azure-Portal wechseln, um die Abrechnung zu verwalten.

Weitere Informationen finden Sie weiter unten in der Liste Features .

Features

Allgemeines:

• Dunkles Design allgemein verfügbar
• Verwalten der Abrechnung für Ihre organization über Azure DevOps

Azure Boards:

• Abfragen von Aufgaben basierend auf Azure Active Directory-Gruppen
• Freigeben des Boards Ihres Teams mithilfe eines Badges
• Abfragen der Arbeit relativ zum Beginn des Tages, der Woche, des Monats oder jahres
• Exportieren von Abfrageergebnissen in eine CSV-Datei

Azure Repos:

• Neue Mergetypen zum Abschließen von Pull Requests

Azure Pipelines:

• Kubernetes-Manifestaufgabe
• Upgrades auf Docker-Aufgabe
• Installer für Kubectl-Tool
• Azure Container Registry in der Docker-Registrierungsdienstverbindung
• cgroup-Unterstützung für gehosteten Ubuntu-Pool
• Einmal ausführen des Agents
• Unterstützung für Visual Studio 2019 (VS2019) im Visual Studio-Testtask
• Aktualisierung der Benutzeroberfläche des Agent-Pools
• Task Assistent zum Bearbeiten von YAML-Dateien
• Imageupdates für gehostete Pipelines
• Verbesserungen an der ServiceNow-Integration
• Unterstützung für Azure PowerShell Az-Modul
• Verbesserungen bei der Ressourcenautorisierung
• Vereinfachte Aufbewahrungsrichtlinien für Buildpipelines
• Pipelineartefakte, die im Release automatisch abgerufen werden
• Aktualisierungen des Cobertura-Code Coverage-Berichts

Berichterstellung:

• Berichte zu Buildfehlern und -dauer
• Allgemeine Verfügbarkeit von Analytics

Wiki:

• Benachrichtigungen auf Wiki-Seiten

Verwaltung:

• Verwalten der Abrechnung für Ihre organization über Azure DevOps

Allgemein

Dunkles Design allgemein verfügbar

Im vergangenen Oktober haben wir die öffentliche Vorschau des dunklen Designs als Teil der neuen Navigation veröffentlicht. Nach mehreren Monaten in der Vorschau, dem Hören von Feedback und der Optimierung der Erfahrung freuen wir uns, die allgemeine Verfügbarkeit des dunklen Designs bekannt zu geben.

Verwalten der Abrechnung für Ihre organization über Azure DevOps

Wir freuen uns, Ihnen mitteilen zu können, dass Sie jetzt die Abrechnung Ihrer organization über das Azure DevOps-Portal verwalten können. Administratoren müssen die Abrechnung über die Azure-Portal nicht mehr einrichten. Um die Abrechnungseinstellungen zu verwalten, wechseln Sie zu Ihren Organisationseinstellungen , und wählen Sie Abrechnung aus.

Im Folgenden finden Sie eine Liste der Einstellungen, die Sie auf der Registerkarte Abrechnung verwalten können.

1. Sie können ein Azure-Abonnement auswählen, das für die Abrechnung verwendet werden soll.

   

2. Sie können das Azure-Abonnement ändern, das Ihr organization für die Abrechnung verwendet, indem Sie ein anderes Abonnement auswählen. Zuvor mussten Sie die Abrechnung entfernen und dann für jede Ihrer kostenpflichtigen Ressourcen (Basic-Benutzer, Paketverwaltungsbenutzer, MS Hosted-Pipelines usw.) die gleiche Ebene erneut erwerben. Dieser Prozess war mühsam und fehleranfällig. Sie können jetzt das Azure-Abonnement ändern, das Ihr organization für die Abrechnung verwendet, indem Sie ein anderes Abonnement auswählen und auf Speichern klicken.

   

3. Es ist nicht mehr erforderlich, zum Visual Studio Marketplace zu wechseln, um die Abrechnungseinrichtung zu verwalten. Wir haben die Möglichkeit hinzugefügt, zusätzliche Benutzer von Basic, Test Manager und Paketverwaltung (Azure Artifacts) zu bezahlen. Sie können die Anzahl der Benutzer erhöhen oder verringern, die Ihr organization auf der neuen Registerkarte Abrechnung bezahlt.

   

Azure Boards

Abfragen von Aufgaben basierend auf Azure Active Directory-Gruppen

Mit der zunehmenden Einführung von Azure Active Directory und der weit verbreiteten Verwendung von Gruppen zum Verwalten der Sicherheit haben Teams zunehmend nach Möglichkeiten gesucht, diese Gruppen in Azure Boards zu nutzen. Zusätzlich zum Abfragen von Arbeitselementen, die von bestimmten Personen mithilfe der Operatoren In Gruppe oder Nicht in Gruppe zugewiesen oder geändert wurden, können Sie Azure Active Directory-Gruppen jetzt auch direkt verwenden.

Weitere Informationen finden Sie in der Dokumentation zu Abfrageoperatoren .

Freigeben des Boards Ihres Teams mithilfe eines Badges

Die README-Datei des Repositorys ist häufig die Heimat, an die sich Ihr Projektteam wendet, um Informationen darüber zu finden, wie Sie zu Ihrer Lösung beitragen und diese verwenden können. Wie bei einem Build- oder Bereitstellungs-status in Azure Pipelines können Sie ihrer INFODATEI einen Badge für das Board Ihres Teams in Azure Boards hinzufügen. Sie können den Badge so konfigurieren, dass nur die Spalten In Bearbeitung oder alle Spalten angezeigt werden, und sogar das Badge öffentlich sichtbar machen, wenn Ihr Projekt Open Source ist.

Wenn Ihre README-Datei auf Markdown basiert, können Sie einfach das Markdown-Beispiel von der Seite status Badgeeinstellungen kopieren und in Ihre Datei einfügen.

Abfragen der Arbeit relativ zum Beginn des Tages, der Woche, des Monats oder jahres

Während teams sich häufig auf die Arbeit im Kontext des nächsten Oder basierend auf Sprintiterationen konzentrieren, ist es oft interessant, die Arbeit durch die Linse des Kalenders zu betrachten, um über alle Arbeiten zu berichten, die im letzten Monat oder im ersten Quartal des Jahres stattgefunden haben. Jetzt können Sie den folgenden neuen Satz von @StartOf Makros zusammen mit einem beliebigen datumsbasierten Feld verwenden, um basierend auf dem Anfang des Tages, der Woche, des Monats oder des Jahres abzufragen:

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

Jedes dieser Makros akzeptiert auch eine neue Modifiziererzeichenfolge, mit der Sie die Daten um verschiedene Datumseinheiten verschieben können. Sie können z. B. eine Abfrage schreiben, um alle Arbeitselemente zu finden, die im ersten Quartal dieses Jahres abgeschlossen wurden, indem Sie zustandsänderungsdatum >= @StartOfYear und Zustandsänderungsdatum <= abfragen @StartOfYear(“+3M”). Weitere Informationen finden Sie in der Dokumentation zu Abfragemakros .

Exportieren von Abfrageergebnissen in eine CSV-Datei

Sie können Abfrageergebnisse jetzt direkt aus dem Web in eine CSV-Formatdatei exportieren.

Azure Repos

Neue Mergetypen zum Abschließen von Pull Requests

Sie haben jetzt mehr Optionen beim Zusammenführen der Änderungen von einem Pull Request mit dem Zielbranch. Wir haben Unterstützung für zwei unserer am häufigsten angeforderten Features auf der Entwicklercommunity hinzugefügt: Schnelles Zusammenführen und semilineares Zusammenführen (auch als "Rebase und Merge" bezeichnet).

Diese neuen Optionen werden nun im Dialogfeld Pull Request abschließen angezeigt:

Auf der aktualisierten Richtlinienverwaltungsseite können Administratoren steuern, welche Mergestrategien für eine Verzweigung oder einen Ordner von Branches zulässig sind.

Es gibt einige Situationen, in denen eine Neubasierung während des Abschlusses von Pull Requests nicht möglich ist:

• Wenn eine Richtlinie für den Zielbranch die Verwendung von Rebasestrategien verbietet, benötigen Sie die Berechtigung "Branchrichtlinien außer Kraft setzen".
• Wenn der Quellbranch des Pull Requests Richtlinien enthält, können Sie ihn nicht neu erstellen. Durch das erneuteBasieren wird der Quellbranch geändert, ohne den Richtliniengenehmigungsprozess durchlaufen zu müssen.
• Wenn Sie die Mergekonflikterweiterung verwendet haben, um Mergekonflikte zu lösen. Konfliktauflösungen, die auf eine Drei-Wege-Zusammenführung angewendet werden, sind selten erfolgreich (oder sogar gültig), wenn alle Commits in einem Pull Request einzeln neu zugeordnet werden.

In all diesen Fällen haben Sie weiterhin die Möglichkeit, Ihren Branch lokal zu basieren und auf den Server zu pushen oder Ihre Änderungen beim Abschließen des Pull Requests squashen zusammenzuführen.

Azure Pipelines

Kubernetes-Manifestaufgabe

Wir haben unseren Releasepipelines eine neue Aufgabe hinzugefügt, um die Bereitstellung in Kubernetes-Clustern mithilfe von Manifestdateien zu vereinfachen. Diese Aufgabe bietet die folgenden Vorteile im Vergleich zur Verwendung von kubectl binary in Skripts:

• Artefaktersetzung: Die Bereitstellungsaktion verwendet als Eingabe eine Liste von Containerimages, die zusammen mit ihren Tags oder Digests angegeben werden können. Dies wird in die Nicht-Vorlagenversion der Manifestdateien ersetzt, bevor sie auf den Cluster angewendet wird, um sicherzustellen, dass die richtige Version des Images von den Knoten des Clusters abgerufen wird.

• Manifeststabilität: Der Rollout status auf die bereitgestellten Kubernetes-Objekte überprüft wird, um Stabilitätsprüfungen zu integrieren, während die Aufgabe status als Erfolg/Fehler gilt.

• Rückverfolgbarkeitsanmerkungen: Anmerkungen werden den bereitgestellten Kubernetes-Objekten hinzugefügt, um Informationen zur Nachverfolgbarkeit zu organization, Projekt, Pipeline und Ausführung zu überlagern.

• Bake-Manifest: Die Bake-Aktion der Aufgabe ermöglicht das Baken von Helm-Diagrammen in Kubernetes-Manifestdateien, damit sie auf den Cluster angewendet werden können.

• Bereitstellungsstrategie: Die Auswahl der Canary-Strategie mit Bereitstellungsaktion führt zur Erstellung des gewünschten Prozentsatzes von Workloads mit dem Suffix "-baseline " und "-canary ", sodass sie während einer ManualIntervention Aufgabe verglichen werden können, bevor die Aktion "Heraufstufen/Ablehnen" der Aufgabe verwendet wird, um die beizubehaltende Version abzuschließen.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Upgrades auf Docker-Aufgabe

Wir haben die Docker-Aufgabe aktualisiert, um die Pipelineerstellung zu vereinfachen. Der Befehl buildAndPush kann jetzt verwendet werden, um mehrere Tags für ein bestimmtes Containerrepository zu erstellen und in einem einzigen Schritt an mehrere Containerregistrierungen zu pushen. Die Aufgabe kann Docker-Registrierungsdienstverbindungen für die Anmeldung bei Containerregistrierungen verwenden. Nachverfolgbarkeitsmetadaten zu Quellrepository, Commit und Build-Provenienz werden den mit dieser Aufgabe erstellten Images als Bezeichnungen hinzugefügt.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Installer für Kubectl-Tool

Wir haben eine neue Aufgabe hinzugefügt, mit der Sie eine bestimmte Version der Kubectl-Binärdatei auf den Agents installieren können. Die aktuellen Zeichenfolgen und semver-Versionszeichenfolgen wie "v1.14.0" werden als gültige Werte für die Kubectl-Versionsspezifikationseingabe akzeptiert.

Azure-Containerregistrierung in Docker-Registrierungsdienstverbindung

Jetzt können Sie eine Docker-Registrierungsdienstverbindung über die Einstellungsseite Ihres Projekts erstellen. Wählen Sie zum Erstellen der Verbindung eine Azure-Containerregistrierung in einem der Abonnements aus, die Ihrer Azure Active Directory-Identität (Azure AD) zugeordnet sind. Alle Aufgaben, die Dienstverbindungen mit Containerregistrierungen wie Docker@2 und KubernetesManifest@0 erfordern, unterstützen eine einzelne Möglichkeit zum Angeben einer Verbindung.

cgroup-Unterstützung für gehosteten Ubuntu-Pool

Unter Linux beendet der Kernel einige Prozesse, wenn die Arbeitsspeicherauslastung zu hoch wird, um den Rest zu schützen. Wenn der Azure Pipelines-Agent-Prozess für die Beendigung ausgewählt ist, schlägt Ihre Pipelineausführung mit einer Fehlermeldung fehl, die besagt, dass die Kommunikation mit dem Agent verloren geht. Im von Microsoft gehosteten Ubuntu-Pool haben wir die Wahrscheinlichkeit reduziert, dass der Agent beendet wird, indem wir Schritte in einer benutzerdefinierten cgroup ausführen. Während Ihre Pipeline möglicherweise immer noch fehlschlägt, wenn Sie den verfügbaren Arbeitsspeicher überschreiten, ist es wahrscheinlicher, dass der Agentprozess den Fehler überlebt und den Fehler ordnungsgemäß meldet. Wenn Sie einen privaten Linux-Agent ausführen, haben wir die von uns verwendeten Einstellungen veröffentlicht , sodass Sie ein ähnliches Setup in Betracht ziehen können.

Einmal ausführen des Agents

Wenn Sie Infrastruktur wie Azure Container Instances verwenden, um private Agents für elastische Datenbanken auszuführen, möchten Sie häufig, dass jeder Agent nur einen Auftrag akzeptiert, bevor er abläuft. Bisher war dies nicht einfach, da Sie den Agent beenden mussten (was möglicherweise zu einem Fehler führte) oder das Risiko akzeptieren mussten, dass ein Agent einen anderen Auftrag erhält, bevor Sie ihn herunterfahren konnten. Mit diesem Update haben wir der Agentkonfiguration das Flag --once hinzugefügt. Wenn Sie den Agent auf diese Weise konfigurieren, akzeptiert er nur einen Auftrag und wird dann selbst heruntergefahren.

Unterstützung für Visual Studio 2019 (VS2019) im Visual Studio-Testtask

Wir haben der Visual Studio-Testaufgabe in Pipelines Unterstützung für VS2019 hinzugefügt. Um Tests mit der Testplattform für VS2019 auszuführen, wählen Sie in der Dropdownliste Version der Testplattform die Optionen Neueste oder Visual Studio 2019 aus.

Aktualisierung der Benutzeroberfläche des Agent-Pools

Die Verwaltungsseite für Agentpools in den Projekteinstellungen wurde mit einer neuen Benutzeroberfläche aktualisiert. Jetzt können Sie leicht alle Aufträge anzeigen, die in einem Pool ausgeführt werden. Darüber hinaus können Sie erfahren, warum ein Auftrag nicht ausgeführt wird.

Task Assistent zum Bearbeiten von YAML-Dateien

Wir erhalten weiterhin viel Feedback, um die Bearbeitung von YAML-Dateien für Pipelines zu vereinfachen. In den vorherigen Updates wurde IntelliSense-Unterstützung hinzugefügt. Jetzt fügen wir dem YAML-Editor eine Aufgabe Assistent hinzu. Damit haben Sie die gleiche vertraute Erfahrung wie beim Hinzufügen einer neuen Aufgabe zu einer YAML-Datei wie im klassischen Editor. Diese neue Assistent unterstützt die meisten gängigen Aufgabeneingabetypen, z. B. Auswahllisten und Dienstverbindungen. Um die neue Aufgabe Assistent zu verwenden, wählen Sie Bearbeiten für eine YAML-basierte Pipeline und dann den Assistent Task aus.

Imageupdates für gehostete Pipelines

Wir freuen uns, Updates für den gehosteten macOS-Pool für OS X Mojave (10.4) bekannt zu geben, der auch Unterstützung für Xcode 10.2 enthält. Wenn Ihre Designer-basierten Pipelines den gehosteten macOS-Pool verwenden, werden Ihre Pipelines automatisch auf Mojave aktualisiert. Wenn Sie OS X High Sierra (10.3) beibehalten möchten, ändern Sie den Pool, auf dem Ihre Builds ausgeführt werden, in Hosted macOS High Sierra.

Wenn Sie YAML verwenden, können Sie die folgenden neuen vmImage-Bezeichnungen verwenden:

• Bildbezeichnung, die immer auf die neueste Version von macOS verweist, derzeit 10.4

vmImage: 'macOS-latest'

• Diese Imagebezeichnung ist speziell für mac OS 10.4 bestimmt, wenn Sie sicherstellen möchten, dass Ihre Pipeline für Mojave ausgeführt wird.

vmImage: 'macOS-10.4'

• Bildbezeichnung, die speziell auf mac OS 10.3 ausgerichtet ist, wenn Sie sicherstellen möchten, dass Ihre Pipeline für High Sierra ausgeführt wird

vmImage: 'macOS-10.3'

Wir haben auch Updates am Windows Server 2019-Image für Ihre gehosteten Azure-Pipelines vorgenommen. Die neuesten Releases finden Sie hier. Dieses Update enthält neue Versionen von VS2019 Preview, Docker, PowerShell Core, Node.js, npm und anderen.

Weitere Informationen dazu, was in unseren gehosteten macOS-VM-Images enthalten ist, und informationen zu den tools, die auf unseren Images verfügbar sind, finden Sie in unserem Repository zur Imagegenerierung auf GitHub.

Verbesserungen an der ServiceNow-Integration

Im vergangenen Dezember haben wir die ServiceNow Change Management-Integration mit Releasepipelines veröffentlicht. Eine wichtige Funktion für die teamübergreifende Zusammenarbeit, die es jedem Team ermöglicht, einen Dienst seiner Wahl zu nutzen und eine effektive End-to-End-Bereitstellung zu erhalten. Mit diesem Update haben wir die Integration verbessert, um alle Arten von Änderungen (Normal, Standard und Notfall) zu unterstützen. Darüber hinaus können Sie jetzt das Gate angeben, das zum Erstellen einer neuen Änderungsanforderung verwendet wird, indem Sie eine vorhandene Vorlage verwenden, gemäß dem ITSM-Prozess, der in Ihrem organization. Schließlich können Sie Auch Releases basierend auf vorhandenen Änderungsanforderungen gaten. Dadurch können Sie CD einführen, ohne den von Ihren IT-Teams empfohlenen Prozess ändern zu müssen.

Unterstützung für Azure PowerShell Az-Modul

Azure PowerShell stellt eine Reihe von Cmdlets bereit, mit denen Sie Azure-Ressourcen über die Befehlszeile verwalten können. Im vergangenen Dezember wurde das Modul Azure PowerShell Az verfügbar und ist nun das geplante Modul für die Verwaltung Ihrer Azure-Ressourcen.

Bisher haben wir keine Unterstützung für das Azure PowerShell Az-Modul in unseren gehosteten Agents bereitgestellt. Mit der neuen Azure PowerShell Taskversion 4.* in Build- und Releasepipelines haben wir Unterstützung für das neue Az-Modul für alle Plattformen hinzugefügt. Azure PowerShell Taskversion 3.* unterstützt weiterhin das AzureRM-Modul. Um jedoch mit den neuesten Azure-Diensten und -Features Schritt zu halten, empfehlen wir, so bald wie möglich auf die Azure PowerShell Taskversion 4.* zu wechseln.

Das Az-Modul verfügt über einen Kompatibilitätsmodus, mit dem Sie vorhandene Skripts verwenden können, während Sie sie aktualisieren, um die neue Syntax zu verwenden. Verwenden Sie den Befehl, um die Kompatibilität für das Enable-AzureRmAlias Az-Modul zu aktivieren. Mit Aliasen können Sie die alten Cmdletnamen mit dem Az-Modul verwenden. Weitere Informationen zur Migration vom Azure RM-Modul zum modul Azure PowerShell Az finden Sie hier.

Weitere Informationen zum modul Azure PowerShell Az finden Sie in der Dokumentation hier.

Verbesserungen bei der Ressourcenautorisierung

Wir mussten Sicherheit für geschützte Ressourcen (z. B. Dienstverbindungen, Variablengruppen, Agentpools, sichere Dateien) bereitstellen, wenn in einer YAML-Datei darauf verwiesen wird. Gleichzeitig wollten wir Es Ihnen erleichtern, Pipelines einzurichten und zu verwenden, die diese Arten von Ressourcen für Nichtproduktionsszenarien verwenden. Zuvor haben wir eine Einstellung hinzugefügt, um eine Ressource als "autorisiert für die Verwendung in allen Pipelines" zu markieren.

Mit diesem Update erleichtern wir Es Ihnen, ein Problem mit der Ressourcenautorisierung zu beheben, auch wenn Sie eine Ressource nicht als solche gekennzeichnet haben. Wenn ein Build aufgrund eines Ressourcenautorisierungsfehlers fehlschlägt, sehen Sie in der neuen Benutzeroberfläche eine Option zum expliziten Autorisieren der Verwendung dieser Ressourcen in der Pipeline, und fahren Sie dann fort. Teammitglieder mit Berechtigungen zum Autorisieren von Ressourcen können diese Aktion direkt bei einem fehlerhaften Build ausführen.

Vereinfachte Aufbewahrungsrichtlinien für Buildpipelines

Wir haben das Aufbewahrungsmodell für alle Buildpipelines, einschließlich YAML-Builds, vereinfacht. Es gibt eine neue Einstellung auf Projektebene, mit der Sie steuern können, wie viele Tage Sie die Builds jeder Pipeline beibehalten möchten und wie viele Tage Sie die Artefakte jedes Builds beibehalten möchten. Wenn Sie den klassischen Editor zum Erstellen Ihrer Buildpipeline verwendet haben, werden die älteren Aufbewahrungseinstellungen weiterhin berücksichtigt, aber neuere Pipelines verwenden die neuen Einstellungen. Sie können die Aufbewahrung auf der Seite mit den Pipelineeinstellungen der Projekteinstellungen verwalten.

Pipelineartefakte, die im Release automatisch abgerufen werden

Wenn zuvor die mit einem Release verknüpfte Buildpipeline Artefakte mithilfe der Aufgabe Pipelineartefakt veröffentlichen veröffentlicht hatte, wurden die Artefakte nicht automatisch in release abgerufen. Stattdessen mussten Sie der Releasepipeline explizit einen Task "Pipelineartefakt herunterladen" hinzufügen, um die Artefakte herunterzuladen.

Jetzt werden alle von der Buildpipeline veröffentlichten Pipelineartefakte automatisch heruntergeladen und in der Version für Sie zur Verfügung gestellt. Sie können den Download Ihres Pipelineartefakts auch über die Phaseneigenschaften der Releasepipeline anpassen.

Aktualisierungen des Cobertura-Code Coverage-Berichts

Wenn Sie zuvor Tests in der Pipeline ausgeführt und Code Coverage-Ergebnisse für Azure DevOps veröffentlicht haben, mussten sowohl die XML-Zusammenfassung als auch eine HTML-Berichtsdatei angegeben werden. Darüber hinaus wurden Formatvorlagen in den HTML-Berichten entfernt, bevor sie auf der Registerkarte Code Coverage gerendert wurden. Diese Entfernung der Formatierung war aus Sicherheitssicht notwendig, da beliebige HTML-Dateien hochgeladen werden konnten.

Mit diesem Update haben wir diese Einschränkungen für Cobertura-Abdeckungsberichte behoben. Beim Veröffentlichen von Code Coverage-Berichten müssen Sie keine HTML-Dateien mehr angeben. Berichte werden automatisch generiert und in entsprechender Formatierung auf der Registerkarte Code Coverage gerendert. Diese Funktion verwendet das Open Source Tool ReportGenerator.

Berichterstellung

Berichte zu Buildfehlern und -dauer

Es ist wichtig, Metriken und Erkenntnisse zu haben, um den Durchsatz und die Stabilität Ihrer Pipeline kontinuierlich zu verbessern. Als ersten Schritt zur Bereitstellung von Pipelineanalysen haben wir zwei Berichte hinzugefügt, um Ihnen Metriken und Erkenntnisse zu Ihren Pipelines zu bieten.

1. Der Fehlerbericht zeigt die Builddurchlaufrate und den Fehlertrend an. Darüber hinaus wird auch der Fehlertrend für Aufgaben angezeigt, um Erkenntnisse darüber zu liefern, welche Aufgabe zur maximalen Anzahl von Fehlern beiträgt.

   

2. Der Dauerbericht weist die Pipelinedauer zusammen mit seinem Trend auf.

   

Allgemeine Verfügbarkeit von Analytics

Wir freuen uns, ihnen mitteilen zu können, dass die folgenden Analytics-Features ohne zusätzliche Kosten in Azure DevOps enthalten sein werden.

1. Die Analysewidgets sind konfigurierbare Module, die Daten auf einem Dashboard anzeigen und Ihnen helfen, den Fortschritt Ihrer Arbeit zu überwachen. Folgende Widgets sind enthalten:

   • Burndown- und Burnupdiagramme überwachen den Fortschritt einer Reihe von bereichsbezogenen Arbeiten über einen bestimmten Zeitraum.

     

   • Zykluszeit und Vorlaufzeit , um zu visualisieren, wie sich die Arbeit im Entwicklungszyklus Ihres Teams bewegt

     

   • Das kumulative Flussdiagramm (Cumulative Flow Diagram, CFD) verfolgt Arbeitselemente nach, während sie verschiedene Zustände durchlaufen.

     

   • Mit Geschwindigkeit wird nachverfolgt, wie ein Team über mehrere Sprints einen Wert liefert.

     

   • Testergebnisse Trend zum Überwachen von Testtrends, Erkennen von Fehler- und Dauermustern für Tests über einzelne oder mehrere Pipelines.

     

2. In das Produkt enthalten wir den Testbericht mit den häufigsten Fehlern , um Erkenntnisse über die häufigsten fehlerhaften Tests in Ihrer Pipeline zu erhalten, um die Zuverlässigkeit der Pipeline zu verbessern und die Testverschuldung zu verringern.

   

Wir werden auch weiterhin power BI-Integration über Analyseansichten und direkten Zugriff auf unseren OData-Endpunkt in der Vorschau für alle Azure DevOps Services Kunden anbieten.

Wenn Sie die Analytics Marketplace-Erweiterung verwenden, können Sie Analytics weiterhin wie zuvor verwenden und müssen keine zusätzlichen Schritte ausführen. Dies bedeutet, dass die Analytics Marketplace-Erweiterung für gehostete Kunden veraltet ist.

Das Azure DevOps Analytics-Angebot ist die Zukunft der Berichterstellung, und wir werden weiterhin in neue Features investieren, die von Analytics gesteuert werden. Weitere Informationen zu Analytics finden Sie unter den folgenden Links.

• Dokumentation zur Analyseübersicht

• Analysewidgets

• Testbericht mit den häufigsten Fehlern

• Power BI-Integration

• OData-Endpunkt

• Azure DevOps Analytics

Wiki

Benachrichtigungen auf Wiki-Seiten

Bis jetzt wusstest du nicht, wann der Inhalt einer Wiki-Seite geändert wurde. Jetzt können Sie Wiki-Seiten folgen, um per E-Mail benachrichtigt zu werden, wenn die Seite bearbeitet, gelöscht oder umbenannt wird. Um an einem Wiki vorgenommene Änderungen nachzuverfolgen, wählen Sie auf der Wiki-Seite die Schaltfläche Folgen aus.

Dieses Feature wurde basierend auf diesem Vorschlagsticket priorisiert. Weitere Informationen finden Sie in unserer Dokumentation hier.

Verwaltung

Verwalten der Abrechnung für Ihre organization über Azure DevOps

Wir freuen uns, Ihnen mitteilen zu können, dass Sie jetzt die Abrechnung Ihrer organization über das Azure DevOps-Portal verwalten können. Administratoren müssen die Abrechnung über die Azure-Portal nicht mehr einrichten. Um die Abrechnungseinstellungen zu verwalten, wechseln Sie zu Ihren Organisationseinstellungen , und wählen Sie Abrechnung aus.

Im Folgenden finden Sie eine Liste der Einstellungen, die Sie auf der Registerkarte Abrechnung verwalten können.

1. Sie können ein Azure-Abonnement auswählen, das für die Abrechnung verwendet werden soll.

   

2. Sie können das Azure-Abonnement ändern, das Ihr organization für die Abrechnung verwendet, indem Sie ein anderes Abonnement auswählen. Zuvor mussten Sie die Abrechnung entfernen und dann für jede Ihrer kostenpflichtigen Ressourcen (Basic-Benutzer, Paketverwaltungsbenutzer, MS Hosted-Pipelines usw.) die gleiche Ebene erneut erwerben. Dieser Prozess war mühsam und fehleranfällig. Sie können jetzt das Azure-Abonnement ändern, das Ihr organization für die Abrechnung verwendet, indem Sie ein anderes Abonnement auswählen und auf Speichern klicken.

   

3. Es ist nicht mehr erforderlich, zum Visual Studio Marketplace zu wechseln, um die Abrechnungseinrichtung zu verwalten. Wir haben die Möglichkeit hinzugefügt, zusätzliche Benutzer von Basic, Test Manager und Paketverwaltung (Azure Artifacts) zu bezahlen. Sie können die Anzahl der Benutzer erhöhen oder verringern, die Ihr organization auf der neuen Registerkarte Abrechnung bezahlt.

   

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 Feedbackmenü, um ein Problem zu melden oder einen Vorschlag zu machen.

Sie können auch Rat und Ihre Fragen von der Community auf Stack Overflow beantworten lassen.

Vielen Dank,

Jeremy Epling