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

Im Sprint 155 Update von Azure DevOps führen wir neue Azure Boards Berichte ein, damit Sie wichtige Teammetriken leichter nachverfolgen können. Auf der Registerkarte "Analyse" werden die neuen Berichte in den Hubs Boards, Backlog und Sprint angezeigt. Diese Berichte sind vollständig interaktiv und ermöglichen Es Ihnen, sie an Ihre Anforderungen anzupassen.

Darüber hinaus freuen wir uns, die neue Azure Boards-App für Slack bekanntzugeben. Mit der App können Sie Arbeitsaufgabenaktivitäten überwachen und Arbeitselemente aus Ihrem Slack-Kanal erstellen.

Weitere Informationen finden Sie in der nachstehenden Liste " Features ".

Neuerungen in Azure DevOps

Funktionen

Allgemeines:

Azure Boards:

Azure Repos:

Azure Artifacts:

Azure Pipelines:

Mehrstufige YAML-Pipelines

Gehostete VMs

Kubernetes

Testen

Azure-Erfahrungen

Integrationen

Allgemein

Einladen GitHub Mitarbeiter in Azure DevOps

Sie können jetzt Mitarbeiter von GitHub zum Azure DevOps einladen, wenn Sie mit Ihrer GitHub Identität angemeldet sind. Sie können andere GitHub Benutzer über die Project Homepage und über die 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 Benutzer ohne GitHub 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 Problembehandlung bei der Authentifizierung beim & Einladen von GitHub Benutzern häufig gestellte Fragen.

Azure Boards

Erhalten Sie Einblicke in die Gesundheit Ihres Teams 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, kumulative Flow Diagramm (CFD) und Geschwindigkeit. Sie können die Berichte auf der neuen Registerkarte "Analyse" anzeigen.

Metriken wie Sprint-Burndown, Arbeitsfluss und Teamgeschwindigkeit bieten Ihnen die Sichtbarkeit des Fortschritts Ihres Teams und helfen Ihnen bei der Beantwortung von Fragen wie:

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

Hinweis

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

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

  • Das Burndowndiagramm finden Sie unter dem Sprints-Hub .

    Analytics tab in Sprint hub.

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

    CFD and velocity reports in boards.

Mit den neuen Berichten haben Sie mehr Kontrolle und Informationen zu Ihrem Team. Hier sind einige Beispiele:

  • Der Sprint Burndown und die Geschwindigkeitsberichte können so festgelegt werden, dass die Anzahl der Arbeitselemente oder die Summe der verbleibenden Arbeit verwendet werden kann.
  • Sie können den Zeitrahmen des Sprint-Burndowns anpassen, ohne dass sich die Projekttermine auswirken. 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 gewinnen, 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 anzeigt.

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 für Slack

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

Mit der App können Sie Ereignisabonnements einrichten und verwalten, einschließlich Erstellungs- und Arbeitsaufgabenaktualisierungen, und Benachrichtigungen für diese Ereignisse in Ihrem Slack-Kanal erhalten. Die Unterhaltungen im Slack-Kanal können zum Erstellen von Arbeitselementen verwendet werden. Sie erhalten auch persönliche Benachrichtigungen, wenn Ihnen Arbeitselemente zugewiesen werden. 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 ihnen eine Option hinzugefügt haben, mit der Sie die Spalten im Taskboard anpassen können. Sie können nun 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 aus dem Entwicklercommunity priorisiert.

Umschalten zum Ein- oder Ausblenden abgeschlossener untergeordneter Arbeitselemente im Backlog

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

Wenn die Umschaltfläche aktiviert ist, werden alle untergeordneten Elemente in einem abgeschlossenen Zustand angezeigt. Wenn die Umschaltfläche 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 aus dem Suchfeld zugreifen, indem Sie das Suchfeld in Azure Boards aktivieren.

Activate the instant search box.

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

Search for a board name.

Die neuesten Tags, die beim Kennzeichnen einer Arbeitsaufgabe angezeigt werden

Wenn Sie eine Arbeitsaufgabe markieren, wird die Option für die automatische Fertigstellung jetzt bis zu fünf Ihrer zuletzt verwendeten Tags angezeigt. Dadurch wird es einfacher, die richtigen Informationen zu Ihren Arbeitselementen hinzuzufügen.

Most recent used tags displayed when tagging a work item.

Azure Repos

Verbesserte Optionen für die Codesuche

