Mejoras de integración y actualizaciones del servicio Azure DevOps

Para asegurarse de que el entorno de Azure DevOps sigue siendo seguro, estamos realizando actualizaciones clave del servicio. Esto incluye la finalización de la compatibilidad con los nuevos registros de aplicaciones de OAuth a partir de abril de 2025, aunque las aplicaciones existentes seguirán funcionando hasta la retirada completa en 2026. Además, se requerirá la indicación de nombre de servidor (SNI) para todas las conexiones HTTPS a partir del 23 de abril de 2025, junto con las actualizaciones de las directivas de registro de TFVC en Azure Repos.

Junto con estas actualizaciones, nos complace anunciar las últimas mejoras en nuestra integración de Azure Boards + GitHub, lo que facilita la vinculación de ramas, solicitudes de incorporación de cambios y confirmaciones en los elementos de trabajo. Además, las canalizaciones ahora proporcionan una mayor visibilidad de las dependencias entre etapas YAML, lo que ayuda a los equipos a administrar flujos de trabajo más complejos de manera más eficaz.

Consulte las notas de publicación para más detalles.

General

• No hay nuevas aplicaciones de OAuth de Azure DevOps a partir de abril de 2025
• Indicación de nombre de servidor (SNI) ahora obligatoria para Azure DevOps Services

Azure Boards:

• Integración de GitHub: mejoras en la vinculación a confirmaciones, ramas y solicitudes de incorporación de cambios
• Integración de GitHub: mostrar el estado de compilación de las canalizaciones de YAML
• Aumento del límite de planes de entrega

Azure Repos

• Cambios en las políticas de registro de TFVC
• La mejora de GetRepository API
• Mejora de la API de consulta de Solicitudes de incorporación de cambios

Azure Pipelines (Canales de Azure)

• Mejora de la visibilidad de las dependencias de la fase de canalización de YAML
• Nuevo agente CDN
• El nodo 16 se quitará de las canalizaciones:* Paquetes del agente de canalización

Planes de prueba de Azure:

• Retirada del registro de acciones y cambio a la grabación de pantalla
• Ejecución manual de prueba con pausa automática

General

No hay nuevas aplicaciones de OAuth de Azure DevOps a partir de abril de 2025

A partir de abril de 2025, ya no se admiten nuevos registros de aplicaciones de OAuth de Azure DevOps. Este es un primer paso hacia nuestra visión a largo plazo de retirar la plataforma OAuth de Azure DevOps. Se recomienda que todos los desarrolladores que compilan aplicaciones sobre las API rest de Azure DevOps exploren la plataforma de identidad de Microsoft y registren en su lugar una nueva aplicación Entra .

Todas las aplicaciones de OAuth de Azure DevOps existentes seguirán funcionando hasta la retirada oficial de la plataforma en 2026. Obtenga más información en nuestra entrada de blog aquí.

Indicación de nombre de servidor (SNI) ahora obligatoria para Azure DevOps Services

A partir del 23 de abril de 2025, se requerirá la indicación de nombre del servidor (SNI) en todas las conexiones HTTPS entrantes a Azure DevOps Services.

SNI es una extensión para el protocolo TLS que permite a los clientes especificar el nombre de host al que se conectan. Todos los exploradores modernos y el software cliente admiten SNI y lo usan de forma predeterminada, lo que garantiza una transición sin problemas para la mayoría de los usuarios. De hecho, más del 99,995% del tráfico de cliente que llega a nuestros servidores está preparado para SNI.

Sin embargo, es posible que algún software cliente no sea compatible con SNI debido a varios factores, como la desactualización, las bibliotecas de red mal configuradas, los entornos de ejecución o los sistemas operativos. Los problemas también pueden surgir de servidores proxy o firewalls NGFW. Las siguientes herramientas que se usan con Azure DevOps pueden verse afectadas por problemas de SNI:

• Clientes de Git
• Complementos y extensiones del IDE (Team Explorer Everywhere)
• Software que se ejecuta en versiones anteriores de Java que no admiten SNI (Java 6 y versiones anteriores) o que no tienen SNI habilitado de forma predeterminada (algunas versiones de Java 7 y 8)
• Versiones anteriores del explorador (consulte https://caniuse.com/sni)

Los problemas de SNI suelen manifestarse por errores de conexión, como:

• ERR_SSL_PROTOCOL_ERROR (Error de protocolo SSL), ERR_CERT_COMMON_NAME_INVALID (Nombre común del certificado no válido)
• javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
• No se pudo establecer la relación de confianza para el canal seguro SSL/TLS

Puede validar la compatibilidad de SNI del sistema llamando al punto de conexión de estado de Azure DevOps, que hemos configurado para requerir SNI. Si esta llamada se realiza correctamente, indica que el host, incluido su sistema operativo y su entorno de red, es compatible con SNI. Para obtener instrucciones detalladas sobre cómo probar, visite nuestra entrada de blog.

Azure Boards

Integración de GitHub: mejoras en la vinculación a confirmaciones, ramas y solicitudes de incorporación de cambios

Estamos mejorando continuamente la integración de Boards + GitHub para cerrar las brechas de facilidad de uso y alinearse con la experiencia con la que está familiarizado en Azure Repos.

Con esta actualización, hemos introducido varias mejoras para simplificar cómo se vinculan las ramas, las solicitudes de incorporación de cambios y las confirmaciones a los elementos de trabajo:

• Cuando una rama de GitHub está vinculada a un elemento de trabajo, las solicitudes de incorporación de cambios asociadas ahora se vincularán automáticamente. No es necesario usar manualmente AB#.

• Una vez combinada una solicitud de incorporación de cambios, la confirmación de combinación se vinculará automáticamente al elemento de trabajo.

• Si la rama se elimina después de combinar la solicitud de incorporación de cambios, el enlace de la rama se quitará automáticamente del elemento de trabajo.

Estas mejoras facilitan el seguimiento del progreso del desarrollo y el mantenimiento de las asociaciones de elementos de trabajo actualizadas.

Integración de GitHub: mostrar el estado de compilación de las canalizaciones de 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 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.

Aumento del límite de planes de entrega

Anteriormente, limitamos los planes de entrega por proyecto a 1000. Con esta actualización, hemos aumentado el máximo de planes de entrega por proyecto a 1500. Puede obtener más información sobre cómo agregar y editar planes de entrega en la documentación aquí.

Azure Repos

Cambios en las directivas de protección de TFVC

Nueva versión (19.255.0-preview) del paquete NuGet Microsoft.TeamFoundationServer.ExtendedClient

El paquete NuGet Microsoft.TeamFoundationServer.ExtendedClient se actualizó con las nuevas clases y métodos de directiva de TFVC.

Cambios de directiva

Estamos realizando cambios en la forma en que las directivas de entrada de TFVC se almacenan en Azure DevOps, lo que también significa actualizaciones sobre cómo el paquete NuGet Microsoft.TeamFoundationServer.ExtendedClient se comunica con el servicio.

Si el proyecto de TFVC usa directivas de protección, migre esas directivas al nuevo formato. Hay dos maneras de hacerlo:

1. Uso de Visual Studio.

Para crear nuevas directivas con el administrador de proyectos de Visual Studio, debe abrir Configuración -> Proyecto de equipo -> Control de código fuente -> Directiva de protección y agregar una nueva directiva (sin marca "obsoleta") con los mismos parámetros que el anterior:

2. Si usa la 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 el registro de TFVC compatible 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 creationDate la propiedad 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 de API y versiones posteriores.

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

Hemos introducido una nueva Label propiedad en la respuesta de la consulta de Solicitud de incorporación de cambios en la API Get. Ahora puede especificar si se deben incluir etiquetas para los pull requests relacionados en cada consulta. Hay una nueva propiedad Include disponible: 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 Bad Request.

Ejemplo de solicitud de carga:

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

Azure Pipelines (Canales de Azure)

Mejora de la visibilidad de las dependencias de la fase de canalización de YAML

Las canalizaciones YAML proporcionan flexibilidad para administrar flujos de trabajo complejos, pero la visualización de las dependencias de fase ha sido un desafío, especialmente en implementaciones de varias regiones.

No siempre ha sido claro cómo se conectan las fases. Por ejemplo, determinar si CUS3 depende de WUS1 además de WUS2 y WUS3 ha requerido revisar el YAML directamente.

Con este sprint, las dependencias de fase se muestran ahora cuando se expande una fase, lo que proporciona información inmediata sobre el orden de ejecución y los requisitos ascendentes.

Nueva CDN del agente

A medida que se retira Edgio CDN, la dirección URL del dominio propiedad de Edgio https://vstsagentpackage.azureedge.net también se retirará. Vamos a agregar una nueva dirección URL https://download.agent.dev.azure.com de dominio compatible con la nueva red CDN. Asegúrese de agregar esta nueva dirección URL de dominio a la lista de permitidos del firewall. Las descargas de paquetes del agente para agentes autohospedados fallarán una vez que se elimine la dirección URL del dominio anterior. Consulte la publicación para obtener más detalles.

El nodo 16 se quitará de las canalizaciones:* Paquetes del agente de canalización

Las tareas del agente se pueden implementar en PowerShell o Node. El agente incluye varias versiones de Node que pueden ser objetivo de las tareas.

A medida que se publican nuevas versiones de Node, las tareas se actualizan para usar nuevas versiones de Node. Los entornos de ejecución se incluyen con el agente.

A medida que las versiones de Node.js salen del período de mantenimiento principal, algunas tareas de canalizaciones continúan dependiendo de ellas. Azure DevOps actualiza las tareas admitidas en una versión de Node compatible. Es posible que las tareas de terceros todavía necesiten versiones anteriores de Node para ejecutarse.

Para dar cabida a esto, tenemos dos tipos de paquetes de agente de canalización:

Si desea ejecutar una tarea que requiera el controlador de ejecución de Node 16 en un agente que no tenga el nodo 16 agrupado, puede instalar el controlador de ejecución insertando la tarea NodeTaskRunnerInstaller@0 en la canalización:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 16

Planes de prueba de Azure

Retirada del registro de acciones y cambio a la grabación de pantalla

Nuestro cliente de Azure Test Runner de escritorio se basa en la grabadora de pasos de problemas (PSR), una herramienta introducida en Windows 7 que ahora está en desuso en versiones más recientes de Windows. Como resultado, es posible que la funcionalidad del registro de acciones en nuestro ejecutor de pruebas de escritorio ya no funcione en actualizaciones futuras.

Para garantizar un seguimiento ininterrumpido de pruebas, se recomienda cambiar a la grabación de pantalla en nuestro ejecutor web, Test & Feedback Extension, que proporciona una manera moderna y confiable de capturar y administrar los pasos de prueba. Si necesita ayuda para realizar la transición a la extensión Test & Feedback, póngase en contacto con nuestro equipo de soporte técnico.

Pausa automática de la ejecución de prueba manual

Nunca pierda el progreso en sus ejecuciones de prueba con la ejecución de casos de prueba de pausa automática. Esta nueva característica pausa automáticamente la ejecución del caso de prueba si se interrumpe el trabajo, lo que garantiza que el progreso parcial se guarde sin necesidad de una pausa manual. Tanto si se aleja como si cierra la sesión, puede reanudar fácilmente el caso de prueba justo donde lo dejó, lo que reduce el riesgo de pérdida de datos y mejora el flujo de trabajo. Al simplificar el proceso de pausa y reanudación, la pausa automática le ayuda a centrarse en las pruebas sin preocuparse por perder el progreso. Pruébelo y cuéntenos a través del correo electrónico lo que piensa.

Pasos siguientes

Vaya a Azure DevOps y eche un vistazo.

Cómo proporcionar comentarios

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

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

Gracias

Silviu Andrica