Prise en charge de GitHub Enterprise et connexions automatiques de service GitHub dans les pipelines de build - Mise à jour sprint 146

  • Article

Dans la mise à jour Sprint 146 d’Azure DevOps, nous avons amélioré notre intégration GitHub à Azure Pipelines. L’Assistant Nouveau pipeline de build peut à présent créer des pipelines pour les dépôts GitHub Enterprise. Il analyse également votre dépôt pour fournir un modèle de langage suggéré. En outre, il peut créer et réutiliser des connexions de service pour les dépôts GitHub que vous sélectionnez.

Pour plus d’informations, consultez la liste des fonctionnalités ci-dessous.

Fonctionnalités

Général :

Azure Boards :

Azure Pipelines :

Azure Artifacts :

Wiki :

Général

Restaurer des projets supprimés

Dans cette mise à jour, nous avons ajouté la possibilité de restaurer des projets supprimés à partir du portail Azure DevOps. Si vous disposez de l’autorisation « supprimer le projet », vous pouvez également restaurer un projet supprimé de la page De vue d’ensemble de l’organisation > Paramètres.

Azure Boards

Simplifier l’organisation de votre travail en utilisant le processus De base

Important

Le processus de base est en préversion publique comme processus par défaut pour les nouveaux projets au sein de nouvelles organisations créées dans la région USA Centre.

Historiquement, Agile a été le processus par défaut pour les nouveaux projets, offrant un ensemble robuste et flexible de types d’éléments de travail et d’états pour répondre à une variété de méthodes de livraison de projet. Pour certaines équipes, qui sont plus familières avec d’autres outils ou qui veulent adopter un ensemble d’outils plus puissant, souhaitent commencer rapidement à utiliser la terminologie avec laquelle ils sont plus familiers.

Le nouveau processus de base fournit trois types d’éléments de travail (épopées, problèmes et tâches) pour planifier et suivre votre travail. Nous vous recommandons d’utiliser Des problèmes pour suivre des éléments tels que des histoires utilisateur, des bogues et des fonctionnalités tout en utilisant Epics pour regrouper les problèmes en unités de travail plus importantes. À mesure que vous progressez sur votre travail, déplacez les éléments le long d’un flux de travail d’état simple de To Do, Doing et Done.

Organize work using the Basic process.

Consultez la documentation sur le suivi des problèmes et des tâches pour vous aider à bien démarrer avec votre nouveau projet.

Azure Pipelines

Prise en charge de GitHub Enterprise dans l’Assistant de pipeline

Auparavant, vous pouvez utiliser le concepteur visuel pour créer des pipelines pour les référentiels GitHub Enterprise. À présent, vous pouvez également utiliser l’Assistant Nouveau pipeline de build pour créer vos pipelines.

GitHub Enterprise support in the pipeline wizard.

L’Assistant analyse votre dépôt GitHub Enterprise pour suggérer un modèle YAML qui correspond à votre langage de projet. Vous pouvez ensuite modifier et enregistrer le YAML en tant que validation directe sur votre branche par défaut ou en tant que demande de tirage.

Edit and save the YAML.

Pour plus d’informations, consultez la documentation sur la création de votre premier pipeline ici.

Connexions de service GitHub automatiques dans les pipelines

Lorsque vous utilisez l’Assistant Nouveau pipeline de build pour créer un pipeline pour GitHub, la page pour choisir ou créer une connexion de service GitHub a entraîné une confusion quant à la connexion à sélectionner dans la liste. À présent, vous n’avez pas besoin de choisir une connexion. L’Assistant crée et utilise automatiquement une connexion de service pour le référentiel que vous choisissez.

Si vous souhaitez choisir manuellement une connexion autre que celle qui est automatiquement sélectionnée, suivez le lien hypertexte Choisir une connexion . Pour plus d’informations, consultez Créer des référentiels GitHub.

Remarque

