Notas de la versión de Azure DevOpsServer 2020 Update 1

Términos de licencia de los requisitos | | del sistema de la comunidad | de desarrolladores DevOps Blog | SHA-1 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, visite la página Descargas de Azure DevOps Server.

La actualización directa a Azure DevOps Server 2020 es compatible con Azure DevOps Server 2019 o Team Foundation Server 2015 o versiones posteriores. Si la implementación de TFS está en TFS 2010 o versiones anteriores, debe realizar algunos pasos provisionales antes de actualizar a Azure DevOps Server 2019. Para más información, consulte Instalación y configuración de Azure DevOps local.

---

Actualización segura de Azure DevOps Server 2019 a Azure DevOps Server 2020

Azure DevOps Server 2020 presenta un nuevo modelo de retención de ejecución de canalización (compilación) que funciona en función de la configuración de nivel de proyecto.

Azure DevOps Server 2020 controla la retención de compilación de forma diferente, en función de las directivas de retención de nivel de canalización. Algunas configuraciones de directiva llevan a que las ejecuciones de canalización se eliminen después de la actualización. Las ejecuciones de canalización que se han conservado manualmente o que se conservan mediante una versión no se eliminarán después de la actualización.

Lea nuestra entrada de blog para más información sobre cómo actualizar de forma segura desde Azure DevOps Server 2019 a Azure DevOps Server 2020.

Azure DevOps Server 2020 Update 1.2 Patch 14 Release Date: 12 de noviembre de 2024

Archivo	Hash SHA-256
devops2020.1.2patch14.exe	29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

Hemos publicado la revisión 14 para Azure DevOps Server 2020 Update 1.2 para incluir una actualización a una dependencia vulnerable.

Fecha de lanzamiento de la actualización 1.2 de Azure DevOps Server 2020: 12 de marzo de 2024

Archivo	Hash SHA-256
devops2020.1.2patch13.exe	55B0A30EABD6EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

Hemos publicado la revisión 13 para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente:

• Se ha resuelto un problema por el que el servidor proxy dejaba de funcionar después de instalar la revisión 12.

Azure DevOps Server 2020 Update 1.2 Patch 12 Release Date: 13 de febrero de 2024

Archivo	Hash SHA-256
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

Hemos publicado la revisión 12 para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente:

• Se ha corregido un error por el que el espacio en disco utilizado por la carpeta de caché de proxy se calculaba incorrectamente y la carpeta no se limpiaba correctamente.
• CVE-2024-20667: Vulnerabilidad de ejecución remota de código de Azure DevOps Server.

Azure DevOps Server 2020 Update 1.2 Patch 11 Release Date: 12 de diciembre de 2023

Archivo	Hash SHA-256
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

Hemos publicado la revisión 11 para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente:

• Se ha corregido un error en el que la herencia de seguridad de aprobación previa a la implementación no funcionaba en fases de canalizaciones.

Azure DevOps Server 2020 Update 1.2 Patch 10 Release Date: 14 de noviembre de 2023

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• Se ha ampliado la lista de caracteres permitidos de las tareas de PowerShell para habilitar la validación de parámetros de argumentos de tareas de shell.

Instalación de revisiones

Configuración de TFX

1. Siga los pasos descritos en la documentación cargar tareas en la colección de proyectos para instalar e iniciar sesión con tfx-cli.

Actualización de tareas mediante TFX

Archivo	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Descargue y extraiga Tasks20231103.zip.
2. Cambie el directorio a los archivos extraídos.
3. Ejecute los siguientes comandos para cargar las tareas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Requisitos de canalización

Para utilizar el nuevo comportamiento, se debe establecer una variable AZP_75787_ENABLE_NEW_LOGIC = true en las canalizaciones que utilizan las tareas afectadas.

• En clásico:

  Defina la variable en la pestaña variable de la canalización.

• Ejemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 1.2 Patch 9 Release Date: 10 de octubre de 2023

Hemos publicado una revisión. para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• Se ha corregido un error en el que la identidad "Propietario del análisis" se muestra como Identidad inactiva en las máquinas de actualización de revisiones.

Azure DevOps Server 2020 Update 1.2 Patch 8 Release Date: 12 de septiembre de 2023

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• CVE-2023-33136: Vulnerabilidad de ejecución remota de código de Azure DevOps Server.
• CVE-2023-38155: Vulnerabilidad de elevación de privilegios de Azure DevOps Server y Team Foundation Server.

Instalación de revisiones

1. Descargue e instale la revisión 8 de Azure DevOps Server 2020 Update 1.2.

Actualización del agente de Azure Pipelines

1. Descargue el agente desde: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Siga los pasos descritos en la documentación de agentes de Windows autohospedados para implementar el agente.  

Configuración de TFX

1. Siga los pasos descritos en la documentación cargar tareas en la colección de proyectos para instalar e iniciar sesión con tfx-cli.

Actualización de tareas mediante TFX

1. Descargar y extraer Tasks_20230825.zip.
2. Cambie el directorio a los archivos extraídos.
3. Ejecute los siguientes comandos para cargar las tareas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Requisitos de canalización

Para utilizar el nuevo comportamiento, se debe establecer una variable AZP_75787_ENABLE_NEW_LOGIC = true en las canalizaciones que utilizan las tareas afectadas.

• En clásico:

  Defina la variable en la pestaña variable de la canalización.

• Ejemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Fecha de lanzamiento de la actualización 1.2 de Azure DevOps Server 2020: 8 de agosto de 2023

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• CVE-2023-36869: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.
• Actualice el servicio SSH para admitir SHA2-256 y SHA2-512. Si tiene archivos de configuración SSH codificados de forma rígida para usar RSA, debe actualizar a SHA2 o quitar la entrada.
• Se ha corregido un problema con vínculos relativos que no funcionaban en archivos markdown.
• Se ha corregido un error con la navegación de comentarios en una página de confirmación.
• Se ha corregido un error en el que la identidad del propietario del análisis se mostraba como Identidad inactiva.
• Se ha corregido un error de bucle infinito en CronScheduleJobExtension.

Azure DevOps Server 2020 Update 1.2 Patch 6 Release Date: 13 de junio de 2023

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• CVE-2023-21565: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.
• CVE-2023-21569: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.
• Se ha corregido un error que interfiera con la inserción de paquetes al actualizar desde 2018 o versiones anteriores.
• Se ha corregido un error en el que la recopilación de desasociación o asociación generaba el siguiente error: "TF246018: la operación de base de datos superó el límite de tiempo de espera y se ha cancelado.

