Configurer des stratégies de déploiement à partir de Portail Azure

Avec ce sprint, nous permettons aux utilisateurs de choisir leurs stratégies de déploiement directement à partir de l’Portail Azure, et nous déployons plusieurs améliorations apportées à l’expérience utilisateur Pipelines et Repos.

Fonctionnalités

Général

Azure Repos

Azure Pipelines

Général

Azure DevOps permet désormais aux administrateurs d’équipe de s’abonner à des événements à partir de MS Teams &Slack

Outre les administrateurs de projet, Azure DevOps permet désormais aux administrateurs d’équipe de s’abonner à des événements pour Azure Boards, Azure Repos et Azure Pipelines directement à partir de Slack et MS Teams.

Notifications MS Teams &Slack pour les événements Repos

En guise d’amélioration de notre intégration MS Teams et Slack, vous pouvez désormais choisir de vous abonner à un ou plusieurs événements sur une demande de tirage (pull request), comme les commentaires, l’envoi de code, les mises à jour et les tentatives de fusion.

Notifications for Repos events.

Azure Repos

Ajouter des pièces jointes au moment de la création d’une demande de tirage

Vous pouvez maintenant ajouter une pièce jointe à une demande de tirage lors de sa création. Pour ajouter une pièce jointe, vous deviez précédemment créer la demande de tirage, puis la modifier, mais vous pouvez maintenant glisser-déplacer directement une image vers la page créer une demande de tirage. Add attachments while creating a pull request.

Nouvelle conversion de plateforme web – Paramètres du référentiel

Nous avons converti les deux pages de paramètres du référentiel en une seule expérience mise à niveau vers une nouvelle plateforme web. Cette mise à niveau rend non seulement l’expérience plus rapide et plus moderne, mais ces pages fournissent également un point d’entrée unique pour toutes les stratégies du niveau du projet au niveau de la branche.

New web platform conversion.

Avec cette nouvelle expérience, la navigation pour les projets avec un nombre important de référentiels est devenue plus facile en raison de temps de chargement plus rapides et d’un filtre de recherche ajouté. Vous pouvez également afficher les stratégies au niveau du projet et la liste des stratégies de référentiel croisé sous l’onglet Stratégies.

View cross-repo policies under the Policies tab.

Si vous cliquez dans un référentiel, vous pouvez afficher les stratégies et les autorisations définies au niveau du référentiel. Dans l’onglet Stratégies, vous pouvez afficher la liste de chaque branche sur laquelle la stratégie est définie. À présent, cliquez sur la branche pour afficher les stratégies tout en ne laissant jamais la page des paramètres du référentiel.

Select branch to see the policies.

À présent, lorsque les stratégies sont héritées d’une étendue supérieure à celle avec laquelle vous travaillez, nous vous montrons où la stratégie a été héritée à côté de chaque stratégie individuelle. Vous pouvez également accéder à la page où la stratégie de niveau supérieur a été définie en cliquant sur le nom de l’étendue.

Show where the policy was inherited from.

La page de stratégie elle-même a également été mise à niveau vers la nouvelle plateforme web avec des sections réductibles ! Pour améliorer l’expérience de recherche d’une stratégie de validation de build, de vérification d’état ou de réviseur automatique, nous avons ajouté des filtres de recherche pour chaque section.

Search filters for each section.

Azure Pipelines

Les tâches peuvent accéder aux variables de sortie à partir des étapes précédentes

Les variables de sortie peuvent désormais être utilisées à plusieurs étapes dans un pipeline YAML. Cela vous permet de transmettre des informations utiles, telles qu’une décision go/no-go ou l’ID d’une sortie générée, d’une étape à l’autre. Le résultat (état) d’une étape précédente et ses travaux sont également disponibles.

Les variables de sortie sont toujours produites par les étapes à l’intérieur des travaux. Au lieu de faire référence à dependencies.jobName.outputs['stepName.variableName'], les phases font référence à stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Remarque

Par défaut, chaque index d’un pipeline dépend de celui qui se trouve juste avant lui dans le fichier YAML. Par conséquent, chaque index peut utiliser des variables de sortie issues de l’index précédent. Vous pouvez modifier la graphe des dépendances, ce qui modifie également les variables de sortie disponibles. Par exemple, si l’étape 3 a besoin d’une variable de l’étape 1, elle doit déclarer une dépendance explicite à l’étape 1.

