Freigeben über

Neue Analyseberichte und Azure Boards-App für Slack – Sprint 155 Update

  • Artikel

Mit dem Azure DevOps-Update aus Sprint 155 werden neue Azure Boards-Berichte eingeführt, die es Ihnen erleichtern, wichtige Teammetriken im Blick zu behalten. Die neuen Berichte werden auf der Registerkarte „Analyse“ in den Boards-, Backlog- und Sprint-Hubs angezeigt. Die Berichte sind interaktiv und können dadurch ganz nach Ihren Anforderungen angepasst werden.

Zusätzlich freuen wir uns, die neue Azure Boards-App für Slack ankündigen zu können. Mit dieser App können Sie die Aktivität von Arbeitselementen überwachen und über Ihren Slack-Kanal Arbeitselemente erstellen.

Weitere Informationen finden Sie in der Nachstehenden Liste der Features .

Neuerungen in Azure DevOps

Features

General:

Azure Boards:

Azure Repos:

Azure Artifacts:

Azure Pipelines:

Multi-stage YAML pipelines (Mehrstufige YAML-Pipelines)

  Gehostete VMs

Kubernetes

Testen

  Azure-Features

Integrationen

Allgemein

Invite GitHub collaborators into Azure DevOps (Einladen von beitragenden GitHub-Benutzern in Azure DevOps)

Sie können jetzt Mitarbeiter von GitHub zu Azure DevOps einladen, wenn Sie mit Ihrer GitHub-Identität angemeldet sind. Sie können andere GitHub-Benutzer von der Project-Homepage und von der Seite "Benutzer" in den Organisationseinstellungen durchsuchen und einladen.

Invite GitHub collaborators into Azure DevOps.

Diese Funktion muss für vorhandene Organisationen über eine Einstellung unter "Richtlinien " in den Organisationseinstellungen aktiviert werden. Sie ist jedoch standardmäßig für Organisationen aktiviert, die von einer GitHub-Identität erstellt wurden.

Enable for existing organizations.

Hinweis

Dieses Feature ist nicht für Nicht-GitHub-Benutzer verfügbar, auch wenn die Richtlinie aktiviert ist.

Weitere Informationen zum Einladen von Teammitgliedern finden Sie in der Dokumentation hier. Wenn Sie Probleme beim Herstellen einer Verbindung mit Azure DevOps mithilfe von GitHub haben, lesen Sie die Häufig gestellte Fragen zur Problembehandlung bei der Authentifizierung und Einladung von GitHub-Benutzern.

Azure Boards

Get insights into your team’s health with three new Azure Boards reports (Überwachen des Teamstatus mit drei neuen Azure Boards-Berichten)

Sie können nicht beheben, was sie nicht sehen können. Daher möchten Sie den Zustand und die Gesundheit ihrer Arbeitsprozesse genau im Auge behalten. Mit diesen Berichten erleichtern wir Es Ihnen, wichtige Metriken mit minimalem Aufwand in Azure Boards nachzuverfolgen.

Die drei neuen interaktiven Berichte sind: Burndown, Kumulatives Flussdiagramm (CFD) und Velocity. Sie können die Berichte auf der neuen Registerkarte "Analyse" sehen.

Metriken wie Sprint-Burndown, Arbeitsfluss und Teamgeschwindigkeit geben Ihnen die Einblicke in den Fortschritt Ihres Teams und helfen Ihnen bei der Beantwortung von Fragen wie:

  • Wie viel Arbeit haben wir in diesem Sprint verlassen? Sind wir auf dem Weg, es abzuschließen?
  • Welcher Schritt des Entwicklungsprozesses dauert am längsten? Können wir etwas dagegen tun?
  • Basierend auf vorherigen Iterationen, wie viel Arbeit sollten wir für den nächsten Sprint planen?

Hinweis

Die zuvor in den Kopfzeilen gezeigten Diagramme wurden durch diese erweiterten Berichte ersetzt.

