GitHub Secret Protection et GitHub Code Security disponibles en tant que produits autonomes dans Azure DevOps

Vous pouvez maintenant obtenir GitHub Secret Protection et GitHub Code Security en tant que produits autonomes dans Azure DevOps. Secret Protection vous donne accès à des fonctionnalités d’analyse des secrets, de protection push et de présentation de la sécurité. La sécurité du code permet d’accéder à toutes les expériences d’analyse des dépendances, d’analyse du code et de vue d’ensemble de la sécurité.

Dans Plans de test, nous publions le nouveau répertoire Plans de test pour vous aider à rester organisé et à gagner du temps. Vous pouvez désormais gérer les plans de test plus efficacement, en ayant un meilleur contrôle sur votre espace de travail et en réduisant les tâches répétitives.

Pour plus d’informations, consultez les notes de publication.

Sécurité avancée GitHub pour Azure DevOps

• GitHub Advanced Security est désormais disponible en tant que Protection secrète GitHub et Sécurité du code pour Azure DevOps

Généralités

• Stratégie de restriction de la création de jetons d’accès personnel (PAT) désormais disponible en préversion publique
• Suppression des applications OAuth Azure DevOps expirées
• Nouveaux périmètres Microsoft Entra OAuth
• Disponibilité de l’URL de demande d’accès

Azure Pipelines

• Pools DevOps gérés - Obsolescence des images
• Page Nouveaux déclencheurs
• Type de paramètre StringList
• Consultez le code YAML complet d’une exécution de pipeline

Azure Test Plans (Plans de test Azure)

• Présentation du nouveau répertoire des plans de test
• Historique des résultats du cas de test avancé
• Afficher l’état de cas de test sous l’onglet Exécuter
• Reprise par défaut pour le cas de test suspendu

Sécurité avancée GitHub pour Azure DevOps

GitHub Advanced Security est désormais disponible en tant que GitHub Secret Protection et Code Security pour Azure DevOps

GitHub Secret Protection et GitHub Code Security peuvent désormais être achetés en tant que produits autonomes sur Azure DevOps pour les nouveaux clients.

Secret Protection vous donne accès à des fonctionnalités d’analyse des secrets, de protection push et de présentation de la sécurité. La sécurité du code permet d’accéder à toutes les expériences d’analyse des dépendances, d’analyse du code et de vue d’ensemble de la sécurité.

Tous les clients Advanced Security existants peuvent continuer à utiliser l’expérience de produit groupée sans interruption. Si vous êtes un client Advanced Security actuel et que vous souhaitez passer aux produits autonomes, contactez le support Azure DevOps via le portail Azure. Vous pouvez déposer un ticket de support pour le service GitHub Advanced Security pour Azure DevOps et sélectionner Billing migration from bundled to standalone products le type de problème.

Pour plus d’informations sur ces produits, consultez le blog de développement.

Généralités

Stratégie d’organisation restreignant la création de jetons d’accès personnels (PAT) désormais disponible en préversion publique

Nous avons introduit une nouvelle stratégie au niveau de l’organisation dans Azure DevOps — Restreindre la création de jetons d’accès personnel (PAT), désormais disponible en préversion publique. Cette fonctionnalité demandée depuis longtemps permet aux administrateurs de collection de projets de contrôler qui peut créer ou régénérer des paTs, ce qui permet de réduire la prolifération des jetons et d’améliorer la sécurité. Lorsque cette option est activée, seuls les utilisateurs figurant sur une liste blanche peuvent générer des PAT, avec prise en charge facultative des étendues de packaging. La stratégie bloque également l’utilisation globale du PAT, sauf autorisation explicite. En savoir plus sur cette stratégie et les meilleures pratiques pour implémenter ce changement dans notre billet de blog !

Suppression des applications OAuth Azure DevOps expirées

À mesure que nous nous préparons à la fin de la vie des applications OAuth Azure DevOps en 2026, nous commencerons à supprimer régulièrement des applications avec des secrets qui ont expiré il y a plus de six mois (il y a 180 jours). Les propriétaires de ces applications inactives seront informés et s’il existe un besoin supplémentaire pour l’inscription de l’application entre maintenant et la fin de vie d’Azure DevOps OAuth en 2026, il vous est demandé de changer la clé secrète de l’application avant le 9 juin, date à laquelle nous commencerons les suppressions d’applications. En savoir plus dans notre billet de blog.

Nouvelles étendues OAuth Microsoft Entra

Azure DevOps a introduit deux nouvelles étendues Microsoft Entra OAuth, vso.pats et vso.pats_manage pour améliorer la sécurité et contrôler les API de gestion du cycle de vie des jetons d’accès personnels (PAT). Ces étendues sont désormais requises pour les flux délégués qui impliquent la création et la gestion de PAT, en remplacement de l’étendue user_impersonation précédemment très large. Cette modification permet aux propriétaires d’applications de réduire les autorisations nécessaires par leur application pour accéder aux API PAT. Limitez vos user_impersonation applications aux étendues minimales nécessaires aujourd’hui !

