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

| Developer CommunityConfiguración de los términos | de licencia de requisitos del sistema | Hashes sha-1 del blog | deDevOps

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 de descargas de Azure DevOps Server.

La actualización directa a Azure DevOps Server 2020 se admite desde 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 provocan que las ejecuciones de canalización se eliminen después de la actualización. Las ejecuciones de canalización que se han retenido 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 obtener más información sobre cómo actualizar de forma segura de Azure DevOps Server 2019 a Azure DevOps Server 2020.

Azure DevOps Server 2020 Update 1.2 Patch 13 Release Date: 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 actualización 1.2 de Azure DevOps Server 2020 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: Azure DevOps Server vulnerabilidad de ejecución remota de código.

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 las 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 publicado 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á la 3.225.0.

Configuración de TFX

1. Siga los pasos descritos en la documentación de carga de 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 usar el nuevo comportamiento, se debe establecer una variable AZP_75787_ENABLE_NEW_LOGIC = true en canalizaciones que usen las tareas afectadas.

• En el 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

Importante

Publicamos actualizaciones del agente de Azure Pipelines con patch 8 publicado 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á la 3.225.0.

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 de "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: Azure DevOps Server vulnerabilidad de ejecución remota de código.
• 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 autohospedado para implementar el agente.  

Nota

El AZP_AGENT_DOWNGRADE_DISABLED debe establecerse en "true" para evitar que el agente se cambie a una versión anterior. En Windows, el siguiente comando se puede usar en un símbolo del sistema administrativo, seguido de un reinicio. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configuración de TFX

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

Actualización de tareas mediante TFX

1. Descargue y extraiga 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 usar el nuevo comportamiento, se debe establecer una variable AZP_75787_ENABLE_NEW_LOGIC = true en canalizaciones que usen las tareas afectadas.

• En el 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 7 Release Date: 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: Azure DevOps Server vulnerabilidad de suplantación de identidad.
• 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 por comentarios en una página de confirmación.
• Se ha corregido un error por 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: Azure DevOps Server vulnerabilidad de suplantación de identidad.
• CVE-2023-21569: Azure DevOps Server vulnerabilidad de suplantación de identidad.
• Se ha corregido un error que interfiere 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 Azure DevOps Server
• Problema de accesibilidad de conjuntos de estantes corregidos a través de la interfaz de usuario web
• Los clientes deben reiniciar el servicio tfsjobagent y Azure DevOps Server grupo de aplicaciones después de actualizar la configuración relacionada con SMTP en la consola de administración de Azure DevOps Server.

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 eliminaron, lo que hace que la base de datos crezca. Con esta corrección, hemos 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 del webhook.
• 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 el error de valor de identidad al asignar un elemento de trabajo a una identidad que aparece en dominios diferentes.

Azure DevOps Server 2020 Update 1.2 Patch 1 Release Date: 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" especificado.

Azure DevOps Server 2020 Update 1.2 Fecha de lanzamiento: 17 de mayo de 2022

Azure DevOps Server 2020 Update 1.2 es un resumen 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 posterior.

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 canalización (compilaciones). Esto significa que el sistema hará lo siguiente:

  • Crear concesiones para las tres compilaciones más recientes generadas al ejecutar Server 2020
  • En el caso de las canalizaciones 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 para la configuración Mínimo para mantener

• Los vínculos de comentarios conjunto de cambios y conjuntos 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 estaba habilitado 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.

Azure DevOps Server fecha de lanzamiento de la revisión 4 de 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.

• Email notificaciones 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 en 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.

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

Azure DevOps Server 2020.1.1 Patch 3 Release Date: 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.

Azure DevOps Server 2020.1.1 Patch 2 Release Date: 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 puede cargar.
• Se ha corregido el problema con los correos electrónicos que no se envían para confirmar la actualización del producto.

Azure DevOps Server 2020.1.1 Patch 1 Release Date: 14 de septiembre de 2021

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

• Corrección del error de descarga/carga de artefactos.
• Resuelva el problema con datos de resultados de pruebas incoherentes.

Azure DevOps Server 2020 Update 1.1 Fecha de lanzamiento: 17 de agosto de 2021

Azure DevOps Server 2020 Update 1.1 es un resumen 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 han corregido casillas de herencia de tipos de mezcla limitados que se muestran para habilitar la modificación de los tipos de combinación de límites después de establecer directivas de repositorios cruzados.

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 vuelva de la página de historial a resumen.

---

