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 Brennen nach Storypunkten, die Anzahl der Aufgaben und das Addieren von benutzerdefinierten Feldern unterstützt. Zusätzlich wurde die Pipelinesicherheit verbessert, indem der Geltungsbereich von Zugriffstokens eingeschränkt wurde.

Weitere Informationen finden Sie in der Nachstehenden Liste der Features .

Neuerungen in Azure DevOps

Features

Azure Repos:

• Verwalten von repositoryübergreifenden Branchrichtlinien

Azure Pipelines:

• Benutzeroberfläche für mehrstufige Pipelines
• Orchestrieren von Bereitstellungsstrategien für Canary in Kubernetes-Umgebungen
• Genehmigungsrichtlinien für YAML-Pipelines
• ACR als erstklassige Pipelineressource
• Metadaten von Pipelineressourcen als vordefinierte Variablen
• Rückverfolgbarkeit für Pipelines und ACR-Ressourcen
• Vereinfachte Ressourcenautorisierung in YAML-Pipelines
• Verbessern der Pipelinesicherheit durch Einschränken des Geltungsbereichs von Zugriffstoken
• Auswerten von Artefaktüberprüfungen
• Markdownunterstützung in Fehlermeldungen für automatisierte Tests
• Diagnostizieren von Cron-Zeitplänen in YAML
• Aktualisierungen der Bereitstellungsaufgabe der ARM-Vorlage
• Sicherheit für Dienstverbindungen auf Projektebene
• Ubuntu 18.04-Pool
• Service Mesh Interface-basierte Canary-Bereitstellungen für KubernetesManifest-Tasks
• ReviewApp in der Umgebung

Azure Artifacts:

• Aktualisierte Benutzeroberfläche für „Verbindung mit Feed herstellen“
• Öffentliche Feeds jetzt einschließlich Upstreamunterstützung allgemein verfügbar
• Erstellen projektbezogener Feeds über das Portal

Berichterstellung:

• Ein Sprint Burndown-Widget mit allem, was Sie gefragt haben

Wiki:

• Synchrones Scrollen zum Bearbeiten von Wiki-Seiten
• Seitenaufrufe für Wiki-Seiten

Azure Repos

Verwalten von repositoryübergreifenden Branchrichtlinien

Verzweigungsrichtlinien sind eines der leistungsstarken Features von Azure Repos, die Ihnen dabei helfen, wichtige Zweigstellen zu schützen. 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 eine bestimmte Verzweigung oder die Standardbranch für alle Repositorys in ihrem Projekt festlegen. Beispielsweise könnte ein Administrator zwei Mindestprüfer für alle Pullanforderungen benötigen, die in jeder Hauptverzweigung in jedem Repository in ihrem Projekt vorgenommen wurden. Sie finden das Feature "Verzweigungsschutz hinzufügen" in den Projekteinstellungen von Repos.

Azure Pipelines

Benutzeroberfläche 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 bringen diese Updates klassische Buildpipelinen und mehrstufige YAML-Pipelines zu einer einzigen Oberfläche zusammen. Die folgenden Funktionen sind beispielsweise in der neuen Oberfläche enthalten. Anzeigen und Verwalten mehrerer Phasen, Genehmigen von Pipelineausführungen, Möglichkeit, in Protokollen zurück zu scrollen, während eine Pipeline noch ausgeführt wird, und die Integrität pro Verzweigung einer Pipeline.

Vielen Dank an alle, die die neue Erfahrung ausprobiert haben. Wenn Sie es 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 folgendes in den letzten beiden Updates angesprochen.

1. Auffindbarkeit der Ordneransicht.
2. Sprunghaftigkeit in der Protokollansicht.
3. Anzeigen von Protokollen aus vorherigen und aktuellen Vorgängen auch dann, wenn eine Ausführung ausgeführt wird.
4. Vereinfachen Sie die Navigation zwischen Aufgaben beim Überprüfen von Protokollen.

Orchestrieren von Bereitstellungsstrategien für Canary in Kubernetes-Umgebungen

Einer der wichtigsten Vorteile der kontinuierlichen Bereitstellung von Anwendungsupdates ist die Möglichkeit, Updates schnell in die Produktion für bestimmte Microservices zu übertragen. Dadurch erhalten 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 Veröffentlichungen ohne Ausfallzeiten erleichtert. Zuvor haben wir die runOnce-Strategie unterstützt, die die Schritte einmal sequenziell ausführte. Mit Unterstützung für die Canarystrategie in mehrstufigen Pipelines können Sie das Risiko jetzt reduzieren, indem Sie die Änderung langsam in eine kleine Teilmenge einführen. Wenn Sie mehr Vertrauen in die neue Version gewinnen, können Sie damit beginnen, sie auf mehr Servern in Ihrer Infrastruktur bereitzustellen und weitere 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'
      postRouteTraffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Die Canarystrategie für Kubernetes wird zuerst die Änderungen mit 10 % Pods bereitstellen, gefolgt von 20 % während der Überwachung der Integrität während postRouteTraffic. Wenn alles gut geht, wird es auf 100 % heraufstufen.

