Condividi tramite

Disponibilità generale delle regole di automazione del team e convalida di AB# migliorata

  • Articolo

Siamo lieti di annunciare che la convalida AB# migliorata dall'app Azure Boards in GitHub e le regole di automazione del team sono disponibili a livello generale. È stata migliorata la convalida AB# in modo che sia possibile ricevere una notifica quando un collegamento a un elemento di lavoro non è valido. In Regole di automazione team è ora possibile configurare ogni livello di backlog per automatizzare l'apertura e la chiusura/risoluzione degli elementi di lavoro in base agli stati dell'elemento figlio.

Con questo aggiornamento, viene anche introdotto il supporto per le query CodeQL personalizzate nell'analisi del codice. In questo modo è possibile creare query personalizzate per identificare i problemi specifici della codebase.

Per informazioni dettagliate, vedere le note sulla versione.

GitHub Advanced Security per Azure DevOps

Azure Boards

Azure Pipelines

GitHub Advanced Security per Azure DevOps

Query CodeQL personalizzate ora supportate in GitHub Advanced Security per Azure DevOps

Siamo lieti di annunciare l'introduzione del supporto per le query CodeQL personalizzate nell'analisi del codice. In questo modo è possibile creare query personalizzate per identificare i problemi specifici della codebase. È ora possibile creare e pubblicare pacchetti contenenti query personalizzate, eseguire queste query nelle pipeline e personalizzare il rilevamento delle vulnerabilità pertinenti all'organizzazione.

Per altre informazioni sull'uso di query personalizzate per l'analisi del codice in GitHub Advanced Security per Azure DevOps, vedere Analisi del codice degli avvisi per GitHub Advanced Security per Azure DevOps.

Microsoft valuta l'input. In caso di domande o commenti e suggerimenti, è consigliabile interagire con la community degli sviluppatori.

Azure Boards

Integrazione di GitHub - La convalida AB# migliorata è disponibile a livello generale

Alcuni sprint fa sono stati annunciati l'anteprima per migliorare la convalida AB# dall'app Azure Boards in GitHub. L'app è stata migliorata per informare meglio gli utenti sulla validità dei collegamenti degli elementi di lavoro, consentendo loro di individuare e risolvere eventuali problemi prima di unire una richiesta pull.

Dopo diverse settimane di test e feedback, questa funzionalità è ora disponibile per tutti gli utenti che usano l'integrazione di GitHub e Azure Boards.

Screenshot della convalida migliorata.

Questa è la prima delle diverse funzionalità che stiamo creando per migliorare l'integrazione corrente. Assicurarsi di controllare le altre funzionalità di integrazione di Azure Boards e GitHub pianificate sulla roadmap pubblica.

Importante

A partire dal 6/8/2024, l'app Azure Boards in GitHub non convaliderà più i collegamenti AB#. È comunque possibile usare la AB# sintassi per collegare elementi di lavoro nelle richieste pull, nei commit e nei problemi di GitHub, come prima di questa modifica.

Le regole di automazione del team sono disponibili a livello generale

Siamo lieti di annunciare il rilascio di questa funzionalità a tutti i clienti del servizio Azure DevOps.

Nota

Questa funzionalità verrà implementata nelle prossime due o tre settimane. Potrebbe non essere disponibile per l'organizzazione fino all'inizio di febbraio 2024.

È ora possibile configurare ogni livello di backlog per automatizzare l'apertura e la chiusura (o la risoluzione) degli elementi di lavoro in base allo stato degli elementi figlio. Esistono due scenari principali che si sta tentando di risolvere.

  • Quando viene attivato un singolo elemento figlio, attivare l'elemento padre.
  • Quando tutti gli elementi figlio vengono chiusi, chiudere l'elemento padre (o risolverlo).

Per abilitare queste impostazioni, fare clic sulla configurazione a livello di backlog per il team. Passare quindi alla scheda Regole di automazione > per visualizzare le due regole diverse che è possibile applicare al backlog. Ogni livello di backlog (requisiti, funzionalità, epiche) può essere configurato in modo diverso a seconda del modo in cui il team vuole lavorare.

Screenshot delle impostazioni del team.

Ad esempio, quando un'attività figlio è impostata su Attivo, rendere attiva la storia utente padre. Quindi, al termine di tutte le attività, impostare La storia utente su Chiuso.

Gif per demo chiudere la storia dell'utente.

Per altre informazioni su questa funzionalità, vedere la documentazione e questo post di blog.

Questa funzionalità è stata assegnata in ordine di priorità in base a questo ticket di suggerimento della community degli sviluppatori.

Azure Pipelines

Aggiornare le attività deprecate prima del 31 gennaio

Le attività deprecate vengono ritirate il 31 gennaio 2024. Per identificare le pipeline che usano queste attività, è stato incluso un messaggio di avviso con un'alternativa suggerita. È consigliabile aggiornare le pipeline per usare una versione più recente dell'attività o un'alternativa prima del 31 gennaio 2024.

Screenshot degli avvisi di deprecazione specifici dell'attività.

Vedere gli annunci precedenti relativi alle attività deprecate:

Gli agenti ospitati da Microsoft usano PowerShell 7.4

Tutti gli agenti ospitati da Microsoft inizieranno a usare PowerShell 7.2 LTS a PowerShell 7.4 LTS dal 28 gennaio. Vedere Novità di PowerShell 7.4 e Disponibilità generale di PowerShell 7.4.

Prendere nota delle modifiche di rilievo e aggiornare gli script di conseguenza:

  • Modifiche di rilievo tra PowerShell 7.3 e 7.4 LTS
  • Modifiche di rilievo tra PowerShell 7.2 LTS & 7.3
  • Comportamento di analisi degli argomenti aggiornato controllato tramite $PSNativeCommandArgumentPassing. Lo script di esempio seguente applica lo stesso comportamento in Linux, macOS e Windows impostando $PSNativeCommandArgumentPassing in modo esplicito.

I nuovi segreti di connessione al servizio di Azure scadono in tre mesi

Le connessioni al servizio di Azure in cui Azure DevOps crea il segreto avranno una scadenza privata di tre mesi invece di due anni.

Per eliminare la necessità di ruotare i segreti, convertire invece la connessione al servizio per usare la federazione dell'identità del carico di lavoro. È possibile usare lo script di esempio seguente per convertire rapidamente più connessioni del servizio di Azure alla federazione dell'identità del carico di lavoro:

#!/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)'"
}

Passaggi successivi

Nota

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Passare ad Azure DevOps e dare un'occhiata.

Passare ad Azure DevOps

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usare il menu ? per segnalare un problema o fornire un suggerimento.

Inviare un suggerimento

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie,

Dan Hellem