GitHub Enterprise-Unterstützung und automatische GitHub-Dienstverbindungen in Buildpipelinen – Sprint 146 Update

Im Sprint 146 Update von Azure DevOps haben wir unsere GitHub-Integration in Azure Pipelines verbessert. Der Assistent für die Erstellung neuer Buildpipelines kann jetzt Pipelines für GitHub-Enterprise-Repositories erstellen. Außerdem wird Ihr Repository analysiert, um eine vorgeschlagene Sprachvorlage bereitzustellen. Darüber hinaus kann es Dienstverbindungen für die von Ihnen ausgewählten GitHub-Repositorys erstellen und wiederverwenden.

Sehen Sie sich die Funktionen unten an.

Features

Allgemein:

• Wiederherstellen gelöschter Projekte

Azure Boards:

• Vereinfachen der Organisation Ihrer Arbeit mithilfe des Grundlegenden Prozesses

Azure-Pipelines:

• Unterstützung für GitHub Enterprise im Pipeline-Assistenten
• Automatische GitHub-Dienstverbindungen in Pipelines
• Anzeigen des Status für jeden Pipeline-Job in GitHub Checks
• Standardautorisierung für YAML-Ressourcen in GitHub
• Dienstcontainer für YAML-Pipelines
• Arbeitsaufgaben, die mit GitHub-Commits verknüpft sind, in der Versionszusammenfassung
• Neue für YAML optimierte Azure App-Dienstaufgaben
• Azure Active Directory (AD)-Authentifizierungsunterstützung für Azure SQL-Aufgabe
• Grafana Annotations Service Hook
• Azure Monitor-Alarmaufgaben abfragen
• Inlineeingabe der Spezifikationsdatei in der Aufgabe "In Kubernetes bereitstellen"
• Docker CLI Installer-Aufgabe
• Langfristiger Java-Support (LTS) für von Microsoft gehostete Agents
• YAML-Unterstützung für Bitbucket Cloud-Pipelines
• Vermeiden Sie das Auslösen mehrerer CI-Builds für Pullanforderungen
• Ändern von Buildnummern, Hochladen und Herunterladen von Artefakten in geforkten Repository-Builds
• Neue Option im "Testergebnisse veröffentlichen"-Task, um bei fehlgeschlagenen Tests den Build fehlschlagen zu lassen
• Updates für das Azure-Portal zum Erstellen eines Azure DevOps-Projekts
• Verwenden des Azure-Portals zum Einrichten und Bereitstellen in einer CosmosDB-Datenbank
• Einrichten von Builds und Releasepipelines für Funktionen im Azure-Portal

Azure Artifacts:

• Statistiken zur Paketnutzung

Wiki:

• Schriftart mit fester Breite für Wiki-Markdown-Editor
• Fett formatierte Wiki-Seitentitel
• Markdown-Tabelle einfügen
• Einbetten von Azure Boards-Abfrageergebnissen in Wiki-

Allgemein

Restore deleted projects (Wiederherstellen gelöschter Projekte)

In diesem Update haben wir die Möglichkeit hinzugefügt, gelöschte Projekte aus dem Azure DevOps-Portal wiederherzustellen. Wenn Sie über die Berechtigung "Projekt löschen" verfügen, können Sie ein gelöschtes Projekt auch über die Übersichtsseite "Organisationseinstellungen>" wiederherstellen.

Azure Boards

Simplify the organization of your work using the Basic process (Vereinfachte Arbeitsorganisation mit dem Basic-Prozess)

In der Vergangenheit war Agile der Standardprozess für neue Projekte und bietet einen robusten und flexiblen Satz von Arbeitsaufgabentypen und -zuständen für eine Vielzahl von Projektbereitstellungsmethoden. Für einige Teams, die mit anderen Tools vertrauter sind oder die wachsen und einen leistungsfähigeren Toolsatz einführen möchten, möchten Sie schnell mit der Terminologie beginnen, mit der sie vertrauter sind.

