Notas de la versión de Azure DevOps Server

| Developer Community | System Requirements and Compatibility | License Terms | DevOps Blog | SHA-256 Hashes |

En este artículo encontrará información sobre la versión más reciente de Azure DevOps Server.

Para obtener más información sobre cómo instalar o actualizar una implementación de Azure DevOps Server, consulte Azure DevOps Server Requirements.

Para descargar productos de Azure DevOps Server, visite la página de descargas de Azure DevOps Server.

La actualización directa a Azure DevOps Server se admite desde Azure DevOps Server 2019 o Team Foundation Server 2015 o versiones posteriores. Si la implementación de TFS está en TFS 2013 o versiones anteriores, debe realizar algunos pasos provisionales antes de actualizar a Azure DevOps Server 2022. Consulte la página Instalar para obtener más información.

Azure DevOps Server Fecha de lanzamiento de la versión de parche 3: 14 de abril de 2026

Hemos publicado Patch 3 para que Azure DevOps Server incluya lo siguiente:

• Se ha corregido un problema por el que se podía producir un error al completar una solicitud de incorporación de cambios debido a una excepción de referencia nula durante la finalización automática del elemento de trabajo.
• Se ha mejorado la validación durante el cierre de sesión para evitar posibles redirecciones malintencionadas.
• Se ha corregido la creación de una conexión PAT a GitHub Enterprise Server.

Fecha de lanzamiento del parche 2 de Azure DevOps Server: 13 de marzo de 2026

Hemos publicado Patch 2 para que Azure DevOps Server incluya lo siguiente:

Esta revisión resuelve un problema introducido en la versión original de Azure DevOps Server que, en determinadas condiciones, podría hacer que las pertenencias a grupos se desactivarán. Para obtener más información relacionada con el problema, consulte la entrada de blog actualizada.

¿Quién debe instalar esta revisión?

Esta revisión se aplica a los clientes que instalaron Azure DevOps Server antes de la nueva publicación del 13 de marzo de 2026. Si anteriormente aplicó la mitigación descrita en instrucciones anteriores, la instalación de Patch 2 completa la corrección. Los clientes que no han ejecutado el script de mitigación no necesitan hacerlo, instalar patch 2 es suficiente.

¿Quién no necesita este parche?

Los clientes que realizan nuevas instalaciones o actualizaciones mediante la versión republicada disponible a partir del 13 de marzo de 2026.

Azure DevOps Server Fecha de lanzamiento del parche 1: 10 de febrero de 2026

Hemos publicado Patch 1 para que Azure DevOps Server incluya lo siguiente:

• Redirección de direcciones URL deshabilitadas cuando una conexión de servicio especifica un parámetro de dirección URL de bigote vacío.
• Deshabilitada la capacidad de usar un PAT con la API EndpointProxy cuando se especifica un EndpointId interno.
• Se ha corregido un problema por el que una actualización local a Azure DevOps Server 25H2 podía producir un error si no se configuró un certificado TLS en la instancia de SQL Server.
• Se ha corregido un problema que provocaba que los pasos de ejecución de pruebas web se interrumpiran después de pausar y reanudar la ejecución.

Azure DevOps Server fecha de lanzamiento: 9 de diciembre de 2025

Azure DevOps Server RTW es una compilación de correcciones de errores y cambios para dar soporte a SQL Server 2025. Incluye todas las características de la Azure DevOps Server RC publicadas anteriormente.

Puede instalar directamente Azure DevOps Server o actualizar desde Azure DevOps Server 2022, 2020, 2019 o Team Foundation Server 2015 o versiones posteriores.

Resumen de las novedades de Azure DevOps Server RTW

• Cambios de localización combinados.
• Cambios en apoyo a SQL Server 2025.
• Se ha corregido un problema por el que los nombres largos de repositorio o rama superaban el control de lista desplegable en la configuración del widget icono de código en la página Paneles.
• Se ha corregido un problema donde el estado del PR en GitHub se guardaba incorrectamente como Cerrado para las solicitudes de incorporación de cambios fusionadas y no fusionadas al usar webhooks. El sistema ahora se basa en el indicador booleano combinado de la carga útil del webhook para registrar con precisión el estado correcto en la base de datos.
• Se ha corregido un problema de propiedad recursiva que provocaba que Visual Studio se bloqueara durante escenarios de vinculación de seguimiento de elementos de trabajo (WIT).
• Se ha resuelto un problema por el que la página Grupo de agentes en Configuración de recopilación produjo un error y no se pudo cargar cuando Analytics estaba en pausa o deshabilitado. La página ahora se carga correctamente independientemente del estado de Analytics.