Azure DevOps Server 2020 Update 1.2 Patch 5 Release Date: 14 de febrero de 2023

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• CVE-2023-21553: Vulnerabilidad de ejecución remota de código de Azure DevOps Server
• Se ha corregido el problema de accesibilidad de los conjuntos de estantes a través de la interfaz de usuario web.
• Los clientes deben reiniciar el servicio tfsjobagent y el grupo de aplicaciones de Azure DevOps Server después de actualizar la configuración relacionada con SMTP en la Consola de administración del servidor de Azure DevOps.

Azure DevOps Server 2020 Update 1.2 Patch 4 Release Date: 13 de diciembre de 2022

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• Se ha corregido la visualización de caracteres especiales en IdentityPicker.

• Los datos de prueba no se han eliminado, lo que hace que la base de datos crezca. Con esta corrección, se ha actualizado la retención de compilación para evitar la creación de nuevos datos de prueba huérfanos.

Azure DevOps Server 2020 Update 1.2 Patch 3 Release Date: 18 de octubre de 2022

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• Resuelva el problema con las identidades de AD recién agregadas que no aparecen en los selectores de identidades del cuadro de diálogo de seguridad.
• Se ha corregido un problema con el filtro Solicitado por miembro del grupo en la configuración de web hook.
• Se ha corregido el error de compilación de la comprobación controlada cuando la configuración de la organización para la canalización tenía el ámbito de autorización del trabajo configurado como Limitar el ámbito de autorización del trabajo al proyecto actual para canalizaciones que no son de versión.
• Se ha corregido la recuperación del token de acceso de Azure al establecer la conexión de servicio detrás del proxy autenticado.

Azure DevOps Server 2020 Update 1.2 Patch 2 Release Date: 9 de agosto de 2022

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• Se ha corregido un error de valor de identidad al asignar un elemento de trabajo a una identidad que aparece en dominios diferentes.

Fecha de lanzamiento de la actualización 1.2 de Azure DevOps Server 2020: 12 de julio de 2022

Hemos publicado una revisión para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• En las API de ejecuciones de pruebas, el token de continuación que se devuelve era mayor que el valor "maxLastUpdatedDate" que se especificó.

Fecha de lanzamiento de La actualización 1.2 de Azure DevOps Server 2020: 17 de mayo de 2022

Azure DevOps Server 2020 Update 1.2 es una acumulación de correcciones de errores. Puede instalar directamente Azure DevOps Server 2020 Update 1.2 o actualizar desde Azure DevOps Server 2020 o Team Foundation Server 2013 o versiones posteriores.

Esta versión incluye correcciones para lo siguiente:

• Azure DevOps Server 2020.1.2 deshabilita el nuevo modelo de retención (introducido en Azure DevOps Server 2020) para evitar la pérdida de ejecuciones de canalización (compilaciones). Esto significa que el sistema hará lo siguiente:

  • Creación de concesiones para las tres compilaciones más recientes generadas al ejecutar Server 2020
  • En el caso de las canalizaciones de YAML y las canalizaciones clásicas sin directivas de retención por canalización, las compilaciones se conservarán según la configuración de retención máxima de nivel de colección.
  • En el caso de las canalizaciones clásicas con directivas de retención personalizadas por canalización, las compilaciones se conservarán según la directiva de retención específica de la canalización.
  • Las compilaciones con concesiones no cuentan hacia el valor Mínimo para mantener la configuración

• Los vínculos de comentarios del conjunto de cambios y del conjunto de cambios no se redirigen correctamente. Cuando se agregaron comentarios a archivos en conjuntos de cambios o conjuntos de estantes, al seleccionar esos comentarios no se redirige al lugar correcto en la vista de archivo.

• No se puede omitir la cola de compilación mediante el botón "Ejecutar siguiente". Anteriormente, el botón "Ejecutar siguiente" solo se habilitaba para los administradores de colecciones de proyectos.

• Revoque todos los tokens de acceso personal después de deshabilitar la cuenta de Active Directory de un usuario.

Fecha de lanzamiento de la revisión 4 de Azure DevOps Server 2020.1.1: 26 de enero de 2022

Hemos publicado una revisión para Azure DevOps Server 2020.1.1 que incluye correcciones para lo siguiente.

• Las notificaciones por correo electrónico no se enviaron al usar el @mention control en un elemento de trabajo.
• La dirección de correo electrónico preferida no se actualizaba en el perfil de usuario. Como resultado, los correos electrónicos se enviaron a la dirección de correo electrónico anterior.
• El encabezado no se mostró en la página Resumen del proyecto. El encabezado se mostró durante unos milisegundos y, a continuación, desapareció.
• Mejora de la sincronización de usuarios de Active Directory.
• Se ha solucionado la vulnerabilidad de Elasticsearch mediante la eliminación de la clase jndilookup de los archivos binarios de log4j.

Pasos de instalación

1. Actualice el servidor con la revisión 4.
2. Compruebe el valor del Registro en HKLM:\Software\Elasticsearch\Version. Si el valor del Registro no está ahí, agregue un valor de cadena y establezca la versión en 5.4.1 (Nombre = Version, Valor = 5.4.1).
3. Ejecute el comando de actualización PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update, tal como se proporciona en el archivo Léame. Puede devolver una advertencia como la siguiente: No se puede conectar al servidor remoto. No cierre la ventana, ya que la actualización realiza reintentos hasta que se completa.

1. Actualice el servidor con la revisión 4.
2. Compruebe el valor del Registro en HKLM:\Software\Elasticsearch\Version. Si el valor del Registro no está ahí, agregue un valor de cadena y establezca la versión en 5.4.1 (Nombre = Version, Valor = 5.4.1).
3. Copie el contenido de la carpeta denominada zip, que se encuentra en C:\Program Files\{TFS Version Folder}\Search\zip, en la carpeta de archivos remotos de Elasticsearch.
4. Ejecute Configure-TFSSearch.ps1 -Operation update en la máquina del servidor de Elasticsearch.

HASH SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Fecha de lanzamiento de la revisión 3 de Azure DevOps Server 2020.1.1: 15 de diciembre de 2021

La revisión 3 para Azure DevOps Server 2020.1.1 incluye correcciones para lo siguiente.