Der neue Basisprozess bietet drei Arbeitselementtypen (Epics, Issues und Tasks), um Ihre Arbeit zu planen und nachzuverfolgen. Es wird empfohlen, Vorgänge zu verwenden, um Aspekte wie Benutzergeschichten, Fehler und Features zu verfolgen, während Epics genutzt werden, um Vorgänge in größere Arbeitseinheiten zu gruppieren. Wenn Sie Fortschritte bei Ihrer Arbeit machen, verschieben Sie Aufgaben entlang eines einfachen Zustandsworkflows von To Do, In Bearbeitung und Done.

Sehen Sie sich die Dokumentation zu -Problemverfolgung und-Aufgaben an, zur Unterstützung Ihrer ersten Schritte bei Ihrem neuen Projekt.

Azure-Pipelines

GitHub Enterprise support in the pipeline wizard (GitHub Enterprise-Unterstützung im Pipeline-Assistenten)

Zuvor könnten Sie den visuellen Designer verwenden, um Pipelines für GitHub Enterprise-Repositorys zu erstellen. Jetzt können Sie auch den Buildpipeline-Assistenten verwenden, um Ihre Pipelines zu erstellen.

Der Assistent analysiert Ihr GitHub Enterprise-Repository, um eine YAML-Vorlage vorzuschlagen, die Ihrer Projektsprache entspricht. Anschließend können Sie die YAML-Datei als direkten Commit in Ihren Standardbranch oder als Pull-Request bearbeiten und speichern.

Weitere Details finden Sie in der Dokumentation zum Erstellen Ihrer ersten Pipeline hier.

Automatic GitHub service connections in pipelines (Automatische GitHub-Dienstverbindungen in Pipelines)

Wenn Sie den Assistenten für neue Build-Pipeline zum Erstellen einer Pipeline für GitHub verwenden, führte die Seite zur Auswahl oder Erstellung einer GitHub-Dienstverbindung zu Verwirrung darüber, welche Verbindung aus der Liste ausgewählt werden sollte. Jetzt müssen Sie keine Verbindung auswählen. Der Assistent erstellt automatisch eine Dienstverbindung für das von Ihnen gewählte Repository und verwendet sie erneut.

Wenn Sie manuell eine andere Verbindung als die automatisch ausgewählte auswählen möchten, folgen Sie dem Verbindung wählen Hyperlink. Weitere Informationen finden Sie unter Erstellen von GitHub-Repositorys.

Display status for each pipeline job in GitHub Checks (Anzeigen des Status jedes Pipelineauftrags in GitHub-Prüfungen)

Zuvor wurde ein einzelner Buildstatus bei den GitHub-Überprüfungen für Ihre Pipeline veröffentlicht, auch wenn dies Aufträge für mehrere Plattformen (z. B. Linux, macOS und Windows) enthielt. Jetzt wird der Status auf GitHub Checks für jeden Auftrag in der Pipeline gepostet. Darüber hinaus können Sie den gesamten Build oder nur einzelne fehlgeschlagene Aufträge von GitHub Checks erneut ausführen. Um diese Funktionalität zu verwenden, muss Ihre Pipeline so konfiguriert sein, dass sie die GitHub-App von Azure Pipelines verwendet. Weitere Details finden Sie unter Integration mithilfe der GitHub-App. Informationen zum Einrichten einer Pipeline mit Aufträgen für mehrere Plattformen finden Sie unter Erstellen einer Mehrplattformpipeline.

Default authorization for YAML resources in GitHub (Standardautorisierung für YAML-Ressourcen in GitHub)

Wenn Sie Ihren Quellcode in GitHub verwalten und YAML verwenden, um Ihre Pipeline zu definieren, ist wahrscheinlich ein Fehler bei der Ressourcenautorisierung aufgetreten. Wenn Sie Ihre YAML-Datei bearbeitet und einen Verweis auf eine der geschützten Ressourcen hinzugefügt haben (z. B. Dienstverbindung, Agentpool, Variablengruppe oder sichere Datei), konnte Azure Pipelines die Identität des Benutzers, der diese Änderung vorgenommen hat, nicht überprüfen und den Build fehlgeschlagen haben. Um dieses Problem zu umgehen, mussten Sie die Buildpipeline im Web-Editor speichern, nachdem Sie eine Änderung an der YAML-Datei vorgenommen haben. Viele der Benutzer, die dieses Problem getroffen haben, wollten lediglich zulassen, dass alle Pipelines die Ressource verwenden können.