Zuvor unterstützte die Codesuche 39 Codesuchfilter wie Kommentar undDef:. Daten haben vorgeschlagen, dass viele Filter nicht verwendet werden, daher werden einige Filter entfernt und andere zusammengeführt. Mit diesem Update haben wir die Anzahl der Filter auf 19 reduziert. Dies wird helfen, indem Codesuchabfragen effizienter gestaltet werden und die Übersichtlichung in der Benutzeroberfläche reduziert wird.

Code search filter options.

Beispiel : jetzt func: maps to method:, d.h. wenn Sie nach func:AccountAdmin suchen, werden die Ergebnisse der Methode:AccountAdmin zugeordnet. Ebenso makrodef: und makroref: werden Makros zugeordnet:. Andererseits wurden Filter wie Union undOrganisation aufgrund fehlender Verwendung veraltet.

Codeabdeckungsmetriken und Verzweigungsrichtlinie für Pullanforderungen

Sie können jetzt Codeabdeckungsmetriken für Änderungen in der Pull-Anforderungsansicht (PR) anzeigen. Dadurch wird sichergestellt, dass Sie Ihre Änderungen über automatisierte Tests angemessen getestet haben. Der Abdeckungsstatus wird in der PR-Übersicht als Kommentar 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 Repobesitzer 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 im Stammverzeichnis des Repositorys und der Abdeckungsrichtlinie eingecheckt ist, mithilfe der vorhandenen Konfiguration einer Verzweigungsrichtlinie für zusätzliche Dienste in Azure Repos definiert werden.

Define coverage thresholds.

Filtern von Kommentarbenachrichtigungen aus Pullanforderungen

Kommentare in Pullanforderungen können häufig aufgrund von Benachrichtigungen viel Rauschen generieren. Wir haben ein benutzerdefiniertes Abonnement hinzugefügt, mit dem Sie filtern können, welche Kommentarbenachrichtigungen Sie nach Kommentaralter, Kommentarer, gelöschtem Kommentar, erwähnten 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.

Diensthaken für Pullanforderungskommentare

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

Service hooks for pull request comments.

Azure Artifacts

Freigeben Ihrer Pakete öffentlich mit öffentlichen Feeds (Vorschau)

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, um Pakete öffentlich zu teilen.

Share your packages with public feeds.

Azure Pipelines

kustomisieren und kompose als Backoptionen in KubernetesManifest-Aufgabe

Kustomize (Teil von Kubernetes sig-cli) ermöglicht Es Ihnen, unformatierte, vorlagenfreie YAML-Dateien für mehrere Zwecke anzupassen und die 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-Verfassen-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)

Unterstützung für Clusteradministratoranmeldeinformationen in der HelmDeploy-Aufgabe

Zuvor verwendet die HelmDeploy-Aufgabe die Clusterbenutzeranmeldeinformationen für Bereitstellungen. Dies führte zu interaktiven Anmeldeaufforderungen und fehlgeschlagenen 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.

Verwalten von Pipelinevariablen im YAML-Editor

Wir haben die Oberfläche zum Verwalten 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.

Neue vordefinierte Variablen in der YAML-Pipeline

Variablen bieten Ihnen eine bequeme Möglichkeit, wichtige Datenbits in verschiedenen Teilen Ihrer Pipeline zu erhalten. Mit diesem Update haben wir ein paar vordefinierte Variablen zu einem Bereitstellungsauftrag 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 von dem Bereitstellungsauftrag ausgerichtet ist.
  • Environment.ResourceId – Die ID der Ressource in der Umgebung, die von dem Bereitstellungsauftrag ausgerichtet ist.
  • Environment.ResourceName – Der Name der Ressource in der Umgebung, die von dem Bereitstellungsauftrag gezielt verwendet wird.

Derzeit können Sie Arbeitselemente 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 Arbeitselementen 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.

Phase abbrechen in einer mehrstufigen YAML-Pipelineausführung

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, um die Wiederholung einer fehlgeschlagenen Phase in zukunft zu unterstützen.

Genehmigungen in mehrstufigen YAML-Pipelines

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 vor einer Phase in jeder Pipeline durchführen, die für sie bereitgestellt wird. Mit vollständiger Trennung von Rollen zwischen Infrastrukturbesitzern (Umgebung) und Anwendungsbesitzern (Pipeline) stellen Sie die manuelle Abmeldung für die Bereitstellung in einer bestimmten Pipeline sicher und erhalten zentrale Kontrolle beim Anwenden derselben Prüfungen über alle Bereitstellungen auf die Umgebung.