• Se ha corregido la macro de elemento de trabajo para las consultas con "Contains Words". Anteriormente, las consultas devolvían resultados incorrectos para los valores que contenían un salto de línea.
• Aumente los límites de longitud de caracteres de la versión del paquete de Maven.
• Problema de localización para los estados de diseño de elementos de trabajo personalizados.
• Problema de localización en la plantilla de notificación por correo electrónico.
• Problema con la evaluación de reglas NOTSAMEAS cuando se definieron varias reglas NOTSAMEAS para un campo.

Fecha de lanzamiento de La revisión 2020.1.1 de Azure DevOps Server 2: 26 de octubre de 2021

La revisión 2 para Azure DevOps Server 2020.1.1 incluye correcciones para lo siguiente.

• Anteriormente, Azure DevOps Server solo podía crear conexiones a GitHub Enterprise Server. Con esta revisión, los administradores de proyectos pueden crear conexiones entre Azure DevOps Server y repositorios en GitHub.com. Puede encontrar esta configuración en la página conexiones de GitHub en Configuración del proyecto.
• Resuelva el problema con el widget Plan de prueba. El informe de ejecución de pruebas mostraba un usuario incorrecto en los resultados.
• Se ha corregido un problema con la página de resumen de Información general del proyecto que no se pudo cargar.
• Se ha corregido un problema con los correos electrónicos que no se envían para confirmar la actualización del producto.

Fecha de lanzamiento de la revisión 1 de Azure DevOps Server 2020.1.1: 14 de septiembre de 2021

La revisión 1 para Azure DevOps Server 2020.1.1 incluye correcciones para lo siguiente.

• Corrija los errores de descarga y carga de artefactos.
• Resuelva el problema con datos de resultados de pruebas incoherentes.

Fecha de lanzamiento de La actualización 1.1 de Azure DevOps Server 2020: 17 de agosto de 2021

Azure DevOps Server 2020 Update 1.1 es una acumulación de correcciones de errores. Puede instalar directamente Azure DevOps Server 2020 Update 1.1 o actualizar desde Azure DevOps Server 2020 o Team Foundation Server 2013 o versiones posteriores.

En esta versión se incluyen las correcciones de los siguientes errores:

Azure Boards

• El hipervínculo "Ver elemento de trabajo" en los correos electrónicos de notificación no usa la dirección URL pública.

Azure Repos

• Se han corregido las casillas de verificación de herencia de tipos de combinación limitados para habilitar la modificación de los tipos de combinación de límites después de establecer directivas entre repositorios.

Azure Pipelines

• Al cambiar la configuración de Actualización del agente, la configuración no se propagaba a otros niveles de aplicación del entorno.

General

• Se ha corregido la ortografía en el Asistente para configuración del servidor.
• Se ha aumentado el tamaño del paquete de extensión y se le permite cambiar el tamaño en el Registro.

Azure Test Plans

• No se puede volver a los resultados de las pruebas una vez que se devuelve del historial a la página de resumen.

---

Fecha de lanzamiento de La revisión 2020.1 de Azure DevOps Server 2: 10 de agosto de 2021

Hemos publicado una revisión para Azure DevOps Server 2020.1 que corrige lo siguiente.

• Se ha corregido el error de interfaz de usuario de definición de compilación.
• Se ha cambiado el historial de exploración para mostrar archivos en lugar del repositorio raíz.

Fecha de lanzamiento de la revisión 1 de Azure DevOps Server 2020.1: 15 de junio de 2021

Hemos publicado una revisión para Azure DevOps Server 2020.1 que corrige lo siguiente.

• Proteja las cookies usadas en flujos de autorización que asercione SameSite=None.

• Resuelva el problema con el SDK de notificaciones. Anteriormente, las suscripciones de notificaciones que usan el filtro ruta de acceso del área no se analizaban correctamente.

Fecha de lanzamiento rtW de Azure DevOps Server 2020.1: 25 de mayo de 2021

Resumen de las novedades de Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW es una acumulación de correcciones de errores. Incluye todas las características de Azure DevOps Server 2020.1 RC2 publicadas anteriormente. Azure DevOps Server 2020.1 RTW es una acumulación de correcciones de errores. Puede instalar directamente Azure DevOps Server 2020.1 o actualizar desde Azure DevOps Server 2020, 2019 o Team Foundation Server 2015 o versiones posteriores.

Fecha de lanzamiento de Azure DevOps Server 2020.1 RC2: 13 de abril de 2021

Resumen de las novedades de Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 es una acumulación de correcciones de errores. Incluye todas las características de Azure DevOps Server 2020.1 RC1 publicadas anteriormente.

Fecha de lanzamiento de Azure DevOps Server 2020.1 RC1: 23 de marzo de 2021

Resumen de las novedades de Azure DevOps Server 2020.1 RC1

Azure DevOps Server 2020.1 RC1 presenta muchas características nuevas. Entre los aspectos destacados se incluyen:

• Reglas de restricción de transición de estado en paneles
• Las partes interesadas ahora pueden mover elementos de trabajo entre columnas de panel
• Mayor seguridad de las versiones al restringir el ámbito de los tokens de acceso
• Experiencia mejorada de solicitud de incorporación de cambios
• Desencadenadores de varios repositorios en canalizaciones

También puede ir a secciones individuales para ver todas las nuevas características de cada servicio:

• Boards
• Repos
• Canalizaciones
• Artefactos

---

Boards

Reglas de restricción de transición de estado

Seguimos cerrando la brecha de paridad de características entre xml hospedado y el modelo de proceso heredado. Esta nueva regla de tipo de elemento de trabajo permite restringir que los elementos de trabajo se muevan de un estado a otro. Por ejemplo, puede restringir que los errores vayan de Nuevo a Resuelto. En su lugar, deben ir de Nuevo -> Activo -> Resuelto

También puede crear una regla para restringir las transiciones de estado por pertenencia a grupos. Por ejemplo, solo los usuarios del grupo "Aprobadores" pueden mover casos de usuario de New -> Approved.

Copiar elemento de trabajo para copiar elementos secundarios

Una de las principales características solicitadas para Azure Boards es la capacidad de copiar un elemento de trabajo que también copia los elementos de trabajo secundarios. Hemos agregado una nueva opción a "Incluir elementos de trabajo secundarios" al cuadro de diálogo copiar elemento de trabajo. Cuando se selecciona, esta opción copiará el elemento de trabajo y copiará todos los elementos de trabajo secundarios (hasta 100).