fecha de lanzamiento de Azure DevOps Server RC: 7 de octubre de 2025

Resumen de las novedades de Azure DevOps Server RC

Azure DevOps Server presenta características que hemos publicado anteriormente en nuestra versión hospedada del producto. Puede ir a secciones individuales para ver todas las nuevas características de cada servicio:

• General
• Paneles
• Repos
• Pipelines
• Planes de prueba
• Informes
• Wiki

General

Copiar bloque de código al portapapeles

En respuesta a sus comentarios en la comunidad de desarrolladores, hemos introducido un botón Copiar al portapapeles para todos los bloques de código en markdown procesado. Esta mejora está disponible en páginas wiki, vistas previas de archivos markdown en Repos, discusiones y descripciones de solicitudes de incorporación de cambios y discusiones de elementos de trabajo.

Se ha agregado el permiso de planes de entrega

Como parte de nuestras mejoras de seguridad en curso, hemos introducido un nuevo permiso para la gestión de planes de entrega a nivel de proyecto. Este cambio se implementó para evitar el acceso de lectura y escritura no intencionada para los usuarios del grupo Lectores.

Boards

Vínculos de AB# en pull requests de GitHub

Como parte de nuestras mejoras continuas en la integración de Azure Boards + GitHub, nos complace introducir una nueva característica que simplifica cómo se muestran los vínculos AB#. Con esta actualización, los vínculos AB# ahora aparecen directamente en la sección de Desarrollo de las solicitudes de incorporación de cambios de GitHub, lo que facilita el acceso a los elementos de trabajo vinculados sin buscar ni en descripciones ni en comentarios.

Estos enlaces solo aparecerán cuando AB# se incluya en la descripción del pull request. Si enlaza directamente desde un elemento de trabajo, no se mostrarán en la sección de Desarrollo. Además, al quitar el vínculo AB# de la descripción, se quita del control de Desarrollo.

Conectar con las mejoras en la búsqueda de repositorios de GitHub

Hemos mejorado el proceso para conectar un proyecto de Azure DevOps a una organización GitHub, especialmente beneficioso para aquellos con miles de repositorios. Anteriormente, podría haber enfrentado desafíos como errores de tiempo de espera y tiempos de espera prolongados. Esta actualización optimiza la experiencia de búsqueda y selección, lo que elimina el riesgo de errores de tiempo de espera y hace que el proceso de conexión sea más suave y eficaz.

Integración de GitHub: mostrar el estado de compilado de las canalizaciones YAML

Nos comprometemos a lograr la paridad de características entre YAML y canalizaciones clásicas. Una característica clave que falta era la capacidad de proporcionar un vínculo "Integrado en la compilación" cuando el repositorio se hospeda en GitHub. Con nuestra versión más reciente, hemos solucionado esta brecha agregando una opción en la configuración de canalización de YAML para que compruebe lo siguiente:

Una vez completada la compilación, el vínculo correspondiente aparecerá automáticamente en los elementos de trabajo asociados, mejorando la historia general de rastreabilidad.

Compatibilidad con la API REST para conectar repositorios de GitHub

Estamos introduciendo nuevos puntos de conexión de API REST que le permiten automatizar la adición y eliminación de repositorios de GitHub en los proyectos de Azure DevOps. Además, hemos aumentado el límite de repositorio por conexión de 500 a 2000 al usar estos puntos de conexión.

Estos puntos de conexión incluyen lo siguiente:

• Enumeración de las conexiones actuales
• Enumeración de repositorios conectados
• Adición y eliminación de repositorios

También hemos proporcionado código de ejemplo para ayudarle a empezar.

Cambio para eliminar rutas de acceso de área e iteración

Eliminar un área o una ruta de iteración puede interrumpir el funcionamiento. Puede mover elementos de trabajo a una nueva ruta de acceso y puede hacer que los equipos pierdan acceso a sus paneles y trabajos pendientes. A pesar de las advertencias y las indicaciones, las rutas de acceso a veces se eliminan sin comprender completamente las consecuencias. Para solucionar esto, hemos cambiado el comportamiento: las rutas de acceso de área e iteración ahora solo se pueden eliminar si ya no las usan los elementos de trabajo.