Die neuen Berichte sind vollständig interaktiv und ermöglichen Es Ihnen, sie an Ihre Anforderungen anzupassen. Sie finden die neuen Berichte auf der Registerkarte "Analyse" in jedem Hub.

  • Das Burndowndiagramm befindet sich unter dem Sprints-Hub .

    Analytics tab in Sprint hub.

  • Auf die CFD- und Velocity-Berichte kann über die Registerkarte "Analyse" unter "Boards" und "Backlogs" zugegriffen werden, indem Sie auf die relevanten Karte klicken.

    CFD and velocity reports in boards.

Mit den neuen Berichten haben Sie mehr Kontrolle und Informationen zu Ihrem Team. Im Folgenden finden Sie einige Beispiele:

  • Der Sprint Burndown und die Geschwindigkeitsberichte können so festgelegt werden, dass die Anzahl der Arbeitsaufgaben oder die Summe der neu Standard arbeit verwendet werden kann.
  • Sie können den Zeitrahmen des Sprint-Burndowns anpassen, ohne dass sich dies auf die Projekttermine auswirkt. Wenn Ihr Team also in der Regel den ersten Tag jeder Sprintplanung verbringt, können Sie jetzt mit dem Diagramm übereinstimmen, um das widerzuspiegeln.
  • Das Burndown-Diagramm verfügt jetzt über ein Wasserzeichen mit Wochenenden.
  • Mit dem CFD-Bericht können Sie Boardspalten wie Design entfernen, um mehr Fokus auf den Fluss zu erhalten, auf den die Teams kontrolle haben.

Hier ist ein Beispiel für den CFD-Bericht, der den Fluss für die letzten 30 Tage des Stories-Backlogs zeigt.

Example of the CFD report.

Das Geschwindigkeitsdiagramm kann jetzt für alle Backlogebenen nachverfolgt werden. Beispielsweise können Sie jetzt features und Epics hinzufügen, während vor dem vorherigen Diagramm nur Anforderungen unterstützt werden. Hier ist ein Beispiel für einen Geschwindigkeitsbericht für die letzten 6 Iterationen des Features-Backlogs.

Example of a velocity report.

Azure Boards app for Slack (Azure Boards-App für Slack)

Wir freuen uns, die neue Azure Boards-App für Slack bekanntzugeben. Mit dieser App können Sie die Aktivität von Arbeitsaufgaben überwachen und Arbeitsaufgaben aus Ihrem Slack-Kanal erstellen.

Die App ermöglicht Ihnen das Einrichten und Verwalten von Ereignisabonnements, einschließlich Erstellungs- und Arbeitsaufgabenaktualisierungen und das Abrufen von Benachrichtigungen für diese Ereignisse in Ihrem Slack-Kanal. Die Unterhaltungen im Slack-Kanal können zum Erstellen von Arbeitsaufgaben verwendet werden. Außerdem erhalten Sie persönliche Benachrichtigungen, wenn Ihnen Arbeitsaufgaben zugewiesen sind. Darüber hinaus können Sie in der Vorschau für UrLs für Arbeitsaufgaben Diskussionen initiieren.

Azure Boards app for Slack.

Klicken Sie hier, um die Azure Boards-App zu installieren.

Anpassen von Taskboardspalten

Wir freuen uns, ihnen mitzuteilen, dass wir eine Option hinzugefügt haben, mit der Sie die Spalten im Taskboard anpassen können. Sie können jetzt die Spalten hinzufügen, entfernen, umbenennen und neu anordnen.

Um die Spalten in Ihrem Taskboard zu konfigurieren, wechseln Sie zu "Spaltenoptionen".

Customizing columns on the taskboard.

Dieses Feature wurde basierend auf einem Vorschlag des Entwicklercommunity priorisiert.

Toggle to show or hide completed child work items on the backlog (Anzeigen oder Ausblenden von abgeschlossenen untergeordneten Arbeitselementen im Backlog mithilfe der Umschaltfläche)

Oft möchten Sie beim Verfeinern des Backlogs nur Elemente sehen, die noch nicht abgeschlossen wurden. Jetzt haben Sie die Möglichkeit, abgeschlossene untergeordnete Elemente im Backlog ein- oder auszublenden.

