Notas de la versión de Azure DevOps Server 2022 Update 2
| Requisitos del sistema de la Comunidad | de desarrolladores y términos | de licencia de compatibilidad | DevOps Blog | SHA-256 Hashes |
En este artículo encontrará información sobre la versión más reciente de Azure DevOps Server.
Para más información sobre cómo instalar o actualizar una implementación de Azure DevOps Server, consulte Requisitos de Azure DevOps Server.
Para descargar productos de Azure DevOps Server, visite la página Descargas de Azure DevOps Server.
La actualización directa a Azure DevOps Server 2022 Update 2 es compatible con Azure DevOps Server 2019 o Team Foundation Server 2015 o posterior. 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 2022 Update 2 Patch 2 Release Date: 12 de noviembre de 2024
| Archivo | Hash SHA-256 |
|---|---|
| devops2022.2patch2.exe | 70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23 |
Hemos publicado la revisión 2 para Azure DevOps Server 2022 Update 2 para incluir una actualización a una dependencia vulnerable.
Fecha de lanzamiento de AZURE DevOps Server 2022.2 RTW: 9 de julio de 2024
Resumen de las novedades de Azure DevOps Server 2022.2 RTW
Nota:
Hemos vuelto a publicar Azure DevOps Server 2022.2 para corregir un problema con la carga de nombres de Teams. El problema se notificó en la entrada de blog Azure DevOps Server 2022.2 RTW ahora disponible. Si ha instalado la versión de Azure DevOps Server 2022.2 publicada el 9 de julio, puede instalar la revisión 1 para Azure DevOps Server 2022.2 para corregir el problema. La revisión 1 no es necesaria si va a instalar Azure DevOps Server 2022.2 por primera vez desde que se han actualizado los vínculos de descarga para incluir la corrección.
Azure DevOps Server 2022.2 RTW es una acumulación de correcciones de errores. Incluye todas las características de Azure DevOps Server 2022.2 RC publicadas anteriormente. Puede instalar directamente Azure DevOps Server 2022.2 o actualizar desde Azure DevOps Server 2020, 2019 o Team Foundation Server 2015 o versiones posteriores. Los siguientes problemas y vulnerabilidades se han solucionado con esta versión:
- CVE-2024-35266: Vulnerabilidad de suplantación de identidad de Azure DevOps Server
- CVE-2024-35267: Vulnerabilidad de suplantación de identidad de Azure DevOps Server
- Vale de comentarios de la comunidad de desarrolladores: la versión del agente no se actualiza después de actualizar a Azure DevOps Server 2022.1 y el uso del agente de actualización en la configuración del grupo de agentes
- Incidencia de comentarios de la comunidad de desarrolladores: problema con la carga de la página configuración del equipo
- Vale de comentarios de la Comunidad de desarrolladores: corregir el control de fechas incorrecto en la notificación por correo electrónico de solicitud de incorporación de cambios para determinados formatos regionales
Fecha de lanzamiento de Azure DevOps Server 2022 Update 2 RC: 7 de mayo de 2024
Azure DevOps Server 2022.2 RC incluye muchas características nuevas. Entre los aspectos destacados se incluyen:
- Límites para rutas de acceso de área e iteración
- Omitir aprobaciones y comprobaciones en canalizaciones
- Validación de YAML mejorada
- Compatibilidad de Azure Artifacts con Crates de carga
- Nueva experiencia de directorio del panel
- Copia rápida e importación con el plan de prueba o el identificador del conjunto de aplicaciones
También puede ir a secciones individuales para ver todas las nuevas características de cada servicio:
General
Tarea Publicar resultados de pruebas
La tarea Publicar resultados de pruebas ahora admite datos adjuntos de ejecución de pruebas para el formato de informe JUnit.
Nueva versión del SDK de extensión web de Azure DevOps
Con esta actualización, publicamos una nueva versión del SDK de extensión web de Azure DevOps. El SDK de cliente permite que las extensiones web se comuniquen con el marco de host. Se puede usar para:
- Notificar al host que la extensión se carga o tiene errores
- Obtenga información contextual básica sobre la página actual (información actual de usuario, host e extensión)
- Obtención de información del tema
- Obtención de un token de autorización para usarlo en llamadas REST a Azure DevOps
- Obtención de servicios remotos ofrecidos por el marco de host
Puede encontrar una referencia completa de API en la documentación del paquete azure-devops-extension-sdk. Esta nueva versión proporciona compatibilidad con los siguientes módulos:
Compatibilidad con módulos ES: el SDK ahora admite módulos ES (ECMAScript) además de los módulos AMD (definición de módulo asincrónico) existentes. Ahora puede importar el SDK mediante la sintaxis del módulo ES, que proporciona mejoras de rendimiento y reduce el tamaño de la aplicación.
Compatibilidad con versiones anteriores para módulos AMD: la compatibilidad existente con los módulos AMD permanece intacta. Si el proyecto usa módulos AMD, puede seguir usándolos como antes sin cambios.
Cómo usar:
En el caso de los módulos ES, puede importar nuestros módulos mediante la instrucción import:
import * as SDK from 'azure-devops-extension-sdk';
// Use the module here
Si usa módulos AMD, puede seguir importando el SDK mediante la require función :
require(['azure-devops-extension-sdk'], function(SDK) {
// Use the module here
});
Boards
Límites para rutas de acceso de área e iteración
Los límites desempeñan un papel importante en el mantenimiento y la eficiencia de un servicio global grande. Con esta versión, estamos introduciendo límites estrictos de 10 000 por proyecto para rutas de acceso de área e iteración. Visite la página Límites del proyecto, proceso y seguimiento del trabajo para obtener más información sobre los distintos límites del servicio.
Controles de desarrollo e implementación
Ahora quitamos los controles Desarrollo o Implementación del elemento de trabajo, en función de cómo se configure el proyecto. Por ejemplo, puede configurar los valores del proyecto para desactivar repositorios o canalizaciones.
Al ir al elemento de trabajo, los controles de desarrollo e implementación correspondientes se ocultarán del formulario.
Si decide conectar un repositorio de GitHub a Azure Boards, se mostrará el control de desarrollo para repositorios de GitHub.
Repos
Nueva "Directiva de rama" que impide que los usuarios aprueben sus propios cambios
Para mejorar el control sobre los cambios que el usuario aprueba y coincide con los requisitos normativos y de cumplimiento más estrictos, proporcionamos una opción para evitar que el usuario apruebe sus propios cambios a menos que se permita explícitamente.
El usuario con capacidad para administrar las directivas de rama ahora puede cambiar la opción "Requerir al menos una aprobación en cada iteración" en "Cuando se insertan nuevos cambios". Cuando se selecciona esta opción, se requiere al menos un voto de aprobación para el último cambio de rama de origen. La aprobación del usuario no se contabiliza para ninguna iteración no aprobada anterior insertada por ese usuario. Como resultado, es necesario que otro usuario realice la aprobación adicional en la última iteración.
En la imagen siguiente se muestra la solicitud de incorporación de cambios creada por el usuario A y 4 confirmaciones adicionales (iteraciones) realizadas a esa solicitud de incorporación de cambios por parte de los usuarios B, C, A de nuevo y C. Después de que se haya realizado la segunda iteración (confirmación realizada por el usuario B), el usuario C lo ha aprobado. En ese momento, implicaba la aprobación de la primera confirmación del usuario A (cuando se creó la solicitud de incorporación de cambios) y la directiva recién introducida se realizará correctamente. Después de la quinta iteración (última confirmación del usuario C), el usuario A realizó la aprobación. Esta aprobación implícita para la confirmación anterior realizada por el usuario C, pero no implicaba la aprobación de la segunda confirmación realizada por el usuario A en la cuarta iteración. Para que la directiva recién introducida se realice correctamente, la iteración no aprobada cuatro debe aprobarse mediante la aprobación del usuario B, C o cualquier otro usuario que no haya realizado ningún cambio en la solicitud de incorporación de cambios.
Nota:
Hay un problema conocido por el que las directivas de rama tomarán un grupo, que se configura como revisor, como entidad de aprobación. Imaginemos que hay una aprobación necesaria realizada por cualquier usuario del grupo G. El usuario A es miembro de ese grupo G. Después de que el usuario A proporcione la aprobación como en la imagen anterior (después de la quinta iteración), la aprobación del grupo G aprueba el cambio realizado por el usuario A. Esto no se espera y se resolverá en la versión RTW.
Compatibilidad con blobles y filtros sin árbol
Importante
De forma predeterminada, la característica está deshabilitada. Para habilitar la característica, ejecute la siguiente consulta en Config DB:
exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1
Azure DevOps ahora admite dos filtros adicionales al clonar o capturar. Estos son: --filter=blob:none y --filter=tree:0 La primera opción (clon de blobles) se usa mejor para el desarrollo normal, mientras que la segunda opción (clon sin árbol) se adapta mejor a aquellos casos en los que se descarta el clon después, por ejemplo, la ejecución de una compilación.
Desuso de SSH-RSA
Azure Repos proporciona dos métodos para que los usuarios accedan a un repositorio git en Azure Repos: HTTPS y SSH. Para usar SSH, debe crear un par de claves mediante uno de los métodos de cifrado admitidos. En el pasado, hemos estado admitiendo solo SSH-RSA y hemos pedido a los usuarios que habiliten SSH-RSA aquí.
Con esta actualización, anunciamos el desuso de SSH-RSA como un método de cifrado compatible para conectarse a Azure Repos mediante SSH. Puede ver más detalles en la entrada de blog Fin de la compatibilidad con SSH-RSA para Azure Repos .
Pipelines
Impedir ejecuciones de canalización no deseadas
En la actualidad, si la canalización de YAML no especifica una trigger sección, se ejecuta para los cambios insertados en su repositorio. Esto puede crear confusión sobre por qué se ejecutó una canalización y provocará muchas ejecuciones no deseadas.
Se ha agregado una configuración de canalizaciones de nivel de proyecto y colección de proyectos denominada Deshabilitar desencadenador de CI DE YAML implícito que le permite cambiar este comportamiento. Puede optar por no desencadenar canalizaciones si falta su sección de desencadenador.
Reintentar una fase cuando se agotan las aprobaciones y se comprueba el tiempo de espera.
Cuando se agota el tiempo de espera de aprobaciones y comprobaciones, se omite la fase a la que pertenecen. Las fases que tienen una dependencia de la fase omitida también se omiten.
Ahora puede volver a intentar una fase cuando las aprobaciones y comprueban el tiempo de espera. Anteriormente, esto solo era posible cuando se agotó el tiempo de espera de una aprobación.
Omitir aprobaciones y comprobaciones
Las aprobaciones y comprobaciones ayudan a proteger el acceso a recursos importantes, como conexiones de servicio, repositorios o grupos de agentes. Un caso de uso común es usar aprobaciones y comprobaciones al implementar en producción y desea proteger la conexión del servicio ARM.
Supongamos que ha agregado las siguientes comprobaciones en la conexión de servicio: aprobación, comprobación de horas laborables e invocación de funciones de Azure (para aplicar un retraso entre regiones diferentes).
Ahora, imagine que tiene que realizar una implementación de revisiones. Inicia una ejecución de canalización, pero no continúa, espera a que se completen la mayoría de las comprobaciones. No puede permitirse esperar a que se completen las aprobaciones y comprobaciones.
Con esta versión hemos hecho posible omitir las aprobaciones y comprobaciones en ejecución, por lo que puede completar la revisión.
Puede omitir la ejecución de aprobaciones, horas laborables, invocar funciones de Azure e invocar comprobaciones de la API REST.
Omitir una aprobación.
Omitir la comprobación del horario comercial.
Omitir invocar la comprobación de funciones de Azure. Omitir la comprobación del horario comercial.
Cuando se omite una comprobación, puede verla en el panel de comprobaciones.
Solo puede omitir una comprobación si es administrador del recurso en el que se definieron las comprobaciones.
Volver a ejecutar la invocación de comprobaciones de funciones de Azure
Imagine que implementa el sistema en varias fases. Antes de implementar la segunda fase, hay una comprobación de aprobación e invocación de funciones de Azure que ejecuta una comprobación de integridad en la parte ya implementada del sistema.
Al revisar la solicitud de aprobación, observe que la comprobación de integridad se ejecutó dos días antes. En este escenario, es posible que tenga en cuenta otra implementación que afecta al resultado de la comprobación de integridad.
Con esta actualización, puede volver a ejecutar Invocar función de Azure e invocar comprobaciones de la API REST. Esta funcionalidad solo está disponible para las comprobaciones que se realizaron correctamente y no tienen reintentos.
Nota:
Solo puede volver a ejecutar una comprobación si es administrador del recurso en el que se definieron las comprobaciones.
Compatibilidad con el servidor de GitHub Enterprise en la comprobación de plantilla necesaria
Las plantillas son un mecanismo de seguridad que permite controlar las fases, los trabajos y los pasos de las canalizaciones de la colección de proyectos.
La comprobación requerir plantilla le permite exigir que una canalización se extienda desde un conjunto de plantillas aprobadas antes de acceder a un recurso protegido, como un grupo de agentes o una conexión de servicio.
Ahora puede especificar plantillas ubicadas en repositorios de GitHub Enterprise Server.
Rol de administrador para todos los entornos
Los entornos de las canalizaciones YAML representan un recurso de proceso en el que se implementa la aplicación, por ejemplo, un clúster de AKS o un conjunto de máquinas virtuales. Proporcionan controles de seguridad y rastreabilidad para las implementaciones.
La administración de entornos puede ser bastante difícil. Esto se debe a que, cuando se crea un entorno, la persona que lo crea se convierte automáticamente en el único administrador. Por ejemplo, si desea administrar las aprobaciones y comprobaciones de todos los entornos de forma centralizada, debe pedir a cada administrador de entorno que agregue un usuario o grupo específico como administrador y, a continuación, use la API REST para configurar las comprobaciones. Este enfoque es tedioso, propenso a errores y no se escala cuando se agregan nuevos entornos.
Con esta versión, se ha agregado un rol de administrador en el nivel de centro de entornos. Esto hace que los entornos se analicen con conexiones de servicio o grupos de agentes. Para asignar el rol Administrador a un usuario o grupo, ya debe ser un administrador de environments-hub o propietario de la colección de proyectos.
Un usuario con este rol de administrador puede administrar permisos, administrar, ver y usar cualquier entorno. Esto incluye la apertura de entornos a todas las canalizaciones.
Cuando se concede un rol de administrador de usuario en el nivel de centro de entornos, se convierten en administradores para todos los entornos existentes y para cualquier entorno futuro.
Validación de YAML mejorada
Para comprobar que la sintaxis de YAML es correcta, puede usar la funcionalidad Validate del editor web de Azure Pipelines. Por lo tanto, es importante que esta funcionalidad capture tantos problemas de YAML como sea posible.
La validación de YAML ahora es más exhaustiva cuando se trata de expresiones.
Al escribir canalizaciones YAML, puede usar funciones para definir valores de variable.
Imagine que define las siguientes variables:
variables:
Major: '1'
Minor: '0'
Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]
La Patch variable se define mediante la counter función y las otras dos variables. En el código YAML anterior, la palabra format está mal escrita. Anteriormente, este error no se detectó. Ahora, la funcionalidad Validar detectará esto y mostrará un mensaje de error.
Azure Pipelines detectará definiciones de variables incorrectas en el nivel de canalización, fase o trabajo.
En las canalizaciones de YAML, puede omitir la ejecución de la fase mediante condiciones. Los errores tipográficos también se pueden mostrar aquí, como en el ejemplo siguiente.
steps:
- task: NuGetCommand@2
condition: eq(variable.Patch, 0)
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'
La NuGetCommand tarea solo se ejecuta si el valor de la Patch variable es 0. De nuevo, hay un error tipográfico en la condición y la funcionalidad Validar la mostrará.
Azure Pipelines detectará condiciones YAML incorrectas definidas en el nivel de canalización, fase o trabajo.
API REST para entornos
Un entorno es una colección de recursos que puede tener como destino las implementaciones desde una canalización. Los entornos proporcionan historial de implementación, rastreabilidad para elementos de trabajo y confirmaciones y mecanismos de control de acceso.
Sabemos que desea crear entornos mediante programación, por lo que hemos publicado documentación para su API REST.
Mejoras en la API REST de aprobaciones
Hemos mejorado la búsqueda de aprobaciones asignadas a un usuario mediante la inclusión de los grupos a los que pertenece el usuario en los resultados de búsqueda.
Las aprobaciones ahora contienen información sobre la ejecución de canalización a la que pertenecen.
Por ejemplo, la siguiente llamada a https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending la API REST GET devuelve
{
"count": 1,
"value":
[
{
"id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
"steps":
[],
"status": "pending",
"createdOn": "2023-11-09T10:54:37.977Z",
"lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers":
[],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
}
},
"pipeline":
{
"owner":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
},
"self":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
}
},
"id": 73222930,
"name": "20231109.1"
},
"id": "4597",
"name": "FabrikamFiber"
}
}
]
}
Los registros de canalización ahora contienen uso de recursos
Los registros de canalización de Azure ahora pueden capturar métricas de uso de recursos, como memoria, uso de CPU y espacio en disco disponible. Los registros también incluyen recursos usados por el agente de canalización y los procesos secundarios, incluidas las tareas que se ejecutan en un trabajo.
Si sospecha que el trabajo de canalización puede encontrarse con restricciones de recursos, habilite los registros detallados para que se inserte información de uso de recursos en los registros de canalización. Esto funciona en cualquier agente, independientemente del modelo de hospedaje.
El agente de Azure Pipelines ahora admite Alpine Linux
El agente de canalización v3.227 ahora admite las versiones 3.13 y posteriores de Alpine Linux . Alpine Linux es una imagen popular para contenedores (base). Puede encontrar el agente en la página de versiones . Las versiones de Alpine Linux del agente tienen un prefijo vsts-agent-linux-musl , por ejemplo, vsts-agent-linux-musl-x64-3.227.1.tar.gz.
Las tareas de Azure Pipelines usan el nodo 16
Las tareas de la canalización se ejecutan mediante un ejecutor, con Node.js se usan en la mayoría de los casos. Las tareas de Azure Pipelines que usan un nodo como ejecutor ahora usan el nodo 16. Como Node 16 es la primera versión de Node para admitir de forma nativa apple silicon, esto también completa la compatibilidad con tareas completas para macOS en apple silicon. Los agentes que se ejecutan en apple silicon no necesitan Rosetta para ejecutarse.
A medida que la fecha de fin de ciclo de vida del nodo 16 se ha movido, hemos iniciado el trabajo para ejecutar tareas con Node 20.
Se han aumentado los límites de Azure Pipeline para alinearse con el tamaño máximo de plantilla de Azure Resource Manager (ARM) de 4 MB.
Puede usar la tarea Implementación de plantillas de Azure Resource Manager para crear una infraestructura de Azure. En respuesta a los comentarios, hemos aumentado el límite de integración de Azure Pipelines de 2 MB a 4 MB. Esto se alineará con el tamaño máximo de las plantillas de ARM de 4 MB resolviendo restricciones de tamaño durante la integración de plantillas grandes.
La tarea AzureRmWebAppDeployment admite la autenticación de Identificador de Entra de Microsoft
Las tareas AzureRmWebAppDeploymentV3 y AzureRmWebAppDeployment@4 se han actualizado para admitir App Service con la autenticación básica deshabilitada. Si la autenticación básica está deshabilitada en App Service, las tareas azureRmWebAppDeploymentV3/4 usan la autenticación de Id. de Microsoft Entra para realizar implementaciones en el punto de conexión de Kudu de App Service. Esto requiere una versión reciente de msdeploy.exe instalada en el agente, que es el caso en los agentes hospedados windows-2022/windows-latest (consulte la referencia de tareas).
Invalidación deshabilitada del estado de la directiva de cobertura de código en Error cuando se produce un error en la compilación
Anteriormente, el estado de la directiva de cobertura de código se invalidaba en "Failed" si se produjo un error en la compilación en la solicitud de incorporación de cambios. Esto fue un bloqueador para algunos de ustedes que tenían la compilación como una comprobación opcional y la directiva de cobertura de código como una comprobación necesaria para las solicitudes de incorporación de cambios, lo que da lugar a que se bloqueen las solicitudes de incorporación de cambios.
Ahora, la directiva de cobertura de código no se invalidará en "Failed" si se produce un error en la compilación. Esta característica se habilitará para todos los clientes.
Artifacts
Introducción a la compatibilidad de Azure Artifacts con Crates de carga
Nos complace anunciar que Azure Artifacts ahora ofrece compatibilidad nativa con cajas de carga. Esta compatibilidad incluye paridad de características con respecto a nuestros protocolos existentes, además de crates.io estar disponible como origen ascendente. Los desarrolladores y equipos de Rust ahora pueden consumir, publicar, administrar y compartir sus cajas de carga sin problemas, al tiempo que usan la sólida infraestructura de Azure y permanecen en el entorno conocido de Azure DevOps.
Anuncio de desuso para tareas de canalización de NuGet Restore v1 y NuGet Installer v0
Si usa las tareas de canalización De restauración de NuGet v1 y Instalador de NuGet v0, realice la transición rápida a la tarea de canalización de NuGetCommand@2. Comenzará a recibir alertas en las canalizaciones pronto si no se ha realizado la transición. Si no se realiza ninguna acción, a partir del 27 de noviembre de 2023, las compilaciones resultarán erróneas.
Compatibilidad de Azure Artifacts con la auditoría de npm
Azure Artifacts ahora admite npm audit comandos y npm audit fix . Esta característica permite a los usuarios analizar y corregir las vulnerabilidades de su proyecto actualizando automáticamente las versiones de paquetes no seguras. Para más información, visite Uso de la auditoría de npm para detectar y corregir vulnerabilidades de paquetes.
Generación de informes
Nueva experiencia de directorio del panel
Hemos escuchado sus comentarios y estamos encantados de presentar la nueva experiencia de directorio del panel. No solo incluye un diseño de interfaz de usuario moderno, sino que también le permite ordenar por cada columna, con la adición de la última columna configurada . Esta columna le proporcionará una mejor información sobre el uso general del panel dentro de la colección de proyectos. Además, ahora puede filtrar por equipos o paneles de nivel de proyecto, lo que le permite acceder solo a la lista de lo que necesita ver mientras oculta los paneles que no desea ver.
Pruébelo ahora y háganos saber lo que piensa en nuestra comunidad de Azure DevOps
Filtrado de elementos de trabajo
Nos complace anunciar el filtrado de gráficos de elementos de trabajo. Esta característica le permitirá mantener el puntero sobre el gráfico de elementos de trabajo para obtener información general rápida y explorar en profundidad segmentos de gráfico específicos para obtener información detallada. Ya no es necesario crear consultas personalizadas para acceder a los datos exactos que necesita. Ahora puede profundizar en los elementos de trabajo en gráficos de elementos de trabajo en unos pocos clics.
Sus comentarios son valiosos para dar forma al futuro de esta característica. Pruébelo ahora y háganos saber lo que piensa en nuestra comunidad de Azure DevOps.
Resultados de cobertura de código para carpetas
Los resultados de la cobertura de código ahora están disponibles para cada archivo y carpeta individuales en lugar de solo como un número de nivel superior. La vista de cobertura de código aparece cuando se alterna el botón Modo de vista carpeta. En este modo, puede explorar en profundidad y ver la cobertura de código de ese subárbol seleccionado. Use el botón de alternancia para cambiar entre las vistas nuevas y antiguas.
Test Plans
Copia rápida e importación con el plan de prueba o el identificador del conjunto de aplicaciones
Ahora puede controlar varios planes de prueba en Azure Test Plans con facilidad. Reconocer los desafíos a los que se enfrentaban anteriormente los menús desplegables largos para importar, copiar o clonar casos de prueba, especialmente para planes o conjuntos extensos, hemos realizado pasos para simplificar el flujo de trabajo.
Nos complace anunciar la característica Test Plan and Suite ID Search . Escriba el plan de prueba o el identificador del conjunto para importar o copiar rápidamente casos de prueba sin retrasos. Esta actualización forma parte de nuestro compromiso continuo de mejorar la experiencia de administración de pruebas, lo que hace que sea más intuitivo y menos lento.
Actualización del ejecutor de pruebas de Azure
Nos complace compartir que Azure Test Runner se ha actualizado a una versión más reciente. Esta actualización mejora la estabilidad y el rendimiento, lo que le permite ejecutar las pruebas sin interrupciones ni retrasos. Ya no se admite la versión anterior de Azure Test Runner. Para obtener el mejor rendimiento y confiabilidad de las operaciones de prueba, se recomienda actualizar a la versión más reciente lo antes posible.
Novedades
- Estabilidad y rendimiento mejorados: hemos realizado mejoras significativas en el ejecutor de pruebas, abordando los problemas que experimentaron algunos usuarios. Esta actualización garantiza un proceso de prueba más confiable, lo que minimiza las interrupciones en el trabajo.
- Mensaje de actualización: para realizar la transición a la nueva versión sin problemas, encontrará un mensaje para actualizar. Esto garantiza que todos los usuarios puedan pasar fácilmente a la versión mejorada en su comodidad, lo que mejora la compatibilidad y el rendimiento.
Comentarios
Nos encantaría que nos diera su opinión. Puede notificar un problema o proporcionar una idea y realizar un seguimiento a través de la Comunidad de desarrolladores y obtener consejos sobre Stack Overflow.