Notas de la versión de Azure DevOps Server 2020

Comunidad de Desarrolladores | Requisitos del Sistema | Términos de la 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 una nueva ejecución de canalización (compilación) modelo de retención que funciona en función de configuración de de nivel de proyecto.

Azure DevOps Server 2020 gestiona la retención de builds de manera diferente, basándose en las políticas de retención a nivel de canalización. Algunas configuraciones de directiva llevan a que las ejecuciones de canalización se eliminen después de la actualización. Las ejecuciones de canalización que se han retenido manualmente o que están retenidas por un lanzamiento 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 0.2 Patch 6 Release Date: 14 de noviembre de 2023

Hemos publicado una revisión para Azure DevOps Server 2020 Update 0.2 que incluye un conjunto de correcciones para los siguientes problemas.

• Se ha ampliado la lista de caracteres permitidos para las tareas de PowerShell para Habilitar la validación de parámetros 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 4 publicada el 12 de septiembre de 2023. Si no instaló las actualizaciones del agente tal como se describe en las notas de la versión de para el parche 4, se recomienda instalar estas actualizaciones antes de instalar el parche 6. La nueva versión del agente después de instalar patch 4 será la 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	SHA-256 Hash
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 de variables de la canalización.

• Ejemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 5 Release Date: 10 de octubre de 2023

Importante

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

Hemos publicado un parche para Azure DevOps Server 2020 Update 0.2 que incluye correcciones para lo siguiente.

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

Azure DevOps Server 2020 Update 0.2 Patch 4 Release Date: 12 de septiembre de 2023

Hemos lanzado un parche para Azure DevOps Server 2020 Update 0.2 que contiene soluciones 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 Azure DevOps Server 2020 Update 0.2 actualización 4.

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 autohospedados de Windows para desplegar el agente.  

Nota

El AZP_AGENT_DOWNGRADE_DISABLED debe configurarse en "true" para evitar que el agente se degrade. En Windows, se puede usar el siguiente comando en una ventana del símbolo del sistema 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. 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 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 0.2 de Azure DevOps Server 2020: 8 de agosto de 2023

Hemos publicado un parche para Azure DevOps Server 2020 Update 0.2 que incluye correcciones para los siguientes problemas.

• Se ha corregido un error que interfería con el envío de paquetes al actualizar desde 2018 o versiones anteriores.

Azure DevOps Server 2020 Update 0.2 Patch 2 Release Date: 13 de junio de 2023

Hemos publicado un parche para Azure DevOps Server 2020 Update 0.2 que incluye correcciones para lo siguiente.

• Se ha corregido un error que interfería con el envío de paquetes al actualizar desde 2018 o versiones anteriores.

Azure DevOps Server 2020 Update 0.2 Patch 1 Release Date: 18 de octubre de 2022

Hemos publicado un parche para Azure DevOps Server 2020 Update 0.2 que incluye correcciones para lo siguiente.

• Resuelva el problema de que las identidades de AD recién agregadas no aparezcan en los selectores de identidad del cuadro de diálogo de seguridad.
• Se ha corregido un problema con el filtro Solicitado por miembro del grupo en la configuración de web hook.
• Se ha corregido el error de compilación al realizar el check-in 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 liberación.

Fecha de lanzamiento de Azure DevOps Server 2020.0.2: 17 de mayo de 2022

Azure DevOps Server 2020.0.2 es una recopilación de correcciones de errores. Puede instalar directamente Azure DevOps Server 2020.0.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.0.2 aproximadamente tres semanas después de esta versión. Puede ver nuestra lista de versiones admitidas actualmente para importar aquí.

Esta versión incluye correcciones para lo siguiente:

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

• Revocar 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 9 de Azure DevOps Server 2020.0.1: 26 de enero de 2022

Hemos publicado un parche para Azure DevOps Server 2020.0.1 que incluye las siguientes correcciones.

• Las notificaciones por correo electrónico no se enviaron al usar el control @mention en un elemento de trabajo.
• Corregir el error TF400813 al cambiar de cuenta. Este error se produjo cuando se actualizó de TFS 2018 a Azure DevOps Server 2020.0.1.
• Se ha corregido un problema con la página de resumen de Información general del proyecto que no se pudo cargar.
• Mejora de la sincronización de usuarios de Active Directory.
• Se ha solucionado la vulnerabilidad de Elasticsearch quitando la clase jndilookup de los archivos binarios log4j.

Pasos de instalación

1. Actualice el servidor con el parche 9.
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 = Versión, 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 según lo indicado en el archivo de instrucciones. Puede devolver una advertencia como: No se puede conectar al servidor remoto. No cierre la ventana, ya que la actualización intenta repetirse hasta completarse.

Nota

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

1. Actualice el servidor con el parche número 9.
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 = Versión, 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 a la carpeta de archivos remotos de Elasticsearch.
4. Ejecute Configure-TFSSearch.ps1 -Operation update en la máquina del servidor Elasticsearch.

Hash SHA-256 : B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

Fecha de lanzamiento de la revisión 8 de Azure DevOps Server 2020.0.1: 15 de diciembre de 2021

Parche 8 para Azure DevOps Server 2020.0.1 incluye correcciones para lo siguiente.

• Problema con la localización para los estados de disposición de elementos de trabajo personalizados.
• Problema de localización en la plantilla de notificación por correo electrónico.
• Problema con los registros de consola que se truncan cuando hay varios enlaces idénticos en sucesión.
• Problema con la evaluación de reglas NOTSAMEAS cuando se definieron varias reglas NOTSAMEAS para un campo.

Fecha de lanzamiento de la revisión 7 de Azure DevOps Server 2020.0.1: 26 de octubre de 2021

Parche 7 de Azure DevOps Server 2020.0.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 este valor en la página de conexiones de GitHub de 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 6 de Azure DevOps Server 2020.0.1: 14 de septiembre de 2021

Revisión 6 para Azure DevOps Server 2020.0.1 incluye correcciones para lo siguiente:

• Solucione los errores de descarga y carga de artefactos.
• Resuelva el problema de incoherencia en los datos de resultados de pruebas.

Fecha de lanzamiento de la revisión 5 de Azure DevOps Server 2020.0.1: 10 de agosto de 2021

Parche 5 para Azure DevOps Server 2020.0.1 incluye las siguientes correcciones.

• Corregir el error de la interfaz de usuario de la definición de compilación.
• Se ha cambiado el historial de exploración para mostrar archivos en lugar del repositorio raíz.
• Se ha corregido un problema con los procesos de envío de correos electrónicos para algunos tipos de elementos de trabajo.

Fecha de lanzamiento de la revisión 4 de Azure DevOps Server 2020.0.1: 15 de junio de 2021

Parche 4 para Azure DevOps Server 2020.0.1 incluye correcciones de lo siguiente.

• Se ha corregido un problema con la importación de datos. La importación de datos tarda mucho tiempo en los clientes que tienen muchos casos de prueba obsoletos. Esto se debe a referencias que aumentaron el tamaño de la tabla tbl_testCaseReferences. Con esta revisión, se han quitado las referencias a casos de prueba obsoletos para ayudar a acelerar el proceso de importación de datos.

Fecha de lanzamiento de la revisión 3 de Azure DevOps Server 2020.0.1: 11 de mayo de 2021

Hemos publicado un parche para Azure DevOps Server 2020.0.1 que corrige lo siguiente.

• Datos de resultados de pruebas incoherentes al usar Microsoft.TeamFoundation.TestManagement.Client.

Si tiene Azure DevOps Server 2020.0.1, debe instalar Azure DevOps Server 2020.0.1 Patch 3.

Verificación de la instalación

• opción 1: ejecutar devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe es el archivo que se descarga del vínculo anterior. La salida del comando indicará que se ha instalado la revisión o que no está instalada.

• opción 2: compruebe la versión del archivo siguiente: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 está instalado en c:\Program Files\Azure DevOps Server 2020 de forma predeterminada. Después de instalar Azure DevOps Server 2020.0.1 Patch 3, la versión será 18.170.31228.1.

Fecha de lanzamiento del parche 2 de Azure DevOps Server 2020.0.1: 13 de abril de 2021

Nota

Si tiene Azure DevOps Server 2020, primero debe actualizar a Azure DevOps Server 2020.0.1 . Una vez que esté en la versión 2020.0.1, instale el parche 2 de Azure DevOps Server 2020.0.1.

Hemos publicado un parche para Azure DevOps Server 2020.0.1 que corrige lo siguiente.

• CVE-2021-27067: Divulgación de información
• CVE-2021-28459: Elevación de privilegios

Para implementar correcciones para esta revisión, tendrá que seguir los pasos que se indican a continuación para la instalación del parche general, AzureResourceGroupDeploymentV2 y AzureResourceManagerTemplateDeploymentV3 instalación de tareas.

Instalación general de parches

Si tiene Azure DevOps Server 2020.0.1, debe instalar Azure DevOps Server 2020.0.1 Patch 2.

Comprobación de la instalación

• opción 1: ejecutar devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe es el archivo que se descarga del vínculo anterior. La salida del comando indicará que la revisión se ha instalado o que no está instalada.

• opción 2: compruebe la versión del archivo siguiente: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 está instalado en c:\Program Files\Azure DevOps Server 2020 de forma predeterminada. Después de instalar Azure DevOps Server 2020.0.1 Patch 2, la versión será 18.170.31123.3.

Instalación de tareas AzureResourceGroupDeploymentV2

Nota

Todos los pasos mencionados a continuación deben realizarse en una máquina Windows.

Instalar

1. Extraiga el paquete AzureResourceGroupDeploymentV2.zip en una nueva carpeta en su ordenador. Por ejemplo: D:\tasks\AzureResourceGroupDeploymentV2.

2. Descargue e instale Node.js 14.15.1 y npm (incluido con la descarga Node.js) según su máquina.

3. Abra una terminal como administrador y ejecute el siguiente comando para instalar tfx-cli.

npm install -g tfx-cli

4. Cree un token de acceso personal con privilegios de acceso completo y cópielo. Este token de acceso personal se usará al ejecutar el comando de inicio de sesión de tfx de.

5. Ejecute lo siguiente desde la terminal de comandos. Cuando se le solicite, escriba la dirección URL del servicio y el token de acceso personal.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Ejecute el siguiente comando para cargar la tarea en el servidor. Utilice la ruta de acceso del archivo .zip extraído del paso 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Instalación de tareas AzureResourceManagerTemplateDeploymentV3

Nota

Todos los pasos mencionados a continuación deben realizarse en una máquina Windows.

Instalar

1. Extraiga el paquete AzureResourceManagerTemplateDeploymentV3.zip en una nueva carpeta del equipo. Por ejemplo:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

2. Descargue e instale Node.js 14.15.1 y npm (incluido con la descarga Node.js) según corresponda para la máquina.

3. Abra una terminal como administrador y ejecute el siguiente comando para instalar tfx-cli.

npm install -g tfx-cli

4. Cree un token de acceso personal con privilegios de acceso completo y cópielo. Este token de acceso personal se usará al ejecutar el comando de inicio de sesión tfx .

5. Ejecute lo siguiente desde la línea de comandos. Cuando se le solicite, escriba la dirección URL del servicio y el token de acceso personal.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Ejecute el siguiente comando para cargar la tarea en el servidor. Utiliza la ruta del archivo .zip extraído del paso 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Fecha de lanzamiento de la revisión 1 de Azure DevOps Server 2020.0.1: 9 de febrero de 2021

Hemos publicado un parche para Azure DevOps Server 2020.0.1 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• Resuelva el problema notificado en este ticket de comentarios de la Comunidad de Desarrolladores | El botón de Nuevo Caso de Prueba no funciona
• Incluya correcciones publicadas con Azure DevOps Server 2020 Patch 2.

Fecha de lanzamiento de la revisión 3 de Azure DevOps Server 2020: 9 de febrero de 2021

Hemos lanzado un parche para Azure DevOps Server 2020 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• Resuelva el problema notificado en este vale de comentarios de la Comunidad de desarrolladores| El botón Nuevo caso de prueba no funciona

Fecha de lanzamiento de Azure DevOps Server 2020.0.1: 19 de enero de 2021

Azure DevOps Server 2020.0.1 es un paquete acumulativo de correcciones de errores. Puede instalar directamente Azure DevOps Server 2020.0.1 o actualizar desde una instalación existente. Las versiones admitidas para la actualización son Azure DevOps Server 2020, Azure DevOps Server 2019 y Team Foundation Server 2012 o posterior.

Esta versión incluye correcciones para los errores siguientes:

• Resuelva un problema de actualización de Azure DevOps Server 2019 donde el proxy de Git puede dejar de funcionar después de la actualización.
• Se ha corregido la excepción System.OutOfMemoryException para colecciones que no son de ENU anteriores a Team Foundation Server 2017 al actualizar a Azure DevOps Server 2020. Resuelve el problema notificado en la incidencia de comentarios de la Comunidad de desarrolladores reportada en.
• Error de mantenimiento causado por la falta de Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Resuelve el problema notificado en esta entrada de feedback de la comunidad de desarrolladores .
• Se ha corregido un error de nombre de columna no válido en Analytics al actualizar a Azure DevOps Server 2020. Resuelve el problema notificado en este ticket de comentarios de la Comunidad de desarrolladores .
• XSS almacenado al mostrar los pasos del caso de prueba en los resultados del caso de prueba.
• Error del paso de actualización al migrar los datos de resultados de puntos a TCM.

Fecha de lanzamiento de la revisión 2 de Azure DevOps Server 2020: 12 de enero de 2021

Hemos publicado un parche para Azure DevOps Server 2020 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• Los detalles de la ejecución de pruebas no muestran los detalles del paso de prueba para los datos de prueba migrados mediante la migración de OpsHub
• Excepción en el inicializador para "Microsoft.TeamFoundation.TestManagement.Server.TCMLogger"
• Las compilaciones no conservadas se eliminan inmediatamente después de la migración a Azure DevOps Server 2020
• Corrección de la excepción del proveedor de datos

Azure DevOps Server 2020 Parche 1 Fecha: 8 de diciembre de 2020

Hemos lanzado un parche para Azure DevOps Server 2020 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• CVE-2020-17145: Vulnerabilidad de suplantación de identidad de Azure DevOps Server y Team Foundation Services

Fecha de lanzamiento de Azure DevOps Server 2020: 6 de octubre de 2020

Azure DevOps Server 2020 es un conjunto de correcciones de errores. Incluye todas las características de Azure DevOps Server 2020 RC2 publicadas anteriormente.

Nota

Azure DevOps 2020 Server tiene un problema con la instalación de uno de los ensamblados usados por el sistema de archivos virtuales de Git (GVFS).

Si va a actualizar desde Azure DevOps 2019 (cualquier versión) o un candidato de lanzamiento de Azure DevOps 2020 y lo está instalando en el mismo directorio que la versión anterior, no se instalará el ensamblado Microsoft.TeamFoundation.Git.dll. Puede verificar que ha encontrado el problema buscando Microsoft.TeamFoundation.Git.dll en las carpetas <Install Dir>\Version Control Proxy\Web Services\bin, <Install Dir>\Application Tier\TFSJobAgent y <Install Dir>\Tools. Si falta el archivo, puede ejecutar una reparación para restaurar los archivos que faltan.

Para ejecutar una reparación, vaya a Settings -> Apps & Features en la máquina o máquina virtual de Azure DevOps Server y ejecute una reparación en Azure DevOps 2020 Server. Una vez completada la reparación, puede reiniciar la máquina o máquina virtual.

Fecha de lanzamiento de Azure DevOps Server 2020 RC2: 11 de agosto de 2020

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

Fecha de re-lanzamiento de la versión Azure DevOps Server 2020 RC1: 10 de julio de 2020

Hemos relanzado Azure DevOps Server 2020 RC1 para corregir este ticket de comentarios de la Comunidad de desarrolladores y.

Anteriormente, después de actualizar de Azure DevOps Server 2019 Update 1.1 a Azure DevOps Server 2020 RC1, no podía ver archivos en los repositorios, canalizaciones y wiki de la interfaz de usuario web. Se ha producido un mensaje de error que indica se ha producido un error inesperado en esta región de la página. Puede intentar volver a cargar este componente o actualizar toda la página. Con esta versión hemos corregido este problema. Consulte la entrada de blog para obtener más información.

Fecha de lanzamiento de Azure DevOps Server 2020 RC1: 30 de junio de 2020

Resumen de las novedades de Azure DevOps Server 2020

Azure DevOps Server 2020 presenta muchas características nuevas. Algunos de los aspectos destacados son:

• canalizaciones de varias fases
• Despliegue continuo en YAML
• Realizar un seguimiento del progreso de los elementos primarios mediante el trabajo pendiente rollup on Boards
• agregar el filtro "Elemento de trabajo primario" al panel de tareas y al trabajo pendiente de sprint
• Nueva interfaz de usuario web para las páginas de destino de Azure Repos
• administración de políticas de rama entre repositorios
• Nuevo plan de pruebas
• Edición enriquecida para páginas wiki de código
• informes de fallas de la canalización y duración

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