Wenn die Umschaltfläche aktiviert ist, werden alle untergeordneten Elemente in einem abgeschlossenen Zustand angezeigt. Wenn der Umschalter deaktiviert ist, werden alle untergeordneten Elemente in einem abgeschlossenen Zustand aus dem Backlog ausgeblendet.

Show or hide child items on the backlog.

Jetzt können Sie ganz einfach auf Ihre zuletzt besuchten Boards, Backlogs, Abfragen und Sprints über das Suchfeld zugreifen, indem Sie das Suchfeld in Azure Boards aktivieren.

Activate the instant search box.

Darüber hinaus können Sie in Ihrem Projekt nach den Boards, Backlogs, Abfragen und Sprints suchen, indem Sie den Boardnamen in das Suchfeld eingeben. Jetzt sind die Boards, die für Sie am wichtigsten sind, nur ein Klick entfernt.

Search for a board name.

Most recent tags displayed when tagging a work item (Anzeigen kürzlich verwendeter Tags beim Taggen eines Arbeitselements)

Beim Kategorisieren einer Arbeitsaufgabe wird jetzt die Option "AutoVervollständigen" bis zu fünf Ihrer zuletzt verwendeten Tags angezeigt. Dies erleichtert das Hinzufügen der richtigen Informationen zu Ihren Arbeitsaufgaben.

Most recent used tags displayed when tagging a work item.

Azure Repos

Improved code search filtering options (Verbesserte Filteroptionen für die Codesuche)

Zuvor unterstützte die Codesuche 39 Codesuchfilter wie "Kommentar" und "def:". Daten haben vorgeschlagen, dass viele Filter nicht verwendet werden, daher werden einige Filter entfernt und andere zusammengeführt. Mit diesem Update wurde die Anzahl der Filter auf 19 reduziert. Dies trägt dazu bei, dass Codesuchabfragen effizienter gestaltet werden und die Unübersichtlichkeit in der Benutzeroberfläche reduziert wird.

Code search filter options.

Beispiel: jetzt func: maps to method:, d.h. if you search for func:AccountAdmin, the results will be mapped to method:AccountAdmin. In ähnlicher Weise sind Makrodef: und Makroref: makro:zugeordnet. Andererseits sind Filter wie Union: und Organisation: aufgrund mangelnder Verwendung veraltet.

Code coverage metrics and branch policy for pull requests (Code-Coverage-Metriken und Branchrichtlinien für Pull Requests)

Sie können jetzt Codeabdeckungsmetriken für Änderungen in der Ansicht "Pull-Anforderung(PR)" sehen. Dadurch wird sichergestellt, dass Sie Ihre Änderungen durch automatisierte Tests angemessen getestet haben. Der Abdeckungsstatus wird als Kommentar in der PR-Übersicht angezeigt. Sie können Details der Abdeckungsinformationen für jede Codezeile anzeigen, die in der Datei-Diff-Ansicht geändert wird.

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

Darüber hinaus können Besitzer von Repositorys jetzt Codeabdeckungsrichtlinien festlegen und verhindern, dass große, nicht getestete Änderungen in eine Verzweigung zusammengeführt werden. Die gewünschten Abdeckungsschwellenwerte können in einer azurepipelines-coverage.yml Einstellungsdatei definiert werden, die am Stamm der Repository- und Abdeckungsrichtlinie eingecheckt ist, mithilfe der vorhandenen Konfiguration einer Verzweigungsrichtlinie für zusätzliche Dienste in Azure Repos definiert werden.

Define coverage thresholds.

Filter comment notifications from pull requests (Herausfiltern von Kommentarbenachrichtigungen aus Pull Requests)

Kommentare in Pullanforderungen können aufgrund von Benachrichtigungen oft viel Rauschen erzeugen. Wir haben ein benutzerdefiniertes Abonnement hinzugefügt, mit dem Sie filtern können, welche Kommentarbenachrichtigungen Sie nach Kommentaralter, Kommentarer, gelöschtem Kommentar, Erwähnung ed-Benutzern, Pullanforderungsautor, Zielzweig- und Threadteilnehmern abonnieren. Sie können diese Benachrichtigungsabonnements erstellen, indem Sie auf das Benutzersymbol in der oberen rechten Ecke klicken und zu den Benutzereinstellungen navigieren.

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