La sélection est basée sur l’application GitHub Azure Pipelines (si elle est installée dans le référentiel) ou votre identité GitHub personnelle (à l’aide d’OAuth).

Affichage du statut de chaque travail de pipeline dans GitHub Checks

Auparavant, un état de build unique a été publié dans GitHub Checks pour votre pipeline, même s’il incluait des travaux pour plusieurs plateformes (par exemple, Linux, macOS et Windows). À présent, l’état est publié dans GitHub Checks pour chaque travail dans le pipeline. En outre, vous pouvez réexécuter l’intégralité de la build ou uniquement des travaux ayant échoué individuellement à partir de GitHub Checks. Pour utiliser cette fonctionnalité, votre pipeline doit être configuré pour utiliser l’application GitHub Azure Pipelines. Pour plus d’informations, consultez Intégrer à l’aide de l’application GitHub. Pour configurer un pipeline avec des travaux pour plusieurs plateformes, consultez Créer un pipeline multiplateforme.

Display status for each pipeline job.

Autorisation par défaut pour les ressources YAML dans GitHub

Si vous gérez votre code source dans GitHub et utilisez YAML pour définir votre pipeline, vous avez probablement rencontré un échec de génération d’autorisation de ressource. Lorsque vous avez modifié votre fichier YAML et ajouté une référence à l’une des ressources protégées (par exemple, connexion de service, pool d’agents, groupe de variables ou fichier sécurisé), Azure Pipelines n’a pas pu valider l’identité de l’utilisateur qui a effectué cette modification et a échoué la build. Pour contourner ce problème, vous deviez enregistrer le pipeline de build dans l’éditeur web après avoir apporté une modification au fichier YAML. Beaucoup d’utilisateurs qui ont rencontré ce problème voulaient simplement permettre à tous les pipelines d’utiliser la ressource.

Pour éviter l’échec de génération d’autorisation des ressources, nous avons modifié le comportement par défaut de toutes les nouvelles connexions de service, pools d’agents et groupes de variables à utiliser dans tous les pipelines. Si vous souhaitez des contrôles plus stricts sur vos ressources, vous pouvez désactiver le modèle d’autorisation par défaut (voir la figure ci-dessous). Lorsque vous le faites, une personne disposant des autorisations d’utilisation de la ressource doit enregistrer le pipeline dans l’éditeur web une fois qu’une référence de ressource est ajoutée au fichier YAML.

Default authorization for YAML resources.

Conteneurs de service pour les pipelines YAML

Auparavant, vous deviez installer, démarrer et arrêter des services tels que des bases de données ou des caches de mémoire si votre pipeline YAML utilisait ces services. Avec cette mise à jour, nous avons ajouté des conteneurs de service qui peuvent gérer ces tâches. Par exemple, si votre pipeline utilise un cache Redis pour les tests d’intégration, vous pouvez inclure l’image conteneur redis en tant que service dans le pipeline. L’agent récupère automatiquement l’image, la démarre et le réseau afin que vos étapes de pipeline puissent y faire référence par le nom d’hôte redis. Une fois le pipeline terminé, l’agent fait tourner le conteneur de service propre ly.

Éléments de travail liés aux validations GitHub dans la page de résumé des mises en production

En décembre, nous avons introduit la possibilité de lier des validations GitHub aux éléments de travail. Nous sommes heureux d’annoncer que vous pouvez maintenant voir tous les éléments de travail Azure Boards liés aux validations GitHub dans la page récapitulative de la version. Cela aidera les équipes à suivre et à récupérer plus d’informations sur les validations déployées dans un environnement.

Nouvelles tâches Azure App Service optimisées pour YAML

Nous prenons désormais en charge quatre nouvelles tâches qui offrent un moyen simple et puissant de déployer Azure App Services avec des développeurs modernes à l’esprit. Ces tâches ont une syntaxe YAML optimisée qui permet de créer des déploiements simples et intuitifs sur Azure AppServices, notamment WebApps, FunctionApps, WebApps pour conteneurs et FunctionApp pour conteneurs sur les plateformes Windows et Linux.