Reglas mejoradas para campos activados y resueltos

Hasta ahora, las reglas de Activated By, Activated Date, Resolved By y Resolved Date han sido un misterio. Solo se establecen para los tipos de elementos de trabajo del sistema y son específicos del valor de estado de "Activo" y "Resuelto". Hemos cambiado la lógica para que estas reglas ya no sean para un estado específico. En su lugar, se desencadenan mediante la categoría (categoría de estado) en la que reside el estado. Por ejemplo, supongamos que tiene un estado personalizado de "Necesidades de pruebas" en la categoría Resuelto. Cuando el elemento de trabajo cambia de "Activo" a "Necesita pruebas", se desencadenan las reglas De fecha resuelta por y Resuelta.

Esto permite a los clientes crear cualquier valor de estado personalizado y seguir generando los campos Activated By, Activated Date, Resolved By y Resolved Date , sin necesidad de usar reglas personalizadas.

Las partes interesadas pueden mover elementos de trabajo entre columnas a bordo

Las partes interesadas siempre han podido cambiar el estado de los elementos de trabajo. Pero cuando van al panel Kanban, no pueden mover los elementos de trabajo de una columna a otra. En su lugar, las partes interesadas tendrían que abrir cada elemento de trabajo, de uno en uno y actualizar el valor de estado. Esto ha sido un punto de dolor para los clientes, y estamos encantados de anunciar que ahora puede mover elementos de trabajo entre columnas a bordo.

Tipos de elementos de trabajo del sistema en registros de trabajo pendiente y paneles

Ahora puede agregar un tipo de elemento de trabajo del sistema al nivel de trabajo pendiente que prefiera. Históricamente, estos tipos de elementos de trabajo solo han estado disponibles en las consultas.

Proceso	Tipo de elemento de trabajo
Ágil	Problema
Scrum	Impedimento
CMMI	Solicitud de cambio
	Problema
	Revisar
	Riesgo

Agregar un tipo de elemento de trabajo del sistema a un nivel de trabajo pendiente es sencillo. Simplemente vaya al proceso personalizado y haga clic en la pestaña Niveles de trabajo pendiente. Seleccione el nivel de trabajo pendiente de elección (ejemplo: Trabajo pendiente de requisitos) y elija la opción editar. A continuación, agregue el tipo de elemento de trabajo.

Límite de repositorio de aplicaciones de GitHub de Azure Boards elevado

El límite de repositorios de la aplicación de Azure Boards en marketplace de GitHub se ha aumentado de 100 a 250.

Estado personalizado de los elementos de trabajo cuando se fusiona mediante combinación una solicitud de incorporación de cambios

No todos los flujos de trabajo son los mismos. Algunos clientes quieren cerrar sus elementos de trabajo relacionados cuando se completa una solicitud de incorporación de cambios. Otros quieren establecer los elementos de trabajo en otro estado que se va a validar antes de cerrar. Deberíamos permitir ambos.

Tenemos una nueva característica que le permite establecer los elementos de trabajo en el estado deseado cuando la solicitud de incorporación de cambios se combina y se completa. Para ello, examinamos la descripción de la solicitud de incorporación de cambios y buscamos el valor de estado seguido del #mention de los elementos de trabajo. En este ejemplo, estamos estableciendo dos casos de usuario en Resuelto y cerrando dos tareas.

Vínculo del elemento de trabajo a compilaciones en otro proyecto

Ahora puede realizar un seguimiento sencillo de las dependencias de compilación en el proyecto simplemente vinculando el elemento de trabajo a una compilación, se encuentra en la compilación o integrada en la compilación.

Edición de la descripción (texto de ayuda) en campos del sistema

Siempre ha podido editar la descripción de los campos personalizados. Pero para los campos del sistema, como prioridad, gravedad y actividad, la descripción no se puede editar. Esta era una diferencia de características entre el XML hospedado y heredado que impedía que algunos clientes migraran al modelo heredado. Ahora puede editar la descripción en los campos del sistema. El valor editado solo afectará a ese campo en el proceso y para ese tipo de elemento de trabajo. Esto le ofrece la flexibilidad de tener descripciones diferentes para el mismo campo en diferentes tipos de elementos de trabajo.

Estado personalizado de los elementos de trabajo cuando se fusiona mediante combinación una solicitud de incorporación de cambios

Las solicitudes de incorporación de cambios a menudo hacen referencia a varios elementos de trabajo. Al crear o actualizar una solicitud de incorporación de cambios, es posible que quiera cerrar algunas de ellas, resolver algunas de ellas y mantener el resto abierto. Ahora puede usar comentarios como los que se muestran en la ilustración siguiente para lograrlo. Consulte la documentación para obtener más información.

Campo principal en el panel de tareas

Debido a una solicitud popular, ahora puede agregar el campo Primario a las tarjetas secundarias y primarias del Panel de tareas.

Quitar la regla "Asignada a" en el tipo de elemento de trabajo Error

Hay varias reglas del sistema ocultas en todos los diferentes tipos de elementos de trabajo en Agile, Scrum y CMMI. Estas reglas han existido durante más de una década y generalmente han funcionado bien sin ninguna queja. Sin embargo, hay un par de reglas que han agotado su bienvenida. Una regla en particular ha causado mucho dolor para los clientes nuevos y existentes y hemos decidido que era el momento de eliminarlo. Esta regla existe en el tipo de elemento de trabajo Error en el proceso agile.

"Establezca el valor Asignado en Creado por cuando se cambia el estado a Resuelto"

Hemos recibido muchos comentarios sobre esta regla. En respuesta, seguimos adelante y quitamos esta regla del tipo de elemento de trabajo Error en el proceso agile. Este cambio afectará a cada proyecto mediante un agile heredado o un proceso de Agile heredado personalizado. Para aquellos clientes que les gusta y dependen de esta regla actual, consulte nuestra entrada de blog sobre los pasos que puede seguir para volver a agregar la regla mediante reglas personalizadas.

Elementos eliminados en la página Elementos de trabajo

