Sécurité améliorée et flux de travail de pipeline

Avec ce sprint, nous améliorons votre flux de travail DevOps avec une meilleure visibilité de la sécurité et des flux de travail de pipeline simplifiés. GitHub Advanced Security inclut désormais un suivi détaillé des activations pour analyse des dépendances, l’analyse du codeet analyse des secrets, offrant des insights plus approfondis sur la couverture de sécurité de votre organisation.

En outre, nous sommes heureux d’introduire des améliorations axées sur le pipeline, notamment de nouvelles fonctions d’expression YAML et des contrôles étendus pour les tâches de validation manuelle, ce qui vous permet de créer des flux de travail plus efficaces et sécurisés.

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

Sécurité avancée GitHub pour Azure DevOps

• vue d’ensemble de la couverture de sécurité spécifique à l’outil

Azure Boards :

• Intégration d’Azure Boards à GitHub Enterprise Cloud avec la résidence des données

Azure Repos

• Sparse checkout pour Azure Repos
• Rendre les politiques cross-repo sensibles à la casse

Azure Pipelines

• Nouvelle fonction d’expression de pipeline
• Améliorations apportées à la tâche ManualValidation

Plans de test

• Correctifs de bogues dans Azure Test Plans

Sécurité avancée GitHub pour Azure DevOps

Couverture de la vue d’ensemble de la sécurité propre à l’outil

La vue d’ensemble de la sécurité dans GitHub Advanced Security pour Azure DevOps fournit désormais une répartition détaillée de l’état d’activation pour chaque outil d’analyse des dépendances, notamment d’analyse des dépendances, analyse du codeet analyse secrète. Cette amélioration vous permet d’afficher les états d’activation affinés dans tous les référentiels de votre organisation.

Pour plus d’informations, consultez Vue d’ensemble de la sécurité avancée.

Azure Boards

Intégration d'Azure Boards avec GitHub Enterprise Cloud et résidence des données (aperçu)

Azure Boards prend désormais en charge l’intégration avec les organisations GitHub Enterprise Cloud qui ont activé la résidence des données. Cette mise à jour s'aligne sur l'annonce de GitHub de septembre 2024 introduisant la résidence des données pour les clients Enterprise Cloud, en commençant par ceux de l'Union européenne (UE).

Pour connecter un projet Azure Boards à votre organisation GitHub Enterprise Cloud avec résidence des données :

1. Créez une connexion dans Azure Boards.

2. Sélectionnez le GitHub Enterprise Cloud avec l’option de résidence des données.

Azure Repos

Sparse checkout pour Azure Repos

La commande git sparse-checkout est désormais prise en charge dans la tâche d’extraction YAML, en même temps que le filtre de clone partiel, pour améliorer les performances d’extraction du référentiel. Vous pouvez utiliser les propriétés sparseCheckoutDirectories et sparseCheckoutPatterns.

Le paramètre sparseCheckoutDirectories active le mode cone, où le processus de checkout utilise l’appariement de répertoires. Vous pouvez également définir sparseCheckoutPatterns, qui déclenche le mode sans cône, permettant un jumelage de motifs plus complexe.

Si les deux propriétés sont définies, l’agent initialise le mode cone avec l’appariement de répertoires. Si aucune propriété n’est spécifiée dans la tâche de checkout, le processus de sparse checkout est désactivé. Tout problème rencontré lors de l’exécution de la commande entraîne l’échec de la tâche de validation.

Exemple YAML pour le mode cone de sparse checkout :

  - checkout: repo
    sparseCheckoutDirectories: src

