Partager via

Améliorations de l’intégration GitHub d’Azure Boards et d’Azure Pipelines - Mise à jour Sprint 149

  • Article

Dans la mise à jour Sprint 149 d’Azure DevOps, nous avons ajouté la possibilité d’accéder directement à Azure Boards à partir de mentions dans un commentaire GitHub, ainsi que la prise en charge d’Azure Boards dans GitHub Enterprise.

Pour Azure Pipelines, nous avons activé une nouvelle fonctionnalité sur les demandes de tirage de GitHub qui vous permet d’exécuter des vérifications facultatives en mentionnant /azp dans le commentaire. Vous pouvez également demander un commentaire sur la demande de tirage à partir d’un référentiel contributeur avant que le pipeline ne s’exécute, ce qui vous permet d’examiner le code des utilisateurs inconnus avant de le générer.

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

Fonctionnalités

Général :

Azure Boards :

Azure Pipelines :

Azure Artifacts :

Création de rapports :

Général

Résoudre les utilisateurs déconnectés d’Azure Active Directory (Azure AD)

Avec notre mise à jour Sprint 148, nous vous avons donné la possibilité de connecter votre organisation à azure Active Directory à partir du portail Azure DevOps. Cette nouvelle expérience simplifiée a enregistré plusieurs étapes précédemment requises dans le Portail Azure. Toutefois, cette nouvelle expérience a laissé un écart ouvert, car vous avez toujours dû appeler la prise en charge pour restaurer l’accès pour les membres qui ont perdu l’accès pendant le processus de connexion. Les utilisateurs perdent l’accès lorsque leur identité de connexion précédente est introuvable dans azure Active Directory nouvellement connecté. Avec cette version, nous vous permettent de restaurer les membres déconnectés par vous-même, en vous enregistrant un appel de support client et en augmentant votre productivité.

Il existe deux étapes pour restaurer les membres déconnectés. Tout d’abord, les identités actuelles de ces membres sont mappées aux identités dans Azure AD nouvellement connecté. Étant donné que certains membres déconnectés peuvent ne pas avoir d’identités correspondantes dans Azure AD, la deuxième étape consiste à inviter ces membres restants en tant qu’invités à Azure AD. Cette mise à jour fournit une interface pour effectuer les deux étapes directement à partir de la page des paramètres Azure AD dans le portail Azure DevOps.

Recherchez les mises à jour dans notre documentation ici.

Azure Boards

Maintenant, lorsque vous mentionnez un élément de travail dans le commentaire d’un problème, d’une demande de tirage ou d’une validation dans GitHub à l’aide de la AB#{work item ID} syntaxe, ces mentions deviendront des liens hypertexte que vous pouvez cliquer pour accéder directement à l’élément de travail mentionné.

Cela ne crée pas de lien formel qui encombre l’élément de travail dans Azure Boards pour chaque conversation associée, mais donne à votre équipe un moyen de fournir un peu plus d’informations sur les éléments de travail lors de la discussion du code ou d’un problème signalé par le client. Pour plus d’informations, consultez la documentation d’intégration GitHub d’Azure Boards.

Navigate to work items from mentions.

Mises à jour des règles de transition de l’élément de travail

Nous avons propre mis en place plusieurs règles de transition d’élément de travail qui ont été incohérentes entre différents processus et types d’éléments de travail. Fermé par, Date fermée et Date de modification de l’état ont été corrigés sur tous les types d’éléments de travail standard et les types d’éléments de travail hérités nouvellement personnalisés. Activé par et date activée sont fixes pour tous les types d’éléments de travail système, mais ne seront pas résolus pour les types d’éléments de travail hérités personnalisés.

Prise en charge de GitHub Enterprise avec Azure Boards

Teams peut désormais connecter des projets Azure Boards à des référentiels hébergés dans des instances GitHub Enterprise Server. Lors de la connexion à l’aide d’OAuth, suivez les étapes décrites dans la documentation relative à l’inscription d’une application OAuth avant de créer une connexion à vos référentiels.

Modifier et supprimer des commentaires dans l’élément de travail