Nous prenons également en charge une nouvelle tâche utilitaire pour la transformation de fichier et la substitution de variables pour les formats XML et JSON.

Prise en charge de l’authentification Azure Active Directory (AD) pour la tâche Azure SQL

La tâche Azure SQL a été améliorée pour prendre en charge la connexion à une base de données à l’aide d’Azure AD (intégré et mot de passe) et d’une chaîne de connexion en plus de la prise en charge existante de l’authentification SQL Server.

Azure AD authentication support for Azure SQL task.

Crochet de service Annotations Grafana

Nous prenons désormais en charge un nouveau hook de service qui vous permet d’ajouter des annotations Grafana pour les événements Deployment Completed à un tableau de bord Grafana. Cela vous permet de mettre en corrélation les déploiements avec les modifications apportées aux métriques d’application ou d’infrastructure qui sont visualisées dans un tableau de bord Grafana.

Grafana annotations service hook.

Interroger les tâches liées à des alertes Azure Monitor

La version précédente de la tâche Requête Azure Monitors a pris en charge les alertes d’interrogation uniquement sur l’expérience de supervision classique. Avec cette nouvelle version de la tâche, vous pouvez interroger des alertes sur l’expérience de supervision unifiée récemment introduite par Azure Monitor.

Query Azure Monitor alerts tasks.

Entrée en ligne du fichier de spécification dans la tâche Déployer sur Kubernetes

Auparavant, la tâche de déploiement Kubernetes vous obligeait à fournir un chemin d’accès de fichier pour la configuration. Vous pouvez maintenant ajouter la configuration incluse.

Inline input of spec file in Deploy to Kubernetes task.

Tâche d’installation de l’interface CLI de Docker

Cette tâche permet l’installation de n’importe quelle version de Docker CLI sur les agents, comme spécifié par l’utilisateur.

Docker CLI Installer task.

Prise en charge à long terme de Java sur les agents hébergés Microsoft

Auparavant, les agents hébergés par Microsoft avaient des kits JDK préinstallés qui étaient surchargés par des licences complexes, des restrictions d’utilisateur final et un manque de support à long terme. Dans cette mise à jour, nous avons remplacé les JDK par des builds LTS testées, certifiées et LTS d’OpenJDK à partir d’Azul Systems. Les développeurs Java utilisant Azure peuvent désormais créer et exécuter des applications Java de production à l’aide de builds Azul Systems Zulu Enterprise d’OpenJDK sans entraîner de coûts de support supplémentaires.

Cette nouvelle offre est conçue pour rendre les builds et déploiements Java hébergés par Microsoft sans souci en intégrant les mises à jour de sécurité trimestrielles et les correctifs de bogues ainsi que les mises à jour et correctifs hors bande critiques en fonction des besoins. Si vous créez ou exécutez actuellement des applications Java localement ou avec d’autres JDK, envisagez de passer à Zulu sur Azure pour bénéficier d’une prise en charge et d’une maintenance gratuites. Pour plus d’informations, consultez le blog Microsoft et Azul Systems pour apporter gratuitement la prise en charge de Java LTS à Azure.

Prise en charge de YAML pour les pipelines cloud Bitbucket

Auparavant, les pipelines YAML ne prenaient pas en charge Bitbucket Cloud. À présent, vous pouvez utiliser YAML pour définir vos pipelines Bitbucket Cloud ou utiliser le concepteur visuel pour faire de même. Pour utiliser YAML, ajoutez un fichier azure-pipelines.yml à votre référentiel. Dans Azure Pipelines, choisissez Nouveau pipeline de build, puis sélectionnez Utiliser le lien hypertexte du concepteur visuel, sélectionnez « Bitbucket Cloud » et « YAML ». Ici, vous pouvez entrer le chemin d’accès au fichier YAML de votre dépôt.