Disponibilité de l’URL de demande d’accès

Les administrateurs Azure DevOps peuvent désactiver la stratégie d’accès aux demandes et fournir une URL permettant aux utilisateurs de demander l’accès à une organisation ou à un projet. Cette URL, précédemment disponible uniquement pour les nouveaux utilisateurs, est désormais affichée aux utilisateurs existants sur la page 404. Pour maintenir la confidentialité, l’URL d’accès aux demandes s’affiche indépendamment de l’existence du projet.

Azure Pipelines

Pools DevOps gérés - Obsolescence des images

En raison de la dépréciation de l’image hébergée par Windows Server 2019 et de la dépréciation d’Ubuntu 20.04, les pools DevOps managés déprécient l’image « Azure Pipelines – Windows Server 2019 » et les images Ubuntu 20.04. Vous trouverez plus de détails sur les obsolescences ici. Vous pouvez en savoir plus sur le cycle de vie des images offertes par les pools DevOps gérés ici.

Nouvelle page Déclencheurs

Les pipelines YAML vous offrent plusieurs options puissantes à définir quand votre pipeline doit s’exécuter. Il n’est pas toujours facile de déterminer si votre pipeline est configuré pour s’exécuter en réponse à un événement, par exemple, l’achèvement d’un pipeline d’alimentation.

Ce sprint a introduit une page Déclencheurs qui vous donne une vue d’ensemble des déclencheurs que vous avez définis dans votre pipeline.

Imaginez que vous avez le pipeline YAML suivant défini dans la main branche d’un répertoire. Considérez qu’il existe également une feature branche qui a le même code de pipeline YAML.

trigger:
- main

schedules:
  - cron: 0 0 * * *
    always: true
    displayName: Nightly build
    branches:
      include:
        - main

resources:
  pipelines:
    - pipeline: FabrikamFiber
      source: FabrikamFiber
      trigger: true

Lorsque vous accédez à la page Déclencheurs , vous voyez les éléments suivants :

Notez que la branche par défaut du pipeline est mainpréélectionnée.

Vous voyez qu’il existe un déclencheur d’intégration continue pour cette branche et qu’il est défini dans le fichier YAML.

Lorsque vous accédez aux déclencheurs de planification, vous voyez qu’il existe des déclencheurs définis et que vous pouvez voir leurs détails.

Lorsque vous accédez à la section Déclencheurs de ressources, vous voyez les déclencheurs de ressources définis et leurs détails.

Vous pouvez passer de la branche main à la branche feature pour voir les déclencheurs que vous avez définis pour la branche feature.

Sous l’onglet Déclencheurs de ressources, lorsque ce n’est pas sur la branche par défaut, vous recevez un avertissement indiquant que les déclencheurs définis pour cette branche sont ignorés.

Lorsque les définitions de déclencheur n’ont pas été correctement traitées par le système, vous recevez un avertissement et des indications sur la façon de résoudre le problème.

Type de paramètre StringList

L’une des principales fonctionnalités de pipelines YAML demandées dans la Communauté des développeurs consiste à définir des paramètres qui contiennent une liste d’éléments.

À compter de ce sprint, nous avons ajouté un nouveau type de paramètre nommé StringList, qui fournit cette fonctionnalité.

Supposons que vous souhaitez autoriser les personnes qui mettent en file d’attente les exécutions de pipeline pour choisir les régions dans lesquelles ils souhaitent déployer une charge utile. Vous pouvez maintenant procéder comme indiqué dans l’exemple ci-dessous.

parameters:
- name: regions
  type: stringList
  displayName: Regions
  values:
    - WUS
    - CUS
    - EUS
  default: 
    - WUS
    - CUS
    - EUS 

stages:
- ${{ each stage in parameters.regions}}:
  - stage: ${{stage}}
    displayName: Deploy to ${{stage}}
    jobs:
    - job:
      steps:
      - script: ./deploy ${{stage}}

Lors de la mise en file d’attente de ce pipeline, vous avez la possibilité de choisir plusieurs régions à déployer, comme illustré dans la capture d’écran suivante.

Consultez le code YAML complet d’une exécution de pipeline

Les pipelines YAML peuvent être composés. Vous pouvez étendre un modèle pour vous assurer que vos pipelines exécutent les outils d’analyse statique nécessaires et inclure des modèles pour exécuter des phases ou des tâches courantes.

Le débogage de tels pipelines n’était pas facile, car vous n’avez pas pu voir le code YAML complet qu’il exécutait.

Supposons que vous disposez du pipeline suivant :

parameters:
- name: PoolName
  type: string
  default: Azure Pipelines
- name: VmImage
  type: string
  default: ubuntu latest

extends:
  template: security-enforcing-template.yml
  parameters:
    jobs:
    - template: job.monitoring.yml
    - template: job.build.yml
      parameters:
        PoolName: ${{parameters.PoolName}}
        VmImage: ${{parameters.VmImage}}