Nous sommes heureux d’annoncer que vous pouvez maintenant modifier et supprimer des commentaires dans la discussion de votre élément de travail dans Azure Boards une fonctionnalité hautement votée de notre forum de la Communauté des développeurs. Pour modifier votre commentaire, pointez simplement sur n’importe quel commentaire que vous possédez, et vous verrez deux nouveaux boutons. Si vous cliquez sur l’icône de crayon, vous entrez en mode édition et pouvez simplement modifier vos modifications et appuyer sur le bouton « Mettre à jour » pour enregistrer vos modifications.

Edit comments in Discussion.

Lorsque vous cliquez sur le menu de dépassement de capacité, vous verrez l’option permettant de supprimer votre commentaire. Une fois que vous cliquez sur ce bouton, vous serez invité à nouveau à confirmer que vous souhaitez supprimer ce commentaire et que le commentaire sera supprimé.

Delete comments in Discussion.

Vous aurez une piste d’audit complète de tous les commentaires modifiés et supprimés sous l’onglet Historique du formulaire élément de travail. Vous verrez également que nous avons mis à jour l’interface utilisateur de notre expérience de discussion pour qu’elle se sente plus moderne et interactive. En outre, nous avons ajouté des bulles autour des commentaires pour qu’il soit plus clair où les commentaires des individus commencent et se terminent.

Ordre des valeurs d’état sur le formulaire d’élément de travail

Auparavant, la valeur d’état du formulaire d’élément de travail était triée par ordre alphabétique. Avec cette mise à jour, nous avons modifié la façon dont les valeurs d’état sont ordonnées pour correspondre à l’ordre de flux de travail dans les paramètres de processus.

New state value order.

Remarque

La modification de l’ordre affecte uniquement le formulaire dans le web et les API REST. L’ordre des valeurs d’état ne sera pas modifié dans les clients à l’aide de l’om client WIT tel que Visual Studio 2017 ou Excel.

Azure Pipelines

Choisir le répertoire du code extrait dans les pipelines YAML

Auparavant, nous avons case activée des dépôts dans le s répertoire sous $(Agent.BuildDirectory). Vous pouvez maintenant choisir le répertoire dans lequel votre dépôt Git sera case activée utilisé avec des pipelines YAML.

Utilisez le path mot clé activé checkout et vous êtes en contrôle de la structure de dossiers. Vous trouverez ci-dessous un exemple de code YAML que vous pouvez utiliser pour spécifier un répertoire.

steps:
- checkout: self
  path: my-great-repo

Dans cet exemple, votre code est case activée transféré vers le répertoire de l’espace my-great-repo de travail de l’agent. Si vous ne spécifiez pas de chemin d’accès, votre dépôt continuera d’être case activée transféré vers un répertoire appelé s.

Les projets privés obtiennent maintenant 60 minutes de temps d’exécution par projet de pipeline

Jusqu’à présent, un compte gratuit (c’est-à-dire un qui n’avait pas acheté de travaux parallèles) exécuterait un travail pendant jusqu’à 30 minutes à la fois, jusqu’à 1 800 minutes par mois. Avec cette mise à jour, nous avons augmenté la limite de 30 à 60 minutes pour les comptes gratuits.

Si vous devez exécuter votre pipeline pendant plus de 60 minutes, vous pouvez payer une capacité supplémentaire par travail parallèle ou exécuter dans un agent auto-hébergé. Les agents auto-hébergés n’ont pas de restrictions de longueur de travail.

Mises à jour des images du pipeline hébergé

Nous avons apporté des mises à jour aux images de machine virtuelle VS2017, Ubuntu 16.04 et Windows Container 1803 pour vos pipelines Azure hébergés. Vous trouverez plus d’informations sur les dernières versions ici. Pour un aperçu complet des outils disponibles sur nos images, visitez notre référentiel Génération d’images sur GitHub ici.

En outre, nous avons adopté Moby comme runtime de conteneur. Moby est une infrastructure ouverte créée par Docker pour assembler des composants dans des systèmes personnalisés basés sur des conteneurs. Cela nous permettra de fournir des correctifs et des améliorations fréquents amont au runtime de conteneur.

Tâche d’installation de l’outil Duffle dans le pipeline de build et de mise en production

Duffle est un outil en ligne de commande qui vous permet d’installer et de gérer des bundles d’applications natives cloud (CNAB). Avec les CNAB, vous pouvez regrouper, installer et gérer des applications natives conteneur et leurs services.

Dans cette mise à jour, nous avons ajouté une nouvelle tâche pour les pipelines de build et de mise en production qui vous permet d’installer une version spécifique du fichier binaire Duffle.