Genehmigungsrichtlinien für YAML-Pipelines

In YAML-Pipelines folgen wir einer vom Ressourcenbesitzer gesteuerten Genehmigungskonfiguration. Ressourcenbesitzer konfigurieren Genehmigungen für die Ressource und alle Pipelines, die die Ressourcenpause für Genehmigungen vor Beginn der Phase verwenden, die die Ressource verbraucht. Es ist üblich, dass SOX-basierte Anwendungsbesitzer den Anforderer der Bereitstellung daran hindern, ihre eigenen Bereitstellungen zu genehmigen.

Sie können jetzt erweiterte Genehmigungsoptionen verwenden, um Genehmigungsrichtlinien wie den Antragsteller zu konfigurieren, die Genehmigung von einer Teilmenge von Benutzern und genehmigungstimeout erforderlich zu machen.

ACR als erstklassige Pipelineressource

Wenn Sie ein containerimage verwenden müssen, das als Teil Ihrer Pipeline in ACR (Azure Container Registry) veröffentlicht wurde und Ihre Pipeline auslöst, sobald ein neues Image veröffentlicht wurde, 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 können auf ACR-Bildmetadaten mithilfe vordefinierter Variablen 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

Metadaten von Pipelineressourcen 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

Rückverfolgbarkeit 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 verbraucht wird, können Sie die Commits, Arbeitsaufgaben und Artefakte zurückverfolgen.

In der Zusammenfassungsansicht "Pipelineausführung" können Sie Folgendes sehen:

• Die Ressourcenversion, die die Ausführung ausgelöst hat. Jetzt kann Ihre Pipeline nach Abschluss einer anderen Azure-Pipelineausführung ausgelöst werden oder wenn ein Containerimage an ACR weitergeleitet wird.

  

• Die Commits , die von der Pipeline verbraucht werden. Sie finden auch die Aufschlüsselung der Commits nach jeder Ressource, die von der Pipeline verbraucht wird.

  

• Die Arbeitsaufgaben , die den einzelnen Ressourcen zugeordnet sind, die von der Pipeline verbraucht werden.

• Die Artefakte , die von der Ausführung verwendet werden können.

  

In der Bereitstellungsansicht der Umgebung können Sie die Commits und Arbeitsaufgaben für jede Ressource anzeigen, die in der Umgebung bereitgestellt wird.

Vereinfachte Ressourcenautorisierung in YAML-Pipelines

Eine Ressource ist alles, was von einer Pipeline verwendet wird, die sich außerhalb der Pipeline befindet. Ressourcen müssen vor der Verwendung autorisiert werden. Zuvor ist bei der Verwendung nicht autorisierter Ressourcen in einer YAML-Pipeline ein Fehler bei der Ressourcenautorisierung aufgetreten. Sie mussten die Ressourcen auf der Zusammenfassungsseite der fehlgeschlagenen Ausführung autorisieren. Darüber hinaus ist die Pipeline fehlgeschlagen, wenn sie eine Variable verwendet hat, die auf eine nicht autorisierte Ressource verweist.

Wir machen es jetzt einfacher, Ressourcenautorisierungen zu verwalten. Anstatt die Ausführung fehlschlagen, wartet die Ausführung auf Berechtigungen für die Ressourcen zu Beginn der Phase, in der die Ressource verbraucht wird. Ein Ressourcenbesitzer kann die Pipeline anzeigen und die Ressource über die Seite "Sicherheit" autorisieren.

Verbessern der Pipelinesicherheit durch Einschränken des Geltungsbereichs 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 in Azure DevOps zurückzurufen. Beispielsweise verwenden wir das Zugriffstoken, um Quellcode abzurufen, Protokolle hochzuladen, Testergebnisse, Artefakte oder REST-Aufrufe in Azure DevOps auszuführen. Ein neues Zugriffstoken wird für jeden Auftrag generiert und läuft nach Abschluss des Auftrags ab. Mit diesem Update haben wir die folgenden Verbesserungen hinzugefügt.