La página Elementos de trabajo es un excelente lugar para encontrar rápidamente los elementos que creó o que se le asignan, entre otras cosas. Proporciona varios filtros y dinámicas personalizados. Una de las principales quejas de la tabla dinámica "Asignado a mí" es que muestra elementos de trabajo eliminados (es decir, elementos de trabajo en estado Eliminado). ¡Y estamos de acuerdo! Los elementos eliminados son trabajo que ya no es de valor y, por tanto, se ha quitado del trabajo pendiente, por lo que incluirlo en esta vista no es útil.

Ahora puede ocultar todos los elementos eliminados de la tabla dinámica Asignado a mí en la página Elementos de trabajo.

Repos

Preferencia de nombre de rama predeterminada

Azure Repos ahora ofrece un nombre de rama predeterminado personalizable para Git. En la configuración del repositorio, puede elegir cualquier nombre de rama legal que se usará cuando se inicialice un repositorio. Azure Repos siempre ha admitido el cambio del nombre de rama predeterminado para un repositorio existente.

Para obtener más información, vea Administrar ramas y Cambiar la rama predeterminada.

Configuración de la rama predeterminada a nivel de organización

Ahora hay una configuración de nivel de colección para el nombre de rama inicial preferido para los nuevos repositorios. Si un proyecto no ha elegido un nombre de rama inicial, se usará esta configuración de nivel de organización. Si no especificó el nombre de rama inicial en la configuración de la organización o la configuración del proyecto, los nuevos repositorios usarán un valor predeterminado definido de Azure DevOps.

Agregar un nuevo ámbito de autenticación para la aportación de comentarios de PR

Esta versión agrega un nuevo ámbito de OAuth para leer y escribir comentarios de solicitud de incorporación de cambios. Si tiene un bot o automatización que solo necesita interactuar con los comentarios, puede darle un PAT solo con este ámbito. Este proceso reduce el radio de explosión si la automatización tiene un error o si el token se ha puesto en peligro.

Mejoras en la experiencia de solicitud de incorporación de cambios

La nueva experiencia de solicitud de incorporación de cambios se ha mejorado con lo siguiente:

• Hacer que las comprobaciones opcionales sean más visibles

Los clientes usan comprobaciones opcionales para atraer la atención de un desarrollador a posibles problemas. En la experiencia anterior, solía ser obvio cuando se produce un error en estas comprobaciones. Sin embargo, no es el caso en la experiencia de versión preliminar. Una marca de verificación grande y verde en las comprobaciones necesarias enmascara los errores en comprobaciones opcionales. Los usuarios solo podían detectar que se produjo un error en las comprobaciones opcionales abriendo el panel de comprobaciones. Los desarrolladores no suelen hacerlo cuando no hay ninguna indicación de un problema. En esta implementación, hemos hecho que el estado de las comprobaciones opcionales sea más visible en el resumen.

• Ctrl-clics en elementos de menú

Los menús de tabulación de una solicitud de incorporación de cambios no admiten ctrl-clic. Los usuarios suelen abrir nuevas pestañas del explorador a medida que revisan una solicitud de incorporación de cambios. Esto se ha solucionado.

• Ubicación de la anotación [+]

La lista de árboles de archivos de una solicitud de incorporación de cambios muestra una anotación [+] para ayudar a los autores y revisores a identificar nuevos archivos. Dado que la anotación estaba después de los puntos suspensivos, a menudo no era visible para nombres de archivo más largos.

• La lista desplegable actualizaciones de pr recupera la información de tiempo

La lista desplegable para seleccionar actualizar y comparar archivos en una solicitud de incorporación de cambios perdió un elemento importante en la experiencia de vista previa. No se mostró cuando se realizó esa actualización. Esto se ha solucionado.

• **Diseño mejorado del filtro de comentarios **

Al filtrar comentarios en la página de resumen de una solicitud de incorporación de cambios, la lista desplegable estaba a la derecha, pero el texto estaba alineado a la izquierda. Esto se ha solucionado.

• Navegación a las confirmaciones primarias

En la página Confirmaciones, puede comparar los cambios realizados en una confirmación determinada con su confirmación primaria. Sin embargo, es posible que desee navegar a la confirmación primaria y comprender aún más cómo difiere esa confirmación de su propio elemento primario. Esto suele ser necesario cuando desea comprender todos los cambios de una versión. Hemos agregado una tarjeta de elementos primarios a una confirmación para ayudarle a lograr esto.

• Más espacio para carpetas y archivos con nombres largos en la pestaña de archivos de PR

Las carpetas y los archivos con nombres largos se cortaron debido a la falta de espaciado horizontal en el árbol de archivos. Hemos recuperado algún espacio adicional en el árbol modificando la sangría del árbol para que coincida con el nodo raíz y ocultando el botón de puntos suspensivos de la página, excepto al mantener el puntero.

Imagen del nuevo árbol de archivos:

Imagen del árbol de archivos al mantener el puntero sobre un directorio:

• Conservación de la posición de desplazamiento al cambiar de tamaño el panel de diferencias en la pestaña de archivos de PR

Al cambiar el tamaño del panel de diferencias en paralelo en la pestaña Archivos de solicitud de incorporación de cambios, se perderá la ubicación de desplazamiento del usuario. Este problema se ha corregido; La ubicación de desplazamiento del usuario ahora se conserva en un cambio de tamaño del panel de diferencias.

• Búsqueda de una confirmación en un dispositivo móvil

Al ver la página Confirmaciones en un dispositivo móvil, falta el cuadro de búsqueda en la nueva experiencia. Como resultado, es difícil encontrar una confirmación por su hash y abrirla. Esto se ha corregido ahora.

• Uso mejorado del espacio de la nueva vista móvil de diferencias de archivos de PR

Hemos actualizado esta página para hacer un mejor uso del espacio para que los usuarios puedan ver más del archivo en vistas móviles en lugar de tener el 40 % de la pantalla tomada por un encabezado.

• Imágenes mejoradas en la vista de resumen de pr

Las imágenes editadas en una solicitud de incorporación de cambios no se mostraban en la vista de resumen de pr, pero se mostraban correctamente en la vista de archivos de solicitud de incorporación de cambios. El problema se ha solucionado.

• Experiencia de marca mejorada al crear una nueva PR

Antes de esta actualización, esta experiencia no era ideal, ya que compararía los cambios con la rama predeterminada del repositorio en lugar de la rama de comparación.

Pipelines

Plataforma de agente adicional: ARM64