Administración mejorada de etiquetas en el formulario de elemento de trabajo

La administración de etiquetas en Azure Boards se ha mejorado para proporcionar una experiencia más simplificada. Las etiquetas eliminadas ya no aparecen en la lista sugerida en los formularios de elementos de trabajo, lo que garantiza que solo se muestran las etiquetas activas.

Compatibilidad mejorada con imágenes en comentarios de elementos de trabajo

Hemos mejorado nuestro soporte para pegar imágenes en comentarios de elementos de trabajo. Ahora puede pegar imágenes directamente desde orígenes como Microsoft Teams, correos electrónicos y documentos de Word en la sección de discusión de un elemento de trabajo.

Límite de comentarios de elementos de trabajo en la API REST

Para mejorar la seguridad, se ha establecido un nuevo límite en el número de comentarios que se pueden agregar a los elementos de trabajo a través de la API REST. Cada elemento de trabajo ahora admite un máximo de 1000 comentarios a través de la API. Esta restricción se aplica únicamente a la API REST y los usuarios pueden agregar comentarios manualmente a través de la interfaz web, incluso más allá del umbral de 1000 comentarios.

Aumento del límite de planes de entrega

Hemos aumentado el número máximo de planes de entrega por proyecto de 1000 a 1500.

Repos

Nueva configuración para deshabilitar la creación de repositorios TFVC

En los últimos años, no se agregaron nuevas características al control de versiones de Team Foundation (TFVC) porque Git se ha convertido en el sistema de control de versiones preferido en Azure Repos. Todas las mejoras recientes en seguridad, rendimiento y accesibilidad se han realizado exclusivamente en repositorios de Git, lo que provoca un descenso continuo del uso de TFVC. Aunque algunos siguen confiando en TFVC y no pretendemos quitar este conjunto de características, planeamos eliminar gradualmente TFVC para nuevos proyectos y colecciones de proyectos, así como para proyectos que actualmente no usan TFVC.

Como parte de esta transición, vamos a introducir una nueva configuración en "Deshabilitar la creación de repositorios tfVC", que solo afectará a la creación de nuevos repositorios tfVC y no afectará a las existentes.

Soporte de la interfaz de usuario para submódulos de Git

Muchos equipos usan activamente submódulos de Git para organizar su código base. Nos complace compartir que hemos agregado compatibilidad con submódulos de Git en el centro de archivos. Ahora puede acceder inmediatamente a un repositorio de submódulos con un solo clic, directamente al commit específico referenciado desde su superproyecto. Cuando se usa como submódulo, se admiten los siguientes servicios de Git: Azure Repos, GitHub, GitLab y Bitbucket. También se admiten varios formatos de dirección URL especificados en el archivo .gitmodules, incluidas las direcciones URL HTTPS absolutas, SSH y relativas.

Nuevo panel "Estado y uso" en el concentrador de archivos del repositorio

A medida que crecen los repositorios de Git, acumulan confirmaciones, blobs y otros datos, lo que puede aumentar la carga en Azure DevOps infraestructura, lo que afecta al rendimiento y a la experiencia del usuario. Mantener un repositorio correcto es fundamental para garantizar un rendimiento y confiabilidad coherentes.

Para respaldar esto, ahora se supervisan varios factores, como el tamaño del repositorio, la frecuencia de confirmaciones, los contenidos y la estructura. Si el repositorio comienza a sobrecargar la infraestructura, puede recibir una notificación con recomendaciones para la acción correctiva. Al administrar el estado del repositorio, puede evitar interrupciones y garantizar operaciones sin problemas.

Para comprobar el estado del repositorio, vaya a Azure Repos, > Archivos y elija "Mantenimiento y uso" en el menú de puntos suspensivos para acceder al panel Estado y uso del repositorio.

Configurar ramas de destino personalizadas para pull requests

La administración de varias ramas en un repositorio puede ser difícil, especialmente al crear nuevos pull requests. Con la nueva característica Configurar ramas de destino para solicitudes de incorporación de cambios, ahora puede especificar una lista de ramas de destino preferidas, lo que garantiza que las sugerencias de solicitud de incorporación de cambios sean más precisas y pertinentes. Esto ayuda a simplificar el flujo de trabajo y reduce las posibilidades de dirigirse a la rama incorrecta. Para usar esta característica, cree un archivo .azuredevops/pull_request_targets.yml en la rama predeterminada del repositorio. Este archivo YAML debe contener una lista titulada pull_request_targets con los nombres o prefijos de rama que coinciden con las ramas candidatas. Por ejemplo:

pull_request_targets:
  - main
  - release/*
  - feature/*

En esta configuración, la rama principal tiene prioridad, pero las ramas que comienzan por release/ o feature/ también se considerarán cuando corresponda. La configuración se aplica en los escenarios siguientes:

• Sugerencias de solicitud de incorporación de cambios: después de insertar una rama en Azure DevOps, la página de Repos puede sugerir la creación de una solicitud de incorporación de cambios desde esa rama, eligiendo dinámicamente la rama de destino.
• Dirección URL de la solicitud de extracción: Al navegar directamente a la página de creación de solicitudes de extracción utilizando un parámetro sourceRef, pero omitiendo el parámetro targetRef, Azure DevOps selecciona dinámicamente una rama de destino.

Se recomienda incluir solo ramas protegidas por directivas de solicitud de incorporación de cambios para garantizar la coherencia en el primer historial primario de la confirmación de propina.

Soporte para diagramas de sirena en el archivo Markdown

Los archivos Markdown que contienen sintaxis de Mermaid se representarán ahora como diagramas en las vistas previas de archivos en el explorador de archivos de repositorios y en los pull requests. Esto puede ayudarle a agregar documentación más completa a los repositorios.

Buscar solicitudes de incorporación de cambios por título en la página de lista de solicitudes de incorporación de cambios

La página de lista de solicitudes de incorporación de cambios ahora incluye un filtro por título de solicitud de incorporación de cambios, lo que facilita la búsqueda de solicitudes de incorporación de cambios específicas.

Configuración dispersa para Azure Repos

El comando git sparse-checkout ahora se admite en la tarea de desprotección de YAML, junto con el filtro de clonación parcial, para mejorar el rendimiento de la desprotección del repositorio. Puede usar las propiedades sparseCheckoutDirectories y sparseCheckoutPatterns.

Establecer sparseCheckoutDirectories habilita el modo cono, donde el proceso de extracción usa la coincidencia de directorios. Como alternativa, puede establecer sparseCheckoutPatterns que desencadena el modo no cono, lo que permite la coincidencia de patrones más compleja.

Si se establecen ambas propiedades, el agente inicializa el modo cono con la coincidencia de directorios. Si no se especifica ninguna propiedad en la tarea de desprotección, el proceso de desprotección dispersa está deshabilitado. Los problemas encontrados durante la ejecución del comando provocan que falle la tarea de verificación. Ejemplo de YAML para el modo de cono de desprotección dispersa:

    checkout: repo
    sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAMLCopy

   checkout: repo
   sparseCheckoutPatterns: /* !/img 

Puede encontrar el agente en la página de versiones.

Hacer que las políticas entre repositorios distingan mayúsculas de minúsculas

Anteriormente, la vista previa del candidato de rama para las directivas entre repositorios mostraba resultados que no distinguían mayúsculas de minúsculas, a pesar de que la coincidencia de ramas distinguía mayúsculas de minúsculas. Esta incoherencia creó una posible desalineación, ya que podría parecer que ciertas ramas estaban protegidas cuando no lo eran. Para resolver este problema, hemos actualizado la vista previa del patrón de rama para ajustarlo al comportamiento que distingue mayúsculas de minúsculas de la aplicación de directivas.

Previamente:

After:

Cambios en las políticas de registro de TFVC

Nueva versión (19.254) del paquete NuGet Microsoft.TeamFoundationServer.ExtendedClient

El paquete de NuGet Microsoft.TeamFoundationServer.ExtendedClient se actualizó con nuevas clases y métodos de políticas de TFVC.

Cambios de directiva

Estamos realizando cambios en cómo se almacenan las directivas de check-in de TFVC en Azure DevOps, lo que también significa actualizaciones en cómo el cliente NuGet Microsoft.TeamFoundationServer.ExtendedClient se comunica con el servicio. Si el proyecto de TFVC utiliza políticas de check-in, migre esas políticas al nuevo formato. Hay dos maneras de hacerlo:

1. Uso de Visual Studio.

Advertencia

Consecuencias peligrosas de una acción. Asegúrese de actualizar Visual Studio a la versión más reciente antes de continuar (VS 2022, VS 2019 y VS 2017 con versiones mínimas 17.14 Preview 3, 17.13.6, 17.12.7, 17.10.13, 17.8.20, 16.11.46, 15.9.72 admiten las nuevas directivas).

Para crear nuevas directivas con Visual Studio project administrador debe abrir Settings -> Team Project -> Source Control -> Check-in Policy y agregar una nueva directiva (sin la marca "Obsoleta") con los mismos parámetros que los antiguos:

2. Si está utilizando una implementación personalizada de Microsoft.TeamFoundationServer.ExtendedClient para comunicarse con el servidor, siga la guía de migración . La migración es necesaria para mantener la compatibilidad de la confirmación de TFVC con las versiones futuras de Azure DevOps. Por el momento, tanto las directivas antiguas (obsoletas) como las nuevas siguen siendo válidas y funcionales. Para obtener información sobre los planes futuros, consulte nuestra entrada de blog.

Mejora de getRepository API

Hemos agregado la propiedad creationDate a la respuesta de Repository - Get Repository API que devuelve la fecha de creación del repositorio. La propiedad está disponible en las versiones 7.2-preview y posteriores de la API.

Mejora de la API de consulta de Solicitudes de incorporación de cambios

Hemos introducido una nueva propiedad Label en la respuesta de la consulta de Solicitud de Extracción - API Get. Ahora puede especificar si se deben incluir etiquetas para los pull requests relacionados en cada consulta. Hay disponible una nueva propiedad Include: si se establece en Etiquetas, la respuesta incluye etiquetas para las solicitudes de incorporación de cambios especificadas. Si se deja como null, las etiquetas no se incluirán. Para evitar errores no deseados, asegúrese de que NotSet no está asignado explícitamente; esto dará como resultado una solicitud incorrecta.

Ejemplo de carga de solicitud:

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Tuberías

TFX valida si una tarea usa un ejecutor de nodo de fin de ciclo de vida

Los autores de tareas usan TFX para publicar extensiones. TFX se ha actualizado para realizar validaciones en otras versiones del ejecutor de Node.

Las extensiones que contienen tareas que usan una versión del ejecutor de Node que es final de ciclo de vida (EOL) (hasta el nodo 16) verán esta advertencia:

La tarea < TaskName > depende de un motor de tareas que está al final de su ciclo de vida y se eliminará en el futuro. Los autores deben revisar la guía de actualización del nodo: https://aka.ms/node-runner-guidance

Acceso a Azure Service Bus desde canalizaciones mediante la autenticación de Microsoft Entra ID

Ahora puede usar autenticación de Microsoft Entra ID para acceder a Azure Service Bus desde Azure Pipelines. Esto le permite aprovechar Azure RBAC para el control de acceso específico.

Las identidades que acceden a Azure Service Bus deben recibir uno de los roles predefinidos de Azure para Azure Service Bus en el servicio de mensajería al que tienen acceso.

tarea de PublishToAzureServiceBus@2

Las nuevas tareas de PublishToAzureServiceBus@2 se pueden configurar mediante una conexión de servicio Azure. Cree una conexión de servicio Azure y rellene las propiedades serviceBusQueueName y serviceBusNamespace de la nueva tarea:

- task: PublishToAzureServiceBus@2
  inputs:
    azureSubscription: my-azure-service-connection
    serviceBusQueueName: my-service-bus-queue
    serviceBusNamespace: my-service-bus-namespace
    useDataContractSerializer: false
    messageBody: |
      {
        "foo": "bar"
      }

Tareas del servidor

Las tareas de servidor personalizado (sin agente) que usan la ejecución de ServiceBus pueden especificar una conexión de servicio Azure como EndpointId y omitir ConnectionString. Consulte Creación de tareas de servidor.

TFX valida si una tarea usa un ejecutor de nodo de fin de ciclo de vida

Los autores de tareas usan TFX para publicar extensiones. TFX se ha actualizado para realizar validaciones en otras versiones del ejecutor de Node.

Las extensiones que contienen tareas que usan una versión del ejecutor de Node que es final de ciclo de vida (EOL) (hasta el nodo 16) verán esta advertencia:

La tarea < TaskName > depende de un motor de tareas que está al final de su ciclo de vida y se eliminará en el futuro. Los autores deben revisar la guía de actualización del nodo: https://aka.ms/node-runner-guidance

Tareas que usan una versión final del ejecutor de Nodo para ejecutar advertencias

Las tareas de canalización que dependen de una versión de Node que ya no tienen soporte comenzarán a recibir advertencias: la versión TaskName de la tarea depende de una versión de Node (10) que ha llegado al final de su vida útil. Póngase en contacto con el propietario de la extensión para obtener una versión actualizada de la tarea. Los mantenedores de tareas deben revisar la guía de actualización de Node: https://aka.ms/node-runner-guidance Para suprimir estas advertencias, puede establecer una variable de entorno o de canalización a nivel de pipeline (trabajo) o de tarea. Por ejemplo:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 usa Docker Compose v2 en modo de compatibilidad v1

Docker Compose v1 llegará al fin de su ciclo de vida y se quitará de los agentes hospedados el 24 de julio de 2024. Hemos actualizado la tarea DockerCompose@0 para usar Docker Compose v2 en modo de compatibilidad v1 si Docker Compose v1 no está disponible en el agente.

Sin embargo, el modo de compatibilidad no aborda todos los problemas de compatibilidad. Véase Migración a Compose V2. Algunos usuarios necesitarán más tiempo para actualizar sus proyectos de Docker Compose para la compatibilidad con Docker Compose v2. En esos casos, siga estas instrucciones para usar la tarea DockerComposeV0 con docker-compose v1. NOTA: Esta guía se basa en la documentación independiente de Install Compose. Utilice docker-compose v1 en Windows. Añada el paso de powershell a su flujo de trabajo para descargar docker-compose v1.29.2 y úselo con la tarea DockerComposeV0 en Windows.

variables:
    dockerComposePath: C:\docker-compose

steps:
- powershell: |
    mkdir -f $(dockerComposePath)
    # GitHub now requires TLS1.2. In PowerShell, run the following
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: '**/docker-compose.yml'
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)\docker-compose.exe
Use docker-compose v1 on Linux
Add the bash step to your pipeline to download Docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Linux:
YAMLCopy
variables:
    dockerComposePath: /tmp/docker-compose

