Disponibilité générale des plans de livraison 2.0

Nous sommes très heureux d’annoncer que les plans de livraison 2.0 sont en disponibilité générale ! Les plans de livraison 2.0 fournissent 3 scénarios clés : une vue chronologie du plan, la progression du travail et le suivi des dépendances.

Pour plus d’informations, consultez les descriptions de fonctionnalités suivantes.

Azure Boards

• Les plans de livraison 2.0 sont généralement disponibles
• Nouvelle API REST de capacité d’itération
• Copier le tableau de bord est désormais disponible en préversion publique

Azure Pipelines

• Modification de la stratégie de préinstallation du Kit de développement logiciel (SDK) .NET sur les agents Ubuntu hébergés par Microsoft
• Autorisations et case activée s sur des groupes de variables et des fichiers sécurisés
• Préversion de la prise en charge des modèles dans l’éditeur YAML
• Ubuntu-16.04 sera supprimé des pools hébergés par Microsoft en septembre 2021

Azure Boards

Les plans de livraison 2.0 sont généralement disponibles

Nous sommes heureux d’annoncer que les plans de livraison 2.0 sont en disponibilité générale ! Il fournit 3 scénarios clés :

• Vue chronologie du plan
• Progression du travail
• Suivi des dépendances

Ces scénarios fonctionnent entre les équipes et les projets. Les plans de livraison 2.0 sont désormais natifs du produit afin qu’une extension ne soit plus nécessaire. Les plans créés avec l’extension Plans d’origine continueront de fonctionner dans les plans de livraison.

Voici une comparaison rapide des différences entre plans et plans de livraison

Fonctionnalité	Plans 1.0 (extension)	Delivery Plans 2.0
Nombre d’équipes	La limite est de 10	La limite est de 15
Délai d’exécution de l’élément de travail	Itérations uniquement	Date de début/cible et itération
Visualisation	Vue carte complète	Vues condensées et développées
Informations de cumul	Aucun	% terminé des éléments enfants et liés
Suivi des dépendances	Aucun	Oui
Visualisation de l’heure de début	Non, uniquement lorsque l’élément de travail se termine	Oui, à la fois les dates de début et de cible
Style de carte	Non	Oui

Fonctionnalités des plans de livraison

Voici les principales fonctionnalités. Le filtrage, les marqueurs et les critères de champ font également partie des plans de livraison.

Il existe deux vues principales : condensée et développée

Les plans de remise 2.0 permettent d’afficher tous les éléments de travail de votre plan sur un chronologie, en utilisant les dates de début et de cible ou les dates d’itération. L’ordre de priorité est les dates de début et de cible, puis l’itération. Cela vous permet d’ajouter des éléments de travail au niveau du portefeuille comme Epic qui ne sont souvent pas définis à une itération.

Il existe deux vues principales de la vue condensée et de la vue développée. Vous pouvez également effectuer un zoom avant et arrière du plan en cliquant sur la loupe située à droite du plan.

• Vue condensée

  La vue condensée affiche tous les éléments de travail carte réduits, ce qui signifie que toutes les informations carte ne sont pas affichées. Cette vue est utile pour une vue globale du travail dans le plan. Pour réduire les champs carte, cliquez sur l’icône carte en regard des icônes de loupe situées à droite du plan.

  Voici un exemple de plan bascule entre les vues condensées et développées.

  

• Vue développée

  La vue développée affiche la progression d’un élément de travail en comptant le nombre d’éléments enfants et liés et en affichant le pourcentage terminé. Actuellement, la progression est déterminée par le nombre d’éléments de travail.

  Voici un exemple de plan utilisant une vue développée. Notez les barres de progression et le pourcentage terminés.

  

Suivi des dépendances

Le suivi des dépendances est basé sur les liens prédécesseurs et successeurs définis dans les éléments de travail. Si ces liens ne sont pas définis, aucune ligne de dépendance n’est affichée. Lorsqu’il existe un problème de dépendance avec un élément de travail, l’icône de lien de dépendance est en rouge.

• Affichage des dépendances

  Les dépendances spécifiques sont consultées via le panneau de dépendances qui affiche toutes les dépendances de cet élément de travail, y compris la direction. Un point d’exclamation rouge indique un problème de dépendance. Pour afficher le panneau, cliquez simplement sur l’icône du lien de dépendance dans le coin supérieur droit de l’carte. Voici des exemples de dépendances.

  

  

