Partager via

Disponibilité générale des règles d’automatisation d’équipe et amélioration de la validation AB#

  • Article

Nous sommes heureux d’annoncer que la validation AB# améliorée par l’application Azure Boards dans GitHub et les règles Team Automation sont généralement disponibles ! Nous avons amélioré la validation AB# afin que vous puissiez être averti lorsqu’un lien vers un élément de travail n’est pas valide. Dans Les règles Team Automation, vous pouvez désormais configurer chaque niveau de backlog pour automatiser l’ouverture et la fermeture/résolution des éléments de travail en fonction de l’état ou des états de l’élément enfant.

Avec cette mise à jour, nous introduisons également la prise en charge des requêtes CodeQL personnalisées dans l’analyse du code ! Cela vous permet de créer vos propres requêtes adaptées pour identifier les problèmes spécifiques à votre codebase.

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

GitHub Advanced Security pour Azure DevOps

Azure Boards

Azure Pipelines

GitHub Advanced Security pour Azure DevOps

Requêtes CodeQL personnalisées désormais prises en charge dans GitHub Advanced Security pour Azure DevOps

Nous sommes ravis d’annoncer l’introduction de la prise en charge des requêtes CodeQL personnalisées dans l’analyse du code ! Cela vous permet de créer vos propres requêtes adaptées pour identifier les problèmes spécifiques à votre codebase. À présent, vous pouvez créer et publier des packs contenant des requêtes personnalisées, exécuter ces requêtes dans vos pipelines et personnaliser la détection des vulnérabilités pertinentes pour votre organisation.

Pour plus d’informations sur l’utilisation de requêtes personnalisées pour l’analyse de code dans GitHub Advanced Security pour Azure DevOps, consultez les alertes d’analyse de code pour GitHub Advanced Security pour Azure DevOps.

Nous apprécions votre entrée. Si vous avez des questions ou des commentaires, nous vous encourageons à collaborer avec notre communauté à la Communauté des développeurs.

Azure Boards

Intégration GitHub - Amélioration de la validation AB# est généralement disponible

Il y a quelques sprints, nous avons annoncé la préversion pour une validation AB# améliorée par l’application Azure Boards dans GitHub. Nous avons amélioré l’application pour mieux informer les utilisateurs de la validité des liens d’élément de travail, les aidant à repérer et à résoudre les problèmes avant de fusionner une demande de tirage.

Après plusieurs semaines de test et de commentaires, cette fonctionnalité est désormais disponible pour tous les utilisateurs à l’aide de l’intégration GitHub + Azure Boards.

Captures d’écran de la validation améliorée.

C’est la première de plusieurs fonctionnalités que nous faisons pour améliorer l’intégration actuelle. Veillez à consulter les autres fonctionnalités d’intégration Azure Boards + GitHub que nous avons planifiées sur la feuille de route publique.

Important

Depuis le 8/6/2024, l’application Azure Boards dans GitHub ne valide plus les liens AB#. Vous pouvez toujours utiliser la AB# syntaxe pour lier des éléments de travail dans vos demandes de tirage GitHub, les validations et les problèmes que vous pourriez rencontrer avant cette modification.

Les règles Team Automation sont généralement disponibles

Nous sommes heureux d’annoncer la publication de cette fonctionnalité à tous les clients d’Azure DevOps Service.

Remarque

Cette fonctionnalité sera déployée au cours des deux à trois prochaines semaines. Il peut ne pas être disponible pour votre organisation jusqu’au début de février 2024.

Vous pouvez maintenant configurer chaque niveau de backlog pour automatiser l’ouverture et la fermeture (ou la résolution) des éléments de travail en fonction de l’état des éléments enfants. Il existe deux scénarios principaux que nous essayons de résoudre.

  • Lorsqu’un seul élément enfant est activé, activez le parent.
  • Lorsque tous les éléments enfants sont fermés, fermez le parent (ou résolvez-le).

Pour activer ces paramètres, cliquez sur la configuration au niveau du backlog pour votre équipe. Accédez ensuite à l’onglet Règles Automation > pour afficher les deux règles différentes que vous pouvez appliquer à votre backlog. Chaque niveau de backlog (exigences, fonctionnalités, épopées) peut être configuré différemment selon la façon dont votre équipe souhaite travailler.

