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 New build pipeline (Neue Buildpipeline) kann jetzt Pipelines für GitHub Enterprise-Repositorys erstellen. Außerdem analysiert er Ihr Repository und schlägt eine Sprachvorlage vor. Darüber hinaus kann es Dienstverbindungen für die von Ihnen ausgewählten GitHub-Repositorys erstellen und wiederverwenden.
Weitere Informationen finden Sie in der Nachstehenden Liste der Features .
Features
General:
Azure Boards:
Azure Pipelines:
- GitHub Enterprise support in the pipeline wizard (GitHub Enterprise-Unterstützung im Pipeline-Assistenten)
- Automatic GitHub service connections in pipelines (Automatische GitHub-Dienstverbindungen in Pipelines)
- Display status for each pipeline job in GitHub Checks (Anzeigen des Status jedes Pipelineauftrags in GitHub-Prüfungen)
- Default authorization for YAML resources in GitHub (Standardautorisierung für YAML-Ressourcen in GitHub)
- Service containers for YAML pipelines (Dienstcontainer für YAML-Pipelines)
- Work items linked to GitHub commits in Release Summary (Mit GitHub-Commits verknüpfte Arbeitselemente in der Releasezusammenfassung)
- New Azure App service tasks optimized for YAML (Neue, für YAML optimierte Azure App Service-Tasks)
- Azure Active Directory (AD)-Authentifizierungsunterstützung für Azure SQL-Aufgabe
- Grafana annotations service hook (Service Hook für Grafana-Anmerkungen)
- Query Azure Monitor alerts tasks (Abfragen von Azure Monitor-Warnungstasks)
- Inline input of spec file in Deploy to Kubernetes task (Inlineeingabe einer Spezifikationsdatei im Kubernetes-Bereitstellungstask)
- Docker CLI Installer task (Docker-CLI-Installertask)
- Java long-term support (LTS) on Microsoft hosted agents (Langfristige Java-Unterstützung in von Microsoft gehosteten Agents)
- YAML support for Bitbucket Cloud pipelines (YAML-Unterstützung für Bitbucket-Cloudpipelines)
- Avoid triggering multiple CI builds for pull requests (Vermeiden mehrerer CI-Builds für Pull Requests)
- Change build numbers, upload and download artifacts in forked repository builds (Ändern von Buildnummern, Hoch- und Herunterladen von Artefakten in geforkten Repositorybuilds)
- New option in Publish Test Results task to fail build on failed tests (Neue Option im Task „Testergebnisse veröffentlichen“, bei der Builds mit fehlgeschlagenen Tests auch fehlschlagen)
- 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:
Wiki:
- Monospaced font for Wiki Markdown editor
- Fett formatierte Wiki-Seitentitel
- Insert Markdown table (Einfügen einer Markdowntabelle)
- 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 auch ein gelöschtes Projekt aus der Organisation Einstellungen > Übersichtsseite wiederherstellen.
Azure Boards
Simplify the organization of your work using the Basic process (Vereinfachte Arbeitsorganisation mit dem Basic-Prozess)
Wichtig
Der Standardprozess befindet sich in der öffentlichen Vorschau als Standardprozess für neue Projekte in neuen Organisationen, die in der Region Zentral-USA erstellt wurden.
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 Grundlegende Prozess bietet drei Arbeitsaufgabentypen (Epics, Issues und Tasks), um Ihre Arbeit zu planen und nachzuverfolgen. Es wird empfohlen, Probleme zu verwenden, um Elemente wie Benutzergeschichten, Fehler und Features während der Verwendung von Epics zu verwenden, um Probleme in größeren Arbeitseinheiten zu gruppieren. Wenn Sie Fortschritte bei Ihrer Arbeit machen, verschieben Sie Elemente entlang eines einfachen Zustandsworkflows von To Do, Do und Done.
Sehen Sie sich die Dokumentation zum Nachverfolgen von Problemen und Aufgaben an, um Ihnen bei den ersten Schritten mit Ihrem neuen Projekt zu helfen.
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 Assistenten für neue Buildpipeline 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 yaML als direkten Commit für Ihre Standardbranch oder als Pullanforderung 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 Buildpipeline zum Erstellen einer Pipeline für GitHub verwenden, führte die Seite zum Auswählen oder Erstellen einer GitHub-Dienstverbindung zu Verwirrung darüber, welche Verbindung aus der Liste ausgewählt werden soll. Jetzt müssen Sie keine Verbindung auswählen. Der Assistent erstellt und verwendet automatisch eine Dienstverbindung für das ausgewählte Repository.
Wenn Sie manuell eine andere Verbindung als die verbindung auswählen möchten, die automatisch ausgewählt ist, folgen Sie dem Link "Verbindung auswählen" . Weitere Informationen finden Sie unter Erstellen von GitHub-Repositorys.
Hinweis
Die Auswahl basiert auf der GitHub-App von Azure Pipelines (sofern sie im Repository installiert ist) oder Ihrer persönlichen GitHub-Identität (mit OAuth).
Display status for each pipeline job in GitHub Checks (Anzeigen des Status jedes Pipelineauftrags in GitHub-Prüfungen)
Zuvor wurde ein einzelner Buildstatus auf GitHub Überprüft auf Ihre Pipeline veröffentlicht, auch wenn er Aufträge für mehrere Plattformen (z. B. Linux, macOS und Windows) enthält. 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 netzwerkt es, damit Ihre Pipelineschritte von den Redis des Hostnamens darauf verweisen können. Wenn die Pipeline abgeschlossen ist, dreht der Agent den Dienstcontainer sauber.
Work items linked to GitHub commits in Release Summary (Mit GitHub-Commits verknüpfte Arbeitselemente in der Releasezusammenfassung)
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. Auf diese Weise können Teams weitere Informationen zu den Commits nachverfolgen und abrufen, die in einer Umgebung bereitgestellt wurden.
Neue Azure-App Dienstaufgaben, die für YAML optimiert sind
Wir unterstützen jetzt vier neue Aufgaben, die eine einfache und dennoch leistungsstarke Möglichkeit bieten, Azure-App Services mit modernen Entwicklern bereitzustellen. Diese Aufgaben verfügen über eine optimierte YAML-Syntax, die es einfach und intuitiv macht, Bereitstellungen für Azure-App Services 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 (Integrated & Password) und einer Verbindungszeichenfolge zusätzlich zur vorhandenen Unterstützung für die SQL Server-Authentifizierung zu unterstützen.
Grafana annotations service hook (Service Hook für Grafana-Anmerkungen)
Wir unterstützen jetzt einen neuen Diensthaken, mit dem Sie Grafana-Anmerkungen für abgeschlossene Bereitstellungsereignisse 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.
Query Azure Monitor alerts tasks (Abfragen von Azure Monitor-Warnungstasks)
Die vorherige Version der Abfrage-Azure Monitor-Aufgabe unterstützt das Abfragen von Warnungen nur auf der klassischen Überwachungsoberfläche. Mit dieser neuen Version der Aufgabe können Sie Warnungen zur einheitlichen Überwachungserfahrung abfragen, die kürzlich von Azure Monitor eingeführt wurde.
Inline input of spec file in Deploy to Kubernetes task (Inlineeingabe einer Spezifikationsdatei im Kubernetes-Bereitstellungstask)
Zuvor mussten Sie mit der Kubernetes-Bereitstellungsaufgabe einen Dateipfad für die Konfiguration angeben. Jetzt können Sie auch die Konfigurationsinline hinzufügen.
Docker CLI Installer task (Docker-CLI-Installertask)
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 wurde entwickelt, um von Microsoft gehostete Java-Builds und -Bereitstellungen beunruhigend zu machen, indem vierteljährliche Sicherheitsupdates und Bugfixes sowie wichtige Out-of-Band-Updates und Patches bei Bedarf integriert werden. Wenn Sie derzeit lokale Oder mit anderen JDKs Java-Apps erstellen oder ausführen, sollten Sie in Betracht ziehen, zu Zulu auf Azure zu wechseln, um kostenlosen Support und Standard tenance 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 die Option "Neue Buildpipeline" und dann den Link "Visueller Designer verwenden" und dann "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.
Avoid triggering multiple CI builds for pull requests (Vermeiden 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 Pullanforderungszweig als Reaktion auf den Fortlaufenden Integrationstrigger und ein zweiter Build für den Pullanforderungszweig als Reaktion auf den Pullanforderungstrigger.
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 Pullanforderungen werden weiterhin mithilfe des Pullanforderungstriggers erstellt. Weitere Informationen finden Sie in der Dokumentation zu Buildpipelinetriggern .
trigger:
- main
Change build numbers, upload and download artifacts in forked repository builds (Ändern von Buildnummern, Hoch- und Herunterladen von Artefakten in geforkten Repositorybuilds)
Bisher haben Pull-Anforderungsüberprüfungsbuilds für Verzweigungsrepositorys keine Berechtigung zum Hochladen und Herunterladen von Buildartefakten oder zum Ändern der Buildnummer. Berechtigungen wurden eingeschränkt, da sie unsicher waren, die erweiterten Berechtigungen des Agents während eines von einem unbekannten Benutzer ausgelösten Verzweigungsbuilds 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, das Sie zum Archivieren von Buildausgaben in einer Tar.gz-Datei in das Artefakt-Stagingverzeichnis verwenden 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 "Buildartefakte 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)'
New option in Publish Test Results task to fail build on failed tests (Neue Option im Task „Testergebnisse veröffentlichen“, bei der Builds mit fehlgeschlagenen Tests auch fehlschlagen)
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 der Build bei Testfehlern fehlschlägt.
Wir haben nun eine Option in der Aufgabe hinzugefügt, um den Build fehlzuschlagen, wenn fehlgeschlagene Tests vorhanden sind.
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.
Framework
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.
Dienst
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. Diese Funktionalität ist für Node.js und .NET Core verfügbar.
Azure Artifacts
Package usage stats (Statistiken zur Paketverwendung)
Bisher haben Azure Artifacts keine Möglichkeit bereitgestellt, die Verwendung oder Beliebtheit von Paketen zu messen. Mit diesem Update haben wir sowohl der Paketliste als auch den Paketdetails eine Anzahl von Downloads und Benutzern hinzugefügt. Sie können die Statistiken auf der rechten Seite einer seite sehen.
Wiki
Monospaced font for 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 Vorschlagsticket priorisiert.
Fett formatierte Wiki-Seitentitel
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 Vorschlagsticket priorisiert.
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.
- Klicken Sie auf der Bearbeitungssymbolleiste auf die Schaltfläche "Abfrageergebnisse".
- 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:
Nächste Schritte
Hinweis
Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.
Lesen Sie die folgenden neuen Features, und fahren Sie mit Azure DevOps fort, um sie selbst zu testen.
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.
Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.
Vielen Dank,
Jeremy Epling