Nouvelles améliorations apportées aux plans de livraison 2.0
Dans ce sprint, nous améliorons les plans de livraison 2.0 avec de nouvelles vues condensées et des informations de cumul. Nous introduisons également la validation manuelle et une nouvelle uses
instruction pour la prédéclaration des ressources dans les pipelines YAML.
Pour plus d’informations, consultez la liste des fonctionnalités ci-dessous.
Azure Boards
Azure Pipelines
- Instruction « uses » pour la prédéclaration des ressources
- Validation manuelle pour les pipelines YAML
Azure Boards
Plans de livraison : informations de cumul
Dans le cadre de la préversion publique des plans de livraison 2.0, les informations de cumul sont désormais disponibles. Lorsque vous traitez avec des éléments de travail de niveau supérieur tels que epics ou fonctionnalités, vous voudrez peut-être voir plus de détails. Le cumul montre la progression des éléments de travail enfants sous-jacents, révélant l’histoire complète. Pour activer cette fonctionnalité, accédez à vos paramètres de plan, puis à Champs, puis sélectionnez Afficher les données de cumul enfant.
Plans de livraison : affichages condensés
Dans le cadre de la préversion publique des plans de livraison 2.0, les clients peuvent désormais basculer entre les affichages Normal et Condensed. Les cartes avec des champs supplémentaires peuvent prendre beaucoup d’espace vertical. Cela rend difficile de voir plus de quelques cartes sur l’écran à la fois, même lorsqu’un zoom arrière complet est effectué. Nous avons créé une vue de carte réduite qui masque tous les champs des cartes et affiche uniquement l’icône et le titre du type d’élément de travail. Le masquage et l’affichage de tous les champs ne sont plus qu’à un clic.
Azure Pipelines
Instruction « uses » pour la prédéclaration des ressources
Lorsqu’un pipeline exécute un travail sur un agent, celui-ci reçoit un jeton d’accès pour rappeler les API REST Azure Pipelines et pour télécharger des ressources telles que des dépôts. Pour les pipelines YAML, nous avons récemment ajouté un paramètre pour limiter le jeton aux dépôts réellement consommés dans un travail. Toutefois, certains clients utilisaient des dépôts sans utiliser explicitement d’étapecheckout
, pour instance, s’ils utilisaient une étape de script pour appeler Git directement. Ces clients n’ont pas pu activer la fonctionnalité de restriction des jetons, car Azure Pipelines n’a pas pu déterminer avec précision quels dépôts étaient nécessaires pour le travail.
Avec cette mise à jour, nous avons ajouté une autre façon d’indiquer à Azure Pipelines qu’un travail souhaite utiliser un dépôt sans utiliser l’étape checkout
. Au lieu de cela, vous pouvez utiliser la nouvelle uses
mot clé, comme suit :
resources:
repositories:
- repository: myrepo
type: git
name: MyProject/MyRepo
jobs:
- job: myjob
uses:
repositories:
- myrepo
steps:
# without the preceding "uses" statement, if you have the
# new limit-repositories feature turned on, then Azure Pipelines
# won't include this repo in the access token and you'll
# get an access error at runtime (also, in a real pipeline
# you must include the auth token header as an argument to Git)
- script: git clone https://dev.azure.com/MyOrg/MyProject/_git/MyRepo
Cette fonctionnalité résout également un problème connexe (bien que moins courant). Si vous utilisez le matrix
mot clé pour générer plusieurs travaux et que ces travaux utilisent des pools spécifiés à l’étape de matrice, vous avez peut-être rencontré des problèmes d’autorisation de ces pools pour le pipeline. La cause racine est la même : étant donné que les matrices sont calculées au moment de l’exécution, le système d’autorisation des ressources initiales ne peut pas déterminer avec précision les pools utilisés. À l’aide de uses
, vous pouvez déclarer les pools que vos travaux utiliseront afin qu’ils puissent être autorisés à l’avance.
jobs:
- job: mtrx
strategy:
matrix:
windows:
mypoolname: Private-Windows
mac:
mypoolname: Private-Mac
pool: $(mypoolname)
# without the following "uses" statement, "pool" won't see
# the pool names until it's too late, and you'll get an error
# at runtime
uses:
pools:
- Private-Windows
- Private-Mac
Validation manuelle pour les pipelines YAML
Avec la tâche de validation manuelle récemment publiée, vous pouvez suspendre un pipeline YAML à mi-étape. Cela vous permet d’effectuer des activités manuelles ou hors connexion, puis de reprendre (ou de rejeter) l’exécution. Cela est particulièrement utile dans les scénarios où vous souhaitez suspendre un pipeline et laisser un homologue valider les paramètres de configuration, générer un package, etc. avant de passer à une tâche longue et gourmande en calculs. Plus d’informations
É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 d’aide pour signaler un problème ou fournir une suggestion.
Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.
Merci,
Matt Cooper