Azure DevOps Server 2020.1 Fecha de lanzamiento de la revisión 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.

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

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

• Proteger las cookies usadas en los flujos de autorización que declaran 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.

Azure DevOps Server 2020.1 RTW Fecha de lanzamiento: 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 la Azure DevOps Server 2020.1 RC2 publicadas anteriormente. Azure DevOps Server 2020.1 RTW es un resumen 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 actualización 2020 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.

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

Resumen de las novedades de Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 es un resumen de correcciones de errores. Incluye todas las características de la Azure DevOps Server 2020.1 RC1 publicadas anteriormente.

Azure DevOps Server 2020.1 RC1 Fecha de lanzamiento: 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 a bordo
• Mejora de la seguridad de la versión mediante la restricción del á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 diferencia 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 desde New –> Active -> Resolved

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 los 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 "Necesita pruebas" en la categoría Resuelto. Cuando el elemento de trabajo cambia de "Activo" a "Necesita pruebas", se desencadenan las reglas Resueltas por y Fecha 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 a través de columnas a bordo.

Tipos de elementos de trabajo del sistema en trabajos pendientes 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
Agile	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 que prefiera (ejemplo: Trabajo pendiente de requisitos) y elija la opción de edición. A continuación, agregue el tipo de elemento de trabajo.

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

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

Personalización del estado del elemento de trabajo cuando se combina la 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 cerrarse. Deberíamos permitir ambos.

Tenemos una nueva característica que 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.

Vinculación 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, encontrada 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 la prioridad, la gravedad y la actividad, la descripción no se puede editar. Esta era una brecha 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.

Personalización del estado del elemento de trabajo cuando se combina la solicitud de incorporación de cambios

Las solicitudes de incorporación de cambios suelen hacer referencia a varios elementos de trabajo. Al crear o actualizar una solicitud de incorporación de cambios, es posible que desee 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 detalles.

Campo primario en el panel de tareas

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

Quitar la regla "Asignada a" en el tipo de elemento de trabajo De 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 hora de eliminarlo. Esta regla existe en el tipo de elemento de trabajo Error en el proceso de Agile.

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

Hemos recibido muchos comentarios sobre esta regla. En respuesta, hemos ido adelante y quitamos esta regla del tipo de elemento de trabajo Bug en el proceso agile. Este cambio afectará a cada proyecto mediante un proceso de Agile heredado heredado o un proceso de Agile heredado personalizado. Para aquellos clientes que quieran y dependan 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 quitados en la página Elementos de trabajo

La página Elementos de trabajo es un excelente lugar para encontrar rápidamente los elementos que ha creado o que se le asignan, entre otras cosas. Proporciona varios filtros y tablas dinámicas personalizadas. 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 el estado Quitado). ¡Y estamos de acuerdo! Los elementos quitados 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 quitados 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. Visite Administración de ramas para obtener más detalles.

 

Nota: si no habilita esta característica, los repositorios se inicializarán con el nombre predeterminado de Azure Repos. En este momento, ese valor predeterminado es master. Para respetar el compromiso de Microsoft y las solicitudes de los clientes para el lenguaje inclusivo, nos uniremos al mismo nivel del sector al cambiar este valor predeterminado a principal. Ese cambio se producirá más adelante este verano. Si desea seguir usando master, debe activar esta característica ahora y establecerla en master.

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

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 la 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 por Azure DevOps.

Adición de un nuevo ámbito de autenticación para contribuir a comentarios de solicitudes de incorporación de cambios

Esta versión agrega un nuevo ámbito de OAuth para leer y escribir comentarios de solicitudes de incorporación de cambios. Si tiene un bot o automatización que solo necesita interactuar con 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 llamar 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 admitieron 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. Puesto 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 de actualizaciones de solicitud 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 versión preliminar. 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 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 ir 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 quiera comprender todos los cambios de una versión. Hemos agregado una tarjeta primaria a una confirmación para ayudarle a lograrlo.

• Más espacio para carpetas y archivos con nombres largos en la pestaña Archivos de solicitud de incorporación de cambios

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:

• Conservar la posición de desplazamiento al cambiar el tamaño del panel de diferencias en la pestaña Archivos de solicitud de incorporación de cambios

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.

• Buscar 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.

• Se ha mejorado el uso del espacio para la nueva vista móvil de diferencias de archivos pr.

Hemos actualizado esta página para aprovechar mejor el espacio para que los usuarios puedan ver más del archivo en las 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 rama mejorada al crear una nueva solicitud de incorporación de cambios

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 compatibles 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 con filtros de etiquetas para recursos de canalización