• general
• paneles
• Repos
• Canalizaciones
• Planes de Prueba
• Artefactos
• wiki
• Informes

---

General

Disponibilidad general de la CLI de Azure DevOps

En febrero, se introdujo la extensión de Azure DevOps para la CLI de Azure. La extensión le permite interactuar con Azure DevOps desde la línea de comandos. Hemos recopilado sus comentarios que nos han ayudado a mejorar la extensión y agregar más comandos. Ahora estamos encantados de anunciar que la extensión está disponible con carácter general.

Para más información sobre la CLI de Azure DevOps, consulte la documentación aquí.

Uso del perfil de publicación para implementar Azure WebApps para Windows desde el Centro de implementación

Ahora puede usar la autenticación basada en perfiles de publicación para implementar las aplicaciones web de Azure para Windows desde el Centro de implementación. Si tiene permiso para implementar en una aplicación web de Azure para Windows mediante su perfil de publicación, podrá configurar la canalización mediante este perfil en los flujos de trabajo del Centro de implementación.

Tableros

Agregar el filtro "Elemento de trabajo primario" al panel de tareas y al trabajo pendiente de sprint

Hemos agregado un nuevo filtro tanto al tablero de Sprint como al trabajo pendiente de Sprint. Esto le permite filtrar los elementos pendientes de nivel de requisitos (primera columna a la izquierda) por su elemento principal. Por ejemplo, en la captura de pantalla siguiente, hemos filtrado la vista para mostrar solo historias de usuario en las que el padre es "Mi gran característica".

Mejora de la experiencia de control de errores: campos obligatorios en Error/Tarea

Históricamente, desde el tablero Kanban, si movías un elemento de trabajo de una columna a otra donde el cambio de estado desencadenaba las reglas de campo, la tarjeta solo mostraría un mensaje de error rojo que te obligaba a abrir el elemento de trabajo para comprender la causa raíz. En sprint 170, hemos mejorado la experiencia para que ahora pueda hacer clic en el mensaje de error rojo para ver los detalles del error sin tener que abrir el propio elemento de trabajo.

Recarga en tiempo real del elemento de trabajo

Anteriormente, al actualizar un elemento de trabajo y un segundo miembro del equipo estaba realizando cambios en el mismo elemento de trabajo, el segundo usuario perdería sus cambios. Ahora, siempre que esté editando campos diferentes, verá actualizaciones dinámicas de los cambios realizados en el elemento de trabajo.

Administrar rutas de iteración y área desde la línea de comandos

Ahora puede administrar las rutas de acceso de iteración y área desde la línea de comandos mediante los comandos az boards iteration y az boards area. Por ejemplo, puede configurar y administrar las rutas de acceso de iteración y área de forma interactiva desde la CLI, o automatizar toda la configuración mediante un script. Para obtener más información sobre los comandos y la sintaxis, consulte la documentación aquí.

Columna primaria del elemento de trabajo como opción de columna

Ahora tiene la opción de ver el padre de cada elemento de trabajo en el backlog del producto o el backlog del sprint. Para habilitar esta característica, vaya a Opciones de columna en el trabajo pendiente deseado y luego agregue la columna Padre.

de trabajo pendiente

Cambio del proceso usado por un proyecto

Tus herramientas deben cambiar a medida que lo hace tu equipo; ahora puedes cambiar tus proyectos de cualquier plantilla de proceso integrada a cualquier otro proceso predefinido. Por ejemplo, puede cambiar el proyecto de usar Agile a Scrum o Básico a Agile. Puedes encontrar la documentación completa y detallada aquí.

Ocultar campos personalizados del diseño

Ahora puede ocultar campos personalizados del diseño del formulario al personalizar el proceso. El campo seguirá estando disponible en consultas y API REST. Esto resulta útil para realizar un seguimiento de campos adicionales cuando se integra con otros sistemas.

Obtenga información sobre el estado del equipo con tres nuevos informes de Azure Boards

No puedes corregir lo que no puedes ver. Por lo tanto, desea supervisar de cerca el estado y la salud de sus procesos de trabajo. Con estos informes, facilitamos el seguimiento de las métricas importantes con un esfuerzo mínimo en Azure Boards.

Los tres nuevos informes interactivos son: Gráfico Burndown, Diagrama de Flujo Acumulativo (CFD) y Velocidad. Puede ver los informes en la nueva pestaña análisis.

Las métricas como la reducción del sprint, el flujo de trabajo y la velocidad del equipo le proporcionan la visibilidad del progreso del equipo y ayudan a responder preguntas como:

• ¿Cuánto trabajo hemos dejado en este sprint? ¿Estamos en camino para completarlo?
• ¿Qué paso del proceso de desarrollo tarda más? ¿Podemos hacer algo al respecto?
• En función de las iteraciones anteriores, ¿cuánto trabajo deberíamos planear para el siguiente sprint?

Nota

Los gráficos mostrados anteriormente en los encabezados se han reemplazado por estos informes mejorados.

Los nuevos informes son totalmente interactivos y permiten ajustarlos para sus necesidades. Puede encontrar los nuevos informes en la pestaña Analytics en cada centro.

• El gráfico de agotamiento se puede encontrar en el centro de Sprints.

  

• Se puede acceder a los informes de CFD y Velocidad desde la pestaña Análisis bajo Tableros y Backlogs haciendo clic en la tarjeta correspondiente.

  

Con los nuevos informes tiene más control e información sobre su equipo. Estos son algunos ejemplos:

• Los informes de Sprint Burndown y de Velocidad pueden configurarse para usar el recuento de los elementos de trabajo o la suma del trabajo restante.
• Puede ajustar la duración del burndown del sprint sin afectar las fechas del proyecto. Por lo tanto, si su equipo normalmente dedica el primer día de cada sprint a la planificación, ahora puede ajustar el gráfico para reflejarlo.
• El gráfico de Burndown ahora tiene una marca de agua que muestra los fines de semana.
• El informe CFD le permite quitar columnas del tablero como Diseño para centrarse más en el flujo que los equipos controlan.

Este es un ejemplo del informe CFD que muestra el flujo durante los últimos 30 días del backlog de Stories.

Ahora se puede realizar el seguimiento del gráfico de velocidad para todos los niveles de trabajo pendiente. Por ejemplo, ahora puede agregar tanto Características como Épicas, mientras que el gráfico anterior solo admitía Requisitos. Este es un ejemplo de un informe de velocidad para las últimas 6 iteraciones del backlog de características.

Personalizar columnas del Panel de tareas

Nos complace anunciar que hemos agregado una opción para permitirle personalizar las columnas en el Panel de tareas. Ahora puede agregar, quitar, cambiar el nombre y reordenar las columnas.

Para configurar las columnas en el Panel de tareas, vaya a Opciones de columna.

Esta característica se ha priorizado en función de una sugerencia de la Comunidad de Desarrolladores .

Alternar para mostrar u ocultar los elementos de trabajo secundarios completados en el backlog

Muchas veces, al refinar el trabajo pendiente, solo quieres ver los elementos que no se han completado. Ahora, puede mostrar u ocultar los elementos secundarios completados en la lista de tareas pendientes.

Si el interruptor está activado, verá todos los elementos secundarios en estado completado. Cuando el conmutador está desactivado, todos los elementos secundarios en un estado completado se ocultarán de la lista de tareas pendientes.

Etiquetas más recientes que se muestran al etiquetar un elemento de trabajo

Al etiquetar un elemento de trabajo, la opción autocompletar ahora mostrará hasta cinco de las etiquetas usadas más recientemente. Esto facilitará la adición de la información correcta a los elementos de trabajo.

Reglas de solo lectura y necesarias para la pertenencia a grupos

Las reglas de elementos de trabajo permiten establecer acciones específicas en los campos de elementos de trabajo para automatizar su comportamiento. Puede crear una regla para establecer un campo como solo lectura u obligatorio en función de la pertenencia al grupo. Por ejemplo, es posible que quiera conceder a los propietarios de productos la capacidad de establecer la prioridad de las funcionalidades, haciéndola de solo lectura para todos los demás.

Personalización de los valores de la lista de selección del sistema

Ahora puede personalizar los valores de cualquier lista de selección del sistema (excepto el campo de motivo), como Gravedad, Actividad, Prioridad, etc. Las personalizaciones de la lista de selección se limitan para que pueda administrar valores diferentes para el mismo campo para cada tipo de elemento de trabajo.

Nuevo parámetro de dirección URL del elemento de trabajo

Comparta enlaces a elementos de trabajo con el contexto del tablero o la lista de pendientes con nuestro nuevo parámetro de URL de elemento de trabajo. Ahora puede abrir un cuadro de diálogo de elemento de trabajo en su tablero, backlog, o en la experiencia de sprint añadiendo el parámetro ?workitem=[ID] a la dirección URL.

¡Cualquier persona con la que compartas el enlace llegará con el mismo contexto que tenías cuando lo compartiste!

Mencionar personas, elementos de trabajo y solicitudes de incorporación de cambios en campos de texto

Al escuchar sus comentarios, entendimos que quería la opción de mencionar personas, elementos de trabajo y PRs en la descripción de elementos de trabajo (y otros campos HTML) y no solo en los comentarios. A veces estás colaborando con alguien en un proyecto o quieres destacar un PR en la descripción de tu proyecto, pero no tienes cómo agregar esa información. Ahora puede mencionar personas, elementos de trabajo y solicitudes de incorporación de cambios en todos los campos de texto largos del elemento de trabajo.

Puede ver un ejemplo aquí.

• Para usar menciones de personas, escriba el signo @ y el nombre de la persona que quiera mencionar. @mentions en los campos de los elementos de trabajo generará notificaciones por correo electrónico de manera similar a como lo hace con los comentarios.
• Para usar menciones de elementos de trabajo, escriba el signo # seguido del identificador o título del elemento de trabajo. #mentions creará un vínculo entre los dos elementos de trabajo.
• Para usar menciones de PR, agregue un ! seguido del identificador o el nombre de la solicitud de incorporación de cambios.

Reacciones sobre comentarios de discusión

Uno de nuestros principales objetivos es hacer que los elementos de trabajo sean más colaborativos para los equipos. Recientemente realizamos una encuesta de en Twitter para descubrir qué características de colaboración desea en las discusiones sobre el ítem de trabajo. ¡Las reacciones a los comentarios ganaron la encuesta, así que las agregamos! Estos son los resultados del sondeo de Twitter.

Puede agregar reacciones a cualquier comentario y hay dos maneras de agregar sus reacciones: el icono sonriente en la esquina superior derecha de cualquier comentario, así como en la parte inferior de un comentario junto a cualquier reacción existente. Puede agregar las seis reacciones si lo desea, o solo una o dos. Para eliminar la reacción, haga clic en la reacción en la parte inferior del comentario y se quitará. A continuación puede ver la experiencia de agregar una reacción, así como cómo se ven las reacciones en un comentario.

Anclar informes de Azure Boards al panel

En la actualización del Sprint 155, hemos incluido versiones actualizadas de los informes CFD y Velocity. Estos informes están disponibles en la pestaña Análisis de paneles y trabajos pendientes. Ahora puede anclar los informes directamente al tablero. Para anclar los informes, mantenga el puntero sobre el informe, seleccione el menú de puntos suspensivos "..." y Copiar al tablero.

Seguimiento del progreso de los elementos primarios mediante el trabajo pendiente de acumulación en paneles

Las columnas de acumulación muestran barras de progreso o totales de campos numéricos o elementos descendientes dentro de una jerarquía. Los elementos descendientes abarcan todos los elementos hijos dentro de la jerarquía. Se pueden agregar una o más columnas de resumen a una cartera o lista de pendientes de producto.

Por ejemplo, aquí se muestra Progreso por elementos de trabajo que muestra las barras de progreso de los elementos de trabajo ascendentes en función del porcentaje de elementos descendientes que se han cerrado. Los elementos descendientes de Epics incluyen todas las características hijas y sus elementos de trabajo hijos o nietos. Los elementos descendientes de Features incluyen todas las historias de usuario secundarias y sus elementos de trabajo correspondientes.

Actualizaciones en directo del Panel de tareas

El panel de tareas ahora se actualiza automáticamente cuando se producen cambios. A medida que otros miembros del equipo mueven o reordenen las tarjetas en el panel de tareas, el panel se actualizará automáticamente con estos cambios. Ya no tiene que presionar F5 para ver los cambios más recientes.

Compatibilidad con campos personalizados en columnas de acumulación

Ahora, el resumen se puede realizar en cualquier campo, incluidos los campos personalizados. Al agregar una columna Rollup, todavía puede elegir una columna Rollup de la lista rápida, pero si desea agregar acumulaciones a campos numéricos que no forman parte de la plantilla de proceso predeterminada, puede configurar su propia de la siguiente manera:

1. En tu backlog, haz clic en "Opciones de columna". A continuación, en el panel, haga clic en "Agregar columna de rollup" y Configurar resumen personalizado.

   

2. Elija entre la barra de progreso y el total .
3. Seleccione un tipo de elemento de trabajo o un nivel de trabajo pendiente (normalmente las carteras de pedidos agregan varios tipos de elementos de trabajo).
4. Seleccione el tipo de agregación. Recuento de elementos de trabajo o Suma. Para Suma, deberá seleccionar el campo que desea resumir.
5. El botón Aceptar le devolverá al panel de opciones de columna donde puede reordenar la nueva columna personalizada.

Tenga en cuenta que no puede editar la columna personalizada después de hacer clic en Aceptar. Si necesita realizar un cambio, quite la columna personalizada y agregue otra como desee.

Nueva regla para ocultar campos en un formulario de elemento de trabajo basado en la condición

Hemos agregado una nueva regla al motor de reglas heredadas para permitirle ocultar campos en un formulario de elemento de trabajo. Esta regla ocultará los campos en función de la pertenencia a grupos de usuarios. Por ejemplo, si el usuario pertenece al grupo "propietario del producto", puede ocultar un campo específico del desarrollador. Para obtener más información, consulte la documentación aquí.

Configuración personalizada de notificaciones de elementos de trabajo

Mantenerse al día en los elementos de trabajo relevantes para usted o su equipo es increíblemente importante. Ayuda a los equipos a colaborar y mantenerse al día con proyectos y se asegura de que todas las partes adecuadas estén implicadas. Sin embargo, diferentes partes interesadas tienen diferentes niveles de inversión en diferentes esfuerzos, y creemos que debe reflejarse en su capacidad de seguir el estado de un elemento de trabajo.

Anteriormente, si quisiera seguir un elemento de trabajo y recibir notificaciones sobre los cambios realizados, recibiría notificaciones por correo electrónico para cualquiera y todos los cambios realizados en el elemento de trabajo. Después de considerar sus comentarios, estamos haciendo que el seguimiento de un elemento de trabajo sea más flexible para todas las partes interesadas. Ahora, verá un nuevo botón de configuración junto al botón Seguir en la esquina superior derecha del elemento de trabajo. Esto le llevará a un elemento emergente que le permitirá configurar las opciones siguientes.

Desde configuración de notificaciones, elige entre tres opciones de notificación. En primer lugar, puede cancelar la suscripción por completo. En segundo lugar, puede estar totalmente suscrito, donde obtendrá notificaciones para todos los cambios en el elemento de trabajo. Por último, puede optar por recibir notificaciones para algunos de los eventos de cambio de elementos de trabajo principales y cruciales. Puede seleccionar solo una o las tres opciones. Esto permitirá a los miembros del equipo seguir los elementos de trabajo en un nivel superior y no distraerse por cada cambio que se realice. Con esta característica, eliminaremos correos electrónicos innecesarios y le permitirá centrarse en las tareas cruciales a mano.

Vinculación de elementos de trabajo a implementaciones

Nos complace publicar el control de implementación en el formulario de elemento de trabajo. Este control vincula los elementos de trabajo a una versión y le permite realizar un seguimiento sencillo de dónde se ha implementado el elemento de trabajo. Para más información, consulte la documentación aquí.

Importación de elementos de trabajo desde un archivo CSV

Hasta ahora, la importación de elementos de trabajo desde un archivo CSV dependía del uso del complemento de Excel. En esta actualización se proporciona una experiencia de importación de primera clase directamente desde Azure Boards para poder importar elementos de trabajo nuevos o actualizarlos. Para más información, consulte la documentación aquí.

Agregar un campo primario a las tarjetas de elementos de trabajo

El contexto principal ahora está disponible en el panel Kanban como un nuevo campo para las tarjetas de trabajo. Ahora puede agregar el campo padre a las tarjetas sin la necesidad de usar soluciones alternativas, como etiquetas y prefijos.

Agregar el campo padre al backlog y a las consultas

El campo primario ahora está disponible al ver los trabajos pendientes y los resultados de la consulta. Para agregar el campo padre, use las opciones de columna de vista .

Repos

Métricas de cobertura de código y directiva de rama para solicitudes de incorporación de cambios