Service hooks for pull request comments (Service Hooks für Kommentare in Pull Requests)

Sie können jetzt Dienst-Hooks für Kommentare in einer Pull-Anforderung basierend auf Repository und Zielzweig erstellen.

Service hooks for pull request comments.

Azure Artifacts

Share your packages publicly with public feeds (preview) (Öffentliches Freigeben von Paketen mithilfe öffentlicher Feeds (Vorschauversion))

Sie können jetzt Ihre Pakete in öffentlichen Feeds erstellen und speichern. Pakete, die in öffentlichen Feeds gespeichert sind, sind für jeden im Internet ohne Authentifizierung verfügbar, unabhängig davon, ob sie sich in Ihrer Organisation befinden oder sogar bei einer Azure DevOps-Organisation angemeldet sind. Erfahren Sie mehr über öffentliche Feeds in unserer Feeds-Dokumentation , oder springen Sie direkt in unser Lernprogramm zum öffentlichen Teilen von Paketen.

Share your packages with public feeds.

Azure Pipelines

kustomize and kompose as bake options in KubernetesManifest task („kustomize“ und „kompose“ als Integrationsoptionen (Bakeoptionen) in der KubernetesManifest-Aufgabe)

Kustomize (Teil von Kubernetes sig-cli) ermöglicht es Ihnen, unformatierte, vorlagenfreie YAML-Dateien für mehrere Zwecke anzupassen und das ursprüngliche YAML unberührt zu lassen. Eine Option für kustomize wurde unter Backaktion von KubernetesManifest-Aufgabe hinzugefügt, sodass alle Ordner, die kustomization.yaml-Dateien enthalten, zum Generieren der Manifestdateien verwendet werden können, die in der Bereitstellungsaktion der KubernetesManifest-Aufgabe verwendet werden.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

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

Kompose wandelt eine Docker Compose-Dateien in eine Kubernetes-Ressource um.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

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

Support for cluster admin credentials in HelmDeploy task (Unterstützung von Clusteradministrator-Anmeldeinformationen in der HelmDeploy-Aufgabe)

Zuvor verwendete die HelmDeploy-Aufgabe die Clusterbenutzeranmeldeinformationen für Bereitstellungen. Dies führte zu interaktiven Anmeldeaufforderungen und fehlerhaften Pipelines für einen azure Active Directory-basierten RBAC-aktivierten Cluster. Um dieses Problem zu beheben, haben wir ein Kontrollkästchen hinzugefügt, mit dem Sie Clusteradministratoranmeldeinformationen anstelle von Clusterbenutzeranmeldeinformationen verwenden können.

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

Manage pipeline variables in YAML editor (Verwalten von Pipelinevariablen im YAML-Editor)

Wir haben die Oberfläche für die Verwaltung von Pipelinevariablen im YAML-Editor aktualisiert. Sie müssen nicht mehr zum klassischen Editor wechseln, um Variablen in Ihren YAML-Pipelines hinzuzufügen oder zu aktualisieren.

Manage pipeline variables in YAML editor.

New predefined variables in YAML pipeline (Neue vordefinierte Variablen in der YAML-Pipeline)

Variablen sind eine praktische Möglichkeit, wichtige Daten in verschiedene Teile Ihrer Pipeline einzufügen. Mit diesem Update haben wir einem Bereitstellungsauftrag einige vordefinierte Variablen hinzugefügt. Diese Variablen werden automatisch vom System festgelegt, auf den spezifischen Bereitstellungsauftrag festgelegt und schreibgeschützt.

  • Environment.Id – Die ID der Umgebung.
  • Environment.Name – Der Name der Umgebung, die vom Bereitstellungsauftrag verwendet wird.
  • Environment.ResourceId – Die ID der Ressource in der Umgebung, die vom Bereitstellungsauftrag gezielt ist.
  • Environment.ResourceName – Der Name der Ressource in der Umgebung, die vom Bereitstellungsauftrag verwendet wird.