Limiter l’accès à l’ensemble des référentiels des services de build

En s’appuyant sur l’amélioration de la sécurité des pipelines en limitant l’étendue des jetons d’accès, Azure Pipelines peut désormais limiter l’accès à son référentiel aux dépôts requis pour un pipeline YAML. Cela signifie que si le jeton d’accès des pipelines était à fuiter, il ne serait en mesure de voir que le ou les référentiels utilisés dans le pipeline. Auparavant, le jeton d’accès était adapté à n’importe quel dépôt Azure Repos dans le projet, ou potentiellement à l’ensemble de la collection.

Cette fonctionnalité sera activée par défaut pour les nouveaux projets et organisations. Pour les organisations existantes, vous devez l’activer dans Organization Paramètres> Pipelines> Paramètres. Lorsque vous utilisez cette fonctionnalité, tous les référentiels Git Azure Repos accessibles par le pipeline à l’aide de l’identité de service de génération doivent être explicitement case activée supprimés à l’aide d’une checkout étape du travail qui utilise le référentiel. Pour plus d’informations, consultez Limiter l’étendue d’autorisation du travail aux référentiels Azure DevOps référencés.

Obtention de détails au moment de l’exécution concernant plusieurs référentiels

Lorsqu’un pipeline est en cours d’exécution, Azure Pipelines ajoute des informations sur le dépôt, la branche et la validation qui a déclenché l’exécution. Maintenant que les pipelines YAML prennent en charge l’case activée l’envoi de plusieurs référentiels, vous pouvez également connaître le dépôt, la branche et la validation qui ont été case activée dépassés pour d’autres référentiels. Ces données sont disponibles via une expression runtime, que vous pouvez désormais mapper dans une variable. Par exemple :

resources :
Dépôts:
- référentiel : autre
type : git
nom : MyProject/OtherTools
variables :
tools.ref : $[ resources.repository['other'].ref ]

steps:
- case activée out : auto
- case activée out : autres
- bash : echo « Version des outils : $TOOLS_REF »

Pipelines à plusieurs étapes en disponibilité générale

L’interface utilisateur des pipelines à plusieurs étapes est désormais en disponibilité générale. Le bouton bascule de fonctionnalité d’aperçu correspondant a été supprimé. 

Vous pouvez accéder à la nouvelle expérience en sélectionnant Pipelines ->Pipelines sous le menu de navigation de gauche dans Azure DevOps. Cette expérience est le point d’entrée pour les pipelines de build classiques ainsi que pour les pipelines YAML. Il est convivial pour les mobiles et apporte diverses améliorations à la façon dont vous gérez vos pipelines. Vous pouvez explorer et afficher les détails du pipeline, les détails de l’exécution, l’analyse du pipeline, les détails du travail, les journaux et bien plus encore.

Pour en savoir plus sur l’expérience utilisateur des pipelines à plusieurs étapes, consultez la documentation ici.

Multi stage pipelines.

Configurer des stratégies de déploiement à partir de Portail Azure

Avec cette fonctionnalité, nous avons simplifié la configuration des pipelines qui utilisent la stratégie de déploiement de votre choix, par exemple Rolling, Canary ou Blue-Green. À l’aide de ces stratégies prêtes à l’emploi, vous pouvez déployer des mises à jour de manière sécurisée et atténuer les risques de déploiement associés. Pour y accéder, cliquez sur le paramètre « Livraison continue » dans une machine virtuelle Azure. Dans le volet de configuration, vous serez invité à sélectionner des détails sur le projet Azure DevOps dans lequel le pipeline sera créé, le groupe de déploiement, le pipeline de build qui publie le package à déployer et la stratégie de déploiement de votre choix. À l’avance, vous allez configurer un pipeline entièrement fonctionnel qui déploie le package sélectionné sur cette machine virtuelle.

Pour plus d’informations, case activée notre documentation sur la configuration des stratégies de déploiement.

Configure Deployment Strategies from Azure portal.

É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.

Comment fournir des commentaires

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

Make a suggestion

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