Ahora puede ver las métricas de cobertura de código para los cambios dentro de la vista de solicitud de extracción (PR). Esto garantiza que haya probado adecuadamente los cambios a través de pruebas automatizadas. El estado de cobertura aparecerá como comentario en la vista general del PR. Puede ver los detalles de la información de cobertura de cada línea de código que se cambia en la vista de diferencias de archivos.

Además, los propietarios de repositorios ahora pueden establecer directivas de cobertura de código y evitar que los cambios grandes y no probados se combinen en una rama. Los umbrales de cobertura deseados se pueden definir en un archivo de configuración de azurepipelines-coverage.yml que está almacenado en la raíz del repositorio, y la directiva de cobertura se puede definir mediante la capacidad existente de para configurar una directiva de rama para servicios adicionales en Azure Repos.

Filtro de notificaciones de comentarios de solicitudes de incorporación de cambios

Los comentarios en las solicitudes de incorporación de cambios a menudo pueden generar mucho ruido debido a las notificaciones. Hemos agregado una suscripción personalizada que le permite filtrar las notificaciones de comentarios a las que se suscribe por edad del comentario, autor del comentario, comentario eliminado, usuarios mencionados, autor del pull request, rama de destino y participantes del hilo. Para crear estas suscripciones de notificación, haga clic en el icono de usuario de la esquina superior derecha y vaya a Configuración de usuario.

Enlaces de servicio para comentarios de solicitudes de incorporación de cambios

Ahora puede crear enlaces de servicio para comentarios en una solicitud de incorporación de cambios basada en el repositorio y la rama de destino.

Directiva para bloquear archivos con patrones especificados

Los administradores ahora pueden establecer una directiva para evitar que las confirmaciones se envíen a un repositorio en función de los tipos de archivo y las rutas. La directiva de validación de nombres de archivo bloqueará las inserciones que coincidan con el patrón proporcionado.

Resolución de elementos de trabajo a través de confirmaciones usando palabras clave.

Ahora puede resolver los elementos de trabajo mediante commits en la rama predeterminada usando palabras clave como resuelve, resuelve, o resuelto. Por ejemplo, puede escribir - "este cambio corrige #476" en el mensaje de commit y el elemento de trabajo n.º 476 se completará cuando se inserte o fusione el commit en la rama predeterminada. Para obtener más información, consulte la documentación aquí.

Granularidad para revisores automáticos

Anteriormente, al agregar revisores de nivel de grupo a una solicitud de incorporación de cambios, solo se requería una aprobación del grupo que se agregó. Ahora puede establecer políticas que requieran más de un revisor de un equipo para aprobar una solicitud de pull cuando se agregan revisores automáticos. Además, puede agregar una directiva para evitar que los solicitantes aprueben sus propios cambios.

Uso de la autenticación basada en cuentas de servicio para conectarse a AKS

Anteriormente, al configurar Azure Pipelines desde el Centro de implementación de AKS, usamos una conexión de Azure Resource Manager. Esta conexión tenía acceso a todo el clúster y no solo al espacio de nombres para el que se configuró la canalización. Con esta actualización, nuestras canalizaciones usarán la autenticación basada en la cuenta de servicio para conectarse al clúster para que solo tenga acceso al espacio de nombres asociado a la canalización.

Vista previa de los archivos Markdown en la solicitud de incorporación de cambios en paralelo

Ahora puede ver una vista previa del aspecto de un archivo markdown mediante el nuevo botón Vista previa. Además, puede ver el contenido completo de un archivo mediante la comparación paralela seleccionando el botón Ver.

Expiración de directivas de compilación para compilaciones manuales

Las directivas aplican los estándares de calidad de código y administración de cambios de su equipo. Anteriormente, podías establecer directivas de expiración de compilaciones para compilaciones automatizadas. Ahora también puede establecer políticas de caducidad en las compilaciones manuales.

Adición de una directiva para bloquear confirmaciones basadas en el correo electrónico del autor de la confirmación

Los administradores ahora pueden establecer una directiva de inserción para evitar que las confirmaciones se inserte en un repositorio para el que el correo electrónico del autor de confirmación no coincide con el patrón proporcionado.

Esta característica se ha priorizado en función de una sugerencia de de la Comunidad de Desarrolladores para ofrecer una experiencia similar. Seguiremos manteniendo abierta la incidencia y animamos a los usuarios a que nos indiquen qué otros tipos de políticas de notificación les gustaría ver.

Marcar archivos como revisados en un pull request

A veces, debe revisar las solicitudes de incorporación de cambios que contienen cambios en un gran número de archivos y puede ser difícil realizar un seguimiento de los archivos que ya ha revisado. Ahora puede marcar los archivos como revisados en una solicitud de incorporación de cambios.

Puede marcar un archivo como revisado mediante el menú desplegable situado junto a un nombre de archivo o mantenga el puntero y haga clic en el nombre de archivo.

Nota

Esta característica solo está pensada para realizar un seguimiento del progreso a medida que revisa una solicitud de incorporación de cambios. No representa la votación en solicitudes de incorporación de cambios, así que estas marcas solo serán visibles para el revisor/a.

Esta característica se ha priorizado en función de una sugerencia de la comunidad de desarrolladores de .

Nueva interfaz de usuario web para páginas de aterrizaje de Azure Repos

Ahora puede probar nuestras nuevas páginas de aterrizaje modernas, rápidas y fáciles de usar en Azure Repos. Estas páginas están disponibles como páginas de inicio de Nuevos Repositorios. Las páginas de destino incluyen todas las páginas excepto los detalles de la solicitud de extracción, los detalles del commit y la comparación entre ramas.

Web

Móvil

Administración de políticas de rama entre varios repositorios

Las directivas de rama son una de las características eficaces de Azure Repos que le ayudan a proteger ramas importantes. Aunque la capacidad de establecer directivas en el nivel de proyecto existe en la API REST, no había ninguna interfaz de usuario para ella. Ahora, los administradores pueden establecer directivas en una rama específica o en la rama predeterminada en todos los repositorios de su proyecto. Por ejemplo, un administrador podría requerir dos revisores mínimos para todas las solicitudes de incorporación de cambios realizadas en cada rama principal en todos los repositorios de su proyecto. Puede encontrar la característica Agregar protección de rama en la configuración del proyecto de repositorios.

Nuevas páginas de destino de conversión de la plataforma web

Hemos actualizado la experiencia de usuario de las páginas de aterrizaje de Repos para que sea moderna, rápida y fácil de usar. Estos son dos ejemplos de las páginas que se han actualizado, continuaremos actualizando otras páginas en futuras actualizaciones.

Experiencia web:

Experiencia móvil:

Compatibilidad con el lenguaje Kotlin

Nos complace anunciar que ahora se admite el resaltado de lenguaje Kotlin en el editor de archivos. El resaltado mejorará la legibilidad de su archivo de texto de Kotlin y le ayudará a escanear rápidamente para encontrar errores. Hemos priorizado esta característica en función de una sugerencia de la comunidad de desarrolladores de .

Suscripción de notificación personalizada para solicitudes de incorporación de cambios de borrador

Para ayudar a reducir el número de notificaciones por correo electrónico de las solicitudes de incorporación de cambios, ahora puede crear una suscripción de notificación personalizada para las solicitudes de incorporación de cambios que se crean o actualizan en estado de borrador. Puede obtener correos electrónicos específicamente para las solicitudes de incorporación de cambios de borrador o filtrar los correos electrónicos de las solicitudes de incorporación de cambios de borrador para que el equipo no reciba notificaciones antes de que la solicitud de incorporación de cambios esté lista para revisarse.

Mejora de la eficacia en la acción de PR

Cuando tenga muchas solicitudes de incorporación de cambios para revisar, comprender dónde debe tomar medidas primero puede ser difícil. Para mejorar la capacidad de acción de las solicitudes de incorporación de cambios, ahora puede crear varias consultas personalizadas en la página de lista de solicitudes de incorporación de cambios con varias opciones nuevas para filtrar por como el estado de borrador. Estas consultas crearán secciones separadas y plegables en tu página de pull request, además de "Creado por mí" y "Asignado a mí". También puede rechazar revisar un pull request al que fue agregado a través del menú de votación o el menú contextual en la página de lista de pull requests. En las secciones personalizadas, ahora verá pestañas independientes para las solicitudes de incorporación de cambios en las que ha proporcionado una revisión o ha rechazado su revisión. Estas consultas personalizadas funcionarán entre repositorios en la pestaña "Mis solicitudes de incorporación de cambios" de la página principal de la colección. Si desea volver a una solicitud de incorporación de cambios, puede marcarla y se mostrarán en la parte superior de la lista. Por último, los pull requests que se hayan configurado para completar automáticamente se marcarán con una insignia que dice "Completar automáticamente" en la lista.

Tuberías

Canalizaciones de varias fases

Hemos estado trabajando en una experiencia de usuario mejorada para gestionar tus tuberías. Estas actualizaciones actualizan la experiencia de canalizaciones, haciéndola moderna y coherente con la dirección de Azure DevOps. Además, estas actualizaciones reúnen canalizaciones de compilación clásicas y canalizaciones YAML de varias fases en una sola experiencia. Es fácil de usar para dispositivos móviles y aporta varias mejoras a la forma de administrar las canalizaciones. Puede explorar en profundidad y ver los detalles de la canalización, los detalles de ejecución, el análisis de canalización, los detalles del trabajo, los registros, etc.

Las siguientes funcionalidades se incluyen en la nueva experiencia:

• visualización y administración de varias fases
• aprobación de ejecuciones de canalización
• desplazarse hasta atrás en los registros mientras una canalización todavía está en curso
• estado por rama de una canalización.

Implementación continua en YAML

Nos entusiasma ofrecer funcionalidades de CD en YAML de Azure Pipelines. Ahora ofrecemos una experiencia de YAML unificada para que pueda configurar cada una de sus canalizaciones para realizar CI, CD o ambos juntos. Las características de CD de YAML presentan varias características avanzadas nuevas que están disponibles para todas las colecciones mediante canalizaciones YAML de varias fases. Algunos de los aspectos destacados son:

• canalizaciones YAML de varias fases (para CI y CD)
• Aprobaciones y Comprobaciones de Recursos
• Entornos y estrategias de implementación de
• Recursos de Kubernetes y de máquinas virtuales en el entorno
• Evaluar aplicaciones para colaboración
• experiencia de usuario actualizada para las conexiones de servicio
• Recursos en tuberías de YAML

Si está listo para empezar a construir, consulte la documentación de o el blog para crear canalizaciones de CI/CD multietapa.

Administración de variables de canalización en el editor de YAML

Hemos actualizado la experiencia para administrar variables de canalización en el editor de YAML. Ya no tiene que ir al editor clásico para agregar o actualizar variables en las canalizaciones de YAML.

Aprobación de versiones directamente desde el centro de versiones

Se ha facilitado gestionar las aprobaciones pendientes. Antes, era posible aprobar una versión desde la página de detalles. Ahora puede aprobar las versiones directamente desde la sección de lanzamientos.

Mejoras en el inicio de las tuberías

Una pregunta común con el asistente de introducción ha sido la capacidad de cambiar el nombre del archivo generado. Actualmente, está registrado como azure-pipelines.yml en la raíz de su repositorio. Ahora puede actualizarlo a otro nombre de archivo o ubicación antes de guardar la canalización.

Por último, tendrás más control al registrar el archivo azure-pipelines.yml en una rama diferente, ya que puedes omitir la creación de un pull request desde esa rama.

Vista previa del documento YAML totalmente analizado sin confirmar ni ejecutar la canalización

Hemos agregado una versión preliminar de pero modo no se ejecuta para canalizaciones YAML. Ahora, puedes probar una canalización de YAML sin comprometerla a un repositorio ni ejecutarla. Dada una canalización existente y una nueva carga de YAML opcional, esta nueva API le devolverá la canalización completa de YAML. En futuras actualizaciones, esta API se usará en una nueva característica del editor.

Para los desarrolladores: Realice una solicitud POST a dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview con un cuerpo JSON como este:

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

La respuesta contendrá el YAML representado.

Programaciones cron en YAML

Anteriormente, podría usar el editor de interfaz de usuario para especificar un desencadenador programado para canalizaciones YAML. Con esta versión, puede programar compilaciones mediante la sintaxis cron en el archivo YAML y aprovechar las siguientes ventajas:

1. Configuración como código: puedes realizar un seguimiento de los horarios junto con tu canalización como parte del código.
2. Expresivo: usted tiene más poder para definir horarios de manera expresiva que con la interfaz de usuario. Por ejemplo, es más fácil especificar una sola programación que inicia una ejecución cada hora.
3. Estándar del sector: muchos desarrolladores y administradores ya están familiarizados con la sintaxis cron.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

También le hemos facilitado el diagnóstico de problemas con las programaciones cron. Las ejecuciones programadas en el menú Ejecutar canalización le proporcionarán una vista previa de las próximas varias ejecuciones planificadas para su canalización, con el fin de ayudarle a diagnosticar errores en sus programaciones cron.

Actualizaciones de la interfaz de usuario de conexiones de servicio

Hemos estado trabajando en una experiencia de usuario actualizada para administrar las conexiones de servicio. Estas actualizaciones hacen que la experiencia de conexión de servicio sea moderna y coherente con la dirección de Azure DevOps. Hemos introducido la nueva interfaz de usuario para las conexiones de servicio como una característica en versión preliminar anterior este año. Gracias a todos los que probaron la nueva experiencia y nos han proporcionado sus valiosos comentarios.

Junto con la actualización de la experiencia del usuario, también hemos agregado dos funcionalidades que son fundamentales para consumir conexiones de servicio en canalizaciones yaML: autorizaciones de canalización y aprobaciones y comprobaciones.

La nueva experiencia de usuario se activará de forma predeterminada con esta actualización. Todavía tendrá la opción de no participar en la versión preliminar.

Nota

Tenemos previsto introducir uso compartido entre proyectos de conexiones de servicio como una nueva funcionalidad. Puede encontrar más detalles sobre la experiencia de uso compartido y los roles de seguridad aquí.

Omitir fases en una canalización YAML

Al iniciar una ejecución manual, es posible que a veces quiera omitir algunas fases de la canalización. Por ejemplo, si no desea implementar en producción o si desea omitir la implementación en algunos entornos en producción. Ahora puedes hacer esto con tus canalizaciones de YAML.

El panel de canalización de ejecución actualizado presenta una lista de fases del archivo YAML y tiene la opción de omitir una o varias de esas fases. Debe tener precaución al omitir las fases. Por ejemplo, si la primera fase genera determinados artefactos necesarios para las fases posteriores, no debe omitir la primera fase. El panel de ejecución presenta una advertencia genérica cada vez que se omiten las etapas que tienen dependencias posteriores. Se deja a su criterio si esas dependencias son verdaderas dependencias de artefactos o si simplemente están presentes para la secuenciación de implementaciones.

Omitir una fase es equivalente a reconfigurar las dependencias entre fases. Las dependencias inmediatas aguas abajo de la fase omitida se configuran para depender del padre ascendente de la fase omitida. Si se produce un error en la ejecución y si intenta volver a ejecutar una fase con errores, ese intento también tendrá el mismo comportamiento de omisión. Para cambiar las fases que se omiten, debe iniciar un nuevo proceso.

Nueva interfaz de usuario de conexiones de servicio como experiencia predeterminada

Hay una nueva interfaz de usuario de conexiones de servicio. Esta nueva interfaz de usuario se basa en los estándares de diseño modernos y incluye varias características críticas para admitir canalizaciones de CD YAML de varias fases, como aprobaciones, autorizaciones y uso compartido entre proyectos.

Obtenga más información sobre las conexiones de servicio aquí.

Selector de versión de recursos de canalización en el cuadro de diálogo Crear ejecución

Hemos agregado la capacidad de seleccionar manualmente las versiones de recursos de canalización en el cuadro de diálogo Ejecutar. Si consume una canalización de como un recurso en otra canalización, ahora puede elegir la versión de esa canalización al crear una ejecución.

mejoras de la CLI de az para Azure Pipelines

Grupos de variables de canalización y comandos de administración de variables

Puede ser difícil migrar canalizaciones basadas en YAML de un proyecto a otro, ya que es necesario configurar manualmente las variables de canalización y los grupos de variables. Sin embargo, con los comandos de administración del grupo de variables de la canalización , y de las variables ,, ahora puede crear scripts para configurar y gestionar variables de canalización y grupos de variables que pueden ser controlados por versión. Esto le permite compartir fácilmente las instrucciones para mover y configurar canalizaciones de un proyecto a otro.

Ejecutar la canalización para una rama de PR

Al crear una solicitud de incorporación de cambios, puede resultar difícil validar si los cambios podrían interrumpir la ejecución de la canalización en la rama de destino. Sin embargo, con la capacidad de desencadenar una ejecución de canalización o poner en cola una compilación para una rama de PR, ahora puede validar y visualizar los cambios que van ejecutándolo en la canalización de destino. Consulte la documentación del comando az pipelines run y az pipelines build queue para más información.

Omitir la primera ejecución de canalización