Um den Ausfall des Ressourcenautorisierungsbuilds zu vermeiden, haben wir das Standardverhalten aller neuen Dienstverbindungen, Agentpools und Variablengruppen geändert, die für die Verwendung in allen Pipelines autorisiert werden sollen. Wenn Sie engere Steuerelemente für Ihre Ressourcen benötigen, können Sie das Standardautorisierungsmodell deaktivieren (siehe Abbildung unten). Wenn Sie dies tun, muss jemand mit Berechtigungen für die Verwendung der Ressource die Pipeline im Web-Editor speichern, nachdem der YAML-Datei ein Ressourcenverweis hinzugefügt wurde.

Service containers for YAML pipelines (Dienstcontainer für YAML-Pipelines)

Zuvor mussten Sie Dienste wie Datenbanken oder Speichercaches installieren, starten und beenden, wenn Ihre YAML-Pipeline diese Dienste verwendet hat. Mit diesem Update haben wir Dienstcontainer hinzugefügt, die diese Aufgaben verarbeiten können. Wenn Ihre Pipeline beispielsweise einen Redis-Cache für Integrationstests verwendet, können Sie das Redis-Containerimage als Dienst in die Pipeline aufnehmen. Der Agent ruft das Image automatisch ab, startet es und verbindet es mit dem Netzwerk, sodass Ihre Pipelineschritte auf den Hostnamen "redis" verweisen können. Sobald die Pipeline abgeschlossen ist, wird der Agent anschließend den Dienstcontainer sauber herunterfahren.

Arbeitsaufgaben, die mit GitHub-Commits verknüpft sind, in der Versionszusammenfassung

Im Dezember wurde die Funktion zum Verknüpfen von GitHub mit Arbeitsaufgaben eingeführt. Wir freuen uns, ihnen mitzuteilen, dass jetzt alle Mit GitHub-Commits verknüpften Azure Boards-Arbeitsaufgaben auf der Versionszusammenfassungsseite angezeigt werden können. Teams können so mehr Informationen über die in einer Umgebung bereitgestellten Commits nachverfolgen und abrufen.

Neue, für YAML optimierte Azure App Service-Aufgaben

Wir unterstützen jetzt vier neue Aufgaben, die eine einfache und dennoch leistungsstarke Möglichkeit bieten, Azure App Services für moderne Entwickler bereitzustellen. Diese Aufgaben verfügen über eine optimierte YAML-Syntax, die es einfach und intuitiv macht, Bereitstellungen für Azure AppServices zu erstellen, einschließlich WebApps, FunctionApps, WebApps für Container und FunctionApp für Container auf Windows- und Linux-Plattformen.

Wir unterstützen auch eine neue Hilfsprogrammaufgabe für die Dateitransformation und variablen Ersetzung für XML- und JSON-Formate.

Azure Active Directory (AD)-Authentifizierungsunterstützung für Azure SQL-Aufgabe

Die Azure SQL-Aufgabe wurde erweitert, um die Verbindung mit einer Datenbank mithilfe von Azure AD (Integriertes & Kennwort) und einer Verbindungszeichenfolge zusätzlich zur vorhandenen Unterstützung für die SQL-Serverauthentifizierung zu unterstützen.

Grafana annotations service hook (Service Hook für Grafana-Anmerkungen)

Wir unterstützen jetzt einen neuen Service-Hook, mit dem Sie Grafana-Anmerkungen für Ereignisse der Kategorie "Bereitstellung abgeschlossen" zu einem Grafana-Dashboard hinzufügen können. Auf diese Weise können Sie Bereitstellungen mit den Änderungen an Anwendungs- oder Infrastrukturmetriken korrelieren, die in einem Grafana-Dashboard visualisiert werden.

