Notes de publication Azure DevOps Server 2022


| | Developer Community System Requirements and Compatibility | License Terms | DevOps Blog | SHA-256 Hashes |


Dans cet article, vous trouverez des informations sur la dernière version pour Azure DevOps Server.

Pour en savoir plus sur l’installation ou la mise à niveau d’un déploiement de Azure DevOps Server, consultez Azure DevOps Server Configuration requise.

Pour télécharger Azure DevOps Server produits, visitez la page Téléchargements Azure DevOps Server.

La mise à niveau directe vers Azure DevOps Server 2022 est prise en charge à partir de Azure DevOps Server 2019 ou de Team Foundation Server 2015 ou version ultérieure. Si votre déploiement TFS est sur TFS 2013 ou une version antérieure, vous devez effectuer certaines étapes intermédiaires avant de procéder à la mise à niveau vers Azure DevOps Server 2022. Pour plus d’informations, consultez la page Installer .


Azure DevOps Server 2022 Patch 1 Date de publication : 24 janvier 2023

Nous avons publié un correctif pour Azure DevOps Server 2022 qui inclut les correctifs suivants.

  • Les données de test n’ont pas été supprimées, ce qui a entraîné la croissance de la base de données. Avec ce correctif, nous avons mis à jour la rétention de build pour empêcher la création de nouvelles données de test orphelines.
  • Mises à jour à l’objet AnalyticCleanupJob, l’état du travail était Arrêté et nous signalons maintenant Réussi.
  • Correction de l’échec de la commande « publication de l’extension tfx » avec l’erreur « La clé donnée n’était pas présente dans le dictionnaire ».
  • Implémentation d’une solution de contournement pour résoudre les erreurs lors de l’accès à l’extension Calendrier d’équipe.

Azure DevOps Server 2022 Date de publication : 6 décembre 2022

Azure DevOps Server 2022 est un cumul de correctifs de bogues. Il inclut toutes les fonctionnalités des Azure DevOps Server 2022 RC2 et RC1 précédemment publiées.

Azure DevOps Server 2022 RC2 Date de publication : 25 octobre 2022

Azure DevOps Server 2022 RC2 est un cumul de correctifs de bogues. Il inclut toutes les fonctionnalités du Azure DevOps Server 2022 RC1 publié précédemment.

Notes

Nouveaux algorithmes SSH RSA activés

La prise en charge des clés publiques RSA a été améliorée pour prendre en charge les types de clés publiques SHA2 en plus du SHA1 SSH-RSA que nous prenions en charge précédemment.

Les types de clés publiques désormais pris en charge sont les suivants :

  • SSH-RSA
  • RSA-SHA2-256
  • RSA-SHA2-512

Action requise

Si vous avez implémenté le travail pour activer SSH-RSA en le spécifiant explicitement dans le .ssh/config1 fichier, vous devez soit supprimer le , soit le PubkeyAcceptedTypesmodifier pour utiliser RSA-SHA2-256 ou RSA-SHA2-512, ou les deux. Vous trouverez des détails sur la procédure à suivre si vous êtes toujours invité à entrer votre mot de passe et GIT_SSH_COMMAND="ssh -v" git fetch qu’aucun algorithme de signature mutuelle n’apparaît dans la documentation ici.

La prise en charge des clés elliptiques n’a pas encore été ajoutée et reste une fonctionnalité très demandée dans notre backlog.

Azure DevOps Server 2022 RC1 Date de publication : 9 août 2022

Résumé des nouveautés de Azure DevOps Server 2022

Important

Le service d’entrepôt et d’analyse a été déprécié dans la version précédente de Azure DevOps Server (2020). Dans Azure DevOps Server 2022, le service d’entrepôt et d’analyse a été supprimé du produit. Analytics fournit désormais l’expérience de création de rapports dans le produit.

Azure DevOps Server 2022 introduit de nombreuses nouvelles fonctionnalités. Voici les principales :

Vous pouvez également accéder à des sections individuelles pour voir toutes les nouvelles fonctionnalités de chaque service :


Boards

Plans de livraison

Nous sommes ravis d’annoncer que les plans de livraison sont désormais inclus dans Azure DevOps Server. Les plans de livraison offrent 3 scénarios clés :

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

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é et développé

Les plans de livraison 2.0 permettent d’afficher tous les éléments de travail de votre plan sur une chronologie, à l’aide de dates de début et de cible ou de dates d’itération. L’ordre de précédence est les dates cibles de début & , suivies d’une itération. Cela vous permet d’ajouter des éléments de travail au niveau du portefeuille commeEpic qui ne sont souvent pas définis pour une itération.