Al crear canalizaciones, a veces quiere crear y confirmar un archivo YAML y no desencadenar la ejecución de la canalización, ya que puede dar lugar a una ejecución errónea debido a una variedad de motivos: la infraestructura no está lista o necesita crear y actualizar grupos de variables o variables, etc. Con la CLI de Azure DevOps, ahora puede omitir la primera ejecución de canalización automatizada en la creación de una canalización mediante la inclusión del parámetro --skip-first-run. Consulte az pipeline create command documentation para obtener más información.

Mejora del comando del punto final de servicio

Los comandos de la CLI del punto de conexión de servicio solo admiten la configuración y administración de puntos de conexión de servicio de Azure rm y github. Sin embargo, con esta versión, los comandos de punto de conexión de servicio permiten crear cualquier punto de conexión de servicio proporcionando la configuración a través del archivo y proporciona comandos optimizados: az devops service-endpoint github y az devops service-endpoint azurerm, que proporcionan compatibilidad de primera clase para crear puntos de conexión de servicio de estos tipos. Consulte la documentación del comando para obtener más información.

Trabajos de implementación

Un trabajo de implementación es un tipo especial de trabajo que se usa para implementar la aplicación en un entorno. Con esta actualización, hemos agregado compatibilidad para las referencias de paso en una tarea de implementación. Por ejemplo, puede definir un conjunto de pasos en un archivo y hacer referencia a él en un trabajo de implementación.

También se ha agregado compatibilidad con propiedades adicionales para la tarea de implementación. Por ejemplo, estas son algunas propiedades de un trabajo de implementación que ahora puede establecer,

• timeoutInMinutes: duración máxima de ejecución del trabajo antes de cancelarse automáticamente
• cancelTimeoutInMinutes: cuánto tiempo se debe permitir que las tareas programadas se ejecuten siempre, incluso si están canceladas, antes de terminarlas
• condición: ejecución condicional del trabajo
• variables: los valores codificados de forma rígida se pueden agregar directamente, o se pueden referenciar grupos de variables, un grupo de variables respaldado por un almacén de claves de Azure, o un conjunto de variables definidas en un archivo.
• continueOnError: si se deben ejecutar trabajos futuros incluso si se produce un error en este trabajo de implementación; el valor predeterminado es "false"

Para obtener más información sobre los trabajos de implementación y la sintaxis completa para especificar un trabajo de implementación, consulte Trabajo de implementación.

Mostrar información de canalizaciones de CD asociadas en canalizaciones de CI

Se ha añadido soporte a los detalles de las canalizaciones CD YAML donde se hace referencia a las canalizaciones CI como recursos de canalización. En la vista de ejecución de tu canalización CI, ahora verás una nueva pestaña "Canalizaciones asociadas" donde puedes encontrar todas las ejecuciones de canalización que consumen tu canalización y sus artefactos.

Compatibilidad con paquetes de GitHub en canalizaciones YAML

Recientemente hemos introducido un nuevo tipo de recurso denominado paquetes que agrega compatibilidad para consumir paquetes NuGet y npm desde GitHub como un recurso en canalizaciones YAML. Como parte de este recurso, ahora puede especificar el tipo de paquete (NuGet o npm) que desea consumir desde GitHub. También puede habilitar desencadenadores automáticos de la canalización al liberar una nueva versión del paquete. En la actualidad, la compatibilidad solo está disponible para consumir paquetes de GitHub, pero en el futuro tenemos previsto ampliar la compatibilidad para consumir paquetes de otros repositorios de paquetes, como NuGet, npm, AzureArtifacts y muchos más. Consulte el ejemplo siguiente para obtener más información:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Nota

En la actualidad, los paquetes de GitHub solo admiten la autenticación basada en PAT, lo que significa que la conexión de servicio de GitHub en el recurso del paquete debe ser de tipo PAT. Una vez que se levante esta limitación, proporcionaremos compatibilidad con otros tipos de autenticación.

De forma predeterminada, los paquetes no se descargan automáticamente en los trabajos, por lo que hemos introducido una macro getPackage que permite consumir el paquete definido en el recurso. Consulte el ejemplo siguiente para obtener más información:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Vínculo de clúster de Azure Kubernetes Service en la vista de recursos de entornos de Kubernetes

Hemos agregado un enlace a la vista de recursos de entornos de Kubernetes, permitiéndole navegar a la hoja de Azure para el clúster correspondiente. Esto se aplica a entornos asignados a espacios de nombres en clústeres de Azure Kubernetes Service.

Filtros de carpeta de publicación en suscripciones de notificación

Las carpetas permiten organizar canalizaciones para facilitar la detección y el control de seguridad. A menudo, es posible que desee configurar notificaciones de correo electrónico personalizadas para todas las canalizaciones de lanzamiento, que están representadas por todas las canalizaciones de una carpeta. Anteriormente, tenía que configurar varias suscripciones o tener una consulta compleja en las suscripciones para obtener correos electrónicos centrados. Con esta actualización, ahora puede agregar una cláusula de carpeta de versión a los eventos de implementación completada , y de aprobación pendiente , y simplificar las suscripciones.

Vinculación de elementos de trabajo con canalizaciones YAML de varias fases

Actualmente, puede vincular automáticamente elementos de trabajo con compilaciones clásicas. Sin embargo, esto no era posible con canalizaciones YAML. Con esta actualización hemos abordado esta brecha. Cuando se ejecuta correctamente una canalización mediante código de una rama especificada, Azure Pipelines asociará automáticamente la ejecución a todos los elementos de trabajo (que se deducen a través de las confirmaciones de ese código). Al abrir el elemento de trabajo, podrá ver las ejecuciones en las que se creó el código de ese elemento de trabajo. Para configurarlo, use el panel de configuración de una canalización.

Cancelar fase en la ejecución de una canalización YAML con varias fases

Al ejecutar una canalización YAML de varias fases, ahora puede cancelar la ejecución de una fase mientras está en curso. Esto resulta útil si sabe que se producirá un error en la fase o si tiene otra ejecución que desea iniciar.

Volver a intentar las etapas fallidas

Una de las características más solicitadas en las canalizaciones de varias fases es la capacidad de reintentar una fase con errores sin tener que empezar desde el principio. Con esta actualización, vamos a agregar una gran parte de esta funcionalidad.

Ahora puede volver a intentar una fase de canalización cuando se produce un error en la ejecución. Se reintentan todos los trabajos que fallaron en el primer intento, así como aquellos que dependen transitivamente de esos trabajos fallidos.

Esto puede ayudarle a ahorrar tiempo de varias maneras. Por ejemplo, al ejecutar varios trabajos en una fase, es posible que quiera que cada fase ejecute pruebas en una plataforma diferente. Si se produce un error en las pruebas de una plataforma mientras se superan otras, puede ahorrar tiempo al no volver a ejecutar los trabajos que se han superado. Como otro ejemplo, es posible que se haya producido un error en una fase de implementación debido a una conexión de red poco dinámica. Volver a intentar esa fase le ayudará a ahorrar tiempo al no tener que generar otra compilación.

Hay algunas lagunas conocidas en esta característica. Por ejemplo, no puedes volver a intentar una etapa que canceles explícitamente. Estamos trabajando para cerrar estas brechas en futuras actualizaciones.

Aprobaciones en canalizaciones YAML de varias fases

Las pipelines de CD de YAML pueden contener aprobaciones manuales. Los propietarios de la infraestructura pueden proteger sus entornos y buscar aprobaciones manuales antes de que una fase de cualquier canalización se implemente en ellos. Con la completa segregación de roles entre los propietarios de la infraestructura (entorno) y la aplicación (flujo de trabajo), usted se asegurará de obtener la aprobación manual para la implementación en un flujo de trabajo determinado y obtendrá un control centralizado al aplicar las mismas verificaciones en todas las implementaciones en el entorno.

La pipeline que implementa en dev se detendrá para su aprobación al comienzo de la etapa.

Aumento del límite de tiempo de espera de las puertas y de la frecuencia

Anteriormente, el límite de tiempo de espera del control en los pipelines de liberación era de tres días. Con esta actualización, se ha aumentado el límite de tiempo de espera a 15 días para permitir puertas con duraciones más largas. También aumentamos la frecuencia de la puerta a durante 30 minutos.

Nueva plantilla de imagen de construcción para Dockerfile

Anteriormente, al crear una nueva canalización para un Dockerfile, la plantilla recomendaba insertar la imagen en una instancia de Azure Container Registry e implementarla en Azure Kubernetes Service. Se ha agregado una nueva plantilla para permitirle crear una imagen mediante el agente sin necesidad de subirla a un registro de contenedores.

Nueva tarea para configurar la configuración de la aplicación de Azure App Service

Azure App Service permite la configuración mediante varios ajustes de como los ajustes de aplicación, las cadenas de conexión y otros ajustes de configuración generales. Ahora tenemos una nueva tarea de Azure Pipelines, Configuración de Azure App Service, que admite la configuración de estas opciones de forma masiva mediante la sintaxis JSON en su aplicación web o en cualquiera de sus ranuras de implementación. Esta tarea se puede usar junto con otras tareas de servicios de aplicaciones para implementar, administrar y configurar aplicaciones web, aplicaciones de funciones o cualquier otro servicio de aplicaciones contenedorizado.

Azure App Service ahora admite intercambio con versión preliminar

Azure App Service ahora admite Intercambio con versión preliminar en sus ranuras de implementación. Esta es una buena manera de validar la aplicación con configuración de producción antes de que la aplicación se traslade definitivamente de un entorno de pruebas a un entorno de producción. Esto también garantizaría que el espacio de destino o producción no sufra tiempo de inactividad.

La tarea de Azure App Service ahora soporta este intercambio en varias fases a través de las siguientes acciones nuevas:

• Iniciar intercambio con la versión preliminar: inicia un intercambio con una versión preliminar (intercambio de varias fases) y aplica la configuración de ranura de destino (por ejemplo, la ranura de producción) a la ranura de origen.
• Completar intercambio con vista previa: cuando esté listo para completar el intercambio pendiente, seleccione la acción Completar intercambio con vista previa.
• Cancelar intercambio con la versión preliminar: para cancelar un intercambio pendiente, seleccione Cancelar intercambio con la versión preliminar.

Filtro de nivel de fase para artefactos de Azure Container Registry y Docker Hub

Anteriormente, los filtros de expresiones regulares para los artefactos de Azure Container Registry y Docker Hub solo estaban disponibles en el nivel de canalización de versión. Ahora también se han agregado en el nivel de etapa.

Mejoras en las aprobaciones en las tuberías de YAML

Hemos habilitado la posibilidad de configurar las aprobaciones en las conexiones de servicio y los grupos de agentes. Para las aprobaciones, seguimos la segregación de roles entre los propietarios de infraestructura y los desarrolladores. Al configurar aprobaciones en los recursos, como entornos, conexiones de servicio y grupos de agentes, estará seguro de que todas las ejecuciones de canalización que usan recursos requerirán primero la aprobación.

La experiencia es similar a configurar aprobaciones para entornos. Cuando una aprobación está pendiente en un recurso al que se hace referencia en una fase, la ejecución de la canalización espera hasta que la canalización se apruebe manualmente.

Compatibilidad con pruebas de estructura de contenedor en Azure Pipelines

El uso de contenedores en aplicaciones aumenta y, por tanto, la necesidad de realizar pruebas y validación sólidas. Azure Pipelines ahora ofrece compatibilidad con pruebas de estructura de contenedor. Este marco proporciona una manera cómoda y eficaz de comprobar el contenido y la estructura de los contenedores.

Puede validar la estructura de una imagen basada en cuatro categorías de pruebas que se pueden ejecutar juntas: pruebas de comandos, pruebas de existencia de archivos, pruebas de contenido de archivos y pruebas de metadatos. Puede usar los resultados del proceso para tomar decisiones de continuar o no continuar. Los datos de prueba están disponibles en la ejecución de la canalización con un mensaje de error para ayudarle a solucionar mejor los errores.

Escriba los detalles del archivo de configuración y de la imagen.

Datos de prueba y resumen

Decoradores de canalización para pipelines de despliegue

Los decoradores de canalización permiten agregar pasos al principio y al final de cada trabajo. Esto es diferente de agregar pasos a una sola definición porque se aplica a todas las canalizaciones de una colección.

Hemos estado apoyando decoradores para construcciones y pipelines YAML, con clientes que los utilizan para controlar centralmente los pasos de sus tareas. Ahora también estamos ampliando la compatibilidad con las canalizaciones de versión. Puede crear extensiones para agregar pasos destinados al nuevo punto de contribución, y estos se agregarán a todas las tareas del agente en estas canalizaciones de versión.

Implementación de Azure Resource Manager (ARM) en el nivel de suscripción y grupo de administración

Anteriormente, solo se admitían implementaciones al nivel de grupo de recursos. Con esta actualización se ha agregado compatibilidad para implementar plantillas de ARM en los niveles de suscripción y grupo de administración. Esto le ayudará a implementar un conjunto de recursos juntos, pero colocarlos en diferentes grupos de recursos o suscripciones. Por ejemplo, la implementación de la máquina virtual de copia de seguridad para Azure Site Recovery en un grupo de recursos y una ubicación independientes.

Funcionalidades de CD para las canalizaciones YAML de varias fases

Ahora puede utilizar los artefactos publicados por la canalización de CI y habilitar los triggers de finalización de la canalización. En las canalizaciones YAML de varias fases, estamos introduciendo pipelines como un recurso. En su YAML, ahora puede hacer referencia a otra canalización y también habilitar los gatillos de CD.

Este es el esquema YAML detallado para el recurso de canalizaciones.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

Además, puede descargar los artefactos publicados por su recurso de pipeline utilizando la tarea - download.

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

Para obtener más información, consulte la documentación de descarga de artefactos aquí.

Orquestar la estrategia de despliegue canario en el entorno para Kubernetes

Una de las principales ventajas de la entrega continua de actualizaciones de aplicaciones es la capacidad de insertar rápidamente actualizaciones en producción para microservicios específicos. Esto le ofrece la capacidad de responder rápidamente a los cambios en los requisitos empresariales. Environment se introdujo como un concepto de primera clase que permite la orquestación de estrategias de despliegue y facilita lanzamientos sin tiempo de inactividad. Anteriormente, soportábamos la estrategia de runOnce que ejecutaba los pasos una vez secuencialmente. Con la compatibilidad con la estrategia canaria en canalizaciones de múltiples etapas, ahora puede reducir el riesgo desplegando los cambios gradualmente a un pequeño subconjunto. A medida que obtenga más confianza en la nueva versión, puede empezar a implementarla en más servidores de la infraestructura y enrutar a más usuarios a ella.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

La estrategia canaria para Kubernetes implementará primero los cambios con 10 pods% seguidos de 20% mientras supervisa el estado durante postRouteTraffic. Si todo sale según lo planeado, se ascenderá a 100%.

Estamos buscando comentarios tempranos sobre la compatibilidad con el recurso de máquina virtual en entornos y la estrategia de implementación gradual en varias máquinas. póngase en contacto con nosotros para inscribirse.

Directivas de aprobación para canalizaciones YAML

En las canalizaciones de YAML, se sigue una configuración de aprobación controlada por el propietario del recurso. Los propietarios de recursos configuran las aprobaciones en el recurso, y todas las canalizaciones que utilizan este recurso se detienen para aprobaciones antes de que comience la etapa que lo consume. Es habitual que los propietarios de aplicaciones basadas en SOX restrinjan que el solicitante de la implementación apruebe sus propias implementaciones.

Ahora puede usar opciones avanzadas de aprobación para configurar políticas de aprobación como que el solicitante no debe ser quien aprueba, requerir la aprobación de un subconjunto de usuarios y establecer un tiempo de espera para la aprobación.

ACR como un recurso de canalización de primera clase

Si necesita consumir una imagen de contenedor publicada en ACR (Azure Container Registry) como parte de la canalización y desencadenar la canalización cada vez que se publique una nueva imagen, puede usar el recurso de contenedor de ACR.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

Además, se puede acceder a los metadatos de imagen de ACR mediante variables predefinidas. En la lista siguiente se incluyen las variables de ACR disponibles para definir un recurso de contenedor ACR en la tubería.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Mejoras para evaluar la directiva de comprobaciones de artefactos en canalizaciones

Hemos mejorado la verificación del artefacto de evaluación para añadir fácilmente directivas de una lista de definiciones de directiva listas para usar. La definición de la política se generará automáticamente y se añadirá a la configuración de verificación , la cual se puede actualizar si es necesario.

Soporte para variables de salida en un trabajo de implementación

Ahora puede definir variables de salida en los enlaces de ciclo de vida de de un trabajo de implementación y consumirlas en otros pasos y trabajos de bajada dentro de la misma fase.

Al ejecutar estrategias de implementación, puede acceder a variables de salida entre trabajos mediante la sintaxis siguiente.

• Para estrategia de runOnce: $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Para estrategia de controlado: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Para estrategia gradual de : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Obtenga más información sobre cómo establecer una variable de salida multitrabajo

