Neues Sprint-Burndown-Widget und verbesserte Pipelinesicherheit – Sprint 160 Update
Im Sprint 160-Update von Azure DevOps haben wir ein neues Sprint-Burndown-Widget hinzugefügt, das das Herunterbrennen nach Storypunkten, Anzahl von Aufgaben und summieren benutzerdefinierten Feldern unterstützt. Darüber hinaus haben wir die Sicherheit von Pipelines verbessert, indem wir den Umfang der Zugriffstoken einschränken.
Weitere Informationen finden Sie weiter unten in der Liste Features .
Neuerungen in Azure DevOps
Features
Azure Repos:
Azure Pipelines:
- UX für mehrstufige Pipelines
- Orchestrieren der Canary-Bereitstellungsstrategie für die Umgebung für Kubernetes
- Genehmigungsrichtlinien für YAML-Pipelines
- ACR als erstklassige Pipelineressource
- Pipelineressourcenmetadaten als vordefinierte Variablen
- Nachverfolgbarkeit für Pipelines und ACR-Ressourcen
- Vereinfachte Ressourcenautorisierung in YAML-Pipelines
- Verbessern der Pipelinesicherheit durch Einschränken des Umfangs von Zugriffstoken
- Auswerten der Artefaktprüfung
- Markdownunterstützung in automatisierten Testfehlermeldungen
- Diagnostizieren von Cron-Zeitplänen in YAML
- Updates zum Bereitstellungstask für ARM-Vorlagen
- Sicherheit auf Projektebene für Dienstverbindungen
- Ubuntu 18.04-Pool
- Service Mesh Interface-basierte Canary-Bereitstellungen in KubernetesManifest-Task
- ReviewApp in Environment
Azure Artifacts:
- Aktualisierte Benutzeroberfläche "Connect to feed" (Verbindung mit Feed herstellen)
- Öffentliche Feeds sind jetzt allgemein verfügbar mit Upstream Unterstützung
- Erstellen von projektbezogenen Feeds über das Portal
Berichterstellung:
Wiki:
Azure Repos
Cross-Repo Branch-Richtlinienverwaltung
Branchrichtlinien sind eines der leistungsstarken Features von Azure Repos, mit denen Sie wichtige Branches schützen können. Obwohl die Möglichkeit zum Festlegen von Richtlinien auf Projektebene in der REST-API vorhanden ist, gab es dafür keine Benutzeroberfläche. Jetzt können Administratoren Richtlinien für einen bestimmten Branch oder die Standardbranch für alle Repositorys in ihrem Projekt festlegen. Beispielsweise könnte ein Administrator zwei Mindestprüfer für alle Pull Requests anfordern, die in jedem Standard Branch in jedem Repository in ihrem Projekt ausgeführt werden. Sie finden das Feature Branchschutz hinzufügen in den Repository-Projekteinstellungen.
Azure Pipelines
UX für mehrstufige Pipelines
Wir haben an einer aktualisierten Benutzeroberfläche gearbeitet, um Ihre Pipelines zu verwalten. Diese Updates machen die Pipelines modern und konsistent mit der Richtung von Azure DevOps. Darüber hinaus vereinen diese Updates klassische Buildpipelines und mehrstufige YAML-Pipelines in einer einzigen Oberfläche. Beispielsweise sind die folgenden Funktionen in der neuen Benutzeroberfläche enthalten: Anzeigen und Verwalten mehrerer Phasen, Genehmigen von Pipelineausführungen, Möglichkeit, den gesamten Weg zurück in Protokollen zu scrollen, während eine Pipeline noch ausgeführt wird, und Integrität pro Branch einer Pipeline.
Vielen Dank an alle, die die neue Erfahrung ausprobiert haben. Wenn Sie es noch nicht ausprobiert haben, aktivieren Sie mehrstufige Pipelines in den Vorschaufeatures. Weitere Informationen zu mehrstufigen Pipelines finden Sie in der Dokumentation hier .
Dank Ihres Feedbacks haben wir in den letzten beiden Updates folgendes behandelt.
- Auffindbarkeit der Ordneransicht.
- Sprunghaftigkeit in der Protokollansicht.
- Anzeigen von Protokollen aus vorherigen und aktuellen Aufgaben, auch wenn eine Ausführung ausgeführt wird.
- Vereinfachen Sie die Navigation zwischen Aufgaben beim Überprüfen von Protokollen.
Hinweis
Im nächsten Update planen wir, dieses Feature standardmäßig für alle Benutzer zu aktivieren. Sie haben weiterhin die Möglichkeit, die Vorschau zu deaktivieren. Einige Wochen danach wird das Feature allgemein verfügbar gemacht.
Orchestrieren der Canary-Bereitstellungsstrategie für die Umgebung für Kubernetes
Einer der wichtigsten Vorteile der kontinuierlichen Bereitstellung von Anwendungsupdates ist die Möglichkeit, Updates für bestimmte Microservices schnell in die Produktion zu übertragen. Dadurch haben Sie die Möglichkeit, schnell auf Änderungen der Geschäftsanforderungen zu reagieren. Die Umgebung wurde als erstklassiges Konzept eingeführt, das die Orchestrierung von Bereitstellungsstrategien ermöglicht und Releases ohne Ausfallzeiten erleichtert. Bisher haben wir die runOnce-Strategie unterstützt, die die Schritte einmal sequenziell ausgeführt hat. Mit der Unterstützung der Canary-Strategie in mehrstufigen Pipelines können Sie das Risiko jetzt verringern, indem Sie die Änderung langsam auf eine kleine Teilmenge einführen. Wenn Sie mehr Vertrauen in die neue Version gewinnen, können Sie damit beginnen, sie auf mehr Server in Ihrer Infrastruktur bereitzustellen und mehr Benutzer an sie weiterzuleiten.
jobs:
- deployment:
environment: musicCarnivalProd
pool:
name: musicCarnivalProdPool
strategy:
canary:
increments: [10,20]
preDeploy:
steps:
- script: initialize, cleanup....
deploy:
steps:
- script: echo deploy updates...
- task: KubernetesManifest@0
inputs:
action: $(strategy.action)
namespace: 'default'
strategy: $(strategy.name)
percentage: $(strategy.increment)
manifests: 'manifest.yml'
postRouteTaffic:
pool: server
steps:
- script: echo monitor application health...
on:
failure:
steps:
- script: echo clean-up, rollback...
success:
steps:
- script: echo checks passed, notify...
Die Canary-Strategie für Kuberenetes stellt zunächst die Änderungen mit 10 % Pods bereit, gefolgt von 20 %, während die Integrität während postRouteTraffic überwacht wird. Wenn alles gut geht, wird es zu 100% heraufstufen.
Wir suchen nach frühem Feedback zur Unterstützung von VM-Ressourcen in Umgebungen und zur Durchführung einer parallelen Bereitstellungsstrategie auf mehreren Computern. Kontaktieren Sie uns , um sich zu registrieren.
Genehmigungsrichtlinien für YAML-Pipelines
In YAML-Pipelines folgen wir einer vom Ressourcenbesitzer kontrollierten Genehmigungskonfiguration. Ressourcenbesitzer konfigurieren Genehmigungen für die Ressource und alle Pipelines, die die Ressourcenpause für Genehmigungen verwenden, bevor die Phase beginnt, in der die Ressource genutzt wird. Es ist üblich, dass SOX-basierte Anwendungsbesitzer den Anforderer der Bereitstellung daran hindern, eigene Bereitstellungen zu genehmigen.
Sie können jetzt erweiterte Genehmigungsoptionen verwenden, um Genehmigungsrichtlinien zu konfigurieren, z. B. der Anforderer sollte nicht genehmigen, die Genehmigung von einer Teilmenge von Benutzern anfordern und das Genehmigungstimeout.
ACR als erstklassige Pipelineressource
Wenn Sie ein Containerimage nutzen müssen, das in ACR (Azure Container Registry) als Teil Ihrer Pipeline veröffentlicht wurde, und Ihre Pipeline bei jeder Veröffentlichung eines neuen Images auslösen müssen, können Sie die ACR-Containerressource verwenden.
resources:
containers:
- container: MyACR #container resource alias
type: ACR
azureSubscription: RMPM #ARM service connection
resourceGroup: contosoRG
registry: contosodemo
repository: alphaworkz
trigger:
tags:
include:
- production
Darüber hinaus kann mithilfe vordefinierter Variablen auf ACR-Bildmetadaten zugegriffen werden. Die folgende Liste enthält die ACR-Variablen, die zum Definieren einer ACR-Containerressource in Ihrer Pipeline verfügbar sind.
resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location
Pipelineressourcenmetadaten als vordefinierte Variablen
Wir haben vordefinierte Variablen für YAML-Pipelineressourcen in der Pipeline hinzugefügt. Hier ist die Liste der verfügbaren Pipelineressourcenvariablen.
resources.pipeline.<Alias>.projectName
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
Nachverfolgbarkeit für Pipelines und ACR-Ressourcen
Wir stellen die vollständige E2E-Rückverfolgbarkeit sicher, wenn Pipelines und ACR-Containerressourcen in einer Pipeline verwendet werden. Für jede Ressource, die von Ihrer YAML-Pipeline genutzt wird, können Sie zu den Commits, Arbeitselementen und Artefakten zurückverfolgen.
In der Zusammenfassungsansicht der Pipelineausführung sehen Sie Folgendes:
Die Ressourcenversion, die die Ausführung ausgelöst hat. Jetzt kann Ihre Pipeline ausgelöst werden, wenn eine andere Azure-Pipelineausführung abgeschlossen ist oder wenn ein Containerimage an ACR gepusht wird.
Die Commits , die von der Pipeline verwendet werden. Sie finden auch die Aufschlüsselung der Commits nach den einzelnen Ressourcen, die von der Pipeline genutzt werden.
Die Arbeitselemente , die jeder ressource zugeordnet sind, die von der Pipeline genutzt wird.
Die Artefakte , die von der Ausführung verwendet werden können.
In der Bereitstellungsansicht der Umgebung sehen Sie die Commits und Arbeitselemente für jede Ressource, die in der Umgebung bereitgestellt wird.
Vereinfachte Ressourcenautorisierung in YAML-Pipelines
Eine Ressource ist alles, was von einer Pipeline außerhalb der Pipeline verwendet wird. Ressourcen müssen vor der Verwendung autorisiert werden. Zuvor war bei der Verwendung nicht autorisierter Ressourcen in einer YAML-Pipeline ein Fehler bei der Ressourcenautorisierung aufgetreten. Sie mussten die Ressourcen über die Zusammenfassungsseite der fehlgeschlagenen Ausführung autorisieren. Darüber hinaus ist für die Pipeline ein Fehler aufgetreten, wenn sie eine Variable verwendet hat, die auf eine nicht autorisierte Ressource verweist.
Wir erleichtern nun die Verwaltung von Ressourcenautorisierungen. Anstatt die Ausführung zu verfehlen, wartet die Ausführung zu Beginn der Phase, in der die Ressource verbraucht wird, auf Berechtigungen für die Ressourcen. Ein Ressourcenbesitzer kann die Pipeline anzeigen und die Ressource auf der Seite Sicherheit autorisieren.
Verbessern der Pipelinesicherheit durch Einschränken des Umfangs von Zugriffstoken
Jeder Auftrag, der in Azure Pipelines ausgeführt wird, erhält ein Zugriffstoken. Das Zugriffstoken wird von den Aufgaben und Von Ihren Skripts verwendet, um azure DevOps zurückzurufen. Beispielsweise verwenden wir das Zugriffstoken, um Quellcode abzurufen, Protokolle hochzuladen, Testergebnisse, Artefakte oder REST-Aufrufe in Azure DevOps durchzuführen. Für jeden Auftrag wird ein neues Zugriffstoken generiert, das nach Abschluss des Auftrags abläuft. Mit diesem Update haben wir die folgenden Verbesserungen hinzugefügt.
Verhindern des Zugriffs des Tokens auf Ressourcen außerhalb eines Teamprojekts
Bisher war der Standardbereich aller Pipelines die Teamprojektsammlung. Sie können den Bereich in klassischen Buildpipelines in das Teamprojekt ändern. Für klassische Release- oder YAML-Pipelines hatten Sie diese Kontrolle jedoch nicht. Mit diesem Update führen wir eine organization-Einstellung ein, um zu erzwingen, dass jeder Auftrag ein projektbezogenes Token erhält, unabhängig davon, was in der Pipeline konfiguriert ist. Außerdem haben wir die Einstellung auf Projektebene hinzugefügt. Nun wird diese Einstellung für jedes neue Projekt und organization, die Sie erstellen, automatisch aktiviert.
Hinweis
Die einstellung organization überschreibt die Projekteinstellung.
Das Aktivieren dieser Einstellung in vorhandenen Projekten und Organisationen kann dazu führen, dass bestimmte Pipelines fehlschlagen, wenn Ihre Pipelines mithilfe von Zugriffstoken auf Ressourcen außerhalb des Teamprojekts zugreifen. Um Pipelinefehler zu minimieren, können Sie dem Project Build-Dienstkonto explizit Zugriff auf die gewünschte Ressource gewähren. Es wird dringend empfohlen, diese Sicherheitseinstellungen zu aktivieren.
Entfernen bestimmter Berechtigungen für das Zugriffstoken
Standardmäßig gewähren wir eine Reihe von Berechtigungen für das Zugriffstoken. Eine dieser Berechtigungen ist Warteschlangenbuilds. Mit diesem Update haben wir diese Berechtigung für das Zugriffstoken entfernt. Wenn Ihre Pipelines diese Berechtigung benötigen, können Sie sie je nach dem verwendeten Token explizit dem Project Build-Dienstkonto oder dem Project Collection Build Service-Konto gewähren.
Artefaktprüfung auswerten
Sie können jetzt einen Satz von Richtlinien definieren und die Richtlinienauswertung als Überprüfung einer Umgebung für Containerimageartefakte hinzufügen. Wenn eine Pipeline ausgeführt wird, wird die Ausführung angehalten, bevor eine Phase gestartet wird, die die Umgebung verwendet. Die angegebene Richtlinie wird anhand der verfügbaren Metadaten für das bereitgestellte Image ausgewertet. Die Überprüfung wird erfolgreich abgeschlossen, wenn die Richtlinie erfolgreich ist, und markiert die Phase als fehlgeschlagen, wenn die Überprüfung fehlschlägt.
Markdownunterstützung in automatisierten Testfehlermeldungen
Wir unterstützen jetzt Markdown in Fehlermeldungen für automatisierte Tests. Sie können Problemlos Fehlermeldungen für Testausführung und Testergebnisse formatieren, um die Lesbarkeit zu verbessern und die Problembehandlung für den Fehler in Azure Pipelines zu vereinfachen. Die unterstützte Markdownsyntax finden Sie hier.
Diagnostizieren von Cronzeitplänen in YAML
Wir haben eine stetige Zunahme der Verwendung von Cron-Syntax zum Angeben von Zeitplänen in Ihren YAML-Pipelines beobachtet. Während wir Ihr Feedback gehört haben, haben wir erfahren, dass es für Sie schwierig war, festzustellen, ob Azure Pipelines Ihre Syntax ordnungsgemäß verarbeitet hatte. Zuvor mussten Sie auf die tatsächliche Zeit der geplanten Ausführung warten, um Zeitplanprobleme zu debuggen. Um Ihnen bei der Diagnose von Branch-/Syntaxfehlern zu helfen, haben wir ein neues Aktionsmenü für die Pipeline hinzugefügt. Mit den geplanten Ausführungen im Menü Pipeline ausführen erhalten Sie eine Vorschau auf die bevorstehenden geplanten Ausführungen für Ihre Pipeline, um Fehler mit Ihren Cron-Zeitplänen zu diagnostizieren.
Updates zum Bereitstellungstask der ARM-Vorlage
Zuvor haben wir die Dienstverbindungen nicht in der Arm-Vorlagenbereitstellungsaufgabe gefiltert. Dies kann dazu führen, dass die Bereitstellung fehlschlägt, wenn Sie eine Dienstverbindung mit niedrigerem Bereich auswählen, um ARM-Vorlagenbereitstellungen in einem breiteren Bereich durchzuführen. Jetzt haben wir die Filterung von Dienstverbindungen hinzugefügt, um Dienstverbindungen mit niedrigerem Umfang basierend auf dem von Ihnen ausgewählten Bereitstellungsbereich herauszufiltern.
Sicherheit auf Projektebene für Dienstverbindungen
Mit diesem Update haben wir die Sicherheit auf Hubebene für Dienstverbindungen hinzugefügt. Jetzt können Sie Benutzer hinzufügen/entfernen, Rollen zuweisen und den Zugriff für alle Dienstverbindungen zentral verwalten.
Ubuntu 18.04-Pool
Azure Pipelines unterstützt jetzt die Ausführung Ihrer Aufträge unter Ubuntu 18.04. Wir haben den von Microsoft gehosteten Azure Pipelines-Pool aktualisiert, um das Ubuntu-18.04-Image zu enthalten. Wenn Sie nun auf den Pool in Ihren YAML-Pipelines verweisen ubuntu-latest , bedeutet ubuntu-18.04 dies und nicht ubuntu-16.04. Sie können weiterhin 16.04-Images in Ihren Aufträgen verwenden, indem Sie explizit verwenden ubuntu-16.04 .
Service Mesh Interface-basierte Canary-Bereitstellungen im KubernetesManifest-Task
Wenn die Canary-Strategie zuvor im KubernetesManifest-Task angegeben wurde, wurden Mit der Aufgabe Baseline- und Canary-Workloads erstellt, deren Replikate einem Prozentsatz der Replikate entsprachen, die für stabile Workloads verwendet werden. Dies war nicht identisch mit dem Aufteilen des Datenverkehrs auf den gewünschten Prozentsatz auf Anforderungsebene. Um dies zu bewältigen, haben wir der KubernetesManifest-Aufgabe Unterstützung für Service Mesh Interface-basierte Canary-Bereitstellungen hinzugefügt.
Die Abstraktion der Service Mesh-Schnittstelle ermöglicht die Plug-and-Play-Konfiguration mit Service Mesh-Anbietern wie Linkerd und Istio. Nun nimmt die KubernetesManifest-Aufgabe die harte Arbeit, die TrafficSplit-Objekte von SMI den stabilen, Baseline- und Canary-Diensten während des Lebenszyklus der Bereitstellungsstrategie zuzuordnen. Die gewünschte prozentuale Aufteilung des Datenverkehrs zwischen Stable, Baseline und Canary ist genauer, da die prozentuale Datenverkehrsteilung für die Anforderungen in der Dienstgitterebene gesteuert wird.
Im Folgenden wird ein Beispiel für die fortlaufende Ausführung von SMI-basierten Canary-Bereitstellungen gezeigt.
- deployment: Deployment
displayName: Deployment
pool:
vmImage: $(vmImage)
environment: ignite.smi
strategy:
canary:
increments: [25, 50]
preDeploy:
steps:
- task: KubernetesManifest@0
displayName: Create/update secret
inputs:
action: createSecret
namespace: smi
secretName: $(secretName)
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy canary
inputs:
action: $(strategy.action)
namespace: smi
strategy: $(strategy.name)
trafficSplitMethod: smi
percentage: $(strategy.increment)
baselineAndCanaryReplicas: 1
manifests: |
manifests/deployment.yml
manifests/service.yml
imagePullSecrets: $(secretName)
containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
postRouteTraffic:
pool: server
steps:
- task: Delay@1
inputs:
delayForMinutes: '2'
ReviewApp in Environment
ReviewApp stellt jeden Pull Request aus Ihrem Git-Repository in einer dynamischen Umgebungsressource bereit. Prüfer können sehen, wie diese Änderungen aussehen und mit anderen abhängigen Diensten arbeiten, bevor sie in den Standard-Branch zusammengeführt und in der Produktion bereitgestellt werden. Dies erleichtert Ihnen das Erstellen und Verwalten von reviewApp-Ressourcen und profitieren von allen Nachverfolgbarkeits- und Diagnosefunktionen der Umgebungsfeatures. Mithilfe der reviewApp Schlüsselwort (keyword) können Sie einen Klon einer Ressource erstellen (dynamisch eine neue Ressource basierend auf einer vorhandenen Ressource in einer Umgebung erstellen) und die neue Ressource der Umgebung hinzufügen.
Im Folgenden finden Sie einen YAML-Beispielausschnitt zur Verwendung von reviewApp unter Umgebungen.
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MasterNamespace
Azure Artifacts
Aktualisierte Benutzeroberfläche "Verbinden mit Feed"
Das Dialogfeld Mit Feed verbinden ist der Einstieg in die Verwendung von Azure Artifacts. Enthält Informationen zum Konfigurieren von Clients und Repositorys zum Pushen und Pullen von Paketen aus Feeds in Azure DevOps. Wir haben das Dialogfeld aktualisiert, um detaillierte Informationen zur Einrichtung hinzuzufügen, und die Tools, für die wir Anweisungen geben, erweitert.
Öffentliche Feeds sind jetzt allgemein verfügbar mit Upstream Support
Die öffentliche Vorschau der öffentlichen Feeds hat große Akzeptanz und Feedback erhalten. In diesem Update haben wir zusätzliche Features auf die allgemeine Verfügbarkeit erweitert. Jetzt können Sie einen öffentlichen Feed als Upstream Quelle aus einem privaten Feed festlegen. Sie können Ihre Konfigurationsdateien einfach halten, indem Sie sowohl zu und aus privaten als auch projektbezogenen Feeds Upstream können.
Erstellen projektbezogener Feeds über das Portal
Als wir öffentliche Feeds veröffentlicht haben, haben wir auch projektbezogene Feeds veröffentlicht. Bisher konnten projektbezogene Feeds über REST-APIs oder durch Erstellen eines öffentlichen Feeds erstellt werden und das Projekt dann privat machen. Jetzt können Sie projektbezogene Feeds direkt im Portal aus jedem Projekt erstellen, wenn Sie über die erforderlichen Berechtigungen verfügen. Sie können auch sehen, welche Feeds Projekt sind und welche in der Feedauswahl organization sind.
Berichterstellung
Ein Sprint Burndown-Widget mit allem, was Sie gefragt haben
Das neue Sprint Burndown-Widget unterstützt das Brennen nach Story Points, Anzahl von Aufgaben oder durch Summieren benutzerdefinierter Felder. Sie können sogar einen Sprint-Burndown für Features oder Epics erstellen. Das Widget zeigt durchschnittlichen Burndown, % abgeschlossen und Bereichsvergrößerung an. Sie können das Team konfigurieren, sodass Sie Sprint-Burndowns für mehrere Teams auf demselben Dashboard anzeigen können. Mit all diesen großartigen Informationen, die angezeigt werden sollen, können Sie die Größe auf dem Dashboard auf bis zu 10 x 10 ändern.
Um es auszuprobieren, können Sie es aus dem Widgetkatalog hinzufügen, oder indem Sie die Konfiguration für das vorhandene Sprint Burndown-Widget bearbeiten und das Kontrollkästchen Neue Version jetzt testen aktivieren.
Hinweis
Das neue Widget verwendet Analytics. Wir haben den Legacy-Sprint-Burndown beibehalten, falls Sie keinen Zugriff auf Analytics haben.
Wiki
Synchroner Bildlauf zum Bearbeiten von Wikiseiten
Das Bearbeiten von Wikiseiten ist jetzt einfacher mit synchronem Scrollen zwischen dem Bearbeitungs- und dem Vorschaubereich. Beim Scrollen auf der einen Seite wird automatisch die andere Seite scrollen, um die entsprechenden Abschnitte zu zuordnen. Sie können den synchronen Bildlauf mit der Umschalttaste deaktivieren.
Hinweis
Der Zustand der synchronen Scroll-Umschaltfläche wird pro Benutzer und organization gespeichert.
Seitenbesuche für Wiki-Seiten
Sie können jetzt Einblicke in die Seitenbesuche für Wiki-Seiten erhalten. Mit der REST-API können Sie auf die Seitenbesuchsinformationen der letzten 30 Tage zugreifen. Sie können diese Daten verwenden, um Berichte für Ihre Wiki-Seiten zu erstellen. Darüber hinaus können Sie diese Daten in Ihrer Datenquelle speichern und Dashboards erstellen, um bestimmte Erkenntnisse wie die am häufigsten angezeigten Seiten zu erhalten.
Außerdem wird eine aggregierte Anzahl der Seitenaufrufe für die letzten 30 Tage auf jeder Seite angezeigt.
Hinweis
Ein Seitenbesuch wird als Seitenansicht eines bestimmten Benutzers in einem Intervall von 15 Minuten definiert.
Nächste Schritte
Hinweis
Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.
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
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für