Il existe deux vues principales : la vue condensée et la vue développée. Vous pouvez également effectuer un zoom avant et arrière sur le plan en cliquant sur la loupe dans le côté de la main du plan.

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

  • Vue condensée

    L’affichage condensé montre toutes les cartes d’éléments de travail réduites , ce qui signifie que toutes les informations de carte ne sont pas affichées. Cette vue est utile pour une vue d’ensemble du travail dans le plan. Pour réduire les champs de carte, cliquez sur l’icône de carte en regard des icônes de loupe situées à droite du plan.

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

    Gif en mode condensé de démonstration.

  • Vue développée

    La vue développée montre la progression d’un élément de travail en comptant le nombre d’éléments enfants et liés et en montrant 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 que les barres de progression et le pourcentage sont terminés.

    Exemple de plan utilisant une vue développée

Suivi des dépendances

Le suivi des dépendances est basé sur la définition des liens de prédécesseur et de successeur dans les éléments de travail. Si ces liens ne sont pas définis, aucune ligne de dépendance ne s’affiche. En cas de problème de dépendance avec un élément de travail, l’icône de lien de dépendance est de couleur rouge.

Suivi des dépendances avec icône de dépendance en rouge pour afficher les dépendances

  • Affichage des dépendances

    Les dépendances spécifiques sont consultées via le panneau des 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 de lien de dépendance dans le coin supérieur droit de la carte. Voici des exemples de dépendances.

    Exemple d’affichage des dépendances

    Autre exemple d’affichage des dépendances

  • Lignes de dépendances

    Les dépendances entre les éléments de travail sont visualisées à l’aide de 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.

    Éléments de travail de dépendances visualisées avec des lignes de direction entre les éléments de travail respectifs

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

    Exemple d’élément de travail avec plusieurs dépendances en mode condensé

    En cas de problème, la couleur de ligne est rouge, de même que l’icône de dépendance.

    Voici un exemple.

    Exemple d’élément de travail avec plusieurs dépendances

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.

Paramètres de style

  • Avant

Style de carte avant

  • Après

Style de carte après

Pour en savoir plus sur les plans de livraison, consultez la documentation ici.

Éléments supprimés sur le hub éléments de travail

Le hub Éléments de travail est l’endroit où afficher une liste d’éléments que vous avez créés ou qui vous sont affectés. Il fournit plusieurs fonctions de tableau croisé dynamique et de filtre personnalisées pour simplifier la liste des éléments de travail. L’une des principales plaintes du tableau croisé dynamique Qui m’est attribué est qu’il affiche les éléments de travail supprimés. Nous convenons que les éléments de travail supprimés n’ont plus de valeur et ne doivent pas être dans le backlog. Dans ce sprint, nous masquons tous les éléments supprimés des affichages Qui m’ont été attribués sur le hub Éléments de travail.

La section développement d’un élément de travail affiche la liste des validations et des demandes de tirage pertinentes. Vous pouvez afficher l’auteur de la validation ou de la demande de tirage ainsi que l’heure associée. Avec cette mise à jour, nous avons résolu un problème d’affichage incorrect de l’avatar de l’auteur dans la vue.

Supprimer la possibilité de télécharger une pièce jointe supprimée de l’historique des éléments de travail

Nous avons résolu un petit problème où les utilisateurs pouvaient télécharger des pièces jointes à partir de l’historique des éléments de travail, même après la suppression de la pièce jointe du formulaire. Maintenant, une fois la pièce jointe supprimée, elle ne peut pas être téléchargée à partir de l’historique, et l’URL de téléchargement ne sera pas disponible à partir de la réponse de l’API REST.

Ajout de la valeur « Ne corrigera pas » au champ Raison du bogue

Comme pour tous les autres types d’éléments de travail, le type d’élément de travail Bogue a un workflow bien défini. Chaque flux de travail se compose de trois états ou plus et d’une raison. Les raisons spécifient la raison pour laquelle l’élément est passé d’un état à un autre. Avec cette mise à jour, nous avons ajouté une valeur de raison ne corrige pas les types d’éléments de travail bogue dans le processus Agile. La valeur sera disponible en tant que raison lors du déplacement des bogues de Nouveau ou Actif vers Résolu. Vous pouvez en savoir plus sur la définition, la capture, le triage et la gestion des bogues logiciels dans Azure Boards documentation.

Pipelines

Suppression des stratégies de rétention par pipeline dans les builds classiques

Vous pouvez maintenant configurer des stratégies de rétention pour les builds classiques et les pipelines YAML dans les paramètres de projet Azure DevOps. Les règles de rétention par pipeline pour les pipelines de build classiques ne sont plus prises en charge. Bien qu’il s’agit de la seule façon de configurer la rétention pour les pipelines YAML, vous pouvez également configurer la rétention pour les pipelines de build classiques par pipeline. Nous avons supprimé toutes les règles de rétention par pipeline pour les pipelines de build classiques dans une prochaine version.