Evitar la reversión de cambios críticos

En las tuberías de lanzamiento clásicas, es habitual confiar en despliegues programados para actualizaciones periódicas. Pero, cuando tenga una corrección crítica, puede optar por iniciar una implementación manual fuera de banda. Al hacerlo, las versiones anteriores siguen estando programadas. Esto planteó un desafío, ya que la implementación manual se revertiría cuando las implementaciones se reanudaran según el horario previsto. Muchos de ustedes informaron de este problema y ahora lo hemos corregido. Con la corrección, todas las implementaciones programadas anteriores en el entorno se cancelarían al iniciar manualmente una implementación. Esto solo es aplicable cuando se selecciona la opción de puesta en cola como "Implementar más reciente y cancelar otros".

Autorización simplificada de recursos en canalizaciones YAML

Un recurso es cualquier cosa utilizada por una canalización que se encuentra fuera de ella. Los recursos deben estar autorizados para poder usarlos. Anteriormente, al usar recursos no autorizados en una canalización de YAML, se produjo un error de autorización de recursos. Tenía que autorizar los recursos desde la página de resumen de la ejecución con errores. Además, se produjo un error en la canalización si se usaba una variable que hacía referencia a un recurso no autorizado.

Ahora estamos haciendo que sea más fácil administrar las autorizaciones de recursos. En lugar de generar un error en la ejecución, la ejecución esperará los permisos en los recursos al principio de la fase que consume el recurso. Un propietario de recursos puede ver la canalización y autorizar el recurso desde la página de Seguridad.

Evaluación de la verificación de artefactos

Ahora puede definir un conjunto de directivas y agregar la evaluación de directivas como comprobación en un entorno para artefactos de imagen de contenedor. Cuando se ejecuta un pipeline, la ejecución se detiene antes de iniciar una fase que utiliza el entorno. La directiva especificada se evalúa con los metadatos disponibles para la imagen que se va a implementar. La comprobación pasa cuando la política es exitosa y marca la fase como fallida si la comprobación falla.

Actualizaciones de la tarea de implementación de plantillas de ARM

Anteriormente, no filtramos las conexiones de servicio en la tarea de implementación de plantillas de ARM. Esto puede dar lugar a un error en la implementación si selecciona una conexión de servicio de ámbito inferior para realizar implementaciones de plantillas de ARM en un ámbito más amplio. Ahora, se ha agregado el filtrado de conexiones de servicio para filtrar las conexiones de servicio con ámbito inferior en función del ámbito de implementación que elija.

ReviewApp en Entorno

ReviewApp despliega cada pull request desde tu repositorio de Git en un recurso de entorno dinámico. Los revisores pueden ver cómo se ven esos cambios, así como trabajar con otros servicios dependientes antes de combinarlos en la rama principal e implementarlos en producción. Esto le permitirá crear y administrar los recursos de aplicación de revisión y beneficiarse de toda la capacidad de trazabilidad y diagnóstico de las características del entorno. Con la palabra clave reviewApp, puede crear un clon de un recurso (crear dinámicamente un nuevo recurso basado en un recurso existente en un entorno) y agregar el nuevo recurso al entorno.

A continuación se muestra un fragmento de código YAML de ejemplo de uso de reviewApp en entornos.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

Recopilación de metadatos automáticos y especificados por el usuario desde la canalización

Ahora puede habilitar la recopilación de metadatos automática y especificada por el usuario desde tareas de canalización. Puede usar metadatos para aplicar la política de artefactos en un entorno mediante la comprobación de evaluación de artefactos.

Implementaciones de máquinas virtuales con entornos

Una de las características más solicitadas en Entornos era las implementaciones de máquinas virtuales. Con esta actualización, habilitamos el recurso máquina virtual en entornos. Ahora puede orquestar implementaciones en varias máquinas y realizar actualizaciones parciales de mediante canalizaciones YAML. También puede instalar el agente en cada uno de los servidores de destino directamente y dirigir la implementación gradual a esos servidores. Además, puede usar el catálogo de tareas completo en las máquinas de destino.

Una implementación gradual reemplaza las instancias de la versión anterior de una aplicación por instancias de la nueva versión de la aplicación en un conjunto de máquinas (conjunto gradual) en cada iteración.

Por ejemplo, a continuación se implementan actualizaciones de implementación hasta cinco destinos en cada iteración. maxParallel determinará el número de objetivos que se pueden implementar en paralelo. La selección tiene en cuenta el número de objetivos que deben permanecer disponibles en cualquier momento, excluyendo los objetivos a los que se está desplegando. También se usa para determinar las condiciones de éxito y error durante la implementación.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Nota

Con esta actualización, todos los artefactos disponibles de la pipeline actual y de los recursos asociados de la pipeline se descargarán únicamente en el punto de enlace de ciclo de vida deploy. Sin embargo, puede optar por descargar eligiendo la tarea Descargar artefacto de canalización. Hay algunas lagunas conocidas en esta característica. Por ejemplo, cuando vuelva a intentar una fase, volverá a ejecutar el despliegue en todas las máquinas virtuales, incluidas las fallidas. Estamos trabajando para cerrar estas brechas en futuras actualizaciones.

Control adicional de los despliegues

Azure Pipelines ha admitido implementaciones controladas con aprobaciones manuales durante algún tiempo. Con las mejoras más recientes, ahora tiene control adicional sobre las implementaciones. Además de las aprobaciones, los propietarios de recursos ahora pueden agregar checks automatizados para verificar las políticas de seguridad y calidad. Estas comprobaciones se pueden usar para desencadenar operaciones y esperar a que se completen. Con las comprobaciones adicionales, ahora puede definir criterios de salud en función de varios orígenes y asegurarse de que todas las implementaciones destinadas a sus recursos son seguras, independientemente de la canalización de YAML que ejecute la implementación. La evaluación de cada comprobación se puede repetir periódicamente en función de la intervalo de reintento especificado para la comprobación. Ahora están disponibles las siguientes comprobaciones adicionales:

• Invocar cualquier API REST y realizar la validación basada en el cuerpo de respuesta o una devolución de llamada del servicio externo
• Invoca una función de Azure y valida en base a la respuesta o un callback de la función
• Consulta de reglas de Azure Monitor para alertas activas
• Asegúrese de que la canalización extienda una o varias plantillas YAML

Notificación de aprobación

Al agregar una aprobación a un entorno o una conexión de servicio, todas las canalizaciones multifase que utilizan el recurso esperan automáticamente la aprobación al inicio de la etapa. Los aprobadores designados deben completar la aprobación antes de que la canalización pueda continuar.

Con esta actualización, se envía una notificación por correo electrónico a los aprobadores para la aprobación pendiente. Los usuarios y los propietarios del equipo pueden optar por no participar o configurar suscripciones personalizadas mediante configuración de notificación.

Configuración de estrategias de implementación desde Azure Portal

Con esta funcionalidad, le hemos facilitado la configuración de canalizaciones que usan la estrategia de implementación que prefiera, por ejemplo, Rolling, Canaryo Blue-Green. Con estas estrategias integradas, puede implementar actualizaciones de forma segura y mitigar los riesgos de implementación asociados. Para acceder a esto, haga clic en la opción "Entrega continua" en una máquina virtual de Azure. En el panel de configuración, se le pedirá que seleccione detalles sobre el proyecto de Azure DevOps donde se creará la canalización, el grupo de implementación, la canalización de compilación que publica el paquete que se va a implementar y la estrategia de implementación que prefiera. En adelante, configurará una canalización totalmente funcional que implemente el paquete seleccionado en esta máquina virtual.

Para obtener más información, consulte nuestra documentación sobre configuración de estrategias de implementación.

Parámetros en tiempo de ejecución

Los parámetros en tiempo de ejecución permiten tener más control sobre qué valores se pueden pasar a una canalización. A diferencia de las variables, los parámetros en tiempo de ejecución tienen tipos de datos y no se convierten automáticamente en variables de entorno. Con los parámetros en tiempo de ejecución, puedes:

• Proporcionar valores diferentes a scripts y tareas en tiempo de ejecución
• Tipos de parámetros de control, intervalos permitidos y valores predeterminados
• Selección dinámica de trabajos y fases con expresión de plantilla

Para obtener más información sobre los parámetros en tiempo de ejecución, consulte la documentación aquí.

Uso de la palabra clave extends en canalizaciones

Actualmente, las canalizaciones se pueden extraer en plantillas, lo que promueve la reutilización y reduce el código redundante. La estructura general de la canalización todavía estaba definida por el archivo YAML raíz. Con esta actualización, hemos agregado una manera más estructurada de usar plantillas de canalización. Ahora, un archivo YAML raíz puede usar la palabra clave extiende para indicar que la estructura de canalización principal se puede encontrar en otro archivo. Esto le permite controlar qué segmentos se pueden extender o modificar y qué segmentos se han corregido. También hemos perfeccionado los parámetros de pipeline con tipos de datos para especificar los hooks que puede proporcionar.

Este ejemplo ilustra cómo puede proporcionar ganchos simples para que los use el autor de la canalización. La plantilla siempre ejecutará una compilación, ejecutará opcionalmente pasos adicionales proporcionados por la canalización y, a continuación, ejecutará un paso de prueba opcional.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Variables de control que se pueden invalidar en tiempo de cola

Anteriormente, podría usar la interfaz de usuario o la API REST para actualizar los valores de cualquier variable antes de iniciar una nueva ejecución. Aunque el autor de la canalización puede marcar determinadas variables como _settable at queue time_, el sistema no lo aplica ni impide que se configuren otras variables. En otras palabras, la configuración solo se usó para solicitar entradas adicionales al iniciar una nueva ejecución.

Hemos agregado una nueva configuración de colección que aplica el parámetro _settable at queue time_. Esto le proporcionará control sobre qué variables se pueden cambiar al iniciar una nueva ejecución. En el futuro, no se puede cambiar una variable que no esté marcada por el autor como _settable at queue time_.

Nota

Esta configuración está desactivada de forma predeterminada en colecciones existentes, pero estará activada de forma predeterminada al crear una nueva colección de Azure DevOps.

Nuevas variables predefinidas en la canalización de YAML

Las variables proporcionan una manera cómoda de obtener fragmentos clave de datos en varias partes del pipeline. Con esta actualización hemos agregado algunas variables predefinidas a un trabajo de implementación. El sistema establece automáticamente estas variables, cuyo ámbito es el trabajo de implementación específico y es de solo lectura.

• Environment.Id: el identificador del entorno.
• Environment.Name: el nombre del entorno destinado al trabajo de implementación.
• Environment.ResourceId: el identificador del recurso en el entorno destinado al trabajo de implementación.
• Environment.ResourceName: el nombre del recurso en el entorno destinado al trabajo de implementación.

Revisar múltiples repositorios

Las canalizaciones suelen basarse en varios repositorios. Puede tener repositorios diferentes con código fuente, herramientas, scripts u otros elementos que necesite para compilar el código. Anteriormente, tenía que agregar estos repositorios como submódulos o como scripts manuales para ejecutar git checkout. Ahora puede obtener y acceder a otros repositorios, además del que usa para almacenar su canalización de YAML.

Por ejemplo, si tiene un repositorio denominado MyCode con una canalización YAML y un segundo repositorio denominado Tools, la canalización de YAML tendrá este aspecto:

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

El tercer paso mostrará dos directorios, MyCode y Tools en el directorio sources.

Se admiten repositorios git de Azure Repos. Para obtener más información, consulte revisión de múltiples repositorios.

Obtención de detalles en tiempo de ejecución sobre varios repositorios

Cuando se ejecuta una canalización, Azure Pipelines agrega información sobre el repositorio, la rama y la confirmación que desencadenó la ejecución. Ahora que las canalizaciones de YAML admiten la obtención de varios repositorios, es posible que también quiera conocer el repositorio, la rama y el commit que se han obtenido para otros repositorios. Estos datos están disponibles a través de una expresión en tiempo de ejecución, que ahora puede asignar a una variable. Por ejemplo:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Permitir referencias de repositorio a otras colecciones de Azure Repos

Anteriormente, al hacer referencia a repositorios en una canalización YAML, todos los repositorios de Azure Repos tenían que estar en la misma colección que la canalización. Ahora, puede señalar repositorios de otras colecciones mediante una conexión de servicio. Por ejemplo:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection apunta a otra colección de Azure DevOps y tiene credenciales que pueden acceder al repositorio en otro proyecto. Ambos repositorios, self y otherrepo, terminarán desprotegidos.

Importante

MyServiceConnection debe ser una conexión de servicio de Azure Repos o Team Foundation Server, consulte la imagen siguiente.

Metadatos de recursos de canalización como variables predefinidas

Hemos agregado variables predefinidas para los recursos de canalizaciones de YAML en la canalización. Esta es la lista de las variables de recursos de canalización disponibles.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize y kompose como opciones de bake en la tarea KubernetesManifest

kustomize (parte de Kubernetes sig-cli) le permite personalizar archivos YAML sin procesar y sin plantilla para varios propósitos y deja los archivos YAML originales intactos. Se ha agregado una opción para kustomize en la acción de 'bake' de la tarea KubernetesManifest, de modo que cualquier carpeta que contenga archivos kustomization.yaml se pueda usar para generar los archivos de manifiesto utilizados en la acción de implementación de la tarea KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose transformará los archivos de Docker Compose en un recurso de Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Compatibilidad con credenciales de administrador de clústeres en la tarea HelmDeploy

Anteriormente, la tarea HelmDeploy usaba las credenciales de usuario del clúster para las implementaciones. Esto dio lugar a solicitudes de inicio de sesión interactivas y canalizaciones con errores para un clúster habilitado para RBAC basado en Azure Active Directory. Para solucionar este problema, se ha agregado una casilla que le permite usar las credenciales de administrador del clúster en lugar de las credenciales de usuario del clúster.

Entrada de argumentos en la tarea Docker Compose

Se ha introducido un nuevo campo en la tarea Docker Compose para permitir agregar argumentos como --no-cache. La tarea pasará el argumento al ejecutar comandos como build.

Mejoras en la tarea de lanzamiento de GitHub

Hemos realizado varias mejoras en la tarea de Publicación de GitHub. Ahora puede obtener un mejor control sobre la creación de versiones mediante el campo de patrón de etiqueta, especificando una expresión regular de etiquetado. La versión solo se creará cuando el commit que provoca el desencadenante esté etiquetado con una cadena coincidente.

También hemos agregado funcionalidades para personalizar la creación y el formato del registro de cambios. En la nueva sección para la configuración del registro de cambios, ahora puede especificar la versión con la que se debe comparar la versión actual. El lanzamiento comparativo de con puede ser el último lanzamiento completo (excluyendo lanzamientos preliminares), el último lanzamiento no borrador o cualquier lanzamiento previo que coincida con la etiqueta de lanzamiento que proporcionaste. Además, la tarea proporciona un campo de tipo de registro de cambios para dar formato al registro de cambios. Según la selección, el registro de cambios mostrará una lista de commits o una lista de problemas/PRs categorizados según las etiquetas.

Abrir la tarea del instalador del agente de directivas

Open Policy Agent es un motor de directivas de uso general y de código abierto que permite el cumplimiento unificado de directivas compatibles con contexto. Hemos agregado la tarea del instalador de Open Policy Agent. Resulta especialmente útil para la aplicación de directivas en canalizaciones con respecto a proveedores de Infraestructura como Código.

Por ejemplo, Open Policy Agent puede evaluar archivos de directiva Rego y planes de Terraform en el pipeline.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Compatibilidad con scripts de PowerShell en la tarea de CLI de Azure

Anteriormente, podía ejecutar scripts por lotes y bash como parte de una tarea de la CLI de Azure. Con esta actualización, se ha agregado compatibilidad con los scripts de PowerShell y PowerShell Core a la tarea.

Implementaciones canarias basadas en la interfaz de Service Mesh en la tarea de KubernetesManifest

Anteriormente, cuando se especificaba la estrategia canaria en la tarea KubernetesManifest, la tarea creaba cargas de trabajo de referencia y canarias cuyas réplicas equivalían a un porcentaje de las utilizadas para las cargas de trabajo estables. Esto no era exactamente igual que dividir el tráfico hasta el porcentaje deseado en el nivel de solicitud. Para abordar esto, hemos añadido soporte para Service Mesh Interface implementaciones canarias a la tarea KubernetesManifest.

La abstracción de la interfaz de malla de servicio permite una configuración sencilla y directa con proveedores como Linkerd e Istio. Ahora, la tarea KubernetesManifest facilita el trabajo de asignar los objetos TrafficSplit de SMI a los servicios estables, de línea de base y canarios durante todo el ciclo de vida de la estrategia de implementación. La división de porcentaje deseado del tráfico entre estable, línea base y canario es más precisa, ya que la división de tráfico porcentual se controla en las solicitudes del plano de malla de servicio.

A continuación se muestra un ejemplo de cómo realizar implementaciones canary basadas en SMI de manera progresiva.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Azure File Copy Task ahora admite AzCopy V10