Duffle tool installer task in build and release pipeline.

Approuver les déploiements Azure Pipelines à partir de Slack

Jusqu’à présent, les utilisateurs de Slack ont eu des fonctionnalités limitées pour gérer les déploiements de mise en production à partir d’un canal. L’application Azure Pipelines pour Slack vous permet d’approuver ou de rejeter un déploiement de mise en production à partir du canal. Cela facilite le processus d’approbation, car vous n’êtes pas obligé d’accéder au portail Azure Pipelines. En outre, vous pouvez approuver les déploiements en déplacement à l’aide de l’application mobile Slack.

Approve Azure Pipelines deployments from Slack.

Pour plus d’informations sur Azure Pipelines et Slack, consultez la documentation ici.

Tous les fournisseurs de sources sont inclus dans l’assistant de nouveau pipeline de build

Jusqu’à présent, les fournisseurs sources tels que GitHub, Azure Repos et Bitbucket Cloud ont été divisés entre l’éditeur de pipeline classique et l’Assistant Nouveau pipeline. Avec cette mise à jour, nous les avons ajoutés à l’Assistant Nouveau pipeline pour un point de départ unique. Vous pouvez toujours cliquer sur le lien en bas de la page pour créer un pipeline sans YAML dans l’éditeur classique.

All source providers included in the new build pipeline wizard.

Les commentaires GitHub déclenchent des optimisations

Nous avons amélioré l’expérience des équipes qui utilisent des commentaires de demande de tirage GitHub pour déclencher des builds. Généralement pour la sécurité, ces équipes ne souhaitent pas générer automatiquement des demandes de tirage. Au lieu de cela, ils veulent qu’un membre de l’équipe examine la demande de tirage et une fois qu’elle est considérée comme sécurisée, déclenchez la génération avec un commentaire de demande de tirage. Un nouveau paramètre conserve cette option tout en autorisant les builds de demande de tirage automatique uniquement pour les membres de l’équipe.

GitHub comments trigger optimizations.

Publier les résultats des tests CTest et PHPUnit

Avec cette mise à jour, nous avons ajouté la prise en charge de la publication des résultats des tests à partir d’une exécution CTest dans des pipelines. Pour publier les résultats du test CTest, sélectionnez l’option CTest dans l’entrée du format de résultat de test de l’onglet Publier les résultats des tests.

Publish CTest and PHPUnit test results.

En outre, nous avons inclus la publication pour les exécutions de test PHPUnit . Bien que le format des résultats JUnit ait toujours été pris en charge, vous pouvez désormais tirer parti des constructions spécifiques de PHPUnit. Pour plus d’informations sur la publication des résultats des tests, consultez la documentation ici.

Azure Artifacts

Sources amont pour Maven

Les sources en amont sont désormais disponibles pour les flux Maven. Cela inclut le référentiel Maven Central principal et les flux Azure Artifacts. Pour ajouter des amont Maven à un flux existant, visitez les paramètres de flux, sélectionnez le tableau croisé dynamique des sources en amont, puis sélectionnez Ajouter amont source.

Upstream sources for Maven.

Reporting

Modification de version Odata d’Analytics Services pour les jeux d’entités de test

Le service Analytics dans Azure DevOps se compose d’ensembles d’entités que vous pouvez interroger directement à partir d’un navigateur pris en charge à l’aide d’OData. Le service fournit une API OData versionnée que vous pouvez ajouter à l’élément _odata.

Avec cette mise à jour, nous migreons les jeux d’entités de test vers la version 3.0-preview. Si vous utilisez le point de terminaison de version OData 2.0-preview, vous devez passer à la version 3.0-preview pour empêcher les modifications cassantes.

La liste suivante inclut les jeux d’entités qui seront migrés vers la version 3.0-preview :

  • TestRuns
  • TestResults
  • Tests
  • Versions
  • Branches
  • Versions
  • ReleaseEnvironments
  • TestResultsDaily
  • ReleasePipelines
  • ReleaseStages
  • BuildPipelines

Pour plus d’informations sur l’utilisation du point de terminaison OData avec le service Analytics, consultez la documentation ici.

Étapes suivantes

Notes

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

Accédez à Azure DevOps et jetez un coup d’œil.

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,

Chris Patterson