Öffentliche Vorschau für neue Boards Hubs

  • Artikel

New Boards Hubs ist jetzt in der öffentlichen Vorschau verfügbar. Die Webplattform wurde aktualisiert, um ein neues modernes Design, reaktionsfähige Reflows, Barrierefreiheitskonformität und eine verbesserte Seitenleistung zu bieten.

Weitere Informationen finden Sie in den Versionshinweisen.

Allgemein

Azure Boards

Azure Pipelines

Allgemein

Die Überwachung ist jetzt ein Opt-In-Feature für Ihre organization

Die Überwachung wurde jetzt als Opt-In-Funktion für Azure DevOps festgelegt. Wenn Ihr organization die Überwachung heute nicht aktiv verwendet (d. h. Überwachungsprotokolle in den letzten 90 Tagen mindestens zweimal besucht oder einen konfigurierten Überwachungsstream konfiguriert haben), müssen Sie explizit Das Überwachungsfeature aktivieren, damit Ihr organization damit beginnen kann. Nach dem Aktivieren werden Überwachungsereignisse in das Überwachungsprotokoll Ihres organization aufgenommen. Für Organisationen, die aktive Benutzer der Überwachung sind, bleibt das Feature ein.

Sie können die Überwachung auf Ihrer organization auf der Seite mit den Organisationseinstellungen aktivieren.

Auf der rechten Seitenleiste sehen Sie Richtlinien unter dem Sicherheitsheader. Vorausgesetzt, Ihre organization wird von Azure Active Directory unterstützt, sollten Sie sehen, dass eine der verfügbaren Sicherheitsrichtlinien für die Aktivierung Protokollüberwachungsereignisse ist. MSA-gestützte Organisationen verfügen nicht mehr über die Überwachungsfeatures.

Überwachen von Ereignissen

Schalten Sie einfach diese Richtlinie ein und Überwachung sollte jetzt verfügbar sein (wenn sie nicht sofort angezeigt wird, aktualisieren Sie die Seite, und sie sollte verfügbar sein). Wenn Sie keine Überwachungsereignisse mehr empfangen möchten, schalten Sie die Schaltfläche auf Aus um. Wenn die Schaltfläche deaktiviert ist, wird die Seite Überwachung nicht mehr in der Seitenleiste angezeigt, und die Seite Überwachungsprotokolle ist nicht verfügbar. Alle konfigurierten Überwachungsdatenströme empfangen keine Ereignisse mehr.

Gastbenutzer werden nur öffentliche Benutzerdaten angezeigt.

Wenn die Richtlinie für den externen Gastzugriffdeaktiviert und die Richtlinie Öffentliche Projektezulassen aktiviert ist, können Gastbenutzer öffentliche Benutzerdaten wie Anzeigename usw. nur für Mitglieder öffentlicher Projekte anzeigen. Dies ist die gleiche Erfahrung, die anonymen Benutzern gewährt wird. Dies gilt für alle personenbezogenen Daten, die über das Weberlebnis verfügbar sind (z. B. in der Identitätsauswahl, die angezeigt wird, wenn ein Benutzer versucht, einen anderen Benutzer zu Erwähnung oder Arbeitselemente zuzuweisen) und alle personenbezogenen Daten, die über unsere REST-APIs verfügbar sind.

Azure Boards

Neue Boards Hubs jetzt in der öffentlichen Vorschau verfügbar

In den letzten Monaten hat sich unser Team auf die Modernisierung der Benutzeroberfläche für die Azure Boards Hubs konzentriert. Die Benutzeroberfläche wurde aktualisiert, um eine schnellere Benutzeroberfläche, Konsistenz mit anderen Teilen des Produkts und eine verbesserte Barrierefreiheit zu bieten. Das Team freut sich, endlich die öffentliche Vorschau für das neue Azure Boards-Erlebnis ankündigen zu können.

Die Funktionalität bleibt unverändert, aber Sie können Folgendes erwarten:

  • Modernes Design
  • Reaktionsschnelle Reflows
  • Verbesserte Leistung
  • Kompatibilität mit Barrierefreiheit

Wenn Sie sich für die öffentliche Vorschauversion anmelden möchten, schalten Sie im Abschnitt Vorschaufeatures das Feature "New Boards Hubs" auf Ein um.

Gif zum Demo-Opt-In für die öffentliche Vorschau.