steps:
- bash: |
    sudo mkdir $(dockerComposePath)
    sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
    sudo chmod 755 $(dockerComposePath)/docker-compose
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)/docker-compose

Planes de prueba

Extensión Test and Feedback en Manifest V3

Nos complace anunciar una nueva actualización de la extensión de prueba y comentarios de Azure DevOps para Chrome y Edge. Esta actualización realiza la transición de la implementación de Manifest V2 a Manifest V3, en línea con el cronograma de retirada de Google para Manifest V2. Aunque las características principales de la extensión permanecen sin cambios, la actualización mejora tanto la seguridad como el rendimiento.

Para obtener más información, consulte nuestra entrada de blog reciente sobre esta actualización. Extensión Test & Feedback en Manifiesto V3

Azure ejecutor de pruebas, versión 1.2.2

Azure Test Plans publicó una corrección en la versión 1.2.2 para un problema reciente en Test Plans en el que Azure Test Runner (ATR) experimentó errores de inicio en la versión 130 de Chrome. Este problema se produjo debido a la nueva compatibilidad proporcionada por Chrome para las direcciones URL de esquema no especiales, lo que afectó al flujo de usuario de ATR. Con esta actualización, se resuelve el error de regresión y se restaura la funcionalidad ATR. Para obtener más información sobre este error de regresión, visite este seguimiento de problemas en Chromium.