Azure Monitor-Warnaufgaben abfragen

Die vorherige Version der Azure Monitor-Abfrageaufgabe unterstützte das Abfragen von Warnungen nur in der klassischen Überwachungserfahrung. Mit dieser neuen Version der Aufgabe können Sie Warnungen zur einheitlichen Überwachungserfahrung abfragen, die kürzlich von Azure Monitor eingeführt wurde.

Inlineeingabe der Spezifikationsdatei in der Aufgabe "In Kubernetes bereitstellen"

Zuvor mussten Sie mit der Kubernetes-Bereitstellungsaufgabe einen Dateipfad für die Konfiguration angeben. Jetzt können Sie die Konfiguration auch inline hinzufügen.

Docker CLI Installer-Aufgabe

Diese Aufgabe ermöglicht die Installation einer beliebigen Version von Docker CLI auf den Agents, wie vom Benutzer angegeben.

Java long-term support (LTS) on Microsoft hosted agents (Langfristige Java-Unterstützung in von Microsoft gehosteten Agents)

Zuvor hatten von Microsoft gehostete Agents JDKs vorinstalliert, die durch komplexe Lizenzierung, Endbenutzereinschränkungen und fehlende langfristige Unterstützung überladen wurden. In diesem Update wurden die JDKs durch getestete, zertifizierte LTS-Builds von OpenJDK von Azul Systems ersetzt. Java-Entwickler, die Azure verwenden, können jetzt Produktions-Java-Anwendungen mit Azul Systems Zulu Enterprise-Builds von OpenJDK erstellen und ausführen, ohne dass zusätzliche Supportkosten anfallen.

Dieses neue Angebot zielt darauf ab, von Microsoft gehostete Java-Builds und -Bereitstellungen sorgenfrei zu machen, indem vierteljährliche Sicherheitsupdates und Bugfixes sowie bei Bedarf kritische Out-of-Band-Updates und Patches integriert werden. Wenn Sie derzeit java-Apps lokal oder mit anderen JDKs erstellen oder ausführen, sollten Sie in Betracht ziehen, zu Zulu auf Azure zu wechseln, um kostenlosen Support und Wartung zu erhalten. Weitere Informationen finden Sie im Blog Microsoft und Azul Systems mit kostenloser Java LTS-Unterstützung für Azure.

YAML support for Bitbucket Cloud pipelines (YAML-Unterstützung für Bitbucket-Cloudpipelines)

Zuvor haben YAML-basierte Pipelines Bitbucket Cloud nicht unterstützt. Jetzt können Sie yaML verwenden, um Ihre Bitbucket Cloud-Pipelines zu definieren oder den visuellen Designer zu verwenden, um dasselbe zu tun. Um YAML zu verwenden, fügen Sie Ihrem Repository eine azure-pipelines.yml Datei hinzu. Wählen Sie in Azure Pipelines Neue Buildpipeline, klicken Sie dann auf den Link Visueller Designer verwenden und wählen Sie "Bitbucket Cloud" und "YAML" aus. Hier können Sie den Pfad zur YAML-Datei Ihres Repositorys eingeben.

Weitere Informationen finden Sie im YAML-Syntaxhandbuch und im GitHub-Repository von YAML-Beispielen.

Vermeiden Sie das Auslösen mehrerer CI-Builds für Pull Requests.

Die yaML-Buildvorlagen, die in Azure-Pipelines enthalten sind, wurden so konfiguriert, dass Builds für alle Verzweigungen innerhalb eines Repositorys ausgelöst werden. Dazu gehörten Pullanforderungs-Themenzweige. Daher wurden zwei Builds ausgelöst, wenn Pullanforderungen erstellt wurden. Ein Build für den Pull-Request-Zweig als Reaktion auf den fortlaufenden Integrations-Trigger und ein zweiter Build für den Pull-Request-Zweig als Reaktion auf den Pull-Request-Trigger.

