Compartir a través de

Disponibilidad general de las reglas de automatización del equipo y validación de AB# mejorada

  • Artículo

Nos complace anunciar que la validación de AB# mejorada por la aplicación de Azure Boards en GitHub y las reglas de Automatización de equipos están disponibles con carácter general. Se ha mejorado la validación de AB# para que pueda recibir notificaciones cuando un vínculo a un elemento de trabajo no es válido. En Reglas de Automatización de equipos, ahora puede configurar cada nivel de trabajo pendiente para automatizar la apertura y cierre o resolución de elementos de trabajo en función de los estados del elemento secundario.

Con esta actualización, también presentamos compatibilidad con consultas de CodeQL personalizadas en el análisis de código. Esto le permitirá crear sus propias consultas adaptadas para identificar problemas específicos del código base.

Consulte las notas de la versión para obtener más información.

GitHub Advanced Security para Azure DevOps

Azure Boards

Azure Pipelines

GitHub Advanced Security para Azure DevOps

Las consultas de CodeQL personalizadas ahora se admiten en Seguridad avanzada de GitHub para Azure DevOps

Estamos encantados de anunciar la introducción de la compatibilidad con consultas de CodeQL personalizadas en el análisis de código. Esto le permite crear sus propias consultas adaptadas para identificar problemas específicos de su código base. Ahora, puede crear y publicar paquetes que contengan consultas personalizadas, ejecutar estas consultas en las canalizaciones y personalizar la detección de vulnerabilidades pertinentes para su organización.

Para más información sobre el uso de consultas personalizadas para el análisis de código en GitHub Advanced Security para Azure DevOps, consulte Análisis de código de alertas para GitHub Advanced Security para Azure DevOps.

Valoramos la entrada. Si tiene alguna pregunta o comentario, le animamos a interactuar con nuestra comunidad en Developer Community.

Azure Boards

Integración de GitHub: la validación ab# mejorada está disponible con carácter general.

Hace unos sprints anunciamos la versión preliminar para mejorar la validación ab# por la aplicación de Azure Boards en GitHub. Hemos mejorado la aplicación para notificar mejor a los usuarios la validez de los vínculos de elementos de trabajo, lo que les ayuda a detectar y corregir los problemas antes de combinar una solicitud de incorporación de cambios.

Después de varias semanas de pruebas y comentarios, esta característica ya está disponible para todos los usuarios mediante la integración de GitHub + Azure Boards.

Capturas de pantalla de la validación mejorada.

Esta es la primera de las características que estamos realizando para mejorar la integración actual. Asegúrese de consultar las otras características de integración de Azure Boards + GitHub que hemos planeado en la hoja de ruta pública.

Importante

A partir del 6/8/2024, la aplicación de Azure Boards en GitHub ya no validará los vínculos AB#. Todavía puede usar la AB# sintaxis para vincular elementos de trabajo en las solicitudes de incorporación de cambios, confirmaciones y problemas de GitHub, como podría antes de este cambio.

Las reglas de Automatización de equipos están disponibles con carácter general

Nos complace anunciar el lanzamiento de esta característica a todos los clientes de Azure DevOps Service.

Nota:

Esta característica se implementará en las próximas dos a tres semanas. Es posible que no esté disponible para su organización hasta principios de febrero de 2024.

Ahora puede configurar cada nivel de trabajo pendiente para automatizar la apertura y el cierre (o resolución) de los elementos de trabajo en función del estado de los elementos secundarios. Hay dos escenarios principales que estamos intentando resolver.

  • Cuando se activa un solo elemento secundario, active el elemento primario.
  • Cuando se cierran todos los elementos secundarios, cierre el elemento primario (o resuélvalo).

Para habilitar esta configuración, haga clic en la configuración de nivel de trabajo pendiente del equipo. A continuación, vaya a la pestaña Reglas de automatización > para ver las dos reglas diferentes que puede aplicar al trabajo pendiente. Cada nivel de trabajo pendiente (requisitos, características, epopeyas) se puede configurar de forma diferente en función de cómo el equipo quiera trabajar.

Capturas de pantalla de la configuración del equipo.

Por ejemplo, cuando cualquier tarea secundaria está establecida en Activo, active el artículo de usuario primario. A continuación, cuando se completen todas las tareas, establezca user story (Historia del usuario) en Closed (Cerrado).

Gif para demostración de la historia del usuario de cierre.

Para obtener más información sobre esta característica, revise la documentación y esta entrada de blog.

Esta característica se ha priorizado en función de este vale de sugerencia de la Comunidad de desarrolladores.

Azure Pipelines

Actualizar tareas en desuso antes del 31 de enero

Estamos retirando tareas en desuso el 31 de enero de 2024. Para ayudarle a identificar las canalizaciones que usan estas tareas, hemos incluido un mensaje de advertencia con una alternativa sugerida. Le recomendamos que actualice las canalizaciones para que usen una versión de tarea más reciente o una alternativa antes del 31 de enero de 2024.

Captura de pantalla de advertencias de desuso específicas de la tarea.

Consulte los anuncios anteriores relacionados con las tareas en desuso:

Los agentes hospedados por Microsoft usan PowerShell 7.4

Todos los agentes hospedados de Microsoft comenzarán a usar PowerShell 7.2 LTS a PowerShell 7.4 LTS desde el 28 de enero. Consulte Novedades de La disponibilidad general de PowerShell 7.4 y PowerShell 7.4.

Tome nota de los cambios importantes y actualice los scripts en consecuencia:

  • Cambios importantes entre PowerShell 7.3 y 7.4 LTS
  • Cambios importantes entre PowerShell 7.2 LTS y 7.3
  • Se ha actualizado el comportamiento de análisis de argumentos controlado a través de $PSNativeCommandArgumentPassing. El siguiente script de ejemplo aplica el mismo comportamiento en Linux, macOS y Windows estableciendo $PSNativeCommandArgumentPassing explícitamente.

Los nuevos secretos de conexión de servicio de Azure expiran en tres meses

Las conexiones de servicio de Azure en las que Azure DevOps crea el secreto tendrán una expiración secreta de tres meses en lugar de dos años.

Para eliminar la necesidad de rotar secretos, convierta la conexión de servicio para usar la federación de identidades de carga de trabajo en su lugar. Puede usar el siguiente script de ejemplo para convertir rápidamente varias conexiones de servicio de Azure a la federación de identidades de carga de trabajo:

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

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Vaya a Azure DevOps.

Cómo enviar sus comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

Hacer una sugerencia

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

Gracias,

Demonio