Pour plus d’informations, consultez le guide de syntaxe YAML et le référentiel GitHub des exemples YAML.

Éviter de déclencher plusieurs builds d’intégration continue pour les demandes de tirage

Les modèles de build YAML inclus dans Azure Pipelines ont été configurés pour déclencher des builds pour n’importe quelle branche au sein d’un référentiel. Cela comprenait les branches de rubriques de demande de tirage( pull request). Par conséquent, deux builds ont été déclenchées lorsque des demandes de tirage ont été créées. Une build pour la branche de demande d’extraction en réponse au déclencheur d’intégration continue et une deuxième build pour la branche de demande d’extraction en réponse au déclencheur de demande de tirage.

À l’aide de l’extrait de code YAML ci-dessous, les modèles YAML intégrés sont configurés pour déclencher une build d’intégration continue uniquement pour la branche maître . Les nouvelles demandes de tirage génèreront toujours à l’aide du déclencheur de demande de tirage. Pour plus d’informations, consultez la documentation relative aux déclencheurs de pipeline de build.

trigger:
- main

Changer les numéros de build, charger et télécharger des artefacts dans des builds de dépôts répliquées

Jusqu’à présent, les builds de validation des demandes de tirage pour les référentiels dupliqués n’ont pas été autorisées à charger et télécharger des artefacts de build ou à modifier le numéro de build. Les autorisations ont été restreintes, car elles n’étaient pas sécurisées pour rendre les autorisations étendues de l’agent disponibles pendant une build de fork déclenchée par un utilisateur inconnu. Avec cette mise à jour, les autorisations de l’agent sont limitées afin que votre pipeline puisse effectuer ces opérations si nécessaire.

Voici un exemple de YAML que vous pouvez utiliser pour archiver les sorties de build dans un fichier tar.gz dans le répertoire intermédiaire de l’artefact. Ensuite, il publie la sortie sur Azure Pipelines à associer à la build. Pour plus d’informations, consultez la documentation sur la tâche Archive Files et la tâche Publier des artefacts de build.

- 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)'

Nouvelle option de la tâche Publier les résultats de test pour faire échouer la génération lorsque des tests ont échoué

La tâche Publier les résultats des tests est utilisée pour publier les résultats des tests dans Azure Pipelines lorsque les tests sont exécutés à l’aide de votre choix d’exécuteur de test. Jusqu’à présent, la tâche publierait simplement les résultats à partir d’un fichier de résultats et n’échouerait pas la génération même si le fichier de résultats contenait des tests ayant échoué. Cela signifie que vous deviez écrire des étapes personnalisées pour que la build échoue sur les échecs de test.

Nous avons maintenant ajouté une option dans la tâche pour échouer la build en cas d’échec des tests.

Fail the build if there are any failed tests.

Mises à jour au portail Azure pour créer un projet Azure DevOps

Le portail Azure inclut désormais des fonctionnalités supplémentaires pour prendre en charge davantage d’infrastructures et de services lors de la création d’un projet Azure DevOps. Vous trouverez ci-dessous la liste des modifications pour chaque zone.

Structure

Azure IoT est un service entièrement managé qui fournit une intelligence cloud localement sur des appareils IoT multiplateformes. À présent, vous pouvez créer un projet Azure DevOps à partir du portail Azure et utiliser l’IoT simple comme framework d’application.

Use the Simple IoT as the application framework.

service

Auparavant, le flux de travail Créer un projet Azure DevOps dans le portail Azure prenait uniquement en charge La création de nouveau en tant qu’option pour Kubernetes Service. Une nouvelle option a été ajoutée pour vous permettre de choisir un cluster existant comme cible de déploiement pour la configuration du pipeline.

Choose an existing cluster as the deployment target for the pipeline setup.