Derzeit können Sie Arbeitsaufgaben automatisch mit klassischen Builds verknüpfen. Dies war jedoch mit YAML-Pipelines nicht möglich. Mit diesem Update haben wir diese Lücke behoben. Wenn Sie eine Pipeline erfolgreich mithilfe von Code aus einer angegebenen Verzweigung ausführen, ordnet Azure Pipelines die Ausführung automatisch allen Arbeitsaufgaben zu (die durch die Commits in diesem Code abgeleitet werden). Wenn Sie die Arbeitsaufgabe öffnen, können Sie die Ausführung sehen, in der der Code für diese Arbeitsaufgabe erstellt wurde. Um dies zu konfigurieren, verwenden Sie den Einstellungsbereich einer Pipeline.

Cancel stage in a multi-stage YAML pipeline run (Abbrechen einer Stufe beim Ausführen einer mehrstufigen YAML-Pipeline)

Wenn Sie eine mehrstufige YAML-Pipeline ausführen, können Sie jetzt die Ausführung einer Phase abbrechen, während sie ausgeführt wird. Dies ist hilfreich, wenn Sie wissen, dass die Phase fehlschlägt oder wenn Sie eine andere Ausführung haben, die Sie starten möchten. Dieses Feature ist auch eine Voraussetzung für uns, die Wiederholung einer fehlgeschlagenen Phase in Der Zukunft zu unterstützen.

Approvals in multi-stage YAML pipelines (Genehmigungen in mehrstufigen YAML-Pipeplines)

Wir verbessern weiterhin mehrstufige YAML-Pipelines. Jetzt können Sie diesen Pipelines manuelle Genehmigungen hinzufügen. Infrastrukturbesitzer können ihre Umgebungen schützen und manuelle Genehmigungen anfordern, bevor eine Phase in jeder Pipeline bereitgestellt wird. Mit vollständiger Trennung von Rollen zwischen Infrastrukturbesitzern (Umgebung) und Anwendungsbesitzern (Pipeline) stellen Sie sicher, dass Sie sich manuell für die Bereitstellung in einer bestimmten Pipeline abmelden und die gleiche Kontrolle über die Anwendung der gleichen Prüfungen für alle Bereitstellungen auf die Umgebung erhalten.

Approvals in multi-stage YAML pipelines.

Die Pipeline führt die Bereitstellung in Der Entwicklung aus, wird zu Beginn der Phase nicht mehr genehmigt.

Pipeline runs deploying to dev will stop for approval.

Updates an gehosteten Pipelineimages

Wir haben Updates für mehrere der von Azure Pipelines gehosteten VM-Images vorgenommen. Weitere Details zu den neuesten Versionen finden Sie hier. Die folgenden Änderungen wurden als Teil dieses Updates hinzugefügt:

  • Für VS2017 und VS2019:

  • Für Ubuntu 16.04:

    • Aktualisierter Helm, um immer den neuesten Stand zu ziehen (nicht mehr angeheftet bei v2.14.0)
    • Es wurden mehrere beliebte Docker-Container hinzugefügt.
    • Python auf Versionen 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4 aktualisiert
    • Geänderte Standardpfade und Umgebungsvariablen von Rust

  • Für alle Bilder wurde eine ImageVersion Umgebungsvariable für die Version des Images hinzugefügt.

Eine vollständige Liste der tools, die für ein bestimmtes Image verfügbar sind, finden Sie unter Einstellungen Details zu Agentpools>. >

Enhancements to DevOps Project for virtual machine (Verbesserungen an DevOps-Projekten für virtuelle Computer)

In diesem Update haben wir den Vm-Workflow (Virtual Machine) von DevOps-Projekten so erweitert, dass die virtuellen Computer enthalten sind, die nicht den Einschränkungen pro Speicherortkontingent entsprechen. Zuvor mussten Sie den virtuellen Computer nach Name und Angebot auswählen. Jetzt haben Sie eine On-Demand-Ansicht mit weiteren Details zu den VM-Angeboten wie Kosten/Monat, RAM, Datenträger usw. Dies erleichtert Ihnen die Auswahl des benötigten virtuellen Computers.

