Notas de la versión de Azure DevOps Server 2020 Update 1

Comunidad de Desarrolladores | Requisitos del Sistema | Términos de Licencia | Blog de DevOps | Hashes SHA-1

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 builds de forma diferente, en función de las políticas de retención a nivel de canalización. Algunas configuraciones de políticas pueden llevar 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 15 Release Date: 11 de marzo de 2025

Archivo	Hash SHA-256
devops2020.1.2patch15.exe	66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5

Hemos publicado parche 15 para Azure DevOps Server 2020 Update 1.2, que incluye lo siguiente:

• Actualizar las tareas debido a la obsolescencia de la CDN de Edgio. Consulte la entrada de blog Switching CDN providers (Cambiar proveedores de CDN) para obtener más detalles.

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

Archivo	Hash SHA-256
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

Hemos publicado el parche 14 para Azure DevOps Server 2020 Update 1.2 para incluir una actualización de 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	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

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.

Nota:

Para implementar correcciones para esta revisión, tendrá que seguir varios pasos para actualizar manualmente las tareas.

Instalación de revisiones

Importante

Publicamos actualizaciones del agente de Azure Pipelines con patch 8 publicada el 12 de septiembre de 2023. Si no instaló las actualizaciones del agente como se describe en las notas de la versión de Patch 8, se recomienda instalar estas actualizaciones antes de instalar patch 10. La nueva versión del agente después de instalar patch 8 será 3.225.0.

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.

• Sobre lo clásico

  Defina la variable en la pestaña de variables 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

Importante

Publicamos actualizaciones del agente de Azure Pipelines con patch 8 publicada el 12 de septiembre de 2023. Si no instaló las actualizaciones del agente como se describe en las notas de la versión de Patch 8, se recomienda instalar estas actualizaciones antes de instalar patch 9. La nueva versión del agente después de instalar patch 8 será 3.225.0.

Hemos publicado un parche. Actualización 1.2 de Azure DevOps Server 2020, 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 máquinas que se actualizan mediante parches.

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.

Importante

Implemente la revisión en un entorno de prueba y asegúrese de que las canalizaciones del entorno funcionan según lo previsto antes de aplicar la corrección a producción.

Nota:

Para implementar correcciones para esta revisión, tendrá que seguir varios pasos para actualizar manualmente el agente y las tareas.

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.  

Nota:

AZP_AGENT_DOWNGRADE_DISABLED debe establecerse en “true” para evitar que el agente sea degradado. En Windows, se puede utilizar el siguiente comando en una ventana de comandos con privilegios de administrador, seguido de un reinicio. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

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.

• Sobre lo clásico

  Defina la variable en la pestaña de variables 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 un parche 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 un parche 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 interfería con el envío de paquetes al actualizar desde 2018 o versiones anteriores.
• Se ha corregido un error en el que desasociar o asociar una colecció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 un parche 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 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 un parche 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 builds para evitar crear nuevos datos de prueba huérfanos.

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

Hemos publicado un parche 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 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 en las compilaciones con puerta cuando la configuración de la organización para la canalización había configurado el ámbito de autorización del trabajo como Limitar el ámbito de autorización del trabajo al proyecto actual para canalizaciones que no son de lanzamiento.
• Se ha corregido la recuperación del token de acceso de Azure al establecer la conexión de servicio detrás de un proxy autenticado.

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

Hemos publicado un parche 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 un parche para Azure DevOps Server 2020 Update 1.2 que incluye correcciones para lo siguiente.

• En la API de ejecución de pruebas, el token de continuación que se estaba devolviendo era mayor que el valor "maxLastUpdatedDate" que se había especificado.

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 compilació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.

Nota:

La herramienta de migración de datos estará disponible para Azure DevOps Server 2020 Update 1.2 aproximadamente tres semanas después de esta versión. Puede ver la lista de versiones actualmente admitidas para la importación en esta página.

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 pipeline (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 políticas de retención personalizadas, las compilaciones se conservarán de acuerdo con la política de retención específica de cada canalización.
  • Las construcciones con arrendamientos no cuentan para alcanzar el mínimo requerido para mantener la configuración.

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

• No se puede omitir la cola de tareas de compilación con 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 un parche 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 el parche 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 README. 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.

Nota:

Si Azure DevOps Server y Elasticsearch están instalados en diferentes máquinas, siga los pasos que se describen a continuación.

1. Actualice el servidor con el parche 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 del elemento de trabajo para las consultas con "Contiene Palabras". 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 de 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 del Parche 2 de Azure DevOps Server 2020.1.1: 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.

• Solucionar los fallos de descarga y carga de artefactos.
• Resuelva el problema con los datos de resultados de pruebas inconsistentes.

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 un conjunto 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.

Nota:

La herramienta de migración de datos estará disponible para Azure DevOps Server 2020 Update 1.1 aproximadamente tres semanas después de esta versión. Puede ver la lista de versiones actualmente admitidas para la importación en esta página.

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 ha corregido la visualización de las casillas de verificación para herencias de tipos de combinación limitados, lo cual permite modificar estos tipos de combinación después de establecer políticas que abarcan múltiples 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 (Planes de Prueba de Azure)

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

---

Fecha de lanzamiento del Parche 2 de Azure DevOps Server 2020.1: 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 la interfaz de usuario en la 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 con el filtro Ruta de Á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 compilació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 un compendio 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.

Nota:

La herramienta de migración de datos estará disponible para Azure DevOps Server 2020 Update 1 aproximadamente tres semanas después de esta versión. Puede ver la lista de versiones actualmente admitidas para la importación en esta página.

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 un conjunto 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 del tablero
• Mejora la seguridad de las versiones restringiendo el ámbito de los tokens de acceso
• Experiencia mejorada de pull requests
• Desencadenadores de varios repositorios en canalizaciones

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

• Tableros
• Repos
• Canalizaciones
• Artefactos

---

Tableros

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 Bugs pasen de Nuevo a Resuelto. En su lugar, deben ir de estado nuevo a activo a 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 historias de usuario de Nuevo -> Aprobado.

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 "Incluir elementos de trabajo secundarios" al cuadro de diálogo para copiar elementos 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 "Necesita pruebas" en la categoría de Resuelto. Cuando el elemento de trabajo cambia de "Activo" a "Necesita pruebas", se desencadenan las reglas de Resuelta por y Fecha de resolución.

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 del tablero

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 problema importante para los clientes, y estamos encantados de anunciar que ahora puede mover elementos de trabajo entre las columnas del tablero.

Tipos de elementos de trabajo del sistema en proyectos pendientes y tableros

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
	Revisión
	Riesgo

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

Límite de repositorios de la aplicación GitHub de Azure Boards aumentado

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

Personalizar el estado del elemento de trabajo cuando se aprueba una solicitud de incorporación de cambios

No todos los flujos de trabajo son los mismos. Algunos clientes desean cerrar sus elementos de trabajo relacionados cuando se completa un pull request. Otros quieren establecer los elementos de trabajo en otro estado para que sean validados antes de cerrar. Deberíamos permitir ambos.

Tenemos una nueva funcionalidad que le permite establecer los elementos de trabajo en el estado deseado cuando la petición de extracción se fusiona y completa. Para ello, escaneamos la descripción de la solicitud de extracción y buscamos el valor de estado seguido de la mención con el símbolo '#' de los elementos de trabajo. En este ejemplo, estamos estableciendo dos casos de usuario en Resuelto y cerrando dos tareas.

Vincula tu elemento de trabajo a las compilaciones de otro proyecto

Ahora puede realizar un seguimiento sencillo de las dependencias de compilación entre proyectos simplemente vinculando el elemento de trabajo a una compilación, encontrado en compilación o integrado en 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.

Personalizar el estado de los elementos de trabajo cuando se fusiona 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 la demanda popular, ahora puede agregar el campo Padre a las tarjetas hijas y padres del Panel de tareas.

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

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 ya no son bienvenidas. 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, procedimos a quitar esta regla del tipo de elemento de trabajo de Error en el proceso Ágil. Este cambio afectará a cada proyecto que utilice un proceso Agile heredado o un proceso 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 de Elementos de trabajo es un excelente lugar para encontrar rápidamente los elementos que has creado o que te han asignado, entre otros. Proporciona varios pivotes y filtros personalizados. Una de las principales quejas de la vista "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 del filtro Asignado a mí en la página de 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 en solicitudes de extracción. Si tiene un bot o automatización que solo necesita interactuar con los comentarios, puede proporcionarle un token de acceso personal (PAT) solo con este alcance. 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 del Pull Request

La nueva experiencia de solicitud de incorporación de cambios (pull request) 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 vista previa. 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 + clic en elementos del menú

Los menús de pestañas de un PR 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.

• El desplegable de actualizaciones PR recupera la información de tiempo

La lista desplegable para seleccionar la opción de actualizar y comparar archivos en una PR perdió un elemento clave 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 un pull request, 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 al commit padre y comprender mejor cómo difiere ese commit de su propio padre. Esto suele ser necesario cuando desea comprender todos los cambios de una versión. Hemos agregado una tarjeta de nodo padre a un commit 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 algo de 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, visible solo al pasar el cursor.

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 Pull Request, se perderá la posición de desplazamiento del usuario. Este problema se ha corregido; la ubicación de desplazamiento del usuario ahora se conserva al redimensionar el panel de comparación.

• 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, te resulta difícil encontrar un commit por su hash y abrirlo. 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 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.

Tuberías

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.

Soporte de filtros de etiquetas para recursos de canalización

Hemos añadido "etiquetas" en las canalizaciones YAML. Puede usar etiquetas para establecer cuándo se ejecutará la canalización de CI 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 disparador programado establecido para la canalización de CD que solo desea ejecutar si la CI tiene la etiqueta de producción, las etiquetas en la sección de desencadenadores aseguran que la canalización de CD solo se inicie si el evento de finalización de CI cumple con la condición de etiquetado.

Control sobre las tareas que se permiten en las canalizaciones

Ahora puede deshabilitar las tareas de Marketplace. Algunos de vosotros podéis permitir extensiones de Marketplace, pero no las tareas de Pipelines que traen consigo. Para un mayor control, también le permitimos deshabilitar de forma independiente todas las tareas predefinidas (excepto el pago, 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 exclusiva de bloqueo de implementación

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 proseguirá. Cualquier ejecución intermedia se cancelará.

Filtros de fases para los desencadenadores de recursos de la canalización

Hemos 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 activar la canalización de CD. Ahora puede optar por activar su canalización de CD al completar una etapa específica de su 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, Artifactory, etc.) y activar sus 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 del contenido 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 vincularlo a la conexión de servicio de webhook entrante. También puede definir filtros adicionales en el recurso webhook, en función de los datos de carga JSON, para personalizar aún más los desencadenadores de cada pipeline, y puede utilizar 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 tuberías suscritas al evento de Webhook.

Soporte y trazabilidad de los problemas relacionados con los desencadenantes 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 cumplen las condiciones.

   

Desencadenadores multirrepositorio

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 activar el pipeline cada vez que se realiza una actualización en el repositorio de la aplicación.

Con esta actualización, los desencadenadores multirrepositorio 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 tubería en este ejemplo se desencadenará si hay actualizaciones en:

• rama main en el repositorio self 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.

Mejoras en la carga de registros de agentes

Cuando un agente deja de comunicarse con el servidor de Azure Pipelines, el trabajo que se estaba ejecutando se abandona. Si por casualidad miraba los registros de la consola de transmisión, es posible que haya obtenido algunas pistas sobre lo que estaba haciendo el agente justo antes de dejar de responder. Pero si no estuviste, o si actualizaste la página, esos registros de consola desaparecieron. Con esta versión, si el agente deja de responder antes de enviar sus registros completos, conservaremos los registros de la consola como la mejor alternativa. 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.

Montar opcionalmente los volúmenes de contenedor en modo de solo lectura

Al ejecutar un trabajo de contenedor en Azure Pipelines, varios volúmenes que contienen el espacio de trabajo, las tareas y otros materiales se mapean como volúmenes. Estos volúmenes tienen acceso de lectura y escritura por defecto. Para aumentar la seguridad, puede montar los volúmenes de solo lectura modificando la especificación del contenedor en YAML. Cada clave bajo mountReadOnly puede establecerse en true 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

Por lo 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.

Aquí tienes un ejemplo de canalización utilizando la nueva capacidad:

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.

Descomprime paquetes 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, por razones de rendimiento, descomprime las tareas una vez por trabajo incluso si la tarea se usa en varios pasos. Si tiene dudas sobre el hecho de que un código no confiable pueda modificar el contenido descomprimido, puede sacrificar un poco de rendimiento haciendo que el agente descomprima la tarea en cada uso. Para habilitar este modo, pase --alwaysextracttask al configurar el agente.

Mejorar la seguridad de los lanzamientos restringiendo el ámbito de los tokens de acceso.

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

Cada trabajo que se ejecuta en una versión obtiene un token de acceso. Los scripts y las tareas utilizan el token de acceso para realizar llamadas de vuelta 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, nos basamos en la mejora de la seguridad de la canalización al restringir el ámbito de los tokens de acceso y extendemos lo mismo a las versiones clásicas.

Esta característica estará activada de forma predeterminada para los nuevos proyectos y colecciones. Para las colecciones existentes, debe habilitarlo en Configuración > Pipelines > Configuración. > Limite el alcance de autorización de trabajos al proyecto actual para las canalizaciones de lanzamiento. 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 hacer una solicitud POST a https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview para recuperar el cuerpo de YAML finalizado. Esta nueva API toma los mismos parámetros que al poner en cola una ejecución, pero ya no requiere el permiso "Queue builds".

Ejecuta este trabajo a continuación

¿Alguna vez ha tenido una corrección de errores que necesitaba implementar en este momento, pero tuvo que esperar debido a 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 pool, normalmente administradores del pool, 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á el 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 levantado esta restricción para los contenedores. Esto le permite usar los contenidos del parámetro en tiempo de ejecución dentro de sus recursos, por ejemplo, para elegir un contenedor en el momento de la cola. Planeamos ampliar este soporte 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 una tarea en formato 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 tu 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 de Node 6 del agente, solicitamos que actualice las extensiones internas y las tareas personalizadas para que también usen Node 10 pronto. Para usar Node 10 en tu task.json, bajo execution, actualiza 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 página de políticas también se ha actualizado a la nueva plataforma en línea 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, continuamos nuestro camino para integrar a Azure Pipelines en el proceso de gestión de cambios gestionado en ServiceNow hacia las canalizaciones YAML.

Al configurar la comprobación "Administración de cambios de ServiceNow" en un recurso, ahora puede pausar para esperar la aprobación del cambio antes de desplegar 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.

Artefactos

Capacidad de crear fuentes de alcance organizacional desde la interfaz de usuario

Estamos restaurando la capacidad para que los clientes creen y gestionen feeds con alcance de colección a través de la interfaz de usuario web para los servicios locales y en la nube.

Ahora puede crear fuentes con ámbito de organización a través de la interfaz de usuario; simplemente, ir a Artefactos -> Crear Fuente y elija un tipo de fuente dentro del ámbito.

Aunque recomendamos el uso de feeds con ámbito de proyecto en consonancia con el resto de las ofertas de Azure DevOps, puede volver a crear, administrar y usar feeds con ámbito de colección a través de la interfaz de usuario y varias API REST. Consulte nuestra documentación de feeds 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
ID del artefacto	camino	VERDADERO	cadena	Identificador de artefacto del paquete
fuente	camino	VERDADERO	cadena	Nombre o identificador de la fuente
Id de grupo	camino	VERDADERO	cadena	ID de grupo del paquete
colección	camino	VERDADERO	cadena	Nombre de la colección de Azure DevOps
versión	camino	VERDADERO	cadena	Versión del paquete
proyecto	camino		cadena	Id. de proyecto o nombre del proyecto
api-version (versión de API)	consulta	VERDADERO	cadena	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
visualizaciones	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