La tarea de copia de archivos de Azure se puede usar en una canalización de compilación o implementación para copiar archivos en blobs de almacenamiento de Microsoft o máquinas virtuales (VM). La tarea usa AzCopy, la herramienta de línea de comandos para la copia rápida de datos desde y hacia el almacenamiento de Azure. Con esta actualización, hemos agregado compatibilidad con AzCopy V10, que es la versión más reciente de AzCopy.

El comando azcopy copy solo admite los argumentos asociados. Debido al cambio en la sintaxis de AzCopy, algunas de las funcionalidades existentes no están disponibles en AzCopy V10. Estos incluyen:

• Especificación de la ubicación del registro
• Limpieza de archivos de registro y plan después de la copia
• Reanudación de la copia si se produce un error en el trabajo

Las funcionalidades adicionales admitidas en esta versión de la tarea son:

• Símbolos comodín en el nombre de archivo o ruta de acceso del origen
• Inferencia del tipo de contenido basado en la extensión de archivo cuando no se proporciona ningún argumento
• Definición de la verbosidad del registro para el archivo pasándole un argumento

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

Cada trabajo que se ejecuta en Azure Pipelines obtiene un token de acceso. Las tareas y los scripts usan el token de acceso para volver a llamar a Azure DevOps. Por ejemplo, se usa el token de acceso para obtener código fuente, cargar registros, resultados de pruebas, artefactos 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, hemos agregado las siguientes mejoras.

• Impedir que el token acceda a recursos fuera de un proyecto de equipo

  Hasta ahora, el ámbito predeterminado de todas las canalizaciones era la colección de proyectos de equipo. Puede cambiar el alcance para que sea el proyecto del equipo en las canalizaciones de compilación clásicas. Sin embargo, no tenía ese control para las canalizaciones de versión clásica o YAML. Con esta actualización, estamos introduciendo una configuración de colección para obligar a cada trabajo a obtener un token de alcance de proyecto, independientemente de lo que esté configurado en el pipeline. También se ha agregado el ajuste a nivel de proyecto. Ahora, todos los proyectos y colecciones nuevos que cree tendrán activada automáticamente esta configuración.

  Nota

  La configuración de la colección invalida la configuración del proyecto.

  Activar esta configuración en proyectos y colecciones existentes puede hacer que ciertas canalizaciones fallen si las canalizaciones acceden a recursos que están fuera de los límites del proyecto de equipo mediante tokens de acceso. Para mitigar los errores de canalización, puede conceder explícitamente a la cuenta de servicio de compilación del proyecto acceso al recurso deseado. Se recomienda encarecidamente activar esta configuración de seguridad.

• Limitar el acceso al ámbito de los repositorios de servicio de compilación

  Basándose en la mejora de la seguridad de la canalización mediante la restricción del ámbito del token de acceso, Azure Pipelines ahora puede limitar el acceso de su repositorio a solo los repositorios necesarios para una canalización basada en YAML. Esto significa que si el token de acceso de la canalización se filtrara, solo podría ver los repositorios utilizados en la canalización. Anteriormente, el token de acceso era bueno para cualquier repositorio de Azure Repos en el proyecto o potencialmente toda la colección.

  Esta característica estará activada de forma predeterminada para los nuevos proyectos y colecciones. Para las colecciones existentes, debe habilitarla en Configuración de colecciones>Canalizaciones>Configuración. Al usar esta característica, todos los repositorios necesarios para la compilación, incluso aquellos que clones mediante un script, deben incluirse en los recursos del repositorio de la canalización.

• Quitar determinados permisos para el token de acceso

  De forma predeterminada, se conceden varios permisos al token de acceso, uno de estos permisos es Las compilaciones de cola. Con esta actualización, hemos quitado este permiso al token de acceso. Si las canalizaciones necesitan este permiso, puede concederlo explícitamente a la cuenta de servicio de compilación de proyecto de o cuenta de servicio de compilación de colecciones de proyectos en función del token que use.

Seguridad de nivel de proyecto para conexiones de servicio

Hemos añadido seguridad a nivel de concentrador para las conexiones de servicio. Ahora, puede agregar o quitar usuarios, asignar roles y administrar el acceso en un lugar centralizado para todas las conexiones de servicio.

Segmentación de pasos y aislamiento de comandos

Azure Pipelines admite la ejecución de trabajos en contenedores o en el host del agente. Anteriormente, un trabajo completo se asignaba a uno de esos dos destinos. Ahora, los pasos individuales (tareas o scripts) se pueden ejecutar en el destino que elija. Los pasos también pueden tener como destino otros contenedores, por lo que una canalización podría ejecutar cada paso en un contenedor especializado y diseñado específicamente.

Los contenedores pueden actuar como límites de aislamiento, lo que impide que el código realice cambios inesperados en la máquina host. La forma en que los pasos se comunican con y acceden a servicios del agente no se ven afectados por aislar los pasos en un contenedor. Por lo tanto, también presentamos un modo de restricción de comandos que puede usar con destinos de paso. Al activar esto, se restringirán los servicios que un paso puede solicitar del agente. Ya no podrá adjuntar registros, cargar artefactos ni otras operaciones.

Este es un ejemplo completo, en el que se muestran los pasos en ejecución en el host de un contenedor de trabajos y en otro contenedor:

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Variables de solo lectura

Las variables del sistema se documentaron como inmutables, pero en la práctica podrían ser sobrescritas por una tarea y las tareas subsecuentes recogerían el nuevo valor. Con esta actualización, ajustamos la seguridad en torno a las variables de canalización para que las variables de tiempo de cola y del sistema sean de solo lectura. Además, puede hacer que una variable YAML sea de solo lectura si la marca como se indica a continuación.

variables:
- name: myVar
  value: myValue
  readonly: true

Acceso basado en roles para conexiones de servicio

Hemos agregado acceso basado en rol para las conexiones de servicio. Anteriormente, la seguridad de la conexión de servicio solo se podía administrar a través de grupos de Azure DevOps predefinidos, como administradores de puntos de conexión y creadores de puntos de conexión.

Como parte de este trabajo, hemos introducido los nuevos roles de Lector, Usuario, Creador y Administrador. Puede establecer estos roles a través de la página de conexiones de servicio en su proyecto, y estos roles serán heredados por las conexiones individuales. Y en cada conexión de servicio tiene la opción de activar o desactivar la herencia e invalidar los roles en el ámbito de la conexión de servicio.

Obtenga más información sobre la seguridad de las conexiones de servicio aquí.

Uso compartido entre proyectos de conexiones de servicio

Se ha habilitado la compatibilidad con el uso compartido de conexiones de servicio entre proyectos. Ahora puede compartir las conexiones de servicio con sus proyectos de forma segura y protegida.

Obtenga más información sobre las conexiones de servicio que comparten aquí.

Rastreabilidad de tuberías y recursos de ACR

Se garantiza la rastreabilidad completa de E2E cuando se usan canalizaciones y recursos de contenedor de ACR en una canalización. Para cada recurso consumido por la canalización de YAML, puede realizar un seguimiento de las confirmaciones, los elementos de trabajo y los artefactos.

En la vista del resumen de la ejecución de la canalización, puede ver:

• La versión del recurso que desencadenó la ejecución. Ahora, tu canalización se puede desencadenar tras la finalización de una ejecución de canalización de Azure o cuando se inserta una imagen de contenedor en Azure Container Registry (ACR).

  

• El confirma que consume la canalización. También puede encontrar el desglose de las confirmaciones según cada recurso consumido por la canalización.

  

• Los elementos de trabajo asociados a cada recurso consumido por la canalización.

• Los artefactos que están disponibles para ser utilizados en la ejecución.

  

En la vista de implementaciones del entorno, puede ver las confirmaciones y los elementos de trabajo de cada recurso implementado en el entorno.

Compatibilidad con datos adjuntos de prueba de gran tamaño

La tarea publicar resultados de pruebas en Azure Pipelines le permite publicar resultados de pruebas cuando se ejecutan pruebas para proporcionar una experiencia completa de análisis e informes de pruebas. Hasta ahora, había un límite de 100 MB para los datos adjuntos de prueba tanto para la ejecución de pruebas como para los resultados de pruebas. Esto limita la carga de archivos grandes, como volcados de memoria o vídeos. Con esta actualización, hemos agregado compatibilidad con grandes archivos adjuntos de prueba, permitiéndole tener todos los datos disponibles para solucionar problemas de sus pruebas fallidas.

Usted podría ver la tarea VSTest o la tarea de publicar resultados de pruebas que devuelven un error 403 o 407 en los registros. Si usa compilaciones autohospedados o agentes de versión detrás de un firewall que filtra las solicitudes salientes, deberá realizar algunos cambios de configuración para poder usar esta funcionalidad. ​

Para corregir este problema, se recomienda actualizar el firewall para solicitudes salientes a https://*.vstmrblob.vsassets.io. Puede encontrar información de solución de problemas en la documentación aquí. ​

Nota

Esto solo es necesario si usa agentes de Azure Pipelines autohospedados y está detrás de un firewall que filtra el tráfico saliente. Si usa agentes hospedados por Microsoft en la nube o que no filtran el tráfico de red saliente, no es necesario realizar ninguna acción.

Mostrar la información correcta del grupo de recursos en cada trabajo

Anteriormente, cuando usabas una matriz para expandir trabajos o una variable para identificar un grupo, a veces se resolvía información incorrecta del grupo en las páginas de los registros. Estos problemas se han resuelto.

Desencadenadores de CI para nuevas ramas

Ha sido una larga solicitud pendiente no activar las construcciones del sistema de integración continua (CI) cuando se crea una nueva rama y cuando esa rama no presenta cambios. Tenga en cuenta los ejemplos siguientes:

• Use la interfaz web para crear una nueva rama basada en una rama existente. Esto desencadenaría inmediatamente una nueva compilación de CI si el filtro de rama coincide con el nombre de la nueva rama. Esto no es deseado porque el contenido de la nueva rama es el mismo cuando se compara con la rama existente.
• Tiene un repositorio con dos carpetas: app y docs. Configuró un filtro de ruta para que CI coincida con "app". En otras palabras, no desea crear una nueva compilación si se ha insertado un cambio en los documentos. Cree una nueva rama localmente, realice algunos cambios en los documentos y, a continuación, inserte esa rama en el servidor. Hemos usado para desencadenar una nueva compilación de CI. Esto no es deseado, ya que se le pidió explícitamente que no busque cambios en la carpeta docs. Sin embargo, debido a la forma en que gestionamos un nuevo evento de rama, parecería que también se ha realizado un cambio en la carpeta de la app.

Ahora, tenemos una mejor forma de gestionar CI para las nuevas ramas de código y solucionar estos problemas. Al publicar una nueva rama, buscamos explícitamente nuevos commits en esa rama y comprobamos si coinciden con los filtros de ruta.

Los trabajos pueden acceder a variables de salida de las etapas anteriores

Las variables de salida ahora se pueden usar en varias fases de una canalización basada en YAML. Esto le ayuda a pasar información útil, como una decisión de go/no-go o el identificador de una salida generada, de una fase a la siguiente. El resultado (estado) de una fase anterior y sus tareas también está disponible.

Las variables de salida se siguen generando mediante pasos dentro de los trabajos. En lugar de hacer referencia a dependencies.jobName.outputs['stepName.variableName'], las fases hacen referencia a stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Nota

De forma predeterminada, cada fase de una canalización depende de la anterior en el archivo YAML. Por lo tanto, cada fase puede usar variables de salida de la fase anterior. Puede modificar el gráfico de dependencias, que también modificará qué variables de salida están disponibles. Por ejemplo, si la fase 3 necesita una variable de la fase 1, deberá declarar una dependencia explícita en la fase 1.

Deshabilitar las actualizaciones automáticas de agentes a nivel de pool

Actualmente, los agentes de canalizaciones se actualizarán automáticamente a la versión más reciente cuando sea necesario. Esto suele ocurrir cuando hay una nueva característica o tarea que requiere que una versión más reciente del agente funcione correctamente. Con esta actualización, vamos a agregar la capacidad de deshabilitar las actualizaciones automáticas en un nivel de grupo. En este modo, si no hay ningún agente de la versión correcta conectada al grupo, las canalizaciones producirán un mensaje de error claro en lugar de solicitar que los agentes se actualicen. Esta característica es principalmente de interés para los clientes con grupos autohospedados y requisitos de control de cambios muy estrictos. Las actualizaciones automáticas están habilitadas de forma predeterminada y no se recomienda que la mayoría de los clientes las deshabiliten.

Diagnósticos del agente

Hemos agregado diagnósticos para muchos problemas comunes relacionados con el agente, como muchos problemas de red y causas comunes de errores de actualización. Para empezar a trabajar con diagnósticos, use run.sh --diagnostics o run.cmd --diagnostics en Windows.

Ganchos de servicio para canalizaciones YAML

La integración de servicios con canalizaciones YAML es más fácil. Con los eventos de enlace de servicio para canalizaciones YAML, ahora puede impulsar actividades en aplicaciones o servicios personalizados en función del progreso de las ejecuciones de canalización. Por ejemplo, puede crear un ticket de soporte cuando se requiera una aprobación, iniciar un flujo de trabajo de supervisión una vez completada una fase o enviar una notificación push a los dispositivos móviles del equipo cuando una fase falla.

El filtrado por nombre de canalización y por nombre de fase está disponible para todos los eventos. Los eventos de aprobación también se pueden filtrar para entornos específicos. Del mismo modo, los eventos de cambio de estado se pueden filtrar por el nuevo estado de la ejecución de canalización o la fase.

Integración de Optimizely

Optimizely es una eficaz plataforma de marcado de características y pruebas A/B para los equipos de productos. La integración de Azure Pipelines con la plataforma de experimentación optimizely permite a los equipos de productos probar, aprender e implementar a un ritmo acelerado, al tiempo que obtiene todas las ventajas de DevOps de Azure Pipelines.

La extensión Optimizely para Azure DevOps agrega pasos de experimentación y despliegue de flags de características a las pipelines de compilación y lanzamiento, por lo que puede iterar continuamente, implementar características y revertirlas utilizando Azure Pipelines.

Obtenga más información sobre la extensión Optimizely de Azure DevOps aquí.

Añadir una versión de GitHub como origen de artefacto

Ahora puedes vincular tus versiones de GitHub como fuente de artefactos en canalizaciones de lanzamiento de Azure DevOps. Esto le permitirá consumir la versión de GitHub como parte de las implementaciones.

Al hacer clic en Agregar un artefacto en la definición de canalización de versión, encontrará el nuevo tipo de origen versión de GitHub. Puede proporcionar la conexión de servicio y el repositorio de GitHub para consumir la versión de GitHub. También puede elegir una versión predeterminada para que la publicación de GitHub la consuma como la más reciente, una versión específica por etiqueta, o seleccionarla en el momento de creación de la publicación. Una vez vinculada una versión de GitHub, se descarga y se pone a disposición automáticamente en los trabajos de lanzamiento.

Integración de Terraform con Azure Pipelines

Terraform es una herramienta de código abierto para desarrollar, cambiar y crear versiones de la infraestructura de forma segura y eficaz. Terraform codifica las API en archivos de configuración declarativos, lo que le permite definir y aprovisionar la infraestructura mediante un lenguaje de configuración de alto nivel. Puede usar la extensión de Terraform para crear recursos en todos los principales proveedores de infraestructura: Azure, Amazon Web Services (AWS) y Google Cloud Platform (GCP).

Para obtener más información sobre la extensión de Terraform, consulte la documentación aquí.

Integración con Google Analytics

El marco de experimentos de Google Analytics le permite probar casi cualquier cambio o variación en un sitio web o aplicación para medir su impacto en un objetivo específico. Por ejemplo, es posible que tenga actividades que quiera que completen los usuarios (por ejemplo, realizar una compra, suscribirse a un boletín) o métricas que quiera mejorar (por ejemplo, ingresos, duración de la sesión, tasa de rebote). Estas actividades le permiten identificar los cambios que merece la pena implementar en función del impacto directo que tienen en el rendimiento de la característica.

La extensión de experimentos de Google Analytics para Azure DevOps agrega pasos de experimentación a las canalizaciones de compilación y lanzamiento, lo que le permite iterar, aprender e implementar de forma continua a un ritmo acelerado al administrar los experimentos de manera continua, mientras obtiene todas las ventajas de DevOps de Azure Pipelines.

Puede descargar la extensión de experimentos de Google Analytics desde el Marketplace.

Integración actualizada de ServiceNow con Azure Pipelines

La aplicación Azure Pipelines para ServiceNow ayuda a integrar Azure Pipelines y ServiceNow Change Management. Con esta actualización, puede integrarse con la versión de New York de ServiceNow. La autenticación entre los dos servicios ahora se puede realizar mediante OAuth y la autenticación básica. Además, ahora puede configurar criterios avanzados de éxito para utilizar cualquier propiedad de cambio y decidir el resultado de la puerta.

Creación de Azure Pipelines desde VSCode