Approvals in multi-stage YAML pipelines.

Die Pipeline führt die Bereitstellung in Dev aus, um die Genehmigung am Anfang der Phase zu beenden.

Pipeline runs deploying to dev will stop for approval.

Updates für gehostete Pipelinesimages

Wir haben Updates für mehrere der Azure Pipelines gehosteten VM-Images vorgenommen. Weitere Informationen 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 an v2.14.0 angeheftet)
    • Mehrere beliebte Docker-Container hinzugefügt
    • Aktualisierte Python auf Versionen 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
    • Geänderte Standardpfade und Umgebungsvariablen
  • Für alle Bilder wurde eine ImageVersion Umgebungsvariable für die Version des Bilds hinzugefügt.

Eine vollständige Liste der für ein bestimmtes Bild verfügbaren Tools finden Sie unter Einstellungen > Agentpools > details.

Verbesserungen an DevOps Project für virtuelle Computer

In diesem Update haben wir den DevOps virtuellen Computer (VM)-Workflow erweitert, um die VMs einzuschließen, die nicht den Einschränkungen für das Kontingent pro Speicherort entsprechen. Zuvor mussten Sie die VM 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 virtuellen Computers, den Sie benötigen.

Enhancements to DevOps Project for virtual machine.

Einzelner gehosteter Pool

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

Mehrere gehostete Pools können manchmal verwirrend sein. Sie erhalten kein genaues Bild davon, wo die Übereinstimmung verbraucht wird. Wenn Sie beispielsweise über eine Übereinstimmung von 10 parallelen Aufträgen verfügen, werden 10 virtuelle Agents in jedem der gehosteten Pools angezeigt, was nicht genau ist. Wenn Ihr Auftrag auf einen bestimmten gehosteten Pool (z. B. gehostete VS2017) mit allen Leerlauf-Agents wartet, denken Sie möglicherweise, dass Azure Pipelines Dienst unterbrochen wird, ohne zu erkennen, dass die Übereinstimmung möglicherweise in anderen gehosteten Pools (z. B. Gehostetes Ubuntu 1604) verwendet wird.

Mit dieser Änderung wird ein einzelner gehosteter Pool angezeigt, der Ihnen ein genaues Bild darüber gibt, wie viele Aufträge in diesem Pool ausgeführt werden. Wir planen, diese Änderung in den nächsten Sprints auszurollen. Sie müssen keine Änderungen an Ihren Pipelines vornehmen, da wir Aufträge automatisch von den alten gehosteten Pools in das entsprechende Bild im neuen einheitlichen Pool umleiten.

Anzeigen korrekter 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 richtiger Poolinformationen auf den Protokollseiten. Mit diesem Update haben wir die Probleme behoben, die zu falschen Poolinformationen führen, die für bestimmte Aufträge angezeigt werden.

In-Product-Unterstützung für die Flaky-Testverwaltung

Flaky-Tests können sich auf die Produktivität von Entwicklern auswirken, da Testfehler möglicherweise nicht mit den änderungen im Test verbunden sind. Sie können auch die Qualität des versandeten Codes beeinflussen. Deshalb haben wir in produktinterne Unterstützung für die schläfige Testverwaltung hinzugefügt. Diese Funktionalität unterstützt End-to-End-Lebenszyklus mit Erkennung, Berichterstellung und Auflösung. Die Flaky-Testverwaltung unterstützt System- und benutzerdefinierte Erkennung.

Die Systemerkennung ist über vsTest-Vorgangs-Wiederholungsfunktion verfügbar. Ein flakiger Test ist ein Test, der verschiedene Ergebnisse bereitstellt, z. B. Pass oder Fehler, auch wenn keine Änderungen in der Quellcode- oder Ausführungsumgebung vorhanden sind. Alle weiteren Ausführungen des Tests für dieselbe Verzweigung werden ebenfalls flakig markiert, bis es aufgelöst und nicht markiert ist. Sie können auch Ihren benutzerdefinierten Erkennungsmechanismus mithilfe unserer APIs anschließen. Sobald ein Test als flakig identifiziert wird, können Sie die Details im Kontexttestbericht in der Pipeline abrufen. Anschließend können Sie entscheiden, ob sich die flakigen Tests auf Ihren Pipelinefehler auswirken. Standardmäßig stehen flakige Testinformationen als zusätzliche Metadaten zur Verfügung.

In-product support for flaky test management.