• Lignes de dépendance

  Les dépendances entre les éléments de travail sont visualisées avec des lignes de direction entre les éléments de travail respectifs. Plusieurs dépendances s’affichent sous la forme de plusieurs lignes. Une ligne de couleur rouge indique un problème.

  Voici quelques exemples.

  

  Voici un exemple d’élément de travail avec plusieurs dépendances et fonctionne également à l’aide d’une vue condensée.

  

  Lorsqu’il y a un problème, la couleur de ligne est rouge, et c’est l’icône de dépendance.

  Voici un exemple.

  

Style de carte

Les cartes peuvent désormais être mises en forme à l’aide de règles, comme les tableaux Kanban. Ouvrez les paramètres du plan, puis cliquez sur Styles. Dans le volet Styles, cliquez sur + Ajouter une règle de style pour ajouter la règle, puis cliquez sur Enregistrer. Il peut y avoir jusqu’à 10 règles et chaque règle peut avoir jusqu’à 5 clauses.

• Avant le

• Après

Copier le tableau de bord est désormais disponible en préversion publique

Avec cette version, un tableau de bord d’équipe ou de projet peut désormais être copié dans le même ou dans un nouveau projet. Les widgets et la disposition du tableau de bord seront copiés, mais les widgets devront toujours être configurés avec de nouvelles requêtes et paramètres.

Pour afficher un aperçu de cette fonctionnalité, activez simplement l’indicateur de fonctionnalité nommé Copy Dashboard Experience (sous fonctionnalités en préversion).

Voici les étapes à suivre pour copier un tableau de bord :

1. Accédez au tableau de bord que vous souhaitez copier. À partir de là, cliquez sur le menu pour afficher le tableau de bord copier, puis cliquez dessus.

2. Entrez le nom et la description du nouveau tableau de bord, puis sélectionnez le type de tableau de bord, l’équipe ou le projet. Lorsque vous sélectionnez un tableau de bord d’équipe, le nouveau projet et l’équipe sont sélectionnés dans les zones déroulantes projet et équipe respectivement. Pour un tableau de bord Project, seul le projet est requis.

Nouvelle API REST de capacité d’itération

Vous pouvez maintenant obtenir la capacité totale de toutes les équipes dans une itération à l’aide de la nouvelle API REST Itérationcapacities . Fournissez la iterationId capacité totale de chaque équipe associée à l’itération, ainsi qu’un total global. Cette fonctionnalité facilite la planification de la capacité d’un incrément. Pour en savoir plus sur itérationcapacities, consultez la documentation ici.

Azure Pipelines

Modification de la stratégie de préinstallation du Kit de développement logiciel (SDK) .NET sur les agents Ubuntu hébergés par Microsoft

Nous modifions les versions du Kit de développement logiciel (SDK) .NET préinstallées sur les agents Ubuntu hébergés par Microsoft. Actuellement, nous installons toutes les versions disponibles et prises en charge du Kit de développement logiciel (SDK) .NET (2.1.x, 3.1.x, 5.0.x). Cette approche sera modifiée en faveur de l’installation de la dernière version de correctif pour chaque version de fonctionnalité. Cette modification est apportée pour vous fournir plus d’espace libre et pour les nouvelles demandes d’outils.

Qu’est-ce que cela signifie ?

La version du Kit de développement logiciel (SDK) est composée des parties suivantes : x.y.znn. z est la version de fonctionnalité et nn est la version corrective. Par exemple, pour la version 2.1.302, la version de fonctionnalité est 3 et 02 est la version corrective. Selon la nouvelle approche, nous allons installer uniquement la dernière version de correctif pour chaque version de fonctionnalité, c’est-à-dire que seules 2.1.302 seront installées pour 2.1.3x, seulement 2.1.403 pour 2.1.4x et ainsi de suite. Toutes les versions du Kit de développement logiciel (SDK) .NET qui ne sont pas les dernières versions correctives seront supprimées des images Ubuntu le 14 juin. Cette modification a un impact sur toutes les versions d’Ubuntu sur les agents hébergés par Microsoft.

Date cible

Le déploiement d’images mises à jour démarre le 14 juin et prendra 3 à 4 jours.

Impact possible

Si vous utilisez un fichier global.json, votre build est affectée dans les cas suivants :

Votre build échoue si le fichier global.json contient la propriété et la rollForward: disable version du Kit de développement logiciel (SDK) qui n’est pas la dernière version du correctif. Par exemple :

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

La version du Kit de développement logiciel (SDK) .NET est automatiquement remplacée par le dernier correctif si le fichier global.json contient la rollForward: patch propriété. Par exemple :

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

Si le rollForward champ n’est pas spécifié dans votre fichier global.json, il n’y aura aucune modification pour vous. Le dernier niveau de correctif installé est utilisé.