Le recomendamos que use la aplicación web para características mejoradas. Si encuentra alguna característica que falta en la aplicación web, nos encantaría escuchar de usted. ¡Comparta sus comentarios con nosotros!

Integración de canalización de compilación sin problemas para la ejecución de casos de prueba

Hemos simplificado el proceso de ejecución de casos de prueba mediante la integración perfecta de configuraciones de canalización de compilación. Las definiciones de compilación e identificadores establecidos en el nivel de plan de prueba ahora se propagan automáticamente al ejecutor web, lo que elimina la necesidad de configuración manual cada vez. Esta mejora ahorra tiempo y mejora la eficacia, lo que le permite centrarse en tareas más críticas.

Restauración de planes de prueba eliminados y conjuntos de pruebas mediante la API REST

Restaure fácilmente los planes de prueba eliminados y los conjuntos de pruebas con nuevas API de autoservicio. Presentamos las API GET y PATCH que permiten buscar planes de prueba eliminados o conjuntos de pruebas eliminados y restaurarlos junto con sus elementos secundarios, todo sin necesidad de asistencia al cliente. Con estas API, puede recuperar rápidamente los elementos de trabajo de prueba eliminados accidentalmente, lo que reduce el tiempo de inactividad y mejora la productividad. Aunque los artefactos de ejecución no se restaurarán, todos los planes de prueba, conjuntos y casos de prueba relacionados se pueden devolver al área de trabajo con facilidad. Esta característica de autoservicio proporciona un mayor control sobre la administración de pruebas y simplifica el proceso de restauración, lo que hace que sea más rápido y eficaz para recuperar recursos de prueba críticos.