Nachfolgend finden Sie ein Beispiel für einen Bericht mit der Testzusammenfassung.

Example of a report with the test summary.

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

Verbesserungen im Bereitstellungscenter für WebApp im Azure-Portal

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

CI-Trigger für neue Zweigstellen

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

  • Sie verwenden die Webschnittstelle, um eine neue Verzweigung basierend auf einem vorhandenen Zweig zu erstellen. Dadurch würde sofort ein neuer CI-Build ausgelöst, wenn der Zweigfilter dem Namen des neuen Zweigs entspricht. Dies ist unerwünscht, da der Inhalt des neuen Zweigs im Vergleich zu dem vorhandenen Zweig identisch ist.
  • Sie verfügen über ein Repository mit zwei Ordnern – App und Dokumente. Sie richten einen Pfadfilter für CI ein, um mit "app" übereinzugleichen. 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 pushen Sie diese Verzweigung dann auf den Server. Wir haben verwendet, um einen neuen CI-Build auszulösen. Dies ist unerwünscht, da Sie explizit aufgefordert haben, nach Änderungen im Ordner "Dokumente" zu suchen. Aufgrund der Art und Weise, wie wir ein neues Branch-Ereignis behandelt haben, würde es jedoch aussehen, dass auch eine Änderung an dem App-Ordner vorgenommen wurde.

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

Terraform-Integration mit Azure Pipelines

Terraform ist ein Open-Source-Tool zum Entwickeln, Ändern und Versionsverwaltungsinfrastruktur sicher und effizient. Terraform codiert APIs in deklarative Konfigurationsdateien, mit denen Sie Infrastruktur mithilfe einer Sprachsprache auf hoher Ebene definieren und bereitstellen können. Sie können die Terraform-Erweiterung verwenden, um Ressourcen in allen wichtigen Infrastrukturanbietern zu erstellen: Azure, Amazon Web Services (AWS) und Google Cloud Platform (GCP).

Weitere Informationen zur Terraform-Erweiterung finden Sie hier.

Terraform integration with Azure Pipelines.

Integration mit Google Analytics

Mit dem Google Analytics-Experimentframework können Sie fast alle Änderungen oder Variationen 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. Kauf vornehmen, sich für einen Newsletter anmelden) und/oder Metriken, die Sie verbessern möchten (z. B. Umsatz, Sitzungsdauer, Unzustellbarkeitsrate). Diese Aktivitäten ermöglichen Es Ihnen, Änderungen zu identifizieren, die auf der Grundlage der direkten Auswirkungen auf die Leistung Ihres Features erforderlich sind.

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

Sie können die Google Analytics-Experimenterweiterung aus dem Marketplace herunterladen.

Integration with Google Analytics.

Pipelinespeicherung (öffentliche Vorschau)

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

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

Befehle für die Pipelinevariablengruppe und variable Verwaltung

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 zur Variablenverwaltung der Pipelinevariablen und Variablenverwaltung können Sie nun die Einrichtung und Verwaltung von Pipelinevariablen und Variablengruppen ausführen, die wiederum versionsgesteuert werden können, sodass Sie die Anweisungen einfach freigeben können, um Pipelines von einem Projekt zu einem anderen zu verschieben und einzurichten.

Ausführen der Pipeline für eine PR-Verzweigung

Beim Erstellen einer PR kann es schwierig sein, zu überprüfen, ob die Änderungen die Pipeline unterbrechen können, die auf dem Zielzweig ausgeführt wird. Mit der Funktion zum Auslösen einer Pipelineausführung oder Warteschlange eines Builds für einen PR-Zweig können Sie die Änderungen jetzt überprüfen und visualisieren, indem Sie sie gegen die Zielpipeline ausführen. Weitere Informationen finden Sie in az-Pipelines, die ausgeführt werden und az-Pipelines erstellen .

Überspringen der ersten Pipelineausführung

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

Verbesserung des Dienstendpunktbefehls

Dienstendpunkt-CLI-Befehle unterstützen nur azure rm und github-Dienstendpunkt einrichten und verwalten. Mit dieser Version können Sie jedoch alle Dienstendpunkte 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 bereitgestellt.

Fahren Sie zu Azure DevOps, und schauen Sie sich an.

Senden von Feedback

Wir würden gerne hören, was Sie über diese Features denken. 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 erhalten, die von der Community auf Stack Overflow beantwortet werden.

Vielen Dank,

Sam Guckenheimer