Hemos agregado una nueva funcionalidad a la extensión de Azure Pipelines para VSCode. Ahora, podrá crear Azure Pipelines directamente desde VSCode sin salir del IDE.

Administración y resolución de errores poco confiables

Introdujimos la gestión de pruebas intermitentes para admitir el ciclo de vida completo con la detección, la generación de informes y la resolución. Para mejorar aún más, estamos agregando la gestión y resolución de errores de pruebas inestables.

Al investigar la prueba inestable, puede crear un bug mediante la acción de Bug que, a continuación, se puede asignar a un desarrollador para investigar aún más la causa raíz de la prueba inestable. El informe de errores incluye información sobre la canalización, como el mensaje de error, la traza de la pila y otra información asociada a la prueba.

Cuando se resuelve o cierra un informe de errores, se desmarcará automáticamente la prueba como inestable.

Establezca las tareas de VSTest para que fallen si no se ejecuta el número mínimo de pruebas

La tarea VSTest detecta y ejecuta pruebas mediante entradas de usuario (archivos de prueba, criterios de filtro, etc.), así como un adaptador de prueba específico del marco de pruebas que se usa. Los cambios en las entradas de usuario o en el adaptador de prueba pueden provocar casos en los que no se detectan pruebas y solo se ejecuta un subconjunto de las pruebas esperadas. Esto puede provocar situaciones en las que las pipelines tienen éxito porque las pruebas se omiten en vez de debido a que el código tiene una calidad suficientemente alta. Para evitar esta situación, hemos agregado una nueva opción en la tarea VSTest que permite especificar el número mínimo de pruebas que se deben ejecutar para que se supere la tarea.

La opción VSTest TestResultsDirectory está disponible en la interfaz de usuario de la tarea.

La tarea VSTest almacena los resultados de las pruebas y los archivos asociados en la carpeta $(Agent.TempDirectory)\TestResults. Hemos agregado una opción a la interfaz de usuario de la tarea para que pueda configurar una carpeta diferente para almacenar los resultados de las pruebas. Ahora, las tareas posteriores que necesiten los archivos de una ubicación determinada pueden usarlas.

Soporte de Markdown en mensajes de error de prueba automatizada

Hemos agregado compatibilidad con Markdown a los mensajes de error de las pruebas automatizadas. Ahora puede dar formato fácilmente a los mensajes de error tanto para la ejecución de pruebas como para los resultados de las pruebas, a fin de facilitar la legibilidad y mejorar la experiencia de resolución de errores de prueba en Azure Pipelines. La sintaxis de Markdown admitida se puede encontrar aquí.

Uso de decoradores de canalización para insertar pasos automáticamente en un trabajo de implementación

Ahora puedes agregar decoradores de canalización a las tareas de implementación. Puede insertar automáticamente cualquier paso personalizado (por ejemplo, un escáner de vulnerabilidades) en cada ejecución de gancho de ciclo de vida de cada trabajo de implementación. Dado que los decoradores de canalización se pueden aplicar a todas las canalizaciones de una colección, pueden aprovecharse para garantizar prácticas de implementación seguras.

Además, los trabajos de implementación se pueden ejecutar como un trabajo de contenedor de junto con complementos de servicios de si está definido.

Planes de prueba

Página de nuevo plan de prueba

Está disponible una nueva página de Planes de Prueba (Planes de Prueba *) para todas las colecciones de Azure DevOps. La nueva página proporciona vistas simplificadas para ayudarle a centrarse en la tarea a mano: planificación de pruebas, creación o ejecución. También es sin desorden y es coherente con el resto de la oferta de Azure DevOps.

ayudarme a comprender la nueva página

La nueva página Planes de prueba tiene un total de 6 secciones de las que los primeros 4 son nuevos, mientras que las secciones Gráficos & Extensibilidad son la funcionalidad existente.

1. encabezado de plan de prueba: úselo para buscar, marcar como favorito, editar, copiar o clonar un plan de prueba.
2. árbol de conjuntos de pruebas: úselo para agregar, administrar, exportar o ordenar conjuntos de pruebas. Aproveche esto para asignar también configuraciones y realizar pruebas de aceptación del usuario.
3. Definir pestaña: Intercalar, añadir y gestionar casos de prueba en un conjunto de pruebas de su elección a través de esta pestaña.
4. pestaña de Ejecución: Asignar y ejecutar pruebas a través de esta pestaña o buscar un resultado de prueba para examinar en detalle.
5. pestaña Gráfico: realizar un seguimiento de la ejecución y el estado de las pruebas a través de gráficos que también se pueden anclar a los paneles.
6. de extensibilidad: admite los puntos de extensibilidad actuales dentro del producto.

Vamos a tomar una vista general de estas nuevas secciones a continuación.

1. Encabezado del plan de prueba

tareas

El encabezado Plan de prueba permite realizar las siguientes tareas:

• Marcar un plan de prueba como favorito
• Desmarcar un plan de prueba favorito
• Navegar fácilmente entre sus planes de prueba favoritos
• Vea la ruta de iteración del plan de prueba, que indica claramente si el plan de prueba es actual o pasado.
• Ver el resumen rápido del informe Progreso de la prueba con un vínculo para ir al informe
• Vuelva a la página All/Mine Test Plans (Planes de pruebas all/mine)

opciones de menú contextual de

El menú contextual del encabezado Plan de prueba proporciona las siguientes opciones:

• Copiar plan de prueba: se trata de una nueva opción que le permite copiar rápidamente el plan de prueba actual. Más detalles a continuación.
• Editar plan de pruebas: esta opción permite editar el formulario del ítem de trabajo del plan de pruebas para administrar los campos del ítem de trabajo.
• configuración del plan de pruebas: esta opción le permite configurar las opciones de ejecución de pruebas (para asociar canalizaciones de compilación o versión) y la configuración de resultados de la prueba.

copia del plan de pruebas (nueva funcionalidad)

Se recomienda crear un nuevo plan de pruebas por sprint/versión. Al hacerlo, por lo general, el plan de pruebas del ciclo anterior se puede copiar y, con pocos cambios, el plan de prueba copiado está listo para el nuevo ciclo. Para facilitar este proceso, hemos habilitado una funcionalidad "Copiar plan de prueba" en la nueva página. Al aprovecharlo, puede copiar o clonar planes de prueba. Su API REST de respaldo se trata aquí y la API le permite copiar o clonar un plan de prueba entre proyectos.
Para obtener más instrucciones sobre el uso de planes de prueba, consulte aquí.

2. Árbol de suites de pruebas

tareas

El encabezado Test Suite permite realizar las siguientes tareas:

• Expandir o Contraer: esta opción de la barra de herramientas permite expandir o contraer el árbol de jerarquía de la suite.
• Mostrar puntos de prueba de suites secundarias: esta opción de barra de herramientas solo está visible cuando se encuentra en la pestaña "Ejecutar". Esto le permite ver todos los puntos de prueba de la suite dada y sus suites secundarias en una sola vista, para facilitar la administración de los puntos de prueba sin tener que navegar a suites individuales una por una.
• Conjuntos de Órdenes: Puede arrastrar y soltar conjuntos para reorganizar la jerarquía de los conjuntos o moverlos de una jerarquía a otra dentro del plan de prueba.

opciones de menú contextual de

El menú contextual del árbol Conjuntos de pruebas proporciona las siguientes opciones:

• Crear conjuntos nuevos: puede crear tres tipos diferentes de conjuntos de la manera siguiente:
  • Use conjunto estático o conjunto de carpetas para organizar las pruebas.
  • Utiliza la suite basada en requisitos para vincular directamente a los requisitos o historias de usuario para una trazabilidad sin problemas.
  • Usa un enfoque basado en consultas para organizar dinámicamente los casos de prueba que cumplan con los criterios de consulta.
• Asignar configuraciones: puede asignar configuraciones para el conjunto (por ejemplo: Chrome, Firefox, EdgeChromium) y, a continuación, se aplicará a todos los casos de prueba existentes o nuevos casos de prueba que agregue más adelante a este conjunto.
• Exportar como pdf/correo electrónico: exporte las propiedades del plan de prueba, las propiedades del conjunto de pruebas junto con los detalles de los casos de prueba y los puntos de prueba como "correo electrónico" o "imprimir en pdf".
• Abrir elemento de trabajo del conjunto de pruebas: esta opción permite editar el formulario de elemento de trabajo del conjunto de pruebas para administrar los campos del elemento de trabajo.
• Asignar evaluadores para ejecutar todas las pruebas: esta opción es muy útil para escenarios de prueba de aceptación de usuario (UAT) en los que es necesario ejecutar o ejecutar la misma prueba por varios evaluadores, generalmente pertenecientes a diferentes departamentos.
• Cambiar nombre o eliminar: estas opciones permiten administrar el nombre del conjunto o quitar el conjunto y su contenido del plan de prueba.

3. Definir pestaña

La pestaña Definir permite intercalar, agregar y administrar casos de prueba para un conjunto de pruebas. Mientras que la pestaña Ejecutar es para asignar puntos de prueba y ejecutarlos.

La pestaña Definir y ciertas operaciones están disponibles solo para los usuarios con Básico + Planes de prueba nivel de acceso o equivalente. Todo lo demás debe ejercerlo un usuario con el nivel de acceso "Básico".

tareas

La pestaña Definir permite realizar las siguientes tareas:

• Agregar nuevo caso de prueba mediante el formulario de elemento de trabajo: esta opción permite crear un nuevo caso de prueba mediante el formulario de elemento de trabajo. El caso de prueba creado se agregará automáticamente al conjunto de aplicaciones.
• Agregar nuevo caso de prueba mediante la cuadrícula: esta opción permite crear uno o varios casos de prueba mediante la vista de cuadrícula casos de prueba. Los casos de prueba creados se agregarán automáticamente al conjunto de aplicaciones.
• Agregar casos de prueba existentes mediante una consulta: esta opción permite agregar casos de prueba existentes al conjunto especificando una consulta.
• Ordenar Casos de Prueba por Arrastrar/Soltar: Puede reordenar los casos de prueba arrastrando y soltando uno o varios casos de prueba dentro de un conjunto determinado. El orden de los casos de prueba solo se aplica a los casos de prueba manuales y no a las pruebas automatizadas.
• Mover casos de prueba de un conjunto de pruebas a otro: Usando arrastrar y soltar, puede mover casos de prueba de un conjunto de pruebas a otro.
• Mostrar cuadrícula: puede usar el modo cuadrícula para ver y editar casos de prueba junto con los pasos de prueba.
• vista en pantalla completa: Puede ver el contenido de toda la pestaña Definir en modo de pantalla completa con esta opción.
• Filtrado: Mediante la barra de filtros, puede filtrar la lista de casos de prueba utilizando los campos de "título del caso de prueba", "asignado a" y "estado". También puede ordenar la lista haciendo clic en los encabezados de columna.
• Opciones de columna: Puede administrar la lista de columnas visibles en la pestaña Definir mediante "Opciones de columna". La lista de columnas disponibles para la selección son principalmente los campos del formulario de elemento de trabajo del caso de prueba.

opciones de menú contextual de

El menú contextual del nodo Caso de prueba de la pestaña Definir proporciona las siguientes opciones:

• Abrir/editar el formulario del elemento de trabajo del caso de prueba: Esta opción permite editar un caso de prueba mediante el formulario de elemento de trabajo, en el cual se pueden editar los campos del elemento de trabajo, incluidos los pasos de prueba.
• Editar casos de prueba: Esta opción permite editar de forma masiva los campos de los elementos de trabajo de los casos de prueba. Sin embargo, no puede usar esta opción para editar de forma masiva los pasos de prueba.
• Editar casos de prueba en la cuadrícula: esta opción permite editar de forma masiva los casos de prueba seleccionados, incluidos los pasos de prueba mediante la vista de cuadrícula.
• Asignar configuraciones: esta opción permite sobrescribir las configuraciones a nivel de suite con configuraciones a nivel de caso de prueba.
• Quitar casos de prueba: esta opción permite quitar los casos de prueba del conjunto especificado. No obstante, no cambia el elemento de trabajo del caso de prueba subyacente.
• Crear una copia o clonación de casos de prueba: esta opción permite crear una copia o clonación de casos de prueba seleccionados. Consulte a continuación para obtener más detalles.
• Ver elementos vinculados: esta opción permite examinar los elementos vinculados de un caso de prueba determinado. Consulte a continuación para obtener más detalles.

casos de prueba de copia y clonación (nueva funcionalidad)

En escenarios en los que desea copiar o clonar un caso de prueba, puede usar la opción "Copiar caso de prueba". Puede especificar el proyecto de destino, el plan de pruebas de destino y el conjunto de pruebas de destino en el que se va a crear el caso de prueba copia o clonado. Además, también puede especificar si desea incluir vínculos o datos adjuntos existentes para fluir a la copia clonada.

Ver elementos vinculados (nueva funcionalidad)

La rastreabilidad entre artefactos de prueba, requisitos y errores es una propuesta de valor crítica del producto Planes de prueba. Con la opción "Ver elementos vinculados", puede ver fácilmente todos los requisitos vinculados con los que está vinculado este caso de prueba, todos los conjuntos de pruebas o planes de pruebas en los que se ha usado este caso de prueba y todos los errores que se han archivado como parte de la ejecución de pruebas.

4. Pestaña de ejecución

La pestaña Definir permite intercalar, agregar y administrar casos de prueba para un conjunto de pruebas. Mientras que la pestaña Ejecutar es para asignar puntos de prueba y ejecutarlos.

¿Qué es un punto de prueba? casos de prueba por sí mismos no son ejecutables. Al agregar un caso de prueba a un conjunto de pruebas, se generan puntos de prueba. Un punto de prueba es una combinación única de casos de prueba, conjunto de pruebas, configuración y evaluador. Ejemplo: si tiene un caso de prueba como "Funcionalidad de inicio de sesión de prueba" y agrega 2 configuraciones a ella como Edge y Chrome, esto da como resultado 2 puntos de prueba. Ahora se pueden ejecutar estos puntos de prueba. En la ejecución, se generan los resultados de la prueba. A través de la vista de resultados de pruebas (historial de ejecución) puede ver todas las ejecuciones de un punto de prueba. La ejecución más reciente del punto de prueba es lo que vea en la pestaña Ejecutar.
Por lo tanto, los casos de prueba son entidades reutilizables. Al incluirlos en un plan de prueba o conjunto, se generan puntos de prueba. Al ejecutar puntos de prueba, se determina la calidad del producto o servicio que se está desarrollando.