Exportación de casos de prueba con columnas personalizadas en XLSX

Ahora puede exportar casos de prueba con columnas personalizadas en XLSX. Basado en sus comentarios, Test Plans admite la exportación de casos de prueba con columnas personalizadas, ofreciéndole una mayor flexibilidad y control sobre los datos que comparte y analiza. Esta mejora le ayuda a adaptar las exportaciones a sus necesidades, lo que garantiza que la información que exporte sea relevante y procesable.

Nuevas funcionalidades de ordenación en el directorio Planes de prueba

El directorio Planes de prueba ahora ofrece opciones de ordenación mejoradas. Con esta actualización, puede organizar rápidamente cada columna de forma alfanumérica, lo que proporciona una manera simplificada de buscar y acceder a los datos.

Deshacer paso de prueba en el ejecutor web y de escritorio

Tome el control de la ejecución del caso de prueba con la nueva opción "Deshacer". Puede revertir fácilmente los estados de los pasos de prueba con un simple doble clic, lo que proporciona más flexibilidad y control durante las ejecuciones de pruebas. No es necesario reiniciar los casos de prueba para solucionar clics accidentales—simplemente deshacer y continuar el flujo de trabajo sin interrumpir.

También presentamos mejoras de accesibilidad y navegación fáciles de usar para garantizar que esta característica funcione sin problemas para todos los usuarios, incluidos aquellos que dependen de tecnologías de asistencia. Esta mejora le ayuda a ahorrar tiempo, reducir la frustración y centrarse en la ejecución de pruebas de forma eficaz.

Mejoras en la tarea v2 de publicar resultados de cobertura de código

Con esta versión se incluyen varias mejoras en la tarea v2:

• Se ha ampliado la compatibilidad con varios formatos de cobertura de código, incluidos: .coverage,.covx,.covb,.cjson,.xml,.lcov y pycov1.

• Generación de un archivo cjson completo (y un informe de cobertura de código) que contiene información detallada de cobertura de código, como nombres de archivo, líneas cubiertas o no cubiertas, etc.

Compatibilidad con la cobertura diferencial (cobertura de PR): v2 puede generar comentarios de cobertura diferencial en solicitudes de incorporación de cambios para varios idiomas dentro del mismo pipeline.

En la tarea v2 ahora se admite la tarea de Comprobación de Calidad de Compilación, que antes no se admitía en la tarea v1.

Compatibilidad con canalizaciones de YAML en planes de prueba

Además de las canalizaciones clásicas, ahora puede usar las canalizaciones de YAML al configurar los planes de prueba o ejecutar pruebas automatizadas desde planes de prueba.

Esta solicitud se ha priorizado en función de los siguientes tickets de sugerencias de la Comunidad de Desarrolladores.

• Permitir el uso de la canalización YAML en la configuración del plan de prueba

• Ejecute las pruebas automatizadas desde Azure Test Plans mediante canalización YAML

Generación de informes

Datos de columnas consolidadas disponibles en el backlog

Hemos actualizado las columnas de resumen para mostrar los datos más recientes disponibles. Anteriormente, estas columnas podían aparecer en blanco para los elementos de trabajo actualizados con frecuencia, lo que provocaba confusión. También verá una marca de tiempo que indica cuándo se actualizaron los datos por última vez. Aunque cierto retraso en el procesamiento de Analytics es normal, estas mejoras tienen como objetivo proporcionar transparencia y una experiencia más fluida al trabajar con columnas de resumen.

Wiki

Mejora del pegado de contenido basado en HTML en wikis

Hemos hecho que sea más fácil pegar contenido basado en HTML en wikis. Ahora, los elementos HTML, como vínculos, listas, tablas, imágenes, Excel hojas, mensajes Microsoft Teams, correos electrónicos y consultas de Azure Data Explorer se convierten automáticamente en la sintaxis de Markdown para una edición más fluida.