Ahora hemos agregado "etiquetas" en las canalizaciones de YAML. Puede usar etiquetas para establecer la canalización de CI para que se ejecute o cuando se desencadene automáticamente.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    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) para ejecutarse cuando la ejecución de la canalización de CD (implementación continua) no se desencadena 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.

Controlar qué tareas se permiten en las canalizaciones

Ahora puede deshabilitar las tareas de Marketplace. Algunos de ustedes pueden permitir extensiones de Marketplace, pero no las tareas de canalizaciones que llevan a cabo. Para un mayor control, también le permitimos deshabilitar de forma independiente todas las tareas en la caja (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 denominada "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, continuará la ejecución más reciente. Se cancelarán las ejecuciones intermedias.

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 después de completar 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) mediante los que 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, estamos introduciendo 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 >del 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 elementos 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 en 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 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 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á. Cada vez 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 los 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 alguna actualización 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.

Se han mejorado las cargas del registro del agente

Cuando un agente deja de comunicarse con el servidor de Azure Pipelines, el trabajo que se estaba ejecutando se abandona. Si le ha ocurrido examinar los registros de la consola de streaming, es posible que haya recibido 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, en ocasiones, 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.

Opcionalmente, monte volúmenes de contenedor de solo 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 el 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 mountReadOnly se 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 específico sobre el inicio o detención del contenedor

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 de Docker.

Esta es una canalización de ejemplo con 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 en 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.

Descomprimir agrupaciones 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 la modificación del contenido descomprimido en el código que no es de confianza, 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.

Mejora de la seguridad de la versión mediante la restricción del ámbito de los tokens de acceso

Basándose en nuestra iniciativa para mejorar la configuración de seguridad de Azure Pipelines, ahora se admite la restricción del á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 al restringir el ámbito de los tokens de acceso y ampliar el 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 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 de la API en versión preliminar de YAML

Ahora puede obtener una vista previa del YAML completo de una canalización sin ejecutarlo. Además, hemos creado una dirección URL dedicada para la funcionalidad de versión preliminar. Ahora puede publicar 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 "Compilaciones de cola".

Ejecución de este trabajo a continuación

¿Alguna vez ha tenido un error que necesitaba implementar en este momento , pero tuvo 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á el trabajo que se ejecutará lo antes posible. (Seguirá necesitando 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 de parámetros 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 sobre las actualizaciones de tareas automatizadas de 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 últimas adiciones de características y correcciones de errores. 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

Dado que el nodo 6 ya no se admite, estamos migrando las tareas para que funcionen con el nodo 10. Para esta actualización, hemos migrado casi el 50 % de las tareas incorporadas 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 el nodo 10 próximamente. Para usar el nodo 10 para la tarea, en , en task.jsonexecution, actualice de Node a Node10.

Mejora de la conversión de YAML en el diseñador de compilaciones clásicas

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 a 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 única 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 todas las ramas en las 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 ir 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 la administración de cambios de ServiceNow con canalizaciones YAML

La aplicación Azure Pipelines para ServiceNow le ayuda a integrar Azure Pipelines y ServiceNow Change Management. Con esta actualización, realizamos nuestro recorrido por hacer 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 "ServiceNow Change Management" en un recurso, ahora puede pausar el cambio que se aprobará antes de implementar la compilación en ese recurso. Puede crear automáticamente un nuevo cambio para una fase o esperar en 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 desde 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 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 volver a crear, administrar y usar fuentes con ámbito de colecció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.

Update Package Version REST API now available for Maven packages (Actualizar la versión del paquete DE REST API ya disponible para paquetes de Maven)

Ahora puede usar la API REST "Update Package Version" de Azure Artifacts para actualizar las versiones del paquete de Maven. Anteriormente, podía usar la API REST para actualizar las versiones de paquetes de NuGet, Maven, npm y Paquetes universales, pero no los 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	TRUE	string	Identificador de artefacto del paquete
feed	path	TRUE	string	Nombre o identificador de la fuente
groupId	path	TRUE	string	Id. de grupo del paquete
collection	path	TRUE	string	Nombre de la colección de Azure DevOps
version	path	TRUE	string	Versión del paquete
proyecto	path		string	Id. de proyecto o nombre del proyecto
api-version	Query	TRUE	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 de él a través de Developer Community y obtener consejos sobre Stack Overflow.

---

Principio de página