Captures d’écran des paramètres d’équipe.

Par exemple, quand une tâche enfant est définie sur Active, rendez l’article utilisateur parent actif. Ensuite, lorsque toutes les tâches sont terminées, définissez l’article utilisateur sur Fermé.

Gif pour démonstration de la fermeture de l’histoire utilisateur.

Pour en savoir plus sur cette fonctionnalité, consultez la documentation et ce billet de blog.

Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion de la Communauté des développeurs.

Azure Pipelines

Mettre à jour les tâches déconseillées avant le 31 janvier

Nous retirons les tâches déconseillées le 31 janvier 2024. Pour vous aider à identifier les pipelines qui utilisent ces tâches, nous avons inclus un message d’avertissement avec une alternative suggérée. Nous vous encourageons à mettre à jour vos pipelines pour utiliser une version de tâche plus récente ou une alternative avant le 31 janvier 2024.

Capture d’écran des avertissements de dépréciation spécifiques à la tâche.

Consultez les annonces antérieures relatives aux tâches dépréciées :

Les agents hébergés par Microsoft utilisent PowerShell 7.4

Tous les agents hébergés par Microsoft commencent à utiliser PowerShell 7.2 LTS vers PowerShell 7.4 LTS à partir du 28 janvier. Découvrez les nouveautés de PowerShell 7.4 et de la disponibilité générale de PowerShell 7.4.

Notez les changements cassants et mettez à jour vos scripts en conséquence :

Les nouveaux secrets de connexion de service Azure expirent dans trois mois

Connexions de service Azure où Azure DevOps crée le secret, aura une expiration de secret de trois mois au lieu de deux ans.

Pour éliminer la nécessité de faire pivoter les secrets, convertissez votre connexion de service pour utiliser la fédération des identités de charge de travail à la place. Vous pouvez utiliser l’exemple de script ci-dessous pour convertir rapidement plusieurs connexions de service Azure en fédération d’identité de charge de travail :

#!/usr/bin/env pwsh
<# 
.SYNOPSIS 
    Convert multiple Azure Resource Manager service connection(s) to use Workload identity federation

.LINK
    https://aka.ms/azdo-rm-workload-identity-conversion

.EXAMPLE
    ./convert_azurerm_service_connection_to_oidc_simple.ps1 -Project <project> -OrganizationUrl https://dev.azure.com/<organization>
#> 
#Requires -Version 7.3

param ( 
    [parameter(Mandatory=$true,HelpMessage="Name of the Azure DevOps Project")]
    [string]
    [ValidateNotNullOrEmpty()]
    $Project,

    [parameter(Mandatory=$true,HelpMessage="Url of the Azure DevOps Organization")]
    [uri]
    [ValidateNotNullOrEmpty()]
    $OrganizationUrl
) 
$apiVersion = "7.1"
$PSNativeCommandArgumentPassing = "Standard" 

#-----------------------------------------------------------
# Log in to Azure
$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

#-----------------------------------------------------------
# Retrieve the service connection
$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=${apiVersion}"
az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug
if (!$serviceEndpoints -or ($serviceEndpoints.count-eq 0)) {
    Write-Warning "No convertible service connections found"
    exit 1
}

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prompt user to confirm conversion
    $choices = @(
        [System.Management.Automation.Host.ChoiceDescription]::new("&Convert", "Converting service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Skip", "Skipping service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Exit", "Exit script")
    )
    $prompt = $serviceEndpoint.isShared ? "Convert shared service connection '$($serviceEndpoint.name)'?" : "Convert service connection '$($serviceEndpoint.name)'?"
    $decision = $Host.UI.PromptForChoice([string]::Empty, $prompt, $choices, $serviceEndpoint.isShared ? 1 : 0)

    if ($decision -eq 0) {

        Write-Host "$($choices[$decision].HelpMessage)"
    } elseif ($decision -eq 1) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        continue 
    } elseif ($decision -ge 2) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        exit 
    }

    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    
    $updatedServiceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    if (!$updatedServiceEndpoint) {
        Write-Debug "Empty response"
        Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
        exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

É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.

Faire une suggestion

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

Merci,

Dan Hellem