Enhancements to DevOps Project for virtual machine.

Einzeln gehosteter Pool

Im letzten Sprint haben wir mitgeteilt, dass wir einen neuen gehosteten Pool namens Azure Pipelines einführen, um alle anderen gehosteten Pools zu ersetzen : Hosted, Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 with VS2019, Hosted macOS und Hosted macOS High Sierra. Diese Änderung wird mit dieser Version implementiert.

Das Vorhandensein mehrerer gehosteter Pools kann manchmal verwirrend sein. Sie erhalten kein genaues Bild davon, wo Parallelität verbraucht wird. Wenn Sie z. B. über eine Parallelität von 10 parallelen Aufträgen verfügen, werden in jedem der gehosteten Pools 10 virtuelle Agents angezeigt, was nicht korrekt ist. Wenn Ihr Auftrag auf einen bestimmten gehosteten Pool (z. B. gehostetes VS2017) mit allen leerstehenden Agents wartet, denken Sie möglicherweise, dass der Azure Pipelines-Dienst unterbrochen wird, ohne zu erkennen, dass die Parallelität möglicherweise in anderen gehosteten Pools genutzt wird (z. B. Gehostetes Ubuntu 1604).

Mit dieser Änderung sehen Sie einen einzelnen gehosteten Pool, der Ihnen ein genaues Bild davon gibt, wie viele Aufträge in diesem Pool ausgeführt werden. Wir planen die Einführung dieser Änderung über die nächsten Sprints. Sie müssen keine Änderungen an Ihren Pipelines vornehmen, da aufträge automatisch von den alten gehosteten Pools an das entsprechende Image im neuen einheitlichen Pool umgeleitet werden.

Show correct pool information on each job (Anzeigen der richtigen Poolinformationen für jeden Auftrag)

Wenn Sie zuvor eine Matrix zum Erweitern von Aufträgen oder einer Variablen zum Identifizieren eines Pools verwendet haben, hatten wir Probleme beim Anzeigen der richtigen Poolinformationen auf den Protokollseiten. Mit diesem Update wurden die Probleme behoben, die dazu führen, dass falsche Poolinformationen für bestimmte Aufträge angezeigt werden.

In-product support for flaky test management (Produktinterne Unterstützung für die Verwaltung unzuverlässiger Tests)

Flaky-Tests können sich auf die Produktivität der Entwickler auswirken, da Testfehler möglicherweise nicht mit den änderungen im Test zusammenhängen. Sie können sich auch auf die Qualität des Versandcodes auswirken. Deshalb haben wir produktinterne Unterstützung für flaky Testmanagement hinzugefügt. Diese Funktionalität unterstützt den End-to-End-Lebenszyklus mit Erkennung, Berichterstellung und Auflösung. Die Verwaltung unzuverlässiger Tests unterstützt die Systemerkennung und die benutzerdefinierte Erkennung.

Die Systemerkennung ist über die VsTest-Task-Wiederholungsfunktion verfügbar. Ein unzuverlässiger Test ist ein Test, der unterschiedliche Ergebnisse liefert, z. B. bestanden oder nicht bestanden, auch wenn keine Änderungen am Quellcode oder an der Ausführungsumgebung vorgenommen wurden. Alle weiteren Testausführungen für denselben Zweig sind auch flackerig gekennzeichnet, bis sie aufgelöst und nicht markiert ist. Sie können ihren benutzerdefinierten Erkennungsmechanismus auch mithilfe unserer APIs anschließen. Sobald ein Test als flaky identifiziert wurde, können Sie die Details im Kontexttestbericht in der Pipeline abrufen. Anschließend können Sie entscheiden, ob sich die flackerigen Tests auf den Pipelineausfall auswirken. Standardmäßig sind flaky Testinformationen als zusätzliche Metadaten verfügbar.