Ce que cela signifie pour vous : tout pipeline de build classique qui avait auparavant des règles de rétention par pipeline sera régi par les règles de rétention au niveau du projet.

Pour vous assurer que vous ne perdez aucune build lors de la mise à niveau, nous allons créer un bail pour toutes les builds existantes au moment de la mise à niveau qui n’ont pas de bail.

Nous vous recommandons de vérifier les paramètres de rétention au niveau du projet après la mise à niveau. Si votre pipeline nécessite spécifiquement des règles personnalisées, vous pouvez utiliser une tâche personnalisée dans votre pipeline. Pour plus d’informations sur l’ajout de baux de rétention par le biais d’une tâche, consultez la documentation Définir des stratégies de rétention pour les builds, les mises en production et les tests.

Nouveaux contrôles pour les variables d’environnement dans les pipelines

L’agent Azure Pipelines analyse la sortie standard des commandes de journalisation spéciales et les exécute. La setVariablecommande peut être utilisée pour définir une variable ou modifier une variable précédemment définie. Cela peut potentiellement être exploité par un acteur en dehors du système. Par exemple, si votre pipeline a une étape qui imprime la liste des fichiers dans un serveur FTP, une personne ayant accès au serveur ftp peut ajouter un nouveau fichier, dont le nom contient la setVariable commande et entraîne la modification de son comportement.