Mithilfe des nachstehenden YAML-Codeausschnitts werden die integrierten YAML-Vorlagen so konfiguriert, dass nur für den Master branch ein fortlaufender Integrationsbuild ausgelöst wird. Neue Pull-Requests werden weiterhin mithilfe des Pull-Request-Triggers erstellt. Weitere Informationen finden Sie in der Dokumentation zu Build-Pipeline-Triggern.

trigger:
- main

Ändern von Buildnummern, Hochladen und Herunterladen von Artefakten in geforkten Repository-Builds

Bisher hatten Validierungsbuilds für Pull-Anfragen in geforkten Repositories nicht die Berechtigung, Build-Artefakte hoch- und herunterzuladen oder die Buildnummer zu ändern. Die Berechtigungen wurden aus Sicherheitsgründen eingeschränkt, da es unsicher war, die erweiterten Berechtigungen des Agents während eines durch einen unbekannten Benutzer ausgelösten Fork-Builds verfügbar zu machen. Bei diesem Update sind Agentberechtigungen so festgelegt, dass Ihre Pipeline diese Vorgänge ausführen kann, falls erforderlich.

Nachfolgend finden Sie ein Beispiel für das YAML, mit dem Sie Buildausgaben in einer tar.gz Datei im Artefakt-Stagingverzeichnis archivieren können. Anschließend veröffentlicht sie die Ausgabe in Azure-Pipelines, die dem Build zugeordnet werden sollen. Weitere Details finden Sie in der Dokumentation zur Aufgabe „Archivdateien“ und zur Aufgabe „Build-Artefakte veröffentlichen“.

- task: ArchiveFiles@2
  inputs:
    archiveType: 'tar'
    tarCompression: 'gz'
    includeRootFolder: false
    rootFolderOrFile: '$(build.sourcesDirectory)/target'
    archiveFile: '$(build.artifactStagingDirectory)/$(build.buildId).tar.gz'
- task: PublishBuildArtifacts@1
  inputs:
    pathtoPublish: '$(build.artifactStagingDirectory)'

Neue Option in der Aufgabe "Testergebnisse veröffentlichen", um den Build bei fehlgeschlagenen Tests zu beenden.

Die Aufgabe "Testergebnisse veröffentlichen " wird verwendet, um Testergebnisse in Azure-Pipelines zu veröffentlichen, wenn Tests mit Ihrer Wahl des Testläufers ausgeführt werden. Bisher würde die Aufgabe einfach Ergebnisse aus einer Ergebnisdatei veröffentlichen und würde den Build nicht fehlschlagen, auch wenn die Ergebnisdatei fehlgeschlagene Tests enthielt. Dies bedeutete, dass Sie benutzerdefinierte Schritte schreiben mussten, damit bei Testfehlern der Build fehlschlägt.

Wir haben nun eine Option zur Aufgabe hinzugefügt, die den Build fehlschlagen lässt, wenn Tests fehlschlagen.

Updates für das Azure-Portal zum Erstellen eines Azure DevOps-Projekts

Das Azure-Portal enthält jetzt zusätzliche Funktionen zur Unterstützung weiterer Frameworks und Dienste beim Erstellen eines Azure DevOps-Projekts. Nachfolgend finden Sie die Liste der Änderungen für jeden Bereich.

Rahmen

Azure IoT ist ein vollständig verwalteter Dienst, der Cloud Intelligence lokal auf plattformübergreifenden IoT-Geräten bereitstellt. Jetzt können Sie ein Azure DevOps-Projekt aus dem Azure-Portal erstellen und das Einfache IoT als Anwendungsframework verwenden.

Dienstleistung

Zuvor unterstützte der Workflow "Azure DevOps-Projekt erstellen" im Azure-Portal nur "Neu erstellen" als Option für Kubernetes Service. Es wurde eine neue Option hinzugefügt, damit Sie einen vorhandenen Cluster als Bereitstellungsziel für das Pipelinesetup auswählen können.

Verwenden des Azure-Portals zum Einrichten und Bereitstellen in einer CosmosDB-Datenbank