Hemos agregado Linux/ARM64 a la lista de plataformas admitidas para el agente de Azure Pipelines. Aunque los cambios de código eran mínimos, muchos trabajos en segundo plano tenían que completarse primero, y estamos encantados de anunciar su lanzamiento.

Compatibilidad del filtro de etiquetas con los recursos de canalización

Ahora se han agregado "etiquetas" en canalizaciones YAML. Puede usar etiquetas para establecer la canalización de CI que se ejecutará o cuándo se desencadenará automáticamente.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

El fragmento de código anterior muestra que las etiquetas se pueden usar para determinar la versión predeterminada de la canalización de CI (integración continua) que se ejecutará cuando la ejecución de la canalización de CD (implementación continua) no se desencadene mediante algún otro origen o recurso o un desencadenador de ejecución programado.

Por ejemplo, si tiene un desencadenador programado establecido para la canalización de CD que solo desea ejecutar si la CI tiene la etiqueta de producción, las etiquetas de la sección desencadenadores garantizan que la canalización de CD solo se desencadene si el evento de finalización de CI cumple la condición de etiquetado.

Control sobre las tareas que se permiten en las canalizaciones

Ahora puede deshabilitar las tareas de Marketplace. Algunos de los usuarios pueden permitir extensiones de Marketplace, pero no las tareas de canalización que llevan a cabo. Para un mayor control, también le permitimos deshabilitar de forma independiente todas las tareas integradas (excepto la desprotección, que es una acción especial). Con ambas opciones habilitadas, las únicas tareas permitidas para ejecutarse en una canalización serían las cargadas mediante tfx. Visite https://dev.azure.com/<your_org>/_settings/pipelinessettings y busque la sección "Restricciones de tareas" para empezar.

Directiva de bloqueo de implementación exclusiva

Con esta actualización, puede asegurarse de que solo se implementa una sola ejecución en un entorno a la vez. Al elegir la comprobación "Bloqueo exclusivo" en un entorno, solo se realizará una ejecución. Las ejecuciones posteriores que quieran implementar en ese entorno se pausarán. Una vez completada la ejecución con el bloqueo exclusivo, la ejecución más reciente continuará. Las ejecuciones intermedias se cancelarán.

Fases filtra los desencadenadores de recursos de canalización

Se ha agregado compatibilidad con "fases" como filtro para los recursos de canalización en YAML. Con este filtro, no es necesario esperar a que se complete toda la canalización de CI para desencadenar la canalización de CD. Ahora puede optar por desencadenar la canalización de CD tras la finalización de una fase específica de la canalización de CI.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Cuando las fases proporcionadas en el filtro de desencadenador se completan correctamente en la canalización de CI, se desencadena automáticamente una nueva ejecución para la canalización de CD.

Desencadenadores basados en webhook genéricos para canalizaciones YAML

En la actualidad, tenemos varios recursos (como canalizaciones, contenedores, compilación y paquetes) a través de los cuales puede consumir artefactos y habilitar desencadenadores automatizados. Sin embargo, hasta ahora no se pudo automatizar el proceso de implementación en función de otros eventos o servicios externos. En esta versión, presentamos compatibilidad con desencadenadores de webhook en canalizaciones YAML para habilitar la integración de la automatización de canalizaciones con cualquier servicio externo. Puede suscribirse a cualquier evento externo a través de sus webhooks (Github, Github Enterprise, Nexus, Aritfactory, etc.) y desencadenar las canalizaciones.

Estos son los pasos para configurar los desencadenadores de webhook:

1. Configure un webhook en el servicio externo. Al crear el webhook, debe proporcionar la siguiente información:

   • Url de solicitud: "https://dev.azure.com/<Colección> de ADO/_apis/public/distributedtask/webhooks/<Nombre> de webHook?api-version=6.0-preview"
   • Secreto: es opcional. Si necesita proteger la carga JSON, proporcione el valor secreto .

2. Cree una nueva conexión de servicio de "Webhook entrante". Se trata de un tipo de conexión de servicio recién introducido que le permitirá definir tres partes importantes de información:

   • Nombre del webhook: el nombre del webhook debe coincidir con el webhook creado en el servicio externo.
   • Encabezado HTTP: el nombre del encabezado HTTP de la solicitud que contiene el valor hash de carga para la comprobación de la solicitud. Por ejemplo, en el caso de GitHub, el encabezado de solicitud será "X-Hub-Signature"
   • Secreto : el secreto se usa para analizar el hash de carga usado para la comprobación de la solicitud entrante (esto es opcional). Si ha usado un secreto para crear el webhook, deberá proporcionar la misma clave secreta.

   

3. En las canalizaciones YAML, se introduce un nuevo tipo de recurso denominado webhooks. Para suscribirse a un evento de webhook, debe definir un recurso de webhook en la canalización y apuntarlo a la conexión del servicio de webhook entrante. También puede definir filtros adicionales en el recurso de webhook en función de los datos de carga JSON para personalizar aún más los desencadenadores de cada canalización y puede consumir los datos de carga en forma de variables en los trabajos.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Cada vez que la conexión del servicio De webhook entrante recibe un evento de webhook, se desencadenará una nueva ejecución para todas las canalizaciones suscritas al evento de webhook.

Soporte técnico y trazabilidad de los problemas de desencadenadores de recursos YAML

Puede resultar confuso cuando los desencadenadores de canalización no se ejecutan según lo previsto. Para ayudar a comprender mejor esto, hemos agregado un nuevo elemento de menú en la página de definición de canalización denominada "Problemas de desencadenador" donde se muestra información sobre por qué los desencadenadores no se están ejecutando.

Los desencadenadores de recursos pueden no ejecutarse por dos motivos.

1. Si el origen de la conexión de servicio proporcionada no es válido o si hay errores de sintaxis en el desencadenador, el desencadenador no se configurará en absoluto. Se muestran como errores.

2. Si las condiciones del desencadenador no coinciden, el desencadenador no se ejecutará. Siempre que esto ocurra, se mostrará una advertencia para que pueda comprender por qué no se han coinciden las condiciones.

   

Desencadenadores de varios repositorios

Puede especificar varios repositorios en un archivo YAML y hacer que una canalización se desencadene mediante actualizaciones en cualquiera de los repositorios. Esta característica es útil, por ejemplo, en los escenarios siguientes:

• Se consume una herramienta o una biblioteca de un repositorio diferente. Quiere ejecutar pruebas para la aplicación siempre que se actualice la herramienta o biblioteca.
• El archivo YAML se mantiene en un repositorio independiente del código de la aplicación. Quiere desencadenar la canalización cada vez que se inserta una actualización en el repositorio de aplicaciones.

Con esta actualización, los desencadenadores de varios repositorios solo funcionarán para repositorios de Git en Azure Repos. No funcionan para los recursos del repositorio de GitHub o BitBucket.

Este es un ejemplo que muestra cómo definir varios recursos de repositorio en una canalización y cómo configurar desencadenadores en todos ellos.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

La canalización de este ejemplo se desencadenará si hay actualizaciones para:

• main rama en el self repositorio que contiene el archivo YAML
• main o release ramas en el tools repositorio

Para más información, consulte Varios repositorios en la canalización.

Mejora de la carga de registros de los agentes

Cuando un agente deja de comunicarse con el servidor de Azure Pipelines, el trabajo que se estaba ejecutando se abandona. Si ha visto los registros de la consola de streaming, es posible que haya obtenido algunas pistas sobre lo que el agente estaba justo antes de dejar de responder. Pero si no lo estaba, o si actualizó la página, esos registros de consola se han ido. Con esta versión, si el agente deja de responder antes de enviar sus registros completos, mantendremos los registros de la consola como lo mejor. Los registros de consola están limitados a 1000 caracteres por línea y, ocasionalmente, pueden estar incompletos, pero son mucho más útiles que mostrar nada. Examinar estos registros puede ayudarle a solucionar problemas de sus propias canalizaciones y, sin duda, ayudará a nuestros ingenieros de soporte técnico cuando le ayuden a solucionar problemas.

Montaje opcional de los volúmenes de contenedor solo para lectura