Wenn die neuen Boards-Hubs aus irgendeinem Grund ein Blockierungsproblem verursachen, können Sie die Vorschau deaktivieren. Aber bitte probieren Sie die neue Erfahrung aus und senden Sie uns Ihr Feedback. Informieren Sie uns unbedingt, wenn etwas fehlt oder nicht wie erwartet funktioniert.

Azure Pipelines

Erweiterte YAML-Pipelines-Vorlagen können jetzt Kontextinformationen für Phasen, Aufträge und Bereitstellungen übergeben werden.

Mit diesem Update fügen wir eine neue templateContext Eigenschaft für job, deploymentund stage YAML-Pipelinekomponenten hinzu, die in Verbindung mit Vorlagen verwendet werden sollen.

Hier sehen Sie ein Szenario für die Verwendung templateContext:

  • Sie verwenden Vorlagen, um Codeduplizierung zu reduzieren oder die Sicherheit Ihrer Pipelines zu verbessern.

  • Ihre Vorlage verwendet als Parameter eine Liste von stages, jobsoder deployments

  • Die Vorlage verarbeitet die Eingabeliste und führt einige Transformationen für die einzelnen Phasen, Aufträge oder Bereitstellungen durch. Sie legt beispielsweise die Umgebung fest, in der jeder Auftrag ausgeführt wird, oder fügt zusätzliche Schritte hinzu, um die Compliance zu erzwingen.

  • Für die Verarbeitung müssen zusätzliche Informationen vom Pipelineautor an die Vorlage für jede Phase, jeden Auftrag oder jede Bereitstellung in der Liste übergeben werden.

Schauen wir uns ein Beispiel an. Angenommen, Sie erstellen eine Pipeline, die End-to-End-Tests für die Überprüfung von Pull Request ausführt. Ihr Ziel besteht darin, nur eine Komponente Ihres Systems zu testen. Da Sie jedoch End-to-End-Tests ausführen möchten, benötigen Sie eine Umgebung, in der mehr Komponenten des Systems verfügbar sind, und Sie müssen deren Verhalten angeben.

Sie erkennen, dass andere Teams ähnliche Anforderungen haben werden, daher entscheiden Sie sich, die Schritte zum Einrichten der Umgebung in eine Vorlage zu extrahieren. Der Code sieht wie folgt aus:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Die Vorlage legt für jeden Auftrag im testSet Parameter die Antwort der Systemkomponenten fest, die durch ${{ testJob.templateContext.requiredComponents }} angegeben wurden, um ${{ testJob.templateContext.expectedHTTPResponseCode }} zurückzugeben.

Anschließend können Sie Eine eigene Pipeline erstellen, die wie im folgenden Beispiel erweitert wird testing-template.yml .

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Diese Pipeline führt zwei Tests aus, einen positiven und einen negativen. Für beide Tests muss die dimensionsapi Komponente verfügbar sein. Der positive_test Auftrag erwartet den dimensionsapi http-Rückgabecode 200, während negative_test er HTTP-Code 500 zurückgibt.

Datum der Einstellung für gehostete Windows 2016-Images aktualisiert

Wir haben das Einstellungsdatum für Windows 2016-Images vom 1. April auf den 30. Juni verschoben. Während die meisten Kunden, die dieses Image verwenden, ihre Pipelines aktualisiert haben, gibt es immer noch Kunden, die dieses Image verwenden. Um zu überprüfen, ob Ihr organization Windows 2016 verwendet, verwenden Sie diese Anweisungen, um Pipelines mithilfe veralteter Images zu identifizieren.

Um Kunden bei der Identifizierung von Pipelines zu unterstützen, führen wir weiterhin Brownouts durch. Dies sind 24-Stunden-Zeiträume, in denen das Image nicht verfügbar ist, was dazu führt, dass Pipelineaufträge, die in dieser Zeit ausgeführt werden, fehlschlagen. Die Brownouts erfolgen bei:

  • Montag, 18. April
  • Dienstag, 26. April
  • Mittwoch, 4. Mai
  • Donnerstag, 12. Mai
  • Freitag, 20. Mai
  • Montag, 23. Mai
  • Dienstag, 31. Mai
  • Mittwoch, 8. Juni
  • Donnerstag, 16. Juni
  • Freitag, 24. Juni
  • Montag, 27. Juni

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.

Navigieren Sie zu Azure DevOps.

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.

Einen Vorschlag unterbreiten

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

Vielen Dank,

Aaron Hallberg