Exemple YAML pour le mode non-cone de sparse checkout :

 - checkout: repo
   sparseCheckoutPatterns: /* !/img 

Vous pouvez trouver l’agent sur la page des versions.

Rendre les politiques cross-repo sensibles à la casse

Auparavant, l’aperçu des candidats de branche pour les politiques cross-repo affichait des résultats de manière insensible à la casse, bien que la correspondance des branches soit sensible à la casse. Cette incohérence a créé un désalignement potentiel, car il pouvait sembler que certaines branches étaient protégées alors qu'elles ne l'étaient pas. Pour résoudre ce problème, nous avons mis à jour l’aperçu du modèle de branche afin qu’il soit conforme au comportement sensible à la casse de l’application des politiques.

Auparavant:

Après :

Azure Pipelines

Nouvelles fonctions d’expression de pipeline

Les fonctions d’expression de pipeline vous permettent d’écrire des pipelines YAML puissants. Dans ce sprint, nous avons introduit deux nouvelles fonctions :

• iif(condition, value_when_true, value_when_false) qui retourne value_when_true lorsque condition prend la valeur true ou value_when_false ; sinon,

• trim(string) qui retourne une nouvelle chaîne dans laquelle les espaces blancs au début et à la fin de la chaîne sont supprimés

Par exemple, vous pouvez utiliser la fonction iif pour sélectionner dynamiquement un pool pour exécuter votre pipeline. Si vous souhaitez générer des demandes de tirage à l’aide du pool Azure Pipelines, mais que toutes les autres exécutions doivent utiliser un pool DevOps managé, vous pouvez écrire le pipeline suivant.

variables:
  poolToUse: ${{ iif(eq(variables['Build.Reason'], 'PullRequest'), 'Azure Pipelines', 'ManagedDevOpsPool')}}

stages:
- stage: build
  pool: ${{variables.poolToUse}}
  jobs:
  - job:
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'

Vous pouvez utiliser la fonction trim pour rendre votre yaML plus résilient aux entrées utilisateur. Par exemple, dans le pipeline suivant, nous utilisons la fonction trim pour vous assurer que le nom de l’étape ne commence pas par les espaces blancs.

parameters:
- name: regions
  type: string
  default: '  wus1,   wus2, wus3,wus4'

stages:
- ${{ each region in split(parameters.regions, ',')}}:
  - stage: stage_${{trim(region)}}
    displayName: Deploy to ${{trim(region)}}
    jobs:
    - job: deploy
      steps:
      - script: ./deploy.sh ${{trim(region)}}

Améliorations apportées à la tâche de Validation Manuelle

La tâche ManualValidation vous permet de mettre en pause l'exécution d'un pipeline et d'attendre une intervention manuelle. L’un des scénarios d’utilisation de cette tâche est un test manuel.

Pour renforcer la sécurité de votre pipeline, vous souhaiterez peut-être restreindre les personnes pouvant effectuer la tâche et reprendre l’exécution du pipeline. À cette fin, nous introduisons une nouvelle version de la tâche qui fournit deux paramètres supplémentaires :

• approvers: restreindre les personnes pouvant effectuer la tâche à un ensemble prédéfini d’utilisateurs / groupes de sécurité / équipes

• allowApproversToApproveTheirOwnRuns : empêcher l’utilisateur qui a mis l’exécution du pipeline en file d’attente de la reprendre

Par exemple, l'extrait YAML suivant restreint l'ensemble des personnes qui peuvent reprendre l'exécution du pipeline aux seuls membres du groupe des Approbateurs de mise en production, à l'exclusion de l'utilisateur à l'origine de cette exécution.

- task: ManualValidation@1
  inputs:
    notifyUsers: 'Release Approvers'
    approvers: 'Release Approvers'
    allowApproversToApproveTheirOwnRuns: false

Dans la propriété approvers, vous pouvez utiliser les valeurs suivantes (séparées par des virgules) :

• Adresse courriel
• Groupe de permissions
• Équipe-Projet
• [ProjectName]\[Groupe d’autorisations],
• [Org]\[Groupe d’autorisations],
• [ProjectName]\[Équipe de projet]

Plans de test

Correctifs de bogues dans Azure Test Plans

Avec ce sprint, nous avons apporté des mises à jour aux plans de test Azure pour résoudre plusieurs bogues et améliorer la facilité d’utilisation. Voici ce qui a été résolu :

• Résultats des étapes partagées désormais visibles : correction d’un bogue qui empêchait les résultats des étapes partagées d'apparaître dans l’éditeur de requêtes lors de l’accès aux cas de test dans le New Boards Hub.

• Sessions du mode parties prenantes améliorées : Résolution d'un problème dans l’extension de test et de commentaires qui empêchait les utilisateurs disposant d’un accès en tant que partie prenante de démarrer des sessions.

• Copie de plan de test plus propre : résolu un problème où les exigences étaient dupliquées lors de la copie d’un plan de test à l’aide de l’option « Référencer les cas de test existants ».

Étapes suivantes

Passez à Azure DevOps et jetez un coup d’œil.

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.

Merci

Silviu Andrica