Si vous devez utiliser la version exacte du Kit de développement logiciel (SDK) .NET qui n’est pas la dernière version du correctif, utilisez UseDotNet la tâche pour l’installer dans le cadre de la build :

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

Autorisations et case activée s sur des groupes de variables et des fichiers sécurisés

Vous pouvez utiliser différents types de ressources partagées dans des pipelines YAML. Par exemple, citons les connexions de service, les groupes de variables, les fichiers sécurisés, les pools d’agents, les environnements ou les référentiels. Pour protéger un pipeline contre l’accès à une ressource, le propriétaire de la ressource peut configurer des autorisations et des case activée sur cette ressource. Chaque fois qu’un pipeline tente d’accéder à la ressource, toutes les autorisations configurées et les case activée sont évaluées. Ces protections ont été disponibles sur les connexions de service, les environnements et les pools d’agents pendant un certain temps. Ils ont été récemment ajoutés aux référentiels. Avec cette version, nous ajoutons les mêmes protections aux groupes de variables et aux fichiers sécurisés.

Pour restreindre l’accès à un groupe de variables ou à un fichier sécurisé à un petit ensemble de pipelines, utilisez la fonctionnalité d’autorisations Pipelines.

Pour configurer des case activée ou des approbations qui doivent être évaluées chaque fois qu’un pipeline s’exécute, utilisez les Approbations et les case activée pour la fonctionnalité Bibliothèque.

Préversion de la prise en charge des modèles dans l’éditeur YAML

Les modèles sont une fonctionnalité couramment utilisée au sein des pipelines YAML. Il s’agit d’un moyen simple de partager des extraits de code de pipeline. Ils sont également un mécanisme puissant pour vérifier ou appliquer la sécurité et la gouvernance via votre pipeline.

Azure Pipelines prend en charge un éditeur YAML qui peut être pratique lors de la modification de votre pipeline. Auparavant, l’éditeur ne prenait pas en charge les modèles. Les auteurs de pipelines YAML n’ont pas pu obtenir d’assistance IntelliSense lors de l’utilisation d’un modèle. Avec cette version, nous prévisualisons la prise en charge des modèles dans l’éditeur YAML. Pour activer cette préversion, accédez à la préversion des fonctionnalités de votre organisation Azure DevOps et activez l’éditeur de modèles YAML.

Lorsque vous modifiez votre fichier principal YAML Azure Pipelines, vous pouvez inclure ou étendre un modèle. Lorsque vous tapez le nom de votre modèle, vous êtes invité à valider votre modèle. Une fois validé, l’éditeur YAML comprend le schéma du modèle, y compris les paramètres d’entrée.

Après validation, vous pouvez choisir d’accéder au modèle. Vous pourrez apporter des modifications au modèle à l’aide de toutes les fonctionnalités de l’éditeur YAML.

Notez que cette fonctionnalité est en préversion. Il existe des limitations connues, dont certaines nous travaillons à résoudre. Si le modèle a des paramètres requis qui ne sont pas fournis en tant qu’entrées dans le fichier YAML principal, la validation échoue et vous invite à fournir ces entrées. Dans une expérience idéale, la validation ne doit pas être bloquée et vous devez être en mesure de renseigner les paramètres d’entrée à l’aide d’IntelliSense. En outre, vous ne pouvez pas créer de modèle à partir de l’éditeur. Vous pouvez uniquement utiliser ou modifier des modèles existants.

Ubuntu-16.04 sera supprimé des pools hébergés par Microsoft en septembre 2021

Le support traditionnel de 5 ans d’Ubuntu 16.04 par Canonical se termine en avril 2021. Pour maintenir notre environnement mis à jour et sécurisé, nous allons supprimer Ubuntu 16.04 le 20 septembre 2021.

Vous devez migrer des flux de travail ubuntu-16.04 vers ubuntu-18.04 ou ubuntu-latest qui s’exécuteront sur Ubuntu 20.04 LTS.

Pour vous assurer que tout le monde est au courant de ce changement, nous avons planifié deux brownouts courts. Toutes les builds Ubuntu 16.04 échouent pendant la période de brunout. Par conséquent, il est recommandé de migrer vos pipelines avant le 6 septembre 2021.

Les brunissements sont provisoirement planifiés pour les dates et heures suivantes. Nous allons mettre à jour ces moments à mesure que nous nous rapprocherons de cette période.

6 septembre 2021 19h00 UTC – 10 :00 UTC

14 septembre 2021 19h00 UTC – 10h00 UTC

É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 Aide pour signaler un problème ou faire une suggestion.

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

Merci,

Aaron Hallberg