Il existe trois modèles utilisés ici. Chaque modèle peut utiliser des expressions conditionnelles basées sur des valeurs de paramètre et de variable pour déterminer les travaux ou étapes réels à exécuter.

En outre, lorsque vous examinez les anciennes exécutions de pipeline, vous ne savez pas si le code du pipeline est le même que lors de l’exécution.

Dans ce sprint, nous ajoutons une nouvelle fonctionnalité qui vous permet de voir facilement le code YAML complet d’une exécution de pipeline.

Azure Test Plans (Plans de test Azure)

Présentation du nouveau répertoire Plans de test

Restez organisé et gagnez du temps avec le nouveau répertoire des plans de test. Nous introduisons plusieurs améliorations pour vous aider à gérer les plans de test plus efficacement, ce qui vous permet de mieux contrôler votre espace de travail et de réduire les tâches répétitives.

Voici les nouveautés :

• Conception plus propre de l’interface utilisateur : parcourez facilement vos plans de test à l’aide d’une interface moderne qui améliore la lisibilité et réduit l’encombrement, ce qui vous permet de vous concentrer sur vos tâches sans distractions.

• Tri des colonnes : recherchez ce dont vous avez besoin plus rapidement en triant les colonnes en fonction du nom, de l’état ou d’autres attributs clés. Cette fonctionnalité vous permet d’organiser et de hiérarchiser rapidement vos plans de test pour une meilleure productivité.

• Filtre d’équipe dans l’onglet Tous : concentrez-vous sur ce qui importe en filtrant les plans de test par équipe, en vous assurant que seuls les plans pertinents s’alignent sur votre travail et vos objectifs.

• Filtres persistants : gagnez du temps avec des filtres persistants qui mémorisent vos paramètres. Lorsque vous revenez à la page, vos filtres précédemment appliqués restent intacts, fournissant une vue organisée sans avoir besoin de réappliquer des filtres à chaque fois.

Ces mises à jour sont conçues pour simplifier votre flux de travail, réduire les tâches répétitives et faciliter le suivi et la gestion de vos plans de test. Donnez-lui une tentative et faites-nous savoir via e-mail ce que vous pensez !

Historique des résultats du cas de test avancé

Suivez facilement les détails de l’exécution des tests clés avec de nouvelles améliorations apportées à la page de résultats du cas de test. Vous verrez des informations critiques telles que l’ID d’exécution, l’ID de pipeline, le propriétaire, le chemin d’itération et le chemin de zone affichés directement sur la page, en fournissant une vue complète de chaque exécution de test en un clin d’œil.

Nous avons ajouté le défilement horizontal pour des valeurs plus longues et des colonnes personnalisables, ce qui vous permet de personnaliser votre disposition et de conserver vos préférences enregistrées au niveau de l’utilisateur. Pour vous aider à avancer plus rapidement, il est possible de cliquer sur les ID d'exécution et les lignes pour accéder rapidement à la vue Tester/Exécuter et obtenir des informations plus détaillées. Ces mises à jour visent à améliorer la visibilité, à gagner du temps et à rationaliser votre flux de travail, ce qui facilite le suivi et la gestion de vos exécutions de test efficacement. Donnez-lui une tentative et faites-nous savoir par e-mail si vous avez des commentaires. Nous aimerions connaître votre opinion !

Afficher l’état de cas de test sous l’onglet Exécuter

Vous pouvez maintenant ajouter la colonne « État de cas de test » à l’onglet Exécuter pour afficher rapidement l’état de chaque cas de test. Qu’il s’agisse d’un état approuvé, en cours ou d’un autre état, cette mise à jour vous offre une visibilité plus claire de la préparation des tests sans changer d’onglets de navigateur ou exécuter des requêtes complexes.

La colonne est facultative et peut être activée via le sélecteur de colonnes. Il s’aligne également sur le filtre d’état existant, ce qui vous permet de filtrer et d’afficher les états de cas de test côte à côte, tous en un seul endroit.

Cette amélioration permet de garantir que les testeurs commencent à s’exécuter avec des cas de test réellement prêts ou approuvés, ce qui réduit le risque d’exécution d’éléments incomplets ou brouillons et rend vos exécutions de test plus efficaces dès le début.

Reprise par défaut pour le cas de test suspendu

Reprenez rapidement vos cas de test suspendus en un seul clic. Nous avons défini « Reprendre » comme action par défaut pour les cas de test suspendus, vous permettant de reprendre exactement là où vous vous êtes arrêté sans navigation supplémentaire. Cette mise à jour facilite la poursuite de votre travail sans interruption.

Pour mieux protéger vos progrès, nous introduisons une requête de confirmation afin d'éviter l'écrasement accidentel de la progression des tests en pause. Cette protection garantit que votre travail partiellement sauvegardé reste intact, ce qui vous permet de gérer vos essais en toute sérénité. Donnez-lui une tentative et faites-nous savoir via e-mail ce que vous pensez !

Étapes suivantes

Comment fournir des commentaires

Nous aimerions entendre 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.