In-product support for flaky test management.

Hier ist ein Beispiel für einen Bericht mit der Testzusammenfassung.

Example of a report with the test summary.

Weitere Informationen zur Flaky-Testverwaltung finden Sie in der Dokumentation hier.

Verbesserungen am Bereitstellungscenter für WebApp im Azure-Portal

Wir haben das Bereitstellungscenter für WebApp im Azure-Portal mit Unterstützung für Pipelines mit mehreren Artefakten verbessert. Wenn nun ein nicht primäres Artefakt von Azure Pipelines in der Web-App bereitgestellt wird, erhalten Sie relevante Details aus der Azure-Portal. Sie haben auch einen Deep-Link zum bereitgestellten Repository, um direkt zum Repository aus dem Azure-Portal zu navigieren. Das Repository kann in Azure Repos oder in GitHub gehostet werden.

CI triggers for new branches (CI-Trigger für neue Branches)

Es war eine lange ausstehende Anforderung, CI-Builds nicht auszulösen, wenn eine neue Verzweigung erstellt wird und wenn diese Verzweigung keine Änderungen aufweist. Betrachten Sie die folgenden Beispiele:

  • Sie verwenden die Webschnittstelle, um eine neue Verzweigung basierend auf einer vorhandenen Verzweigung zu erstellen. Dadurch würde sofort ein neuer CI-Build ausgelöst, wenn ihr Verzweigungsfilter mit dem Namen der neuen Verzweigung übereinstimmt. Dies ist unerwünschte, da der Inhalt der neuen Verzweigung im Vergleich zur vorhandenen Verzweigung identisch ist.
  • Sie verfügen über ein Repository mit zwei Ordnern – App und Dokumente. Sie richten einen Pfadfilter für CI ein, der mit "app" übereinstimmt. Mit anderen Worten, Sie möchten keinen neuen Build erstellen, wenn eine Änderung an Dokumente verschoben wurde. Sie erstellen eine neue Verzweigung lokal, nehmen einige Änderungen an Dokumenten vor, und übertragen Sie diese Verzweigung dann an den Server. Wir haben verwendet, um einen neuen CI-Build auszulösen. Dies ist unerwünscht, da Sie explizit aufgefordert haben, nicht nach Änderungen im Dokumentordner zu suchen. Aufgrund der Art und Weise, wie wir ein neues Verzweigungsereignis behandelt haben, scheint es jedoch so, als ob auch eine Änderung am App-Ordner vorgenommen wurde.

Jetzt haben wir eine bessere Möglichkeit, CI für neue Filialen zu behandeln, um diese Probleme zu beheben. Wenn Sie eine neue Verzweigung veröffentlichen, suchen wir explizit nach neuen Commits in dieser Verzweigung, und überprüfen Sie, ob sie den Pfadfiltern entsprechen.

Terraform integration with Azure Pipelines (Terraform-Integration für Azure Pipelines)

Terraform ist ein Open-Source-Tool zur sicheren und effizienten Entwicklung, Änderungs- und Versionsverwaltungsinfrastruktur. Terraform codiert APIs in deklarative Konfigurationsdateien, sodass Sie die Infrastruktur mithilfe einer allgemeinen Konfigurationssprache definieren und bereitstellen können. Sie können die Terraform-Erweiterung verwenden, um Ressourcen für alle wichtigen Infrastrukturanbieter zu erstellen: Azure, Amazon Web Services (AWS) und Google Cloud Platform (GCP).

Weitere Informationen zur Terraform-Erweiterung finden Sie hier in der Dokumentation.

Terraform integration with Azure Pipelines.

Integration with Google Analytics (Google Analytics-Integration)

Mit dem Google Analytics-Experimentframework können Sie nahezu jede Änderung oder Variation einer Website oder App testen, um ihre Auswirkungen auf ein bestimmtes Ziel zu messen. Sie können beispielsweise Aktivitäten haben, die Ihre Benutzer abschließen möchten (z. B. einen Kauf tätigen, sich für einen Newsletter registrieren) und/oder Metriken, die Sie verbessern möchten (z. B. Umsatz, Sitzungsdauer, Unzustellbarkeitsrate). Mit diesen Aktivitäten können Sie Änderungen identifizieren, die eine Implementierung wert sind, basierend auf den direkten Auswirkungen, die sie auf die Leistung Ihres Features haben.