• Verhindern, dass das Token auf Ressourcen außerhalb eines Teamprojekts zugreift

  Bisher war der Standardumfang aller Pipelines die Teamprojektsammlung. Sie können den Bereich ändern, um das Teamprojekt in klassischen Buildpipelines zu sein. Sie haben jedoch nicht über dieses Steuerelement für klassische Release- oder YAML-Pipelines verfügen. Mit diesem Update führen wir eine Organisationseinstellung ein, um zu erzwingen, dass jeder Auftrag ein Projektbereichstoken erhält, unabhängig davon, was in der Pipeline konfiguriert ist. Außerdem wurde die Einstellung auf Projektebene hinzugefügt. Jetzt wird diese Einstellung für jedes neue Projekt und jede von Ihnen erstellte Organisation automatisch aktiviert.

  Hinweis

  Die Organisationseinstellung setzt die Projekteinstellung außer Kraft.

  Das Aktivieren dieser Einstellung in vorhandenen Projekten und Organisationen kann dazu führen, dass bestimmte Pipelines fehlschlagen, wenn Ihre Pipelines auf Ressourcen zugreifen, die sich außerhalb des Teamprojekts befinden, mithilfe von Zugriffstoken. Um Pipelinefehler zu mindern, können Sie explizit project Build Service Account 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 dem Zugriffstoken eine Reihe von Berechtigungen, 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 dem Project Build Service Account oder dem Project Collection Build Service Account je nach verwendeten Token explizit erteilen.

Auswerten von Artefaktüberprüfungen

Sie können jetzt eine Reihe 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 Prüfung wird übergeben, wenn die Richtlinie erfolgreich ist, und kennzeichnet die Phase als fehlgeschlagen, wenn die Überprüfung fehlschlägt.

Markdownunterstützung in Fehlermeldungen für automatisierte Tests

Wir unterstützen Markdown jetzt in Fehlermeldungen für automatisierte Tests. Sie können Fehlermeldungen sowohl für testausführungs- als auch für Testergebnisse einfach formatieren, um die Lesbarkeit zu verbessern und die Fehlerbehandlung in Azure Pipelines zu vereinfachen. Die unterstützte Markdown-Syntax finden Sie hier.

Diagnostizieren von Cron-Zeitplänen in YAML

Wir haben eine stetige Zunahme der Verwendung von Cron-Syntax zur Angabe von Zeitplänen in Ihren YAML-Pipelines gesehen. Da wir Uns Ihr Feedback anhörten, haben wir gehört, dass es für Sie schwierig war zu ermitteln, ob Azure Pipelines Ihre Syntax richtig verarbeitet hatten. Zuvor müssten Sie auf die tatsächliche Zeit der geplanten Ausführung warten, um Zeitplanprobleme zu debuggen. Um Verzweigungs-/Syntaxfehler zu diagnostizieren, haben wir ein neues Aktionsmenü für die Pipeline hinzugefügt. Die geplante Ausführung im Menü "Pipeline ausführen" gibt Ihnen eine Vorschau der bevorstehenden geplanten Ausführungen für Ihre Pipeline, um Fehler mit Ihren Cron-Zeitplänen zu diagnostizieren.

Aktualisierungen der Bereitstellungsaufgabe der ARM-Vorlage

Zuvor haben wir die Dienstverbindungen in der BEREITSTELLUNGsaufgabe der ARM-Vorlage nicht gefiltert. Dies kann dazu führen, dass die Bereitstellung fehlschlägt, wenn Sie eine Verbindung mit einem niedrigeren Bereich auswählen, um ARM-Vorlagenbereitstellungen in einem breiteren Bereich auszuführen. Jetzt haben wir die Filterung von Dienstverbindungen hinzugefügt, um basierend auf dem von Ihnen ausgewählten Bereitstellungsbereich dienstbezogene Verbindungen herauszufiltern.

Sicherheit für Dienstverbindungen auf Projektebene

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 an einem zentralen Ort für alle Dienstverbindungen verwalten.

Ubuntu 18.04-Pool

Azure Pipelines unterstützt jetzt das Ausführen Ihrer Aufträge auf Ubuntu 18.04. Wir haben den von Microsoft gehosteten Azure Pipelines-Pool aktualisiert, um das Ubuntu-18.04-Image einzuschließen. 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-Bilder in Ihren Aufträgen verwenden, indem ubuntu-16.04 Sie explizit verwenden.

Service Mesh Interface-basierte Canary-Bereitstellungen für KubernetesManifest-Tasks