Derzeit können Sie den Azure DevOps-Projektworkflow im Azure-Portal verwenden, um Build- und Freigabepipelinen für ein Git-Repository einzurichten. Jetzt können Sie azure Web App für Container (Linux) oder Azure Kubernetes Service bereitstellen, wobei eine CosmosDB als Datenbank bereitgestellt wird, die die Apps auf diesen Zielen unterstützt. Dies ist derzeit für alle Node.js-Vorlagen verfügbar, und wir erwarten, dass wir zukünftig Unterstützung für andere Vorlagen hinzufügen.

Einrichten von Builds und Releasepipelines für Funktionen im Azure-Portal

Sie können jetzt den Azure DevOps-Projektworkflow im Azure-Portal verwenden, um Build- und Freigabepipelinen für Git-Repository einzurichten, die Azure Functions 2.0 (Windows) bereitstellen. Dies ist für Node.js und .NET Core verfügbar.

Azure Artifacts

Statistiken zur Paketnutzung

Bisher haben Azure Artifacts keine Möglichkeit bereitgestellt, die Verwendung oder Beliebtheit von Paketen zu messen. Mit diesem Update haben wir die Anzahl der Downloads und Benutzer sowohl den Paketlisten- als auch den Paketdetailseiten hinzugefügt. Sie können die Statistiken auf der rechten Seite einer seite sehen.

Wiki

Monospace-Schriftart für den Wiki-Markdown-Editor

Mit der Einführung von monospaced Fonts für den Wiki Markdown-Editor ist die Lesbarkeit keine Herausforderung mehr. Die Markdown-Quelle sieht sauber und einfach zu lesen aus. Dieses Feature wurde basierend auf diesem Vorschlagsticketpriorisiert.

Fette Wiki-Seitennamen

Früher sahen sowohl der Wiki-Seitentitel als auch die Kopfzeile 1 gleich aus. Dies erschwerte es den Lesern, zwischen ihnen zu unterscheiden. Jetzt wurden die Wiki-Seitentitel fett formatiert und unterscheiden sich von Kopfzeile 1. Dieses Feature wurde basierend auf diesem Vorschlagsticketpriorisiert.

Insert Markdown table (Einfügen einer Markdowntabelle)

Das Erstellen von Markdown-Tabellen in einem Wiki ist keine Herausforderung mehr. Sie können jetzt eine Markdown-Tabelle mit einem Klick auf eine Schaltfläche hinzufügen. Dieses Feature wurde basierend auf diesem Featurevorschlagsticket priorisiert.

Einbetten von Azure Boards-Abfrageergebnissen in Wiki

Sie können jetzt Azure Boards-Abfrageergebnisse in eine Wiki-Seite in Form einer Tabelle einbetten. Die folgende Abbildung zeigt ein Beispiel einer Wiki-Seite mit einer Liste aller veröffentlichten Features und alle aktiven Fehler im aktuellen Sprint, die in das Wiki eingebettet sind. Der auf der Seite angezeigte Inhalt verwendet eine vorhandene Arbeitsaufgabenabfrage. Mit diesem neuen Feature können Sie dynamische Inhalte erstellen und müssen sich keine Gedanken darüber machen, die Wiki-Seite manuell zu aktualisieren.

Die Abfrageergebnisse können in zwei Schritten hinzugefügt werden.

1. Klicken Sie auf der Bearbeitungssymbolleiste auf die Schaltfläche "Abfrageergebnisse".

2. Wählen Sie die erforderliche Abfrage aus, und klicken Sie auf die Schaltfläche "Einfügen".

Die Ergebnisse der Abfrage können nun in Form einer Tabelle angezeigt werden, nachdem Sie die Seite gespeichert haben.

Dies wurde basierend auf den folgenden Featurevorschlägen priorisiert:

1. Arbeitsaufgabenabfragen in Wiki
2. Dynamische Wiki-Inhalte hinzufügen

Nächste Schritte

Lesen Sie die folgenden neuen Features, und fahren Sie mit Azure DevOps fort, um sie selbst zu testen.

So geben Sie Feedback

Wir würden uns freuen zu hören, was Sie über diese Features denken. Verwenden Sie das Feedbackmenü, 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,

Jeremy Epling