Die Erweiterung der Google Analytics-Experimente für Azure DevOps fügt den Build- und Releasepipelinen Experimentierschritte hinzu, sodass Sie die Experimente kontinuierlich durchlaufen, lernen und bereitstellen können, indem Sie die Experimente kontinuierlich verwalten und gleichzeitig alle DevOps-Vorteile von Azure Pipelines gewinnen.

Sie können die Erweiterung der Google Analytics-Experimente aus dem Marketplace herunterladen.

Integration with Google Analytics.

Pipeline caching (public preview) (Pipelinezwischenspeicherung (Public Preview))

Mit der Pipelinezwischenspeicherung können Sie die Ergebnisse eines lange ausgeführten Vorgangs speichern, z. B. eine Paketwiederherstellung oder eine Abhängigkeitskompilierung, und sie während der nächsten Ausführung einer Pipeline wiederherstellen. Dies kann zu schnelleren Builds führen.

Weitere Details finden Sie im Blogbeitrag mit der vollständigen Ankündigung hier.

Befehle für Variablengruppen und Variablenverwaltung in Pipelines

Es kann schwierig sein, YAML-basierte Pipelines von einem Projekt zu einem anderen zu portieren, da Sie die Pipelinevariablen und Variablengruppen manuell einrichten müssen. Mit den Befehlen für die Pipelinevariablengruppe und variablenverwaltung können Sie nun die Einrichtung und Verwaltung von Pipelinevariablen und Variablengruppen skripten, die wiederum versionsgesteuert werden können, sodass Sie die Anweisungen zum Verschieben und Einrichten von Pipelines von einem Projekt zu einem anderen problemlos freigeben können.

Ausführen von Pipelines für einen PR-Branch

Beim Erstellen einer PR kann es schwierig sein zu überprüfen, ob die Änderungen die Pipeline für den Zielzweig unterbrechen könnten. Mit der Möglichkeit, eine Pipelineausführung auszulösen oder einen Build für eine PR-Verzweigung in die Warteschlange zu stellen, können Sie die Änderungen jetzt überprüfen und visualisieren, indem Sie sie für die Zielpipeline ausführen. Weitere Informationen finden Sie in der Datei "az pipelines run " und "az pipelines build queue command documentation".

Überspringen der ersten Pipelineausführung

Beim Erstellen von Pipelines möchten Sie manchmal eine YAML-Datei erstellen und übernehmen und die Pipelineausführung nicht auslösen, da dies zu einer fehlerhaften Ausführung aufgrund einer Vielzahl von Gründen führen kann – Infrastruktur ist nicht bereit oder muss Variable/Variable-Gruppen erstellen und aktualisieren usw. Mit Azure DevOps CLI können Sie jetzt die erste automatisierte Pipelineausführung beim Erstellen einer Pipeline überspringen, indem Sie den Parameter "--skip-first-run" einschließen. Weitere Informationen finden Sie in der Dokumentation zum Erstellen von Befehlen in az pipeline.

Verbesserungen des Dienstendpunktbefehls

Dienstendpunkt-CLI-Befehle unterstützen nur azure rm und github-Dienstendpunkt einrichten und verwalten. Mit dieser Version können Sie jedoch mit Dienstendpunktbefehlen einen beliebigen Dienstendpunkt erstellen, indem Sie die Konfiguration über Datei bereitstellen und optimierte Befehle bereitstellen – az devops service-endpoint github und az devops service-endpoint azurerm, die erstklassige Unterstützung zum Erstellen von Dienstendpunkten dieser Typen bieten. Weitere Informationen finden Sie in der Befehlsdokumentation .

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 zu diesen Features halten. Verwenden Sie das Feedbackmenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Make a suggestion

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

Vielen Dank,

Sam Guckenheimer