Una de las principales ventajas de la nueva página es para los usuarios que principalmente realizan pruebas de ejecución o seguimiento (solo necesitan tener el nivel de acceso "Básico", no están abrumados por la complejidad de la administración del conjunto de aplicaciones (la pestaña definir está oculta para dichos usuarios).

La pestaña Definir y determinadas operaciones solo están disponibles para los usuarios con nivel de acceso Básico + Planes de prueba o equivalente. Todo lo demás, incluida la pestaña "Ejecutar" debe ser ejecutable por un usuario con el nivel de acceso "Básico".

tareas

La pestaña Ejecutar permite realizar las siguientes tareas:

• marca masiva de puntos de prueba: esta opción permite marcar rápidamente el resultado de los puntos de prueba como superados, fallidos, bloqueados o no aplicables, sin tener que ejecutar el caso de prueba a través del ejecutor de pruebas. El resultado puede marcarse de una vez para uno o varios puntos de prueba.
• Ejecutar puntos de prueba: esta opción le permite ejecutar los casos de prueba de forma individual pasando por cada paso de prueba y marcando que se superan o producen errores mediante un ejecutor de pruebas. En función de la aplicación que esté probando, puede usar "Web Runner" para probar una "aplicación web" o el "ejecutor de escritorio" para probar aplicaciones web o de escritorio. También puede invocar la opción "Ejecutar con opciones" para especificar una compilación con la que desea realizar las pruebas.
• Opciones de columna: Puede administrar la lista de columnas visibles en la pestaña Ejecutar mediante "Opciones de columna". La lista de columnas disponibles para la selección está asociada a puntos de prueba, como Ejecutar por, Evaluador asignado, Configuración, etc.
• vista de pantalla completa: puede ver el contenido de toda la pestaña Ejecutar en el modo de pantalla completa con esta opción.
• Filtrado: Con la barra de filtro, puede filtrar la lista de puntos de prueba mediante los campos de "título del caso de prueba", "asignado a", "estado", "resultado de la prueba", "probador" y "configuración". También puede ordenar la lista haciendo clic en los encabezados de columna.

opciones de menú contextual de

El menú contextual del nodo Punto de prueba de la pestaña Ejecutar proporciona las siguientes opciones:

• Marcar el resultado de la prueba: igual que lo anterior, le permite marcar rápidamente el resultado de los puntos de prueba: superados, con errores, bloqueados o no aplicables.
• Ejecutar puntos de prueba: igual que antes, permite ejecutar los casos de prueba a través del ejecutor de pruebas.
• Restablecer la prueba a activa: esta opción permite restablecer el resultado de la prueba a activo, ignorando el último resultado del punto de prueba.
• formulario para abrir/editar elemento de trabajo del caso de prueba: esta opción permite editar un caso de prueba mediante el formulario del elemento de trabajo donde puede editar los campos del elemento de trabajo, incluidos los pasos de prueba.
• Asignarevaluador: esta opción permite asignar los puntos de prueba a los evaluadores para la ejecución de pruebas.
• Ver el resultado de la prueba: esta opción le permite ver los detalles más recientes del resultado de la prueba, incluido el resultado de cada paso de prueba, comentarios agregados o errores archivados.
• Ver historial de ejecución: esta opción permite ver todo el historial de ejecución del punto de prueba seleccionado. Se abre una nueva página en la que puede ajustar los filtros para ver el historial de ejecución de no solo el punto de prueba seleccionado, sino también para todo el caso de prueba.

Informe de progreso de planes de prueba

Este informe predefinido le ayuda a realizar un seguimiento de la ejecución y el estado de uno o varios planes de prueba de un proyecto. Visite Planes de prueba > Informe de progreso* para empezar a usar el informe.

Entre las tres secciones del informe se incluyen las siguientes:

1. Resumen: muestra una vista consolidada para los planes de prueba seleccionados.
2. Tendencia de resultados: representa una instantánea diaria para proporcionarle una línea de tendencia de ejecución y estado. Puede mostrar datos durante 14 días (valor predeterminado), 30 días o un intervalo personalizado.
3. Detalles: esta sección le permite explorar en profundidad cada plan de prueba y proporciona análisis importantes para cada conjunto de pruebas.

Artefactos

Nota

Azure DevOps Server 2020 no importa fuentes que se encuentran en la papelera de reciclaje durante la importación de datos. Si desea importar fuentes que están en la papelera de reciclaje, restáurelas desde la papelera de reciclaje antes de iniciar la importación de datos.

Expresiones de licencia y licencias insertadas

Ahora puede ver los detalles de la información de licencia de los paquetes NuGet almacenados en Azure Artifacts durante la exploración de paquetes en Visual Studio. Esto se aplica a las licencias que se representan mediante expresiones de licencia o licencias insertadas. Ahora puede ver un vínculo a la información de licencia en la página de detalles del paquete de Visual Studio (flecha roja en la imagen siguiente).

Al hacer clic en el vínculo, se le llevará a una página web donde puede ver los detalles de la licencia. Esta experiencia es la misma para las expresiones de licencia y las licencias insertadas, por lo que puede ver los detalles de licencia de los paquetes almacenados en Azure Artifacts en un solo lugar (para paquetes que especifican información de licencia y son compatibles con Visual Studio).

Tareas de autenticación ligeras

Ahora puede autenticarse con administradores de paquetes populares de Azure Pipelines mediante tareas de autenticación ligeras. Esto incluye NuGet, npm, PIP, Twine y Maven. Anteriormente, podría autenticarse con estos administradores de paquetes mediante tareas que proporcionan una gran cantidad de funcionalidad, incluida la capacidad de publicar y descargar paquetes. Sin embargo, esto requiere el uso de estas tareas para todas las actividades que interactúan con los administradores de paquetes. Si tuviera sus propios scripts para ejecutar tareas como publicar o descargar paquetes, no podrá usarlas en la canalización. Ahora, puede usar scripts de su propio diseño en la canalización YAML y realizar la autenticación con estas nuevas tareas ligeras. Ejemplo con npm:

El uso del comando "ci" y "publish" en esta ilustración es arbitrario, podría usar los comandos admitidos por YAML de Azure Pipelines. Esto le permite tener un control completo de la invocación de comandos y facilita el uso de scripts compartidos en la configuración de la canalización. Para obtener más información, consulte la documentación de la tarea de autenticación de NuGet, npm, PIP, Twiney Maven.

Mejoras en el tiempo de carga de la página de feed

Nos complace anunciar que hemos mejorado el tiempo de carga de la página de fuente. En promedio, los tiempos de carga de página de fuente han disminuido en 10%. Las fuentes más grandes han visto la mejora del tiempo de carga de la página de alimentación percentil 99 (los tiempos de carga más altos en el 99% de todas las fuentes) disminuyeron en 75%.

Comparte tus paquetes públicamente con canales públicos

Ahora puede crear y almacenar sus paquetes en fuentes públicas. Los paquetes almacenados en fuentes públicas están disponibles para todos los usuarios de Internet sin autenticación, independientemente de si están en la colección o incluso han iniciado sesión en una colección de Azure DevOps. Obtenga más información sobre las fuentes públicas en nuestra documentación de fuentes de o vaya directamente a nuestro tutorial de para compartir paquetes públicamente.

Configurar ascendentes en diferentes colecciones dentro de un inquilino de AAD

Ahora puede agregar un feed en otra colección asociada con su inquilino de Azure Active Directory (AAD) como un origen ascendente a su feed de Artifacts. Su feed puede encontrar y usar paquetes de los feeds configurados como orígenes ascendentes, permitiendo el fácil intercambio de paquetes entre las colecciones asociadas con su tenant de AAD. Vea cómo configure esto en la documentación.

Uso del proveedor de credenciales de Python para autenticar pip y twine con fuentes de Azure Artifacts

Ahora puede instalar y usar el proveedor de credenciales de Python (artifacts-keyring) para configurar automáticamente la autenticación para publicar o consumir paquetes de Python en una fuente de Azure Artifacts. Con el proveedor de credenciales, no es necesario configurar ningún archivo de configuración (pip.ini/pip.conf/.pypirc), simplemente se le llevará a través de un flujo de autenticación en el explorador web al llamar a pip o twine por primera vez. Vea más información en la documentación.

Fuentes de Azure Artifacts en el Administrador de paquetes de Visual Studio

Ahora se muestran iconos de paquete, descripciones y autores en el Administrador de paquetes NuGet de Visual Studio para paquetes servidos desde fuentes de Azure Artifacts. Anteriormente, la mayoría de estos metadatos no se proporcionaban a VS.

Experiencia actualizada de conexión a la fuente

El cuadro de diálogo Conectar a la fuente es la entrada al uso de Azure Artifacts; contiene información sobre cómo configurar clientes y repositorios para insertar y extraer paquetes de fuentes en Azure DevOps. Hemos actualizado el cuadro de diálogo para agregar información detallada de configuración y expandimos las herramientas para las que proporcionamos instrucciones.

Las fuentes públicas ahora están disponibles con carácter general con soporte ascendente

La vista previa pública de las fuentes públicas ha recibido una gran aceptación y comentarios. En esta versión, hemos ampliado nuevas características a la disponibilidad general. Ahora, puede establecer una fuente pública como origen ascendente desde una fuente privada. Puede simplificar los archivos de configuración al poder transferir tanto hacia como desde feeds privados y específicos de proyecto.

Crear fuentes de datos de ámbito de proyecto desde el portal

Cuando publicamos fuentes públicas, también publicamos fuentes de ámbito de proyecto . Hasta ahora, las fuentes con ámbito de proyecto se podrían crear a través de las API REST o mediante la creación de una fuente pública y, a continuación, convertir el proyecto en privado. Ahora, puede crear fuentes con ámbito de proyecto directamente en el portal desde cualquier proyecto si tiene los permisos necesarios. También puede ver qué fuentes están dentro del ámbito del proyecto y cuáles están dentro del ámbito de la colección en el selector de fuentes.

Mejoras en el rendimiento de npm

Hemos realizado cambios en nuestro diseño principal para mejorar la forma en que almacenamos y entregamos paquetes npm en fuentes de Azure Artifacts. Esto nos ha ayudado a lograr una reducción de hasta diez veces en la latencia para algunas de las API más utilizadas en npm.

Mejoras de accesibilidad

Hemos implementado correcciones para solucionar problemas de accesibilidad en nuestra página de fuentes. Las correcciones incluyen lo siguiente:

• Crear experiencia de feed
• Experiencia de configuración de canales globales
• Conexión a la experiencia de fuente

Wiki

Edición avanzada para páginas wiki de código

Anteriormente, al editar una página wiki de código, se le redirigió al centro de Azure Repos para su edición. Actualmente, el centro de repositorios no está optimizado para la edición de Markdown.

Ahora puede editar una página wiki de código en el editor en paralelo dentro de la wiki. Esto le permite usar la barra de herramientas de Markdown enriquecida para crear el contenido haciendo que la experiencia de edición sea idéntica a la de la wiki del proyecto. Todavía puede elegir editar en repositorios seleccionando la opción Editar en repositorios en el menú contextual.

Crear e insertar elementos de trabajo desde una página wiki

Tras escuchar sus comentarios, oímos que utilizan wikis para capturar documentos de lluvia de ideas, documentos de planificación, ideas sobre características, documentos de especificación y actas de reunión. Ahora puede crear fácilmente características e historias de usuario directamente desde un documento de planificación sin salir de la página wiki.

Para crear un elemento de trabajo, seleccione el texto de la página wiki donde desea insertar el elemento de trabajo y seleccione Nuevo elemento de trabajo. Esto le ahorra tiempo, ya que no tiene que crear primero el elemento de trabajo, vaya a editar y, a continuación, busque el elemento de trabajo para insertarlo. También reduce los cambios de contexto, ya que no sales del entorno del wiki.

Para obtener más información sobre cómo crear e insertar un elemento de trabajo desde la wiki, consulte nuestra documentación aquí.

Comentarios en páginas wiki

Anteriormente, no tenía una manera de interactuar con otros usuarios wiki dentro de la wiki. Esto hizo que la colaboración en el contenido y obtener respuestas a preguntas fuera un desafío, ya que las conversaciones tenían que ocurrir a través de los canales de correo electrónico o de chat. Con comentarios, ahora puede colaborar con otros usuarios directamente dentro de la wiki. Puede aprovechar la funcionalidad de usuarios de @mention dentro de los comentarios para llamar la atención de los demás miembros del equipo. Esta característica se ha priorizado en función de este ticket de sugerencia. Para obtener más información sobre los comentarios, consulte nuestra documentación aquí.

Ocultar carpetas y archivos a partir de "." en el árbol wiki

Hasta ahora, el árbol wiki mostró todas las carpetas y archivos a partir de un punto (.) en el árbol wiki. En escenarios wiki de código, esto provocó que las carpetas como .vscode, que están diseñadas para estar ocultas, se muestren en el árbol wiki. Ahora, todos los archivos y carpetas que comienzan con un punto permanecerán ocultos en el árbol wiki, reduciendo el desorden innecesario.

Esta característica se ha priorizado en función de esta solicitud de sugerencia.

Direcciones URL de la página Wiki breves y legibles

Ya no tiene que usar una dirección URL de varias líneas para compartir vínculos de página wiki. Estamos aprovechando los identificadores de página en la dirección URL para quitar parámetros, por lo que la dirección URL es más corta y fácil de leer.

La nueva estructura de direcciones URL tendrá el siguiente aspecto:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Este es un ejemplo de la nueva dirección URL de una página de bienvenida a la wiki de Azure DevOps:

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Esto se ha priorizado en función de este ticket de sugerencia de características de la Comunidad de Desarrolladores.

Desplazamiento sincrónico para editar páginas wiki

La edición de páginas wiki ahora es más fácil con el desplazamiento sincrónico entre la edición y el panel de vista previa. El desplazamiento en un lado desplazará automáticamente el otro lado para alinear las secciones correspondientes. Puede deshabilitar el desplazamiento sincrónico con el interruptor.

Nota

El estado del interruptor de desplazamiento sincrónico se guarda por usuario y cuenta.

Visitas a páginas wiki

Ahora puede obtener información sobre las visitas a la página para las páginas wiki. La API REST le permite acceder a la información de visitas de la página en los últimos 30 días. Puede usar estos datos para crear informes para las páginas wiki. Además, puede almacenar estos datos en el origen de datos y crear paneles para obtener información específica, como páginas más vistas de la parte superior n.

También verá un recuento de visitas de página agregadas durante los últimos 30 días en cada página.

Nota

Una visita de página se define como una vista de página por parte de un usuario determinado en un intervalo de 15 minutos.

Informes

Informes de fallos y duración de la canalización

Las métricas y la información le ayudan a mejorar continuamente el rendimiento y la estabilidad de las canalizaciones. Hemos agregado dos nuevos informes para proporcionar información sobre las canalizaciones.

1. El informe de fallos de canalización muestra la tasa de éxito de compilación y la tendencia de fallos. Además, mostrará la tendencia de fallos de tareas para proporcionar información sobre qué tarea del flujo de trabajo contribuye al mayor número de errores.

2. El informe de duración de la canalización indica la tendencia en el tiempo que toma ejecutar una canalización. También muestra qué tareas de la canalización tardan más tiempo.

Mejora del widget Resultados de la consulta

El widget de resultados de consulta es uno de nuestros widgets más populares y por buena razón. El widget muestra los resultados de una consulta directamente en el panel y es útil en muchas situaciones.

Con esta actualización, hemos incluido muchas mejoras muy esperadas.

• Ahora puede seleccionar tantas columnas como quiera mostrar en el widget. No más límite de 5 columnas.
• El widget admite todos los tamaños, de 1x1 a 10x10.
• Al cambiar el tamaño de una columna, el ancho de columna se guardará.
• Puede expandir el widget a la vista de pantalla completa. Cuando se expanda, mostrará todas las columnas devueltas por la consulta.

Filtrado avanzado de widgets de tiempo de prospecto y tiempo de ciclo

Los equipos usan el tiempo de entrega y el tiempo de ciclo para ver cuánto tiempo tarda el trabajo en fluir a través de sus canalizaciones de desarrollo y, en última instancia, ofrecer valor a sus clientes.

Hasta ahora, los widgets de tiempo de ciclo y de entrega no admiten criterios de filtro avanzados para preguntas como: "¿Cuánto tiempo tarda mi equipo en cerrar los elementos de mayor prioridad?"

Con esta actualización, se pueden responder preguntas como esta filtrando en el carril del tablero.

También hemos incluido filtros de elementos de trabajo para limitar los elementos de trabajo que aparecen en el gráfico.

Reducción de sprint en línea mediante puntos de historia

Ahora, el Sprint Burndown se puede desglosar por historias. Esto responde a tus comentarios de la comunidad de desarrolladores .

En el centro de Sprint, seleccione la pestaña Análisis. A continuación, configure el informe como se indica a continuación:

1. Selección del trabajo pendiente de historias
2. Seleccione esta opción para registrar en la suma de puntos de historia

Un widget Sprint Burndown con todo lo que has estado pidiendo

El nuevo widget Sprint Burndown admite la reducción por Puntos de Historia, el recuento de Tareas o mediante la suma de campos personalizados. Incluso puede crear un burndown de sprint para características o épicas. El widget muestra el promedio de agotamiento, % completado y aumento del ámbito. Puede configurar el equipo, permitiéndole mostrar las gráficas de reducción de trabajo del sprint para varios equipos en el mismo tablero. Con toda esta gran información para mostrar, le permitimos redimensionarlo hasta 10x10 en el panel.

Para probarlo, puede agregarlo desde el catálogo de widgets o editar la configuración del widget Sprint Burndown existente y activar el cuadro Probar la nueva versión ahora.

Nota

El nuevo widget usa Analytics. Hemos mantenido el Sprint Burndown heredado en caso de que no tenga acceso a Analytics.

Miniatura de burndown de sprint en línea

¡El Sprint Burndown vuelve! Hace unos cuantos sprints, hemos quitado la quema de sprint en contexto de los encabezados Sprint Burndown y Taskboard. En función de sus comentarios, hemos mejorado y vuelto a introducir la miniatura del burndown de sprint.

Al hacer clic en la miniatura se mostrará inmediatamente una versión más grande del gráfico con una opción para ver el informe completo en la pestaña Análisis. Los cambios realizados en el informe completo se reflejarán en el gráfico que se muestra en el encabezado. Por lo tanto, ahora puede configurarlo para quemar en función de historias, puntos de historia o recuento de tareas, en lugar de solo la cantidad de trabajo restante.

Crear un panel sin un equipo

Ahora puede crear un panel sin asociarlo a un equipo. Al crear un panel, seleccione el tipo Panel de proyectos.

Un panel de proyecto es como un panel de equipo, excepto que no está asociado a un equipo y puede decidir quién puede editar o administrar el panel. Al igual que un panel de equipo, es visible para todos los usuarios del proyecto.

Todos los widgets de Azure DevOps que requieren un contexto de equipo se han actualizado para permitirle seleccionar un equipo en su configuración. Puede agregar estos widgets a los paneles del proyecto y seleccionar el equipo específico que desee.

Nota

En el caso de widgets personalizados o de terceros, un panel de proyectos pasará el contexto del equipo predeterminado a esos widgets. Si tiene un widget personalizado que se basa en el contexto del equipo, debe actualizar la configuración para permitirle seleccionar un equipo.

---

Comentarios

¡Nos encantaría oír de ti! Puede notificar un problema o proporcionar una idea y realizar un seguimiento a través de Developer Community y obtener consejos sobre Stack Overflow.

---

parte superior de la página