Nous avons de nombreux utilisateurs qui s’appuient sur la définition de variables à l’aide de la commande de journalisation dans leur pipeline. Avec cette version, nous apportons les modifications suivantes pour réduire le risque d’utilisations indésirables de la setVariable commande.

  • Nous avons ajouté une nouvelle construction pour les auteurs de tâches. En incluant un extrait de code tel que le suivant dans task.json, un auteur de tâche peut contrôler si des variables sont définies par sa tâche.
{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 
  • En outre, nous mettons à jour un certain nombre de tâches intégrées telles que ssh afin qu’elles ne puissent pas être exploitées.

  • Enfin, vous pouvez maintenant utiliser des constructions YAML pour contrôler si une étape peut définir des variables.

steps:
- script: echo hello
  target:
    settableVariables: none
steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Générer des jetons non restreints pour les builds de duplication

Les utilisateurs de GitHub Enterprise utilisent généralement des duplications forks pour contribuer à un dépôt en amont. Quand Azure Pipelines génère des contributions à partir d’une duplication d’un dépôt GitHub Enterprise, il limite les autorisations accordées au jeton d’accès au travail et n’autorise pas l’accès aux secrets de pipeline par ces travaux. Vous trouverez plus d’informations sur la sécurité de la création de duplications dans notre documentation.

Cela peut être plus restrictif que souhaité dans ces environnements fermés, où les utilisateurs peuvent toujours bénéficier d’un modèle de collaboration interne source. Bien que vous puissiez configurer un paramètre dans un pipeline pour rendre les secrets disponibles pour les duplications, il n’existe aucun paramètre pour contrôler l’étendue du jeton d’accès au travail. Avec cette version, nous vous donnons le contrôle pour générer un jeton d’accès de travail standard, même pour les builds de duplications.

Vous pouvez modifier ce paramètre à partir de Déclencheurs dans l’éditeur de pipeline. Avant de modifier ce paramètre, assurez-vous de bien comprendre les implications en matière de sécurité de l’activation de cette configuration.

Générer des jetons non restreints pour les builds de duplication

Dépôts en tant que ressource protégée dans les pipelines YAML

Vous pouvez organiser votre projet Azure DevOps pour héberger de nombreux sous-projets, chacun avec son propre dépôt Git Azure DevOps et un ou plusieurs pipelines. Dans cette structure, vous souhaiterez peut-être contrôler les pipelines qui peuvent accéder aux dépôts. Par exemple, supposons que vous avez deux référentiels A et B dans le même projet et deux pipelines X et Y qui créent normalement ces dépôts. Vous souhaiterez peut-être empêcher le pipeline Y d’accéder au référentiel A. En général, vous souhaitez que les contributeurs de A contrôlent les pipelines auxquels ils souhaitent fournir l’accès.

Bien que cela soit partiellement possible avec les référentiels et pipelines Git Azure, il n’y avait aucune expérience de gestion. Cette fonctionnalité répond à cette lacune. Les référentiels Git Azure peuvent désormais être traités comme des ressources protégées dans des pipelines YAML, tout comme les connexions de service et les pools d’agents.

En tant que contributeur du dépôt A, vous pouvez ajouter des vérifications et des autorisations de pipeline à votre dépôt. Pour ce faire, accédez aux paramètres du projet, sélectionnez Référentiels, puis votre dépôt. Vous remarquerez un nouveau menu appelé « Vérifications », dans lequel vous pouvez configurer l’une des vérifications in-the-box ou personnalisées sous la forme de fonctions Azure.

Ajouter des vérifications

Sous l’onglet « Sécurité », vous pouvez gérer la liste des pipelines qui peuvent accéder au dépôt.

Gérer la liste des pipelines dans l’onglet Sécurité

Chaque fois qu’un pipeline YAML utilise un référentiel, l’infrastructure Azure Pipelines vérifie et garantit que toutes les vérifications et autorisations sont satisfaites.

Notes

Ces autorisations et vérifications s’appliquent uniquement aux pipelines YAML. Les pipelines classiques ne reconnaissent pas ces nouvelles fonctionnalités.

Autorisations et vérifications sur les groupes de variables et les fichiers sécurisés

Vous pouvez utiliser différents types de ressources partagées dans des pipelines YAML. Les connexions de service, les groupes de variables, les fichiers sécurisés, les pools d’agents, les environnements ou les dépôts en sont des exemples. Pour empêcher un pipeline d’accéder à une ressource, le propriétaire de la ressource peut configurer des autorisations et des vérifications sur cette ressource. Chaque fois qu’un pipeline tente d’accéder à la ressource, toutes les autorisations et vérifications configurées sont évaluées. Ces protections sont disponibles depuis un certain temps sur les connexions de service, les environnements et les pools d’agents. Ils ont été récemment ajoutés aux dépôts. 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é Autorisations de pipelines .

Mes variables secrètes

Pour configurer des vérifications ou des approbations qui doivent être évaluées chaque fois qu’un pipeline s’exécute, utilisez la fonctionnalité Approbations et vérifications pour la bibliothèque .

Ajouter l’approbation des vérifications

Modifications apportées à la création automatique d’environnements

Lorsque vous créez un pipeline YAML et que vous faites référence à un environnement qui n’existe pas, Azure Pipelines crée automatiquement l’environnement. Cette création automatique peut se produire dans le contexte utilisateur ou dans le contexte système. Dans les flux suivants, Azure Pipelines connaît l’utilisateur qui effectue l’opération :

  • Vous utilisez l’Assistant Création de pipeline YAML dans l’expérience web Azure Pipelines et faites référence à un environnement qui n’a pas encore été créé.
  • Vous mettez à jour le fichier YAML à l’aide de l’éditeur web Azure Pipelines et enregistrez le pipeline après avoir ajouté une référence à un environnement qui n’existe pas. Dans chacun des cas ci-dessus, Azure Pipelines a une compréhension claire de l’utilisateur effectuant l’opération. Par conséquent, il crée l’environnement et ajoute l’utilisateur au rôle d’administrateur de l’environnement. Cet utilisateur dispose de toutes les autorisations nécessaires pour gérer l’environnement et/ou inclure d’autres utilisateurs dans différents rôles pour la gestion de l’environnement.

Dans les flux suivants, Azure Pipelines ne dispose pas d’informations sur l’utilisateur qui crée l’environnement : vous mettez à jour le fichier YAML à l’aide d’un autre éditeur de code externe, ajoutez une référence à un environnement qui n’existe pas, puis déclenchez un pipeline d’intégration continue. Dans ce cas, Azure Pipelines ne connaît pas l’utilisateur. Auparavant, nous avons géré ce cas en ajoutant tous les contributeurs de projet au rôle d’administrateur de l’environnement. Tout membre du projet peut ensuite modifier ces autorisations et empêcher d’autres personnes d’accéder à l’environnement.

Nous avons reçu vos commentaires sur l’octroi d’autorisations d’administrateur sur un environnement à tous les membres d’un projet. Lorsque nous avons écouté vos commentaires, nous avons entendu que nous ne devrions pas créer automatiquement un environnement s’il n’est pas clair qui est l’utilisateur qui effectue l’opération. Avec cette version, nous avons apporté des modifications à la façon dont les environnements seront automatiquement créés :

  • À l’avenir, les exécutions de pipeline ne créent pas automatiquement un environnement s’il n’existe pas et si le contexte utilisateur n’est pas connu. Dans ce cas, le pipeline échoue avec une erreur Environnement introuvable. Vous devez précréer les environnements avec la sécurité appropriée et vérifier la configuration avant de l’utiliser dans un pipeline.
  • Les pipelines avec le contexte utilisateur connu créent toujours automatiquement des environnements comme ils l’ont fait par le passé.
  • Enfin, il convient de noter que la fonctionnalité permettant de créer automatiquement un environnement a été ajoutée uniquement pour simplifier le processus de prise en main d’Azure Pipelines. Il était destiné aux scénarios de test, et non aux scénarios de production. Vous devez toujours précréer des environnements de production avec les autorisations et les vérifications appropriées, puis les utiliser dans les pipelines.

Boîte de dialogue Supprimer des insights du pipeline de génération

En fonction de vos commentaires, la boîte de dialogue Insights sur la tâche/pipeline qui s’affiche lors de la navigation dans le pipeline de build a été supprimée pour améliorer le flux de travail. L’analytique de pipeline est toujours disponible afin que vous disposiez des insights dont vous avez besoin.

Prise en charge des déploiements séquentiels plutôt que de la dernière version uniquement lors de l’utilisation de vérifications de verrous exclusifs

Dans les pipelines YAML, les vérifications sont utilisées pour contrôler l’exécution des phases sur les ressources protégées. L’une des vérifications courantes que vous pouvez utiliser est une vérification de verrouillage exclusive. Cette vérification ne permet qu’une seule exécution à partir du pipeline de continuer. Lorsque plusieurs exécutions tentent de déployer dans un environnement en même temps, la vérification annule toutes les anciennes exécutions et autorise le déploiement de la dernière exécution.

L’annulation des anciennes exécutions est une bonne approche lorsque vos mises en production sont cumulatives et contiennent toutes les modifications de code des exécutions précédentes. Toutefois, il existe certains pipelines dans lesquels les modifications de code ne sont pas cumulatives. Avec cette nouvelle fonctionnalité, vous pouvez choisir d’autoriser toutes les exécutions à se poursuivre et de les déployer de manière séquentielle dans un environnement, ou de conserver le comportement précédent qui consiste à annuler les anciennes exécutions et à autoriser uniquement les dernières exécutions. Vous pouvez spécifier ce comportement à l’aide d’une nouvelle propriété appelée lockBehavior dans le fichier YAML du pipeline. La valeur de sequential implique que toutes les exécutions acquièrent le verrou séquentiellement sur la ressource protégée. La valeur de runLatest implique que seule la dernière exécution acquiert le verrou de la ressource.

Pour utiliser la vérification de verrouillage exclusif avec sequential les déploiements ou runLatest, procédez comme suit :

  1. Activez la vérification de verrouillage exclusive sur l’environnement (ou une autre ressource protégée).
  2. Dans le fichier YAML du pipeline, spécifiez une nouvelle propriété appelée lockBehavior. Cela peut être spécifié pour l’ensemble du pipeline ou pour une étape donnée :

Défini sur une scène :

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Défini sur le pipeline :

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Si vous ne spécifiez pas de lockBehavior, il est supposé être runLatest.

Prise en charge de la version québécoise de ServiceNow

Azure Pipelines a une intégration existante à ServiceNow. L’intégration s’appuie sur une application dans ServiceNow et une extension dans Azure DevOps. Nous avons maintenant mis à jour l’application pour qu’elle fonctionne avec la version québécoise de ServiceNow. Les pipelines classiques et YAML fonctionnent maintenant avec le Québec. Pour vous assurer que cette intégration fonctionne, effectuez une mise à niveau vers la nouvelle version de l’application (4.188.0) à partir du magasin Service Now. Pour plus d’informations, consultez Intégrer à ServiceNow Change Management.

Nouvelles expressions conditionnelles YAML

L’écriture d’expressions conditionnelles dans des fichiers YAML s’est simplifiée avec l’utilisation d’expressions ${{ else }} et ${{ elseif }} . Vous trouverez ci-dessous des exemples d’utilisation de ces expressions dans des fichiers de pipelines YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg
variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Prise en charge des caractères génériques dans les filtres de chemin

Les caractères génériques peuvent être utilisés lors de la spécification de branches d’inclusion et d’exclusion pour les déclencheurs CI ou PR dans un fichier YAML de pipeline. Toutefois, ils ne peuvent pas être utilisés lors de la spécification de filtres de chemin d’accès. Par exemple, vous ne pouvez pas inclure tous les chemins qui correspondent à src/app/**/myapp*. Cela a été signalé comme un inconvénient par plusieurs clients. Cette mise à jour comble cette lacune. À présent, vous pouvez utiliser des caractères génériques (**, *ou ?) lors de la spécification de filtres de chemin d’accès.

La spécification de l’agent par défaut pour les pipelines est Windows-2022

L’image windows-2022 est prête à être la version par défaut de l’étiquette windows-latest dans les agents hébergés par Microsoft Azure Pipelines. Jusqu’à présent, cette étiquette pointait vers les agents windows-2019. Ce changement sera déployé sur une période de plusieurs semaines à compter du 17 janvier. Nous prévoyons de terminer la migration d’ici mars.

Azure Pipelines est pris en charge windows-2022 depuis septembre 2021. Nous avons surveillé vos commentaires pour améliorer la stabilité de l’image windows-2022 et nous sommes maintenant prêts à les définir comme les plus récents.

L’image windows-2022 inclut Visual Studio 2022. Pour obtenir la liste complète des différences entre windows-2022 et windows-2019, consultez le problème GitHub. Pour obtenir la liste complète des logiciels installés sur l’image, consultez ici.

Le renommage du dossier de pipeline valide les autorisations

Les dossiers contenant des pipelines peuvent être renommés. Le changement de nom d’un dossier réussit désormais uniquement si l’utilisateur dispose d’autorisations de modification sur au moins un pipeline contenu dans le dossier.

Planification de la mise à niveau du runtime de l’Agent de pipelines

Qu’est-ce que l’agent de pipeline ?

L’agent de pipeline Azure DevOps est le produit logiciel qui s’exécute sur un hôte de pipeline pour exécuter des travaux de pipeline. Il s’exécute sur les agents hébergés par Microsoft, les agents de groupe identique et les agents auto-hébergés. Dans ce dernier cas, vous l’installez vous-même. L’agent de pipeline se compose d’un écouteur et d’un worker (implémentés dans .NET), le Worker exécute des tâches qui sont implémentées dans Node ou PowerShell et héberge donc ces runtimes pour eux.

Dépréciation de la mise à niveau vers .NET 6 & Red Hat 6

Avec la version de .NET 6 , nous sommes en mesure de tirer parti de ses nouvelles fonctionnalités multiplateformes. Plus précisément, nous serons en mesure de fournir une compatibilité native pour Apple Silicon et Windows Arm64. Par conséquent, nous prévoyons de passer à .NET 6 pour l’agent de pipeline (écouteur et worker) dans les mois à venir.

En raison d’un certain nombre de contraintes que cela impose, nous supprimons la prise en charge de Red Hat Enterprise Linux 6 à partir de notre agent le 30 avril 2022.

Mises à jour à la tâche de copie de fichiers Azure

Nous déployons une nouvelle version de la tâche de copie de fichiers Azure. Cette tâche est utilisée pour copier des fichiers vers des objets blob de stockage Microsoft Azure ou des machines virtuelles. La nouvelle version comporte plusieurs mises à jour qui ont été souvent demandées par la communauté :

  • La version de l’outil AzCopy a été mise à jour vers la version 10.12.2, qui prend en charge les types de contenu de fichiers. Par conséquent, lorsque vous copiez des fichiers PDF, Excel, PPT ou l’un des types mime pris en charge, le type de contenu du fichier est correctement défini.

  • Avec la nouvelle version d’AzCopy, vous pouvez également configurer un paramètre pour nettoyer la cible lorsque le type de destination est Azure Blob. La définition de cette option supprime tous les dossiers/fichiers de ce conteneur. Ou si un préfixe d’objet blob est fourni, tous les dossiers/fichiers de ce préfixe sont supprimés.

  • La nouvelle version de la tâche s’appuie sur les modules Az installés sur l’agent au lieu des modules AzureRM. Cela supprime un avertissement inutile dans certains cas lors de l’utilisation de la tâche.

Les modifications font partie d’une mise à jour de version majeure pour cette tâche. Vous devez mettre à jour explicitement vos pipelines pour utiliser la nouvelle version. Nous avons choisi de mettre à jour la version principale pour nous assurer de ne pas interrompre les pipelines qui dépendent toujours des modules AzureRM.

Nouveaux points d’extension pour l’affichage des détails des pipelines

Nous avons ajouté deux nouveaux points d’extensibilité que vous pouvez cibler dans vos extensions. Ces points d’extensibilité vous permettent d’ajouter un bouton personnalisé dans l’en-tête de pipeline et un menu personnalisé dans un dossier de pipeline :

  • Bouton personnalisé dans l’en-tête de pipeline : ms.vss-build-web.pipelines-header-menu
  • Menu personnalisé sur un dossier de pipeline : ms.vss-build-web.pipelines-folder-menu

Pour utiliser ces nouveaux points d’extensibilité, ajoutez simplement une nouvelle contribution qui les cible dans le fichier manifeste de vss-extension.json votre extension Azure DevOps.

Par exemple :

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Le résultat sera :

  • Bouton personnalisé dans l’en-tête de pipeline

    Bouton personnalisé dans l’en-tête de pipeline

  • Menu personnalisé sur un dossier de pipeline

    Menu personnalisé sur un dossier de pipeline

Amélioration de la migration vers Azure DevOps Services

Lors de l’exécution d’une importation de Azure DevOps Server vers Azure DevOps Services, vous devez tenir compte du fait qu’Azure DevOps ne prend plus en charge les règles de rétention par pipeline. Avec cette mise à jour, nous avons supprimé ces stratégies lorsque vous migrez vers Azure DevOps Services de votre Azure DevOps Server local. Pour en savoir plus sur la configuration des stratégies de rétention, consultez notre documentation sur la définition de stratégies de rétention pour les builds, les mises en production et les tests.

Amélioration de l’API REST des exécutions de pipelines

Auparavant, l’API REST Pipelines Exécute ne renvoyait que le self dépôt. Avec cette mise à jour, l’API REST Pipelines Runs retourne toutes les ressources de dépôt d’une build.

Les modèles de pipelines YAML étendus peuvent désormais être transmis des informations de contexte pour les étapes, les travaux et les déploiements

Avec cette mise à jour, nous ajoutons une nouvelle templateContext propriété pour jobles composants de pipeline YAML , deploymentet stage destinés à être utilisés conjointement avec des modèles.

Voici un scénario d’utilisation templateContextde :

  • Vous utilisez des modèles pour réduire la duplication de code ou améliorer la sécurité de vos pipelines

  • Votre modèle prend comme paramètre une liste de stages, jobsou deployments

  • Le modèle traite la liste d’entrée et effectue certaines transformations sur chacune des étapes, travaux ou déploiements. Par exemple, il définit l’environnement dans lequel chaque travail s’exécute ou ajoute des étapes supplémentaires pour appliquer la conformité

  • Le traitement nécessite que des informations supplémentaires soient transmises par l’auteur du pipeline dans le modèle pour chaque étape, tâche ou déploiement dans la liste

Prenons un exemple. Supposons que vous créez un pipeline qui exécute des tests de bout en bout pour la validation des demandes de tirage. Votre objectif est de tester un seul composant de votre système, mais, comme vous prévoyez d’exécuter des tests de bout en bout, vous avez besoin d’un environnement dans lequel davantage de composants du système sont disponibles et vous devez spécifier leur comportement.

Vous réalisez que d’autres équipes auront des besoins similaires. Vous décidez donc d’extraire les étapes de configuration de l’environnement dans un modèle. Son code se présente comme suit :

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Ce que fait le modèle, pour chaque travail dans le testSet paramètre, définit la réponse des composants du système spécifiés par ${{ testJob.templateContext.requiredComponents }} pour renvoyer ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Ensuite, vous pouvez créer votre propre pipeline qui s’étend testing-template.yml comme dans l’exemple suivant.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Ce pipeline exécute deux tests, un positif et un négatif. Les deux tests nécessitent que le dimensionsapi composant soit disponible. Le positive_test travail attend le dimensionsapi code HTTP de retour 200, tandis qu’il negative_test s’attend à retourner le code HTTP 500.

Comptes de service managés de groupe de support en tant que compte de service d’agent

L’agent Azure Pipelines prend désormais en charge les comptes de service managés de groupe sur les agents auto-hébergés sur Windows.

Les comptes de service gérés de groupe fournissent une gestion centralisée des mots de passe pour les comptes de domaine qui jouent le rôle de comptes de service. L’agent Azure Pipelines peut reconnaître ce type de compte, de sorte qu’aucun mot de passe n’est nécessaire pendant la configuration :

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Exécutions d’informations

Une exécution d’informations vous indique qu’Azure DevOps n’a pas pu récupérer le code source d’un pipeline YAML. Une telle exécution ressemble à ce qui suit.

Pipelines récemment exécutés

Azure DevOps récupère le code source d’un pipeline YAML en réponse à des événements externes, par exemple, une validation poussée ou en réponse à des déclencheurs internes, par exemple, pour vérifier s’il y a des modifications de code et démarrer une exécution planifiée ou non. Lorsque cette étape échoue, le système crée une exécution d’informations. Ces exécutions sont créées uniquement si le code du pipeline se trouve dans un référentiel GitHub ou BitBucket.

La récupération du code YAML d’un pipeline peut échouer pour les raisons suivantes :

  • Le fournisseur de référentiels rencontre une panne
  • Limitation des tentatives d’accès
  • Problèmes d’authentification
  • Impossible de récupérer le contenu du fichier .yml du pipeline

En savoir plus sur les exécutions d’informations.

La propriété de l’API retentionRules REST de définition de build est obsolète

Dans le type de réponse de l’API REST de définition de BuildDefinition build, la retentionRules propriété est désormais marquée comme obsolète, car cette propriété retourne toujours un jeu vide.

Repos

Nouvelles pages TFVC

Nous avons mis à jour différentes pages dans Azure DevOps pour utiliser une nouvelle plateforme web dans le but de rendre l’expérience plus cohérente et plus accessible dans les différents services. Les pages TFVC ont été mises à jour pour utiliser la nouvelle plateforme web. Avec cette version, nous mettons les nouvelles pages TFVC en disponibilité générale.

Désactiver un dépôt

Les clients ont souvent demandé un moyen de désactiver un dépôt et d’empêcher les utilisateurs d’accéder à son contenu. Par exemple, vous pouvez effectuer cette opération dans les cas suivants :

  • Vous avez trouvé un secret dans le dépôt.
  • Un outil d’analyse tiers a constaté qu’un dépôt n’était pas conforme.

Dans ce cas, vous pouvez désactiver temporairement le dépôt pendant que vous travaillez pour résoudre le problème. Avec cette mise à jour, vous pouvez désactiver un dépôt si vous disposez des autorisations Supprimer le dépôt . En désactivant un dépôt, vous :

  • Peut répertorier le dépôt dans la liste des dépôts
  • Impossible de lire le contenu du dépôt
  • Impossible de mettre à jour le contenu du dépôt
  • Afficher un message indiquant que le dépôt a été désactivé lorsqu’il tente d’accéder au dépôt dans l’interface utilisateur Azure Repos

Une fois les étapes d’atténuation nécessaires prises, les utilisateurs disposant de l’autorisation Supprimer le dépôt peuvent réactiver le dépôt. Pour désactiver ou activer un dépôt, accédez à Paramètres du projet, sélectionnez Référentiels, puis le dépôt spécifique.

Désactiver un dépôt

Configurer les créateurs de branche pour ne pas obtenir « Gérer les autorisations » sur leurs branches

Lorsque vous créez une branche, vous obtenez « Gérer les autorisations » sur cette branche. Cette autorisation vous permet de modifier les autorisations d’autres utilisateurs ou d’autoriser d’autres utilisateurs à contribuer à cette branche. Par exemple, un créateur de branche peut utiliser cette autorisation pour autoriser un autre utilisateur externe à apporter des modifications au code. Ils peuvent également autoriser un pipeline (build service identity) à modifier le code dans cette branche. Dans certains projets avec des exigences de conformité plus élevées, les utilisateurs ne doivent pas être en mesure d’apporter ces modifications.

Avec cette mise à jour, vous pouvez configurer tous les dépôts de votre projet d’équipe et empêcher les créateurs de branches d’obtenir l’autorisation « Gérer les autorisations ». Pour ce faire, accédez aux paramètres du projet, sélectionnez Référentiels, puis Paramètres pour tous les dépôts ou un dépôt spécifique.

Paramètres de tous les dépôts

Ce paramètre est activé par défaut pour imiter le comportement existant. Toutefois, vous pouvez la désactiver si vous souhaitez utiliser cette nouvelle fonctionnalité de sécurité.

Empêcher les utilisateurs de la duplication de voter sur leurs demandes de tirage en amont

Avec Azure Repos, les utilisateurs disposant de l’autorisation « lecture » sur un dépôt peuvent dupliquer le dépôt et apporter des modifications à leur duplication. Pour soumettre une demande de tirage avec leurs modifications à l’amont, les utilisateurs ont besoin de l’autorisation « contribuer aux demandes de tirage » sur l’amont. Toutefois, cette autorisation détermine également qui peut voter sur les demandes de tirage dans le dépôt en amont. Par conséquent, vous pouvez vous retrouver dans des situations où un utilisateur, qui n’est pas un contributeur au dépôt, peut envoyer une demande de tirage et la fusionner en fonction de la façon dont vous configurez les stratégies de branche.

Dans les projets qui font la promotion d’un modèle source interne, la duplication et la contribution sont un modèle courant. Pour sécuriser et promouvoir davantage ce modèle, nous modifions l’autorisation de voter sur une demande de tirage de « contribuer aux demandes de tirage » en « contribuer ». Toutefois, cette modification n’est pas effectuée par défaut dans tous les projets. Vous devez vous inscrire et sélectionner une nouvelle stratégie sur votre dépôt, appelée « Mode de vote strict » pour changer cette autorisation. Nous vous recommandons de le faire si vous utilisez des duplications dans Azure Repos.

Paramètres du référentiel

Rapports

Regrouper par étiquettes disponibles dans les widgets de graphique

Le widget de graphique Regrouper par étiquettes est désormais disponible par défaut pour tous les clients. Lorsque vous utilisez le widget de graphique, une option est désormais disponible pour les balises. Les utilisateurs peuvent visualiser leurs informations en sélectionnant toutes les étiquettes ou un ensemble de balises dans le widget.


Regrouper par étiquettes disponibles dans les widgets de graphique

Afficher les types d’éléments de travail personnalisés dans le widget burndown

Auparavant, vous n’étiez pas en mesure de voir les types d’éléments de travail personnalisés configurés dans le widget burn down et additionnés ou comptés par un champ personnalisé. Avec cette mise à jour, nous avons résolu ce problème et vous pouvez maintenant voir les types d’éléments de travail personnalisés dans le widget burndown.


Commentaires

Nous aimerions connaître votre opinion ! Vous pouvez signaler un problème ou fournir une idée et le suivre à travers Developer Community et obtenir des conseils sur Stack Overflow.


Haut de la page