Als zuvor die Canary-Strategie in der KubernetesManifest-Aufgabe angegeben wurde, erstellt die Aufgabe geplante und canarylasten, deren Replikate einem Prozentsatz der Replikate entsprechen, die für stabile Workloads verwendet werden. Dies war nicht genau identisch mit dem Aufteilen des Datenverkehrs bis zum gewünschten Prozentsatz auf Anforderungsebene. Um dies zu bewältigen, haben wir Unterstützung für Service Mesh Interface-basierte Canary-Bereitstellungen zur KubernetesManifest-Aufgabe hinzugefügt.

Die Abstraktion von Service Mesh Interface ermöglicht die Plug-and-Play-Konfiguration mit Dienstanbietern wie Linkerd und Istio. Jetzt nimmt die KubernetesManifest-Aufgabe die harte Arbeit der Zuordnung von SMI-TrafficSplit-Objekten zu den stabilen, Basisplan- und Canary-Diensten während des Lebenszyklus der Bereitstellungsstrategie ab. Die gewünschte prozentuale Aufteilung des Datenverkehrs zwischen stabilen, Basislinien und Canaryn ist genauer, da die prozentuale Datenverkehrsteilung für die Anforderungen in der Dienstgitterebene gesteuert wird.

Im Folgenden sehen Sie ein Beispiel für die Durchführung von SMI-basierten Canarybereitstellungen auf rollierende Weise.

- 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 der Umgebung

ReviewApp stellt jede Pullanforderung 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 mit der Hauptverzweigung zusammengeführt und in der Produktion bereitgestellt werden. Dies erleichtert Ihnen das Erstellen und Verwalten von ReviewApp-Ressourcen und profitiert von allen Funktionen zur Rückverfolgbarkeit und Diagnose der Umgebungsfeatures. Mithilfe des Schlüsselworts "reviewApp " können Sie einen Klon einer Ressource erstellen (dynamisch eine neue Ressource basierend auf einer vorhandenen Ressource in einer Umgebung erstellen) und der Umgebung die neue Ressource hinzufügen.

Es folgt ein Beispiel für einen YAML-Codeausschnitt der 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 für „Verbindung mit Feed herstellen“

Das Dialogfeld "Mit Feed verbinden" ist der Einstieg in die Verwendung von Azure Artifacts; sie enthält Informationen zum Konfigurieren von Clients und Repositorys zum Pushen und Abrufen von Paketen aus Feeds in Azure DevOps. Wir haben das Dialogfeld aktualisiert, um detaillierte Einrichtungsinformationen hinzuzufügen und die Tools, für die wir Anweisungen geben, erweitert.

Öffentliche Feeds jetzt einschließlich Upstreamunterstützung allgemein verfügbar

Die öffentliche Vorschau öffentlicher 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 Upstreamquelle aus einem privaten Feed festlegen. Sie können Ihre Konfigurationsdateien einfach halten, indem Sie sowohl private als auch projektbezogene Feeds vor- und heraufführen können.

Erstellen projektbezogener Feeds über das Portal

Wenn 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 und dann das Projekt privat gedreht werden. Jetzt können Sie projektbezogene Feeds direkt im Portal aus einem beliebigen Projekt erstellen, wenn Sie über die erforderlichen Berechtigungen verfügen. Sie können auch sehen, welche Feeds Projekt sind und welche in der Feedauswahl auf den Bereich "Organisation" ausgerichtet sind.

Reporting

Ein Sprint Burndown-Widget mit allem, was Sie gefragt haben

Das neue Sprint Burndown-Widget unterstützt das Brennen von Story Points, die Anzahl der Aufgaben oder das Addieren von benutzerdefinierten Feldern. Sie können sogar einen Sprint-Burndown für Features oder Epics erstellen. Das Widget zeigt die durchschnittliche Burndown-, % abgeschlossene 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 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 die Konfiguration für das vorhandene Sprint Burndown-Widget bearbeiten und das Kontrollkästchen "Jetzt testen" überprüfen.

Wiki

Synchrones Scrollen zum Bearbeiten von Wiki-Seiten

Das Bearbeiten von Wiki-Seiten ist jetzt mit synchroner Bildlauf zwischen dem Bearbeitungsbereich und dem Vorschaubereich einfacher. Wenn Sie auf einer Seite scrollen, scrollen Sie automatisch auf der anderen Seite, um die entsprechenden Abschnitte zuzuordnen. Sie können den synchronen Bildlauf mit der Umschaltfläche deaktivieren.

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 in den letzten 30 Tagen auf die Seitenbesuchsinformationen 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 Einblicke wie die am häufigsten angezeigten Seiten zu erhalten.

Außerdem wird eine Anzahl aggregierter Seitenbesuche für die letzten 30 Tage auf jeder Seite angezeigt.

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