Al ejecutar un trabajo de contenedor en Azure Pipelines, varios volúmenes que contienen el área de trabajo, las tareas y otros materiales se asignan como volúmenes. Estos volúmenes tienen como valor predeterminado acceso de lectura y escritura. Para aumentar la seguridad, puede montar los volúmenes de solo lectura modificando la especificación del contenedor en YAML. Cada clave de se mountReadOnly puede establecer true en para solo lectura (el valor predeterminado es false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Control pormenorizado del inicio y la detención de los contenedores

En general, se recomienda permitir que Azure Pipelines administre el ciclo de vida de los contenedores de trabajos y servicios. Sin embargo, en algunos escenarios poco comunes, es posible que quiera iniciarlos y detenerlos usted mismo. Con esta versión, hemos creado esa funcionalidad en la tarea docker.

Esta es una canalización de ejemplo mediante la nueva funcionalidad:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Además, se incluye la lista de contenedores en una variable de canalización, Agent.ContainerMapping. Puede usarlo si desea inspeccionar la lista de contenedores de un script, por ejemplo. Contiene un objeto JSON con cadena que asigna el nombre del recurso ("builder" del ejemplo anterior) al identificador de contenedor que administra el agente.

Descompresión de lotes de tareas para cada paso

Cuando el agente ejecuta un trabajo, primero descarga todos los conjuntos de tareas requeridos por los pasos del trabajo. Normalmente, para el rendimiento, descomprime las tareas una vez por trabajo incluso si la tarea se usa en varios pasos. Si tiene dudas sobre el código que no es de confianza al modificar el contenido descomprimido, puede cambiar un poco de rendimiento haciendo que el agente descomprima la tarea en cada uso. Para habilitar este modo, pase --alwaysextracttask al configurar el agente.

Mayor seguridad de las versiones al restringir el ámbito de los tokens de acceso

Basándonos en nuestra iniciativa para mejorar la configuración de seguridad de Azure Pipelines, ahora se admite restringir el ámbito de los tokens de acceso para las versiones.

Cada trabajo que se ejecuta en versiones obtiene un token de acceso. Las tareas y los scripts usan el token de acceso para volver a llamar a Azure DevOps. Por ejemplo, usamos el token de acceso para obtener código fuente, descargar artefactos, cargar registros, resultados de pruebas o realizar llamadas REST a Azure DevOps. Se genera un nuevo token de acceso para cada trabajo y expira una vez completado el trabajo.

Con esta actualización, se basa en la mejora de la seguridad de la canalización mediante la restricción del ámbito de los tokens de acceso y la extensión de la misma a las versiones clásicas.

Esta característica estará activada de forma predeterminada para los nuevos proyectos y colecciones. Para las colecciones existentes, debe habilitarla en Configuración de > canalizaciones > de recopilación. > Limite el ámbito de autorización del trabajo al proyecto actual para las canalizaciones de versión. Obtenga más información aquí.

Mejoras en la API de vista previa de YAML

Ahora puede obtener una vista previa del CÓDIGO YAML completo de una canalización sin ejecutarlo. Además, hemos creado una nueva dirección URL dedicada para la funcionalidad de versión preliminar. Ahora puede POST para https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview recuperar el cuerpo de YAML finalizado. Esta nueva API toma los mismos parámetros que la puesta en cola de una ejecución, pero ya no requiere el permiso "Queue builds".

Ejecución de este trabajo a continuación

¿Alguna vez ha tenido un error que necesitaba implementar en este momento , pero tenía que esperar detrás de los trabajos de CI y PR? Con esta versión, ahora le permitimos aumentar la prioridad de un trabajo en cola. Los usuarios con el permiso "Administrar" en el grupo , normalmente administradores del grupo, verán un nuevo botón "Ejecutar siguiente" en la página de detalles del trabajo. Al hacer clic en el botón, se establecerá que el trabajo se ejecute lo antes posible. (Todavía necesitará paralelismo disponible y un agente adecuado, por supuesto).

Expresiones de plantilla permitidas en el bloque YAML resources

Anteriormente, no se permitían expresiones en tiempo de compilación (${{ }}) en la resources sección de un archivo YAML de Azure Pipelines. Con esta versión, hemos elevado esta restricción para los contenedores. Esto le permite usar el contenido del parámetro en tiempo de ejecución dentro de los recursos, por ejemplo, para elegir un contenedor en tiempo de cola. Tenemos previsto ampliar esta compatibilidad a otros recursos a lo largo del tiempo.

Control de las actualizaciones de las tareas automatizadas desde Marketplace

Al escribir una canalización YAML, normalmente solo se especifica el número de versión principal de las tareas incluidas. Esto permite que las canalizaciones tomen automáticamente las adiciones de características y correcciones de errores más recientes. En ocasiones, es posible que tenga que revertir a una versión de punto anterior de una tarea y, con esta actualización, hemos agregado la capacidad de hacerlo. Ahora puede especificar una versión completa de la tarea major.minor.patch en las canalizaciones de YAML.

No se recomienda hacerlo con regularidad y usarlo solo como solución temporal cuando encuentre que una tarea más reciente interrumpe las canalizaciones. Además, esto no instalará una versión anterior de una tarea desde Marketplace. Ya debe existir en la colección o se producirá un error en la canalización.

Ejemplo:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Compatibilidad con Node 10 en el agente y las tareas

Puesto que el nodo 6 ya no se admite, estamos migrando las tareas para trabajar con el nodo 10. Para esta actualización, hemos migrado casi el 50 % de las tareas integradas al nodo 10. El agente ahora puede ejecutar tareas de Node 6 y Node 10. En una actualización futura, quitaremos completamente el nodo 6 del agente. Para prepararse para la eliminación del nodo 6 del agente, se solicita que actualice las extensiones internas y las tareas personalizadas para que también usen node 10 pronto. Para usar el nodo 10 para la tarea, en , executionen task.json, actualice de Node a Node10.

Mejora de la conversión de YAML en el diseñador de compilación clásico

Con esta versión, presentamos una nueva característica de "exportación a YAML" para canalizaciones de compilación del diseñador. Guarde la definición de canalización y busque "Exportar a YAML" en el ... menú.

La nueva función de exportación reemplaza la función "Ver como YAML" que se encontró anteriormente en el diseñador de compilación clásico. Esa función estaba incompleta, ya que solo podía inspeccionar lo que la interfaz de usuario web sabía sobre la compilación, lo que a veces llevó a que se generara YAML incorrecto. La nueva función de exportación tiene en cuenta exactamente cómo se procesará la canalización y genera YAML con plena fidelidad a la canalización del diseñador.

Nueva conversión de plataforma web: configuración del repositorio

Hemos convertido las dos páginas de configuración del repositorio en una sola experiencia que se actualizó a una nueva plataforma web. Esta actualización no solo hace que la experiencia sea más rápida y moderna, sino que estas páginas también proporcionan un único punto de entrada para todas las directivas del nivel de proyecto al nivel de rama.

Con esta nueva experiencia, la navegación para proyectos con un número considerable de repositorios se ha vuelto más fácil debido a tiempos de carga más rápidos y un filtro de búsqueda agregado. También puede ver las directivas de nivel de proyecto y la lista de directivas entre repositorios en la pestaña Directivas.

Si hace clic en un repositorio, puede ver las directivas y los permisos establecidos en el nivel de repositorio. Dentro de la pestaña Directivas, puede ver una lista de cada rama en la que se establece la directiva. Ahora, haga clic en la rama para ver todas las directivas mientras nunca sale de la página Configuración del repositorio.

Ahora, cuando las directivas se heredan de un ámbito superior al que está trabajando, le mostramos dónde se heredó la directiva junto a cada directiva individual. También puede navegar a la página donde se estableció la directiva de nivel superior haciendo clic en el nombre del ámbito.

La propia página de directiva también se ha actualizado a la nueva plataforma web con secciones contraíbles. Para mejorar la experiencia de buscar una directiva determinada de validación de compilación, comprobación de estado o revisor automático, hemos agregado filtros de búsqueda para cada sección.

Integración de administración de cambios de ServiceNow con las canalizaciones de YAML

La aplicación Azure Pipelines para ServiceNow le ayuda a integrar Azure Pipelines y ServiceNow Change Management. Con esta actualización, llevamos a cabo nuestro recorrido para que Azure Pipelines sea consciente del proceso de administración de cambios administrado en ServiceNow más allá de las canalizaciones de YAML.

Al configurar la comprobación "Administración de cambios de ServiceNow" en un recurso, ahora puede pausar el cambio que se va a aprobar antes de implementar la compilación en ese recurso. Puede crear automáticamente un nuevo cambio para una fase o esperar a una solicitud de cambio existente.

También puede agregar la UpdateServiceNowChangeRequest tarea en un trabajo de servidor para actualizar la solicitud de cambio con el estado de implementación, notas, etc.

Artifacts

Capacidad de crear fuentes con ámbito de organización a partir de la interfaz de usuario

Estamos devolviendo la capacidad de que los clientes creen y administren fuentes con ámbito de recopilación a través de la interfaz de usuario web para los servicios locales y hospedados.

Ahora puede crear fuentes con ámbito de organización a través de la interfaz de usuario; para ello, vaya a Artefactos:> crear fuente y elija un tipo de fuente dentro del ámbito.

Aunque se recomienda el uso de fuentes con ámbito de proyecto en consonancia con el resto de las ofertas de Azure DevOps, puede crear, administrar y usar fuentes con ámbito de recopilación a través de la interfaz de usuario y varias API REST. Consulte nuestra documentación de fuentes para obtener más información.

Disponibilidad de la API REST “Update Package Version” para los paquetes Maven

Ahora puede usar la API REST "Update Package Version" de Azure Artifacts para actualizar las versiones del paquete de Maven. Anteriormente, podría usar la API REST para actualizar las versiones de paquetes para NuGet, Maven, npm y Paquetes universales, pero no paquetes de Maven.

Para actualizar los paquetes de Maven, use el comando HTTP PATCH como se indica a continuación.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Puede establecer lo siguiente:

Parámetros de URI

Nombre	In	Obligatorio	Tipo	Descripción
artifactId	path	VERDADERO	string	Identificador de artefacto del paquete
feed	path	VERDADERO	string	Nombre o identificador de la fuente
groupId	path	VERDADERO	string	Id. de grupo del paquete
collection	path	VERDADERO	string	Nombre de la colección de Azure DevOps
version	path	VERDADERO	string	Versión del paquete
proyecto	path		string	Id. de proyecto o nombre del proyecto
api-version	Query	VERDADERO	string	Versión de la API que se va a usar. Debe establecerse en "5.1-preview.1" para usar esta versión de la API.

Cuerpo de la solicitud

Nombre	Tipo	Descripción
views	JsonPatchOperation	Vista a la que se agregará la versión del paquete.

Para obtener más información, consulte la documentación de la API REST a medida que se actualiza.

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.

---

Principio de página