Utiliser le portail Azure pour configurer et déployer sur une base de données CosmosDB

Actuellement, vous pouvez utiliser le flux de travail Azure DevOps Project dans le portail Azure pour configurer des pipelines de génération et de mise en production pour un dépôt Git. À présent, vous pouvez déployer sur Azure Web App pour conteneurs (Linux) ou Azure Kubernetes Service avec une base de données provisionnée en tant que base de données qui sauvegarde les applications sur ces cibles. Ceci est actuellement disponible pour tous les modèles Node.js et nous prévoyons d’ajouter la prise en charge d’autres modèles à l’avenir.

Use the Azure Portal to set up and deploy to an Azure Cosmos DB database.

Configurer des builds et des pipelines de mise en production pour Functions dans le portail Azure

Vous pouvez maintenant utiliser le flux de travail Azure DevOps Project dans le portail Azure pour configurer des pipelines de génération et de mise en production pour le référentiel Git qui déploient Azure Functions 2.0 (Windows). Cette fonctionnalité est disponible pour Node.js et .NET Core.

Set up builds and release pipelines for Functions in Azure portal.

Azure Artifacts

Statistiques d’utilisation des packages

Jusqu’à présent, Azure Artifacts n’a pas fourni de moyen de mesurer l’utilisation ou la popularité des packages. Avec cette mise à jour, nous avons ajouté un nombre de téléchargements et d’utilisateurs aux pages de détails de package et de liste de packages. Vous pouvez voir les statistiques sur le côté droit de l’une ou l’autre des pages.

Package usage stats.

Wiki

Police monospaced pour l’éditeur Wiki Markdown

Avec l’introduction de polices monospaced pour l’éditeur Wiki Markdown, la lisibilité n’est plus un défi. La source Markdown semble propre et facile à lire. Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion.

Monospaced font for Wiki Markdown editor.

Titres de page Wiki gras

Précédemment, le titre de la page Wiki et l’en-tête 1 semblaient identiques. Cela a rendu difficile la distinction entre les lecteurs. À présent, les titres de page Wiki ont été mis en gras et distincts de l’en-tête 1. Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion.

Bold Wiki page titles.

Insérer un tableau de Markdown

La création de tables Markdown dans un wiki n’est plus un défi. Vous pouvez maintenant ajouter une table Markdown en un clic sur un bouton. Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion de fonctionnalité.

Insert Markdown table.

Incorporer des résultats de requête Azure Boards dans Wiki

Vous pouvez désormais incorporer des résultats de requête Azure Boards dans une page wiki sous la forme d’une table. L’image ci-dessous montre un exemple de page wiki avec une liste de toutes les fonctionnalités publiées et tous les bogues actifs dans le sprint actuel incorporé dans le wiki. Le contenu affiché dans la page utilise une requête d’élément de travail existante. Avec cette nouvelle fonctionnalité, vous pouvez créer du contenu dynamique et ne pas avoir à vous soucier de la mise à jour manuelle de la page wiki.

Embed Azure Boards query results in Wiki.

Les résultats de la requête peuvent être ajoutés en deux étapes

  1. Cliquez sur le bouton « Résultats de la requête » dans la barre d’outils Modifier.

Select the Query Results button from the edit toolbar.

  1. Sélectionnez la requête requise, puis cliquez sur le bouton « Insérer ».

Les résultats de la requête peuvent maintenant être consultés sous la forme d’une table après avoir enregistré la page.

View results of the query.

Cela a été hiérarchisé en fonction des suggestions de fonctionnalités suivantes :

  1. Requêtes d’élément de travail dans wiki
  2. Ajouter du contenu Wiki dynamique

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Découvrez les nouvelles fonctionnalités ci-dessous et passez à Azure DevOps pour les essayer vous-même.

Accéder à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu commentaires pour signaler un problème ou fournir une suggestion.

Make a suggestion

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Jeremy Epling