Notas de la versión de Azure DevOps Server 2020

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

En este artículo, encontrará información sobre la versión más reciente de Azure DevOps Server.

Para obtener más información sobre cómo instalar o actualizar una implementación de Azure DevOps Server, consulte requisitos de Azure DevOps Server. Para descargar productos de Azure DevOps, visite la página descargas de Azure DevOps Server.

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

---

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

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

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

Lea nuestra entrada de blog para 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 correcciones para lo siguiente.

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

Nota

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

Instalación de revisiones

Importante

Publicamos actualizaciones del agente de Azure Pipelines con patch 4 publicado el 12 de septiembre de 2023. Si no instaló las actualizaciones del agente como se describe en las notas de la versión de Patch 4, se recomienda instalar estas actualizaciones antes de instalar Patch 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 de carga de tareas en la colección de proyectos para instalar e iniciar sesión con tfx-cli.

Actualización de tareas mediante TFX

Archivo	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Descargue y extraiga Tasks20231103.zip.
2. Cambie el directorio a los archivos extraídos.
3. Ejecute los comandos siguientes 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 las canalizaciones que usan las tareas afectadas.

• En el clásico:

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

• Ejemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Importante

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

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

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

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

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

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

Importante

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

Nota

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

Instalación de revisiones

1. Descargue e instale Azure DevOps Server 2020 Update 0.2 patch 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 de Windows autohospedados para implementar el agente.  

Nota

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

Configuración de TFX

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

Actualización de tareas mediante TFX

1. Descargue y extraiga Tasks_20230825.zip.
2. Cambie el directorio a los archivos extraídos.
3. Ejecute los comandos siguientes 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 las canalizaciones que usan las tareas afectadas.

• En el clásico:

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

• Ejemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 3 Release Date: 8 de agosto de 2023

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

• Se ha corregido un error que interfiere con la inserción 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 una revisión para Azure DevOps Server 2020 Update 0.2 que incluye correcciones para lo siguiente.

• Se ha corregido un error que interfiere con la inserción 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 una revisión para Azure DevOps Server 2020 Update 0.2 que incluye correcciones para lo siguiente.

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

Azure DevOps Server fecha de publicación de 2020.0.2: 17 de mayo de 2022

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

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 la lista de versiones actualmente admitidas para la importación en esta página.

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 estaba habilitado para los administradores de colecciones de proyectos.

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

Azure DevOps Server 2020.0.1 Fecha de lanzamiento de la revisión 9: 26 de enero de 2022

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

• Email notificaciones no se enviaron al usar el @mention control en un elemento de trabajo.
• Se ha corregido TF400813 error al cambiar de cuentas. 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 puede cargar.
• Mejora en la sincronización de usuarios de Active Directory.
• Se ha solucionado la vulnerabilidad de Elasticsearch mediante la eliminación de la clase jndilookup de los archivos binarios de log4j.

Pasos de instalación

1. Actualice el servidor con la revisión 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 = Version, Valor = 5.4.1).
3. Ejecute el comando de actualización PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update, tal como se proporciona en el archivo Léame. Puede devolver una advertencia como la siguiente: No se puede conectar al servidor remoto. No cierre la ventana, ya que la actualización realiza reintentos hasta que se completa.

Nota

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

1. Actualice el servidor con Patch 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 = Version, Valor = 5.4.1).
3. Copie el contenido de la carpeta denominada zip, que se encuentra en C:\Program Files\{TFS Version Folder}\Search\zip, en la carpeta de archivos remotos de Elasticsearch.
4. Ejecute Configure-TFSSearch.ps1 -Operation update en la máquina del servidor de Elasticsearch.

Hash SHA-256: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

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

La revisión 8 para Azure DevOps Server 2020.0.1 incluye correcciones para lo siguiente.

• Problema de localización para los estados de diseño de elementos de trabajo personalizados.
• Problema de localización en la plantilla de notificación por correo electrónico.
• Problema con los registros de consola que se truncan cuando hay varios vínculos idénticos en una fila.
• Problema con la evaluación de reglas NOTSAMEAS cuando se definieron varias reglas NOTSAMEAS para un campo.

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

La revisión 7 para 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 esta configuración en la página Conexiones de GitHub en Configuración del proyecto.
• Resuelva el problema con el widget Plan de prueba. El informe de ejecución de pruebas mostraba un usuario incorrecto en los resultados.
• Se ha corregido un problema con la página de resumen de Información general del proyecto que no se puede cargar.
• Se ha corregido el problema con los correos electrónicos que no se envían para confirmar la actualización del producto.

Azure DevOps Server fecha de lanzamiento de la revisión 6 de 2020.0.1: 14 de septiembre de 2021

La revisión 6 para Azure DevOps Server 2020.0.1 incluye correcciones para lo siguiente.

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

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

La revisión 5 para Azure DevOps Server 2020.0.1 incluye correcciones para lo siguiente.

• Se ha corregido el error de la interfaz de usuario de definición de compilación.
• Se ha cambiado el historial de exploración para mostrar archivos en lugar del repositorio raíz.
• Se ha corregido un problema con los trabajos de entrega de correo electrónico para algunos tipos de elementos de trabajo.

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

La revisión 4 para Azure DevOps Server 2020.0.1 incluye correcciones para lo siguiente.

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

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

Hemos publicado una revisión 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.

Comprobación de la instalación

• Opción 1: Ejecute 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 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 3, la versión será 18.170.31228.1.

Azure DevOps Server fecha de lanzamiento de la revisión 2 de 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 en 2020.0.1, instale Azure DevOps Server 2020.0.1 Patch 2

Hemos publicado una revisión 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 de revisiones generales, AzureResourceGroupDeploymentV2 y las instalaciones de tareas AzureResourceManagerTemplateDeploymentV3 .

Instalación de revisiones generales

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: Ejecute 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 la tarea 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 carpeta nueva del equipo. Por ejemplo: D:\tasks\AzureResourceGroupDeploymentV2.

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

3. Abra un símbolo del sistema en modo de 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 tfx login.

5. En el símbolo del sistema, ejecute el siguiente comando. 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. Use la ruta de acceso del archivo .zip extraído en el paso 1.

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

Instalación de la tarea 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 carpeta nueva 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 su máquina.

3. Abra un símbolo del sistema en modo de 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 tfx login.

5. En el símbolo del sistema, ejecute el siguiente comando. 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. Use la ruta de acceso del archivo .zip extraído en el paso 1.

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

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

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

• Resolución del problema notificado en este vale de comentarios de Developer Community | El botón Nuevo caso de prueba no funciona
• Incluya correcciones publicadas con la revisión 2 de Azure DevOps Server 2020.

Azure DevOps Server 2020 Patch 3 Fecha de lanzamiento: 9 de febrero de 2021

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

• Resolución del problema notificado en este vale de comentarios de Developer Community | El botón Nuevo caso de prueba no funciona

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

Azure DevOps Server 2020.0.1 es un resumen 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 versiones posteriores.

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

• 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 las colecciones que no son de ENU antes de Team Foundation Server 2017 al actualizar a Azure DevOps Server 2020. Resuelve el problema notificado en este vale de comentarios de Developer Community.
• Error de mantenimiento causado por la falta de Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Resuelve el problema notificado en este vale de comentarios de Developer Community.
• Se ha corregido el error de nombre de columna no válido en Analytics al actualizar a Azure DevOps Server 2020. Resuelve el problema notificado en este vale de comentarios de Developer Community.
• 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.

Azure DevOps Server 2020 Patch 2 Fecha de lanzamiento: 12 de enero de 2021

Hemos publicado una revisión 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 detenidas 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 Revisión 1 Fecha: 8 de diciembre de 2020

Hemos publicado una revisión 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

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

Azure DevOps Server 2020 es una acumulación de correcciones de errores. Incluye todas las características de la 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 virtual de Git (GVFS).

Si va a actualizar desde Azure DevOps 2019 (cualquier versión) o un candidato de versión de Azure DevOps 2020 e instalando en el mismo directorio que la versión anterior, el ensamblado Microsoft.TeamFoundation.Git.dll no se instalará. Para comprobar que ha alcanzado el problema, busque Microsoft.TeamFoundation.Git.dll en las carpetas y <Install Dir>\Application Tier\TFSJobAgent<Install Dir>\Tools .<Install Dir>\Version Control Proxy\Web Services\bin 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.

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

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

Azure DevOps Server 2020 RC1 fecha de lanzamiento: 10 de julio de 2020

Hemos vuelto a publicar Azure DevOps Server 2020 RC1 para corregir este vale de comentarios Developer Community.

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 que 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. Entre los aspectos destacados se incluyen:

• Canalizaciones de varias fases
• Implementación continua en YAML
• Realizar un seguimiento del progreso de los elementos primarios mediante el trabajo pendiente de acumulación en paneles
• Agregar el filtro "Elemento de trabajo primario" al panel de tareas y al trabajo pendiente de sprint
• Nueva interfaz de usuario web para Azure Repos páginas de aterrizaje
• Administración de directivas entre repositorios
• Página Nuevo plan de prueba
• Edición enriquecida para páginas wiki de código
• Informes de errores y duración de la canalización

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

• General
• Boards
• Repos
• Canalizaciones
• Test Plans
• 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 a 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 azure WebApps 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.

Boards

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

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

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

Históricamente, desde el panel Kanban, si movió un elemento de trabajo de una columna a otra donde el cambio de estado desencadenó las reglas de campo, la tarjeta simplemente mostraría un mensaje de error rojo que le obligará a abrir el elemento de trabajo para comprender la causa principal. 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 dinámica del elemento de trabajo

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

Administrar las rutas de acceso 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 az boards iteration comandos 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 elemento primario de cada elemento de trabajo en el trabajo pendiente del producto o el trabajo pendiente de sprint. Para habilitar esta característica, vaya a Opciones de columna en el trabajo pendiente deseado y agregue la columna Primario .

Cambiar el proceso usado por un proyecto

Las herramientas deben cambiar como lo hace el equipo, ahora puede cambiar los proyectos de cualquier plantilla de proceso lista para usar a cualquier otro proceso estándar. Por ejemplo, puede cambiar el proyecto de mediante Agile a Scrum o Básico a Agile. Puede encontrar la documentación completa paso a paso 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 el 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 arreglar lo que no puedes ver. Por lo tanto, desea tener un ojo cercano sobre el estado y el estado de sus procesos de trabajo. Con estos informes, le facilitamos el seguimiento de métricas importantes con un esfuerzo mínimo en Azure Boards.

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

Las métricas como el agotamiento de sprints, el flujo de trabajo y la velocidad del equipo le proporcionan la visibilidad sobre el 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 sobre esto?
• En función de las iteraciones anteriores, ¿cuánto trabajo debemos 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 Análisis de cada centro.

• El gráfico de quemaduras se puede encontrar en el centro sprints .

  

• Se puede acceder a los informes cfd y velocidad desde la pestaña Análisis en Paneles y Trabajos pendientes 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 Velocity se pueden establecer para usar el recuento de elementos de trabajo o la suma del trabajo restante.
• Puede ajustar el período de tiempo del agotamiento del sprint sin afectar a las fechas del proyecto. Por lo tanto, si su equipo suele pasar el primer día de cada planeamiento de sprint, ahora puede coincidir con el gráfico para reflejarlo.
• El gráfico Burndown ahora tiene una marca de agua que muestra los fines de semana.
• El informe CFD le permite quitar columnas de tablero como Diseño para obtener más foco en el flujo en el que los equipos tienen control.

Este es un ejemplo del informe cfd que muestra el flujo de los últimos 30 días del trabajo pendiente de historias.

Ahora se puede realizar un seguimiento del gráfico de velocidad para todos los niveles de trabajo pendiente. Por ejemplo, ahora puede agregar características y epopeyas, mientras que antes del gráfico anterior solo admitía requisitos. Este es un ejemplo de un informe de velocidad para las últimas 6 iteraciones del trabajo pendiente de características.

Personalización de 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 del Developer Community.

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

Muchas veces, al refinar el trabajo pendiente, solo quiere ver los elementos que no se han completado. Ahora, tiene la capacidad de mostrar u ocultar los elementos secundarios completados en el trabajo pendiente.

Si el botón de alternancia está activado, verá todos los elementos secundarios en un estado completado. Cuando el botón de alternancia está desactivado, todos los elementos secundarios en un estado completado se ocultarán del trabajo pendiente.

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 adecuada 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 elemento de trabajo para automatizar su comportamiento. Puede crear una regla para establecer un campo en de solo lectura o requerido en función de la pertenencia a grupos. Por ejemplo, puede conceder a los propietarios de productos la capacidad de establecer la prioridad de las características al tiempo que hace que sea 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 vínculos a elementos de trabajo con el contexto de su panel o trabajo pendiente con nuestro nuevo parámetro de dirección URL del elemento de trabajo. Ahora puede abrir un cuadro de diálogo de elemento de trabajo en la experiencia de panel, trabajo pendiente o sprint anexando el parámetro ?workitem=[ID] a la dirección URL.

Cualquier persona con la que comparta el vínculo llegará con el mismo contexto que tenía cuando compartió el vínculo.

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

A medida que escuchamos sus comentarios, hemos oído que querías mencionar personas, elementos de trabajo y solicitudes de incorporación de cambios en el área de descripción del elemento de trabajo (y otros campos HTML) en el elemento de trabajo y no solo en comentarios. A veces está colaborando con alguien en un elemento de trabajo o desea resaltar una solicitud de incorporación de cambios en la descripción del elemento de trabajo, pero no tenía una manera de 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 desea mencionar. @mentions en los campos del elemento de trabajo generará notificaciones por correo electrónico como lo que hace para los comentarios.
• Para usar menciones de elemento de trabajo, escriba el # signo seguido del identificador o el título del elemento de trabajo. #mentions creará un vínculo entre los dos elementos de trabajo.
• Para usar menciones de solicitud de incorporación de cambios, agregue un valor ! 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 hemos realizado una encuesta en Twitter para averiguar qué características de colaboración desea en los debates sobre el elemento de trabajo. Traer reacciones a los comentarios ganaron la encuesta, así que los 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 eliminará. A continuación puede ver la experiencia de agregar una reacción, así como el aspecto de las reacciones en un comentario.

Anclar informes de Azure Boards al panel

En la actualización 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 panel. Para anclar los informes, mantenga el puntero sobre el informe y seleccione los puntos suspensivos "..." menú y Copiar en el panel.

Realizar un seguimiento del progreso de los elementos primarios mediante el trabajo pendiente de acumulación en paneles

Las columnas de resumen muestran barras de progreso o totales de campos numéricos o elementos descendientes dentro de una jerarquía. Los elementos descendientes corresponden a todos los elementos secundarios dentro de la jerarquía. Se pueden agregar una o varias columnas de resumen a un trabajo pendiente de producto o cartera.

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 para Epopeyas incluyen todas las características secundarias y sus elementos de trabajo secundarios o secundarios secundarios. Los elementos descendientes de características incluyen todos los casos de usuario secundarios y sus elementos de trabajo secundarios.

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

El paquete acumulativo ahora se puede realizar en cualquier campo, incluidos los campos personalizados. Al agregar una columna acumulación, todavía puede seleccionar una columna De resumen de la lista rápida, pero si desea acumular campos numéricos que no forman parte de la plantilla de proceso lista para usar, puede configurar la suya propia de la siguiente manera:

1. En el trabajo pendiente, haga clic en "Opciones de columna". A continuación, en el panel, haga clic en "Agregar columna de acumulación" y en Configurar el paquete acumulativo personalizado.

   

2. Elija entre barra de progreso y Total.
3. Seleccione un tipo de elemento de trabajo o un nivel de trabajo pendiente (normalmente, los trabajos pendientes agregan varios tipos de elementos de trabajo).
4. Seleccione el tipo de agregación. Recuento de elementos de trabajo o Suma. En Suma, deberá seleccionar el campo que se va a resumir.
5. El botón Aceptar le devolverá al panel de opciones de columna, donde podrá 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 más información, consulte la documentación aquí.

Configuración de notificación de elemento de trabajo personalizado

Mantenerse al día sobre 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, las distintas partes interesadas tienen diferentes niveles de inversión en diferentes esfuerzos y creemos que deben 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 una ventana emergente que le permitirá configurar las opciones de seguimiento.

En Configuración de notificación, puede elegir 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 una notificación 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 todos los cambios que se realicen. Con esta característica, eliminaremos los correos electrónicos innecesarios y le permitirá centrarse en las tareas cruciales que se tienen en cuenta.

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 fácil 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 depende 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 primario ahora está disponible en el panel Kanban como un nuevo campo para las tarjetas de elementos de trabajo. Ahora puede agregar el campo Primario a las tarjetas, omitiendo la necesidad de usar soluciones alternativas, como etiquetas y prefijos.

Adición de un campo primario a trabajos pendientes y consultas

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

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 en la vista de solicitud de incorporación de cambios (PR). Esto garantiza que haya probado adecuadamente los cambios a través de pruebas automatizadas. El estado de cobertura aparecerá como comentario en la introducción a la solicitud de incorporación de cambios. 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 archivo.

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 azurepipelines-coverage.yml archivo de configuración protegido en la raíz del repositorio y la directiva de cobertura mediante la configuración existente de una directiva de rama para la funcionalidad de servicios adicionales en Azure Repos.

Filtrado 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 comentario a las que se suscribe por edad de comentario, comentario, comentario eliminado, usuarios mencionados, autor de solicitudes de incorporación de cambios, rama de destino y participantes de subprocesos. 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 inserte en un repositorio en función de los tipos de archivo y las rutas de acceso. 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 mediante confirmaciones mediante palabras clave

Ahora puede resolver elementos de trabajo a través de confirmaciones realizadas en la rama predeterminada mediante palabras clave como fix, fixes o fixed. Por ejemplo, puede escribir : "este cambio fijo #476" en el mensaje de confirmación y el elemento de trabajo #476 se completarán cuando se inserte o combine la confirmación en la rama predeterminada. Para 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 directivas que requieran más de un revisor de un equipo para aprobar una solicitud de incorporación de cambios al agregar 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 cuentas de servicio para conectarse al clúster de modo 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

Ahora puede ver una vista previa del aspecto de un archivo Markdown mediante el botón Nueva vista previa . Además, puede ver el contenido completo de un archivo desde la diferencia en paralelo seleccionando el botón Ver .

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

Las directivas aplican los estándares de administración de cambios y la calidad del código del equipo. Anteriormente, podía establecer directivas de expiración de compilación para compilaciones automatizadas. Ahora también puede establecer directivas de expiración de compilación en las compilaciones manuales.

Adición de una directiva para bloquear confirmaciones basadas en el correo electrónico del autor de 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 del Developer Community para ofrecer una experiencia similar. Seguiremos manteniendo abierta la incidencia y animamos a los usuarios a indicarnos qué otros tipos de directivas de inserción desea ver.

Marcar archivos como revisados en una solicitud de incorporación de cambios

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 sobre el nombre de archivo 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 las solicitudes de incorporación de cambios, por lo que estas marcas solo serán visibles para el revisor.

Esta característica se priorizó en función de una sugerencia del Developer Community.

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

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 aterrizaje de Nuevos repositorios. Las páginas de aterrizaje incluyen todas las páginas excepto los detalles de la solicitud de incorporación de cambios, los detalles de confirmación y la comparación de ramas.

Web

Móvil

Administración de directivas entre 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 repos.

Nuevas páginas de aterrizaje de conversión de 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 para dispositivos móviles. 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 del archivo de texto de Kotlin y le ayudará a examinar rápidamente para encontrar errores. Hemos priorizado esta característica en función de una sugerencia de la Developer Community.

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

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 borradores de solicitudes de incorporación de cambios o filtrar correos electrónicos de 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 su revisión.

Mejora de la capacidad de acción de la solicitud de incorporación de cambios

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, por ejemplo, el estado de borrador. Estas consultas crearán secciones independientes y contraíbles en la página de solicitud de incorporación de cambios, además de "Creado por mí" y "Asignado a mí". También puede rechazar la revisión de una solicitud de incorporación de cambios a la que se agregó a través del menú Votar o el menú contextual de la página de lista de solicitudes de incorporación de cambios. 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 la 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, las solicitudes de incorporación de cambios que se han establecido en autocompletar se marcarán con una píldora que dice "Autocompletar" en la lista.

Pipelines

Canalizaciones de varias fases

Hemos estado trabajando en una experiencia de usuario actualizada para administrar las canalizaciones. Estas actualizaciones hacen que las canalizaciones sean modernas y coherentes 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 única 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 las canalizaciones, los detalles de la ejecución, el análisis de las canalizaciones, 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 sigue en curso
• mantenimiento por rama de una canalización.

Implementación continua en YAML

Nos complace proporcionar características de CD de YAML de Azure Pipelines. Ahora ofrecemos una experiencia yaML unificada para que pueda configurar cada una de las canalizaciones para realizar ci, CD o CI y CD 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. Entre los aspectos destacados se incluyen:

• Canalizaciones YAML de varias fases (para CI y CD)
• Aprobaciones y comprobaciones en los recursos
• Entornos y estrategias de implementación
• Recursos de Kubernetes y máquina virtual en el entorno
• Revisión de aplicaciones para la colaboración
• Experiencia de usuario actualizada para las conexiones de servicio
• Recursos en canalizaciones de YAML

Si está listo para empezar a compilar, consulte la documentación o el blog para compilar canalizaciones de CI/CD de varias fases.

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.

Aprobar versiones directamente desde el centro de versiones

Actuar en aprobaciones pendientes se ha hecho más fácil. Antes, era posible aprobar una versión de la página de detalles de la versión. Ahora puede aprobar versiones directamente desde el centro de versiones.

Mejoras en la introducción a las canalizaciones

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

Por último, tendremos más control al proteger el azure-pipelines.yml archivo en otra rama, ya que puede omitir la creación de una solicitud de incorporación de cambios desde esa rama.

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

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

Para desarrolladores: PUBLIQUE en dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview con un cuerpo JSON de la siguiente manera:

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

La respuesta contendrá el CÓDIGO YAML representado.

Programaciones cron en YAML

Anteriormente, podría usar el editor de interfaz de usuario para especificar un desencadenador programado para canalizaciones de 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: puede realizar un seguimiento de las programaciones junto con la canalización como parte del código.
2. Expresivo: tiene más poder expresivo en la definición de programaciones que lo que pudo 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 hemos hecho que sea fácil diagnosticar problemas con programaciones cron. Las ejecuciones programadas en el menú Ejecutar canalización le proporcionarán una vista previa de las próximas ejecuciones programadas de la canalización para ayudarle a diagnosticar errores con las programaciones cron.

Novedades a 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 del 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 de este año. Gracias a todos los que probaron la nueva experiencia y nos proporcionaron 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 el uso compartido entre proyectos del servicio Connections como una nueva funcionalidad. Puede encontrar más detalles sobre la experiencia de uso compartido y los roles de seguridad aquí.

Omisión de fases en una canalización de 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 puede hacerlo con las 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 omite las fases que tienen dependencias de bajada. Se le deja saber si esas dependencias son verdaderas dependencias de artefactos o si solo están presentes para la secuenciación de implementaciones.

Omitir una fase es equivalente a volver a realizar el cambio de las dependencias entre las fases. Las dependencias de bajada inmediatas de la fase omitida se realizan para depender del elemento primario 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 una nueva ejecución.

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 estándares de diseño modernos y viene con varias características críticas para admitir canalizaciones de CD de 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 del recurso de canalización en el cuadro de diálogo crear ejecución

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

az Mejoras de la CLI para Azure Pipelines

Comandos de administración de variables y grupo de variables de canalización

Puede ser difícil portar canalizaciones basadas en YAML de un proyecto a otro, ya que necesita configurar manualmente las variables de canalización y los grupos de variables. Sin embargo, con el grupo de variables de canalización y los comandos de administración de variables, ahora puede crear scripts para configurar y administrar variables de canalización y grupos de variables que, a su vez, se pueden controlar con versiones, lo que le permite compartir fácilmente las instrucciones para mover y configurar canalizaciones de un proyecto a otro.

Ejecución de una canalización para una rama de solicitud de incorporación de cambios

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 en ejecución 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 desea 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 la documentación del comando az pipeline create para más información.

Mejora del comando del punto de conexión de servicio

Los comandos de la CLI del punto de conexión de servicio solo admiten la configuración y administración del punto 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, se ha agregado compatibilidad con referencias de pasos en un trabajo 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 hemos agregado compatibilidad con propiedades adicionales para el trabajo de implementación. Por ejemplo, estas son algunas propiedades de un trabajo de implementación que ahora puede establecer,

• timeoutInMinutes : cuánto tiempo se debe ejecutar el trabajo antes de cancelar automáticamente
• cancelTimeoutInMinutes : cuánto tiempo se debe dar a "ejecutar siempre si las tareas canceladas" antes de finalizarlas
• condition : ejecución condicional del trabajo
• variables : los valores codificados de forma rígida se pueden agregar directamente o grupos de variables, se puede hacer referencia a un grupo de variables respaldado por un almacén de claves de Azure o puede hacer referencia a un conjunto de variables definidas en un archivo.
• continueOnError : si se deben ejecutar trabajos futuros aunque se produzca 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 agregado compatibilidad con los detalles de las canalizaciones de YAML de CD en los que se hace referencia a las canalizaciones de CI como recursos de canalización. En la vista de ejecución de canalización de CI, ahora verá una nueva pestaña "Canalizaciones asociadas", donde puede encontrar todas las ejecuciones de canalización que consumen la canalización y los artefactos de ella.

Compatibilidad con paquetes de GitHub en canalizaciones de YAML

Recientemente hemos introducido un nuevo tipo de recurso denominado paquetes que agrega compatibilidad para consumir paquetes NuGet y npm de GitHub como un recurso en canalizaciones de 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 de canalización automatizados tras la publicación de una nueva versión del paquete. Hoy en día, 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 vínculo a la vista de recursos de los entornos de Kubernetes para que pueda ir a la hoja de Azure del clúster correspondiente. Esto se aplica a entornos asignados a espacios de nombres en clústeres de Azure Kubernetes Service.

Filtros de carpeta de versió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 versión, que se representan mediante todas las canalizaciones de una carpeta. Anteriormente, tenía que configurar varias suscripciones o tener una consulta compleja en las suscripciones para centrarse en los correos electrónicos. Con esta actualización, ahora puede agregar una cláusula de carpeta de versión a los eventos completados y aprobados pendientes de implementación 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 con 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 compiló el código de ese elemento de trabajo. Para configurarlo, use el panel de configuración de una canalización.

Cancelar fase en una ejecución de canalización YAML de 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 es útil si sabe que se producirá un error en la fase o si tiene otra ejecución que desea iniciar.

Fases con error de reintento

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. Todos los trabajos con errores en el primer intento y aquellos que dependen transitivamente de esos trabajos con errores se vuelven a intentar.

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 puede reintentar una fase que cancele explícitamente. Estamos trabajando para cerrar estas brechas en futuras actualizaciones.

Aprobaciones en canalizaciones YAML de varias fases

Las canalizaciones 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 segregación completa de roles entre los propietarios de la infraestructura (entorno) y la aplicación (canalización), se asegurará de que se cierre la sesión manual para la implementación en una canalización determinada y obtenga control central al aplicar las mismas comprobaciones en todas las implementaciones al entorno.

La canalización se ejecuta la implementación en dev se detendrá para su aprobación al principio de la fase.

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

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

Nueva plantilla de imagen de compilación para Dockerfile

Anteriormente, al crear una nueva canalización para un Dockerfile en la creación de una canalización, la plantilla recomienda insertar la imagen en una Azure Container Registry e implementarla en un Azure Kubernetes Service. Hemos agregado una nueva plantilla para permitirle compilar una imagen mediante el agente sin necesidad de insertar en un registro de contenedor.

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

Azure App Service permite la configuración a través de varias opciones, como la configuración de la aplicación, las cadenas de conexión y otras opciones de configuración generales. Ahora tenemos una nueva tarea de Azure Pipelines Azure App Service Configuración que permite configurar estas opciones de forma masiva mediante la sintaxis JSON en la aplicación web o cualquiera de sus ranuras de implementación. Esta tarea se puede usar junto con otras tareas de App Service para implementar, administrar y configurar las aplicaciones web, las aplicaciones de funciones o cualquier otro App Services en contenedor.

Azure App Service ahora admite Intercambio con versión preliminar

Azure App Service ahora admite Swap with preview 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 cambie realmente de una ranura de ensayo a una ranura de producción. Esto también garantizaría que la ranura de destino o producción no experimente tiempo de inactividad.

Azure App Service tarea ahora admite este intercambio de varias fases mediante las siguientes acciones nuevas:

• Iniciar intercambio con 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 versión preliminar : cuando esté listo para completar el intercambio pendiente, seleccione la acción Completar intercambio con vista previa.
• Cancelar intercambio con versión preliminar : para cancelar un intercambio pendiente, seleccione Cancelar intercambio con versión preliminar.

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

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

Mejoras en las aprobaciones en canalizaciones de YAML

Hemos habilitado la configuración de aprobaciones en conexiones de servicio y grupos de agentes. Para las aprobaciones, seguimos la segregación de roles entre los propietarios de la 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 la configuración de 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 las pruebas de estructura de contenedores en Azure Pipelines

El uso de contenedores en aplicaciones aumenta y, por tanto, la necesidad de pruebas y validación sólidas. Azure Pipelines ahora admite 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 de la canalización para tomar decisiones de go/no go. Los datos de prueba están disponibles en la ejecución de la canalización con un mensaje de error que le ayudará a solucionar mejor los errores.

Entrada del archivo de configuración y los detalles de la imagen

Datos de prueba y resumen

Decoradores de canalización para canalizaciones de versión

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

Hemos estado admitiendo decoradores para compilaciones y canalizaciones YAML, con clientes que los usan para controlar de forma centralizada los pasos de sus trabajos. 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 se agregarán a todos los trabajos del agente en las canalizaciones de versión.

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

Anteriormente, solo se admitía la implementación en el nivel de grupo de recursos. Con esta actualización, hemos 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 consumir artefactos publicados por la canalización de CI y habilitar desencadenadores de finalización de canalización. En las canalizaciones YAML de varias fases, estamos introduciendo pipelines como un recurso. En yaml, ahora puede hacer referencia a otra canalización y también habilitar desencadenadores 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 el recurso de canalización mediante la - download tarea .

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

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

Orquestación de la estrategia de implementación controlada en el entorno para Kubernetes

Una de las principales ventajas de la entrega continua de las 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. El entorno se introdujo como un concepto de primera clase que permite orquestar estrategias de implementación y facilitar cero versiones de tiempo de inactividad. Anteriormente, se admitía la estrategia runOnce que ejecutó los pasos una vez secuencialmente. Con la compatibilidad con la estrategia de valor controlado en canalizaciones de varias fases, ahora puede reducir el riesgo implementando lentamente el cambio en 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 de valor controlado para Kuberenetes implementará primero los cambios con un 10 % de pods seguidos del 20 % al supervisar el estado durante postRouteTraffic. Si todo va bien, se promoverá al 100%.

Estamos buscando comentarios anticipados sobre la compatibilidad con el recurso de máquina virtual en entornos y la realización de una 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, seguimos una configuración de aprobación controlada por el propietario del recurso. Los propietarios de recursos configuran aprobaciones en el recurso y todas las canalizaciones que usan la pausa de recursos para las aprobaciones antes de comenzar la fase que consume el recurso. 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 directivas de aprobación como el solicitante no debe aprobar, requerir aprobación de un subconjunto de usuarios y tiempo de espera de 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 de ACR en la canalización.

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 comprobación del artefacto de evaluación para facilitar la adición de directivas de una lista de definiciones de directiva listas para usar. La definición de directiva se generará automáticamente y se agregará a la configuración de comprobación que se puede actualizar si es necesario.

Compatibilidad con variables de salida en un trabajo de implementación

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

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

• Para la estrategia runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Para la estrategia de valores controlados: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Para la estrategia gradual : $[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

Más información sobre cómo establecer una variable de salida de varios trabajos

Evitar la reversión de cambios críticos

En las canalizaciones de versión clásicas, es habitual confiar en implementaciones programadas 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 plantea un desafío, ya que la implementación manual se revertiría cuando las implementaciones se reanudaron según la programación. Muchos de ustedes notificaron 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 la opción de puesta en cola está seleccionada como "Implementar más reciente y cancelar otros".

Autorización simplificada de recursos en canalizaciones de YAML

Un recurso es todo lo que usa una canalización que está fuera de la canalización. Los recursos deben estar autorizados para poder usarse. Anteriormente, al usar recursos no autorizados en una canalización 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 usaba una variable a la que se hacía referencia a un recurso no autorizado.

Ahora facilitamos la administración de las autorizaciones de recursos. En lugar de que se produce 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 Seguridad.

Evaluación de la comprobació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 una canalización, la ejecución se detiene antes de iniciar una fase que usa 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 directiva se realiza correctamente y marca la fase como errónea si se produce un error en la comprobación.

Novedades a 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 provocar 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, hemos 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 el entorno

ReviewApp implementa todas las solicitudes de incorporación de cambios del repositorio de Git en un recurso de entorno dinámico. Los revisores pueden ver el aspecto de 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 recursos de reviewApp y beneficiarse de todas las funcionalidades de seguimiento y diagnóstico de las características del entorno. Mediante 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 de la canalización

Ahora puede habilitar la recopilación automática y especificada por el usuario de metadatos desde tareas de canalización. Puede usar metadatos para aplicar la directiva 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, se habilita el recurso de máquina virtual en entornos. Ahora puede orquestar implementaciones en varias máquinas y realizar actualizaciones graduales mediante canalizaciones de YAML. También puede instalar el agente en cada uno de los servidores de destino directamente y impulsar la implementación gradual en 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 hasta cinco destinos en cada iteración. maxParallel determinará el número de destinos que se pueden implementar en paralelo. La selección tiene en cuenta el número de destinos que deben permanecer disponibles en cualquier momento, excepto los destinos en los que se va a implementar. También se usa para determinar las condiciones de acierto 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 canalización actual y de los recursos de canalización asociados solo se descargan en deploy el enlace del ciclo de vida. Sin embargo, puede optar por descargar especificando 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 la implementación en todas las máquinas virtuales, no solo destinos con errores. Estamos trabajando para cerrar estas brechas en futuras actualizaciones.

Control adicional de las implementaciones

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 automatizados checks para comprobar las directivas de seguridad y calidad. Estas comprobaciones se pueden usar para desencadenar operaciones y, a continuación, esperar a que se completen. Con las comprobaciones adicionales, ahora puede definir criterios de mantenimiento basados en varios orígenes y asegurarse de que todas las implementaciones destinadas a los recursos son seguras, independientemente de la canalización de YAML que realice la implementación. La evaluación de cada comprobación se puede repetir periódicamente en función del intervalo de reintento especificado para la comprobación. Ahora están disponibles las siguientes comprobaciones adicionales:

• Invocación de cualquier API REST y realización de la validación en función del cuerpo de la respuesta o una devolución de llamada desde el servicio externo
• Invocación de una función de Azure y realización de la validación en función de la respuesta o una devolución de llamada de la función
• Consulta de reglas de Azure Monitor para alertas activas
• Asegúrese de que la canalización extiende 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 de varias fases que usan el recurso esperan automáticamente la aprobación al principio de la fase. Los aprobadores designados deben completar la aprobación antes de que la canalización pueda continuar.

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

Configurar estrategias de implementación desde Azure Portal

Con esta funcionalidad, hemos facilitado la configuración de canalizaciones que usan la estrategia de implementación que prefiera, por ejemplo, Rolling, Canary o Blue-Green. Con estas estrategias de fábrica, 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 los 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 cómo configurar 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 puede:

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

Para 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 factorizar en plantillas, lo que promueve la reutilización y reduce la reutilizable. La estructura general de la canalización todavía se definió mediante el archivo YAML raíz. Con esta actualización, hemos agregado una manera más estructurada de usar plantillas de canalización. Un archivo YAML raíz ahora puede usar la palabra clave extends 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 cuáles son los segmentos fijos. También hemos mejorado los parámetros de canalización con tipos de datos para aclarar los enlaces que puede proporcionar.

En este ejemplo se muestra cómo puede proporcionar enlaces simples para que el autor de la canalización lo use. 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, podí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 ciertas variables como _settable at queue time_, el sistema no lo ha hecho ni impide que se establezcan 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 _settable at queue time_ parámetro . 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 los bits de clave de los datos en distintas partes de la canalización. 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 son de solo lectura.

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

Desprotección de varios repositorios

Las canalizaciones suelen depender de 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 capturar y extraer otros repositorios, además del que usa para almacenar la canalización de YAML.

Por ejemplo, si tiene un repositorio denominado MyCode con una canalización YAML y un segundo repositorio denominado Herramientas, 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 Herramientas en el directorio sources.

se admiten Azure Repos repositorios de Git. Para obtener más información, consulte Desprotección de varios 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 desproteger varios repositorios, es posible que también quiera conocer el repositorio, la rama y la confirmación que se desprotegeron 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 Azure Repos tenían que estar en la misma colección que la canalización. Ahora, puede apuntar a 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 y selfotherrepo, terminarán desprotegidos.

Importante

MyServiceConnectiondebe 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 el YAML original intacto. Se ha agregado una opción para kustomize en la acción bake de la tarea KubernetesManifest para que cualquier carpeta que contenga archivos kustomization.yaml se pueda usar para generar los archivos de manifiesto usados 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, hemos agregado una casilla que le permite usar credenciales de administrador de clúster en lugar de 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 versión de GitHub

Hemos realizado varias mejoras en la tarea versión de GitHub. Ahora puede tener un mejor control sobre la creación de versiones mediante el campo de patrón de etiqueta especificando una expresión regular de etiqueta y la versión solo se creará cuando la confirmación de desencadenamiento se etiquete 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. Compare to release puede ser la última versión completa (excluye versiones preliminares), la última versión sin borrador o cualquier versión anterior que coincida con la etiqueta de versión proporcionada. Además, la tarea proporciona un campo de tipo de registro de cambios para dar formato al registro de cambios. En función de la selección, el registro de cambios mostrará una lista de confirmaciones o una lista de problemas o solicitudes de incorporación de cambios clasificadas en función de las etiquetas.

Abrir la tarea del instalador del agente de directivas

Open Policy Agent es un motor de directivas de uso general código abierto que permite la aplicación unificada de directivas compatibles con contexto. Hemos agregado la tarea del instalador del Agente de directiva abierta. Resulta especialmente útil para la aplicación de directivas dentro de la canalización con respecto a la infraestructura como proveedores de código.

Por ejemplo, Open Policy Agent puede evaluar los archivos de directiva de Rego y los planes de Terraform en la canalización.

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

Compatibilidad con scripts de PowerShell en la tarea de la 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 principales de PowerShell y PowerShell a la tarea.

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

Anteriormente, cuando se especificaba la estrategia de valor controlado en la tarea KubernetesManifest, la tarea crearía cargas de trabajo de línea base y de valor controlado cuyas réplicas equivalen a un porcentaje de las réplicas usadas para cargas de trabajo estables. Esto no era exactamente lo mismo que dividir el tráfico hasta el porcentaje deseado en el nivel de solicitud. Para abordar esto, hemos agregado compatibilidad con implementaciones controladas basadas en la interfaz de Service Mesh a la tarea KubernetesManifest.

La abstracción de la interfaz de Service Mesh permite la configuración de plug-and-play con proveedores de malla de servicio como Linkerd e Istio. Ahora, la tarea KubernetesManifest quita el trabajo duro de asignar los objetos TrafficSplit de SMI a los servicios estables, de línea base y controlados durante el ciclo de vida de la estrategia de implementación. La división porcentual deseada del tráfico entre estable, base de referencia y valor controlado 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 controladas basadas en SMI de forma gradual.

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

Tarea de copia de archivos de Azure ahora admite AzCopy V10

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

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

• Especificación de la ubicación del registro
• Limpieza de archivos de registro y plan después de la copia
• Reanudar 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 o ruta de acceso del archivo de origen
• Inferencia del tipo de contenido basado en la extensión de archivo cuando no se proporcionan argumentos
• Definir el nivel de detalle del registro para el archivo de registro pasando 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, usamos 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 ámbito para que sea el proyecto de equipo en canalizaciones de compilación clásicas. Sin embargo, no tenía ese control para las canalizaciones de YAML o de versión clásica. Con esta actualización se presenta una configuración de recopilación para forzar que cada trabajo obtenga un token con ámbito de proyecto, independientemente de lo que esté configurado en la canalización. También hemos agregado la configuración en el nivel de proyecto. Ahora, cada nuevo proyecto y colección que cree tendrá activada esta configuración automáticamente.

  Nota

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

  Activar esta configuración en proyectos y colecciones existentes puede provocar un error en determinadas canalizaciones si las canalizaciones acceden a los recursos que están fuera del proyecto de equipo mediante tokens de acceso. Para mitigar los errores de canalización, puede conceder explícitamente acceso a la cuenta de servicio de compilación del proyecto 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 reducir el ámbito del acceso del repositorio a solo los repositorios necesarios para una canalización basada en YAML. Esto significa que si el token de acceso de las canalizaciones fuera a filtrarse, solo podría ver los repositorios usados en la canalización. Anteriormente, el token de acceso era bueno para cualquier repositorio de Azure Repos del 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ónde canalizaciones> de recopilación>. Al usar esta característica, todos los repositorios necesarios para la compilación (incluso los que se clonan mediante un script) deben incluirse en los recursos del repositorio de la canalización.

• Eliminación de 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 para el token de acceso. Si las canalizaciones necesitan este permiso, puede concederla explícitamente a la cuenta de servicio de compilación de proyectos o a la cuenta de servicio de compilación de la colección de proyectos, en función del token que use.

Seguridad de nivel de proyecto para conexiones de servicio

Hemos agregado seguridad de nivel de centro 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.

Aislamiento de comandos y destino de pasos

Azure Pipelines admite la ejecución de trabajos en contenedores o en el host del agente. Anteriormente, todo el trabajo se estableció en 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 los servicios de acceso y desde el agente no se ven afectados por el aislamiento de los pasos de un contenedor. Por lo tanto, también se presenta 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 sobrescribirse mediante una tarea y las tareas de nivel inferior recogerían el nuevo valor. Con esta actualización, se ajusta 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 roles 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 del proyecto y estas se heredan mediante 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 los proyectos de forma segura y segura.

Obtenga más información sobre el uso compartido de conexiones de servicio aquí.

Rastreabilidad de canalizaciones 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 de resumen de ejecución de canalización, puede ver:

• Versión del recurso que desencadenó la ejecución. Ahora, la canalización se puede desencadenar al finalizar otra ejecución de canalización de Azure o cuando se inserta una imagen de contenedor en ACR.

  

• Confirmaciones consumidas por la canalización. También puede encontrar el desglose de las confirmaciones por cada recurso consumido por la canalización.

  

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

• Los artefactos que están disponibles para su uso por 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 informes y análisis de pruebas. Hasta ahora, había un límite de 100 MB para los datos adjuntos de prueba para la ejecución de pruebas y los resultados de las pruebas. Esto limita la carga de archivos grandes, como volcados de memoria o vídeos. Con esta actualización, hemos agregado compatibilidad con datos adjuntos de prueba de gran tamaño, lo que le permite tener todos los datos disponibles para solucionar los problemas de las pruebas con errores.

Es posible que vea la tarea VSTest o la tarea 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 las 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 en cada trabajo

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

Desencadenadores de CI para nuevas ramas

Ha sido una solicitud pendiente larga para no desencadenar compilaciones de CI cuando se crea una nueva rama y cuando esa rama no tiene cambios. Considere los siguientes ejemplos:

• La interfaz web se usa para crear una 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: aplicación y documentos. Configure un filtro de ruta de acceso para que ci coincida con "app". En otras palabras, no desea crear una nueva compilación si se ha insertado un cambio en la documentación. 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 ha pedido explícitamente que no busque cambios en la carpeta docs. Sin embargo, debido a la forma en que controlamos un nuevo evento de rama, parecería que también se ha realizado un cambio en la carpeta de la aplicación.

Ahora, tenemos una mejor manera de controlar la ci para que las nuevas ramas solucione estos problemas. Al publicar una nueva rama, buscamos explícitamente nuevas confirmaciones en esa rama y comprobamos si coinciden con los filtros de ruta de acceso.

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

Las variables de salida ahora se pueden usar en las fases de una canalización basada en YAML. Esto le ayuda a pasar información útil, como una decisión de uso o sin uso o el identificador de una salida generada, de una fase a la siguiente. El resultado (estado) de una fase anterior y sus trabajos también están disponibles.

Las variables de salida todavía se generan por 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á las variables de salida disponibles. Por ejemplo, si la fase 3 necesita una variable de la fase 1, deberá declarar una dependencia explícita en la fase 1.

Deshabilitación de las actualizaciones automáticas de agentes en un nivel de grupo

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 una versión más reciente del agente para funcionar 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 se actualicen los agentes. 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 los diagnósticos, use run.sh --diagnostics o run.cmd --diagnostics en Windows.

Enlaces de servicio para canalizaciones YAML

La integración de servicios con canalizaciones YAML es más fácil. Con 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 una incidencia del departamento de soporte técnico 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 se produce un error en una fase.

El filtrado por el nombre de canalización y el nombre de fase se admite 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 la canalización o la fase.

Integración optimizada

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 implementación de marcas de características y experimentación a las canalizaciones de compilación y versión, por lo que puede iterar continuamente, implementar características y revertirlas mediante Azure Pipelines.

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

Adición de una versión de GitHub como origen de artefacto

Ahora puede vincular las versiones de GitHub como origen de artefactos en canalizaciones de versión 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 de la 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 versión de GitHub consuma como versión de etiqueta específica más reciente o seleccionar en el momento de la creación de la versión. Una vez que se vincula 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 control de versiones de la infraestructura de forma segura y eficaz. Terraform codifies API en archivos de configuración declarativos que le permiten 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 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 versión, por lo que puede iterar e implementar continuamente a un ritmo acelerado mediante la administración continua de los experimentos mientras obtiene todas las ventajas de DevOps de Azure Pipelines.

Puede descargar la extensión de experimentos de Google Analytics desde 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 Nueva 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 de éxito avanzados para que pueda usar cualquier propiedad de cambio para decidir el resultado de la puerta.

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

Solución y administración de errores poco confiables

Se ha introducido la administración de pruebas poco dinámicas para admitir el ciclo de vida completo con detección, generación de informes y resolución. Para mejorar aún más, vamos a agregar una solución y administración de errores de prueba poco confiables.

Al investigar la prueba escamosa, puede crear un error mediante la acción De error que, a continuación, se puede asignar a un desarrollador para investigar aún más la causa principal de la prueba flaky. El informe de errores incluye información sobre la canalización, como el mensaje de error, el seguimiento de la pila y otra información asociada a la prueba.

Cuando se resuelva o cierre un informe de errores, se desmarcará automáticamente la prueba como poco fiera.

Establezca las tareas de VSTest en error si no se ejecuta un 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 canalizaciones se realizan correctamente porque las pruebas se omiten en lugar de porque el código es de 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 TESTResultsDirectory de VSTest 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 $(Agent.TempDirectory)\TestResults carpeta . 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, todas las tareas posteriores que necesiten los archivos de una ubicación determinada pueden usarlas.

Compatibilidad con 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 para la ejecución de pruebas y el resultado de la prueba para mejorar la legibilidad y facilitar la experiencia de solución de problemas 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 puede agregar decoradores de canalización a trabajos de implementación. Puede tener cualquier paso personalizado (por ejemplo, detector de vulnerabilidades) insertado automáticamente en cada ejecución de enlace 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, esto se puede aprovechar como parte de la aplicación de prácticas de implementación seguras.

Además, los trabajos de implementación se pueden ejecutar como un trabajo de contenedor junto con servicios side-car si se definen.

Test Plans

Página Nuevo plan de prueba

Hay disponible una nueva página de Test Plans (Test Plans *) 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 libre de desorden y es coherente con el resto de la oferta de Azure DevOps.

Ayúdame a comprender la nueva página

La nueva página de Test Plans 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 del plan de prueba: úselo para buscar, favoritos, 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 de usuario.
3. Definir pestaña: Intercalar, agregar y administrar casos de prueba en un conjunto de pruebas que prefiera a través de esta pestaña.
4. Pestaña Ejecutar: asigne y ejecute pruebas a través de esta pestaña o busque un resultado de prueba para profundizar.
5. Pestaña Gráfico: realice 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. Extensibilidad: admite los puntos de extensibilidad actuales dentro del producto.

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

1. Encabezado del plan de prueba

Tareas

El encabezado Plan de pruebas 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 acceso de iteración del plan de prueba, que indica claramente si el plan de prueba es Actual o Pasado.
• Vea el resumen rápido del informe Progreso de la prueba con un vínculo para ir al informe.
• Vuelva a la página de Test Plans All/Mine

Opciones del menú contextual

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

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

Copia del plan de prueba (nueva funcionalidad)

Se recomienda crear un nuevo plan de pruebas por sprint o 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 en proyectos también.
Para obtener más instrucciones sobre Test Plans uso, consulte aquí.

2. Árbol de conjuntos de pruebas

Tareas

El encabezado Test Suite permite realizar las siguientes tareas:

• Expandir o contraer: esta barra de herramientas le permite expandir o contraer el árbol de jerarquía del conjunto de aplicaciones.
• Mostrar puntos de prueba de conjuntos secundarios: 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 del conjunto determinado y sus elementos secundarios en una vista para facilitar la administración de puntos de prueba sin tener que navegar a conjuntos individuales de uno en uno.
• Conjuntos de pedidos: puede arrastrar o colocar conjuntos para reordenar la jerarquía de conjuntos o moverlos de una jerarquía de conjuntos a otra dentro del plan de prueba.

Opciones del menú contextual

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

• Create nuevos conjuntos: puede crear 3 tipos diferentes de suites de la siguiente manera:
  • Use conjunto estático o conjunto de carpetas para organizar las pruebas.
  • Use el conjunto basado en requisitos para vincular directamente los requisitos o casos de usuario para una rastreabilidad sin problemas.
  • Use la consulta basada en consultas para organizar dinámicamente los casos de prueba que cumplen los criterios de consulta.
• Asignar configuraciones: puede asignar configuraciones para el conjunto de aplicaciones (por ejemplo: Chrome, Firefox, EdgeChromium) y, a continuación, se aplicarán a todos los casos de prueba existentes o a los nuevos casos de prueba que agregue más adelante a este conjunto.
• Exportar como pdf/correo electrónico: exporte las propiedades del plan de pruebas, 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 pruebas 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 le 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 determinadas operaciones solo están disponibles para los usuarios con el nivel de acceso Básico + Test Plans o equivalente. Todo lo demás debe ser ejercicio por 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 grid: 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 arrastrando o colocando: puede reordenar los casos de prueba arrastrando o colocando 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 aplicaciones a otro: mediante arrastrar y colocar, puede mover casos de prueba de un conjunto de pruebas a otro.
• Mostrar cuadrícula: puede usar el modo de cuadrícula para ver o editar casos de prueba junto con los pasos de prueba.
• Vista de pantalla completa: puede ver el contenido de toda la pestaña Definir en un modo de pantalla completa con esta opción.
• Filtrado: con la barra de filtro, puede filtrar la lista de casos de prueba mediante los campos de "título del caso de prueba", "asignado a" y "state". 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 del menú contextual

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

• Abrir o editar formulario de 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 que se editan los campos del elemento de trabajo, incluidos los pasos de prueba.
• Editar casos de prueba: esta opción permite editar de forma masiva campos de elementos de trabajo caso 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 invalidar las configuraciones de nivel de conjunto con configuraciones de nivel de caso de prueba.
• Quitar casos de prueba: esta opción permite quitar los casos de prueba del conjunto de aplicaciones especificados. Sin embargo, no cambia el elemento de trabajo subyacente del caso de prueba.
• Create 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 más información.
• Ver elementos vinculados: esta opción permite examinar los elementos vinculados de un caso de prueba determinado. Consulte a continuación para más información.

Copiar o clonar casos de prueba (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 de 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 Test Plans. 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 donde 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 Ejecutar

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? Los casos de prueba por sí mismos no son ejecutables. Cuando se agrega 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 las pruebas. A través de la vista de resultados de la prueba (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 ve en la pestaña Ejecutar.
Por lo tanto, los casos de prueba son entidades reutilizables. Al incluirlos en un plan o conjunto de pruebas, se generan puntos de prueba. Al ejecutar puntos de prueba, usted 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 el seguimiento o ejecución de pruebas (solo necesitan tener el nivel de acceso "Básico", no están sobrecargados por la complejidad de la administración del conjunto de aplicaciones (definir pestaña está oculta para dichos usuarios).

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

Tareas

La pestaña Ejecutar permite realizar las siguientes tareas:

• Puntos de prueba de marca masiva: esta opción permite marcar rápidamente el resultado de los puntos de prueba: superados, con errores, bloqueados o no aplicables, sin tener que ejecutar el caso de prueba a través del ejecutor de pruebas. El resultado se puede marcar para uno o varios puntos de prueba en una sola vez.
• Ejecutar puntos de prueba: esta opción le permite ejecutar los casos de prueba pasando individualmente por cada paso de prueba y marcandolos superando o fallando 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 un 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", "state", "test outcome", "Tester" y "Configuration". También puede ordenar la lista haciendo clic en los encabezados de columna.

Opciones del menú contextual

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 antes, 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 en activo, lo que omite el último resultado del punto de prueba.
• Abrir o editar formulario de 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 que se editan los campos del elemento de trabajo, incluidos los pasos de prueba.
• Asignar evaluador: 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, incluidos el resultado de cada paso de prueba, comentarios agregados o errores archivados.
• Ver el 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 donde 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 Test Plans

Este informe lista para usar le ayuda a realizar un seguimiento de la ejecución y el estado de una o varias Test Plans en un proyecto. Visite Test Plans > Informe de progreso* para empezar a usar el informe.

Las tres secciones del informe 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.

Artifacts

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, restaure 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 los 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, podía autenticarse con estos administradores de paquetes mediante tareas que proporcionaban una gran cantidad de funcionalidad, incluida la capacidad de publicar y descargar paquetes. Sin embargo, esto requiere usar 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 de uso de 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 más información, consulte la documentación de la tarea de autenticación de NuGet, npm, PIP, Twine y Maven .

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

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 un 10 %. Las fuentes más grandes han visto la mayor mejora del tiempo de carga de la página de alimentación del percentil 99 (tiempos de carga en el 99 % más alto de todas las fuentes) disminuyeron en un 75 %.

Compartir los paquetes públicamente con fuentes públicas

Ahora puede crear y almacenar los paquetes dentro de fuentes públicas. Los paquetes almacenados en fuentes públicas están disponibles para todos los usuarios de Internet sin autenticación, tanto si están en la colección como si 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 o vaya directamente a nuestro tutorial para compartir paquetes públicamente.

Configuración de ascendentes en diferentes colecciones dentro de un inquilino de AAD

Ahora puede agregar una fuente en otra colección asociada al inquilino de Azure Active Directory (AAD) como origen ascendente a la fuente Artifacts. La fuente puede encontrar y usar paquetes de las fuentes que están configuradas como orígenes ascendentes, lo que permite que los paquetes se compartan fácilmente entre colecciones asociadas con el inquilino de AAD. Vea cómo configurarlo 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 (artefactos y llaves) para configurar automáticamente la autenticación para publicar o consumir paquetes de Python en una fuente de Azure Artifacts o desde él. Con el proveedor de credenciales, no es necesario configurar ningún archivo de configuración (pip.ini/pip.conf/.pypirc), simplemente se le dirigirá a través de un flujo de autenticación en el explorador web al llamar a pip o twine por primera vez. Consulte más información en la documentación.

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

Ahora se muestran iconos, descripciones y autores de paquetes 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.

Se ha actualizado la experiencia de conexión a la fuente

El cuadro de diálogo Conectar a 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 sobre la configuración y ampliar las herramientas para las que proporcionamos instrucciones.

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

La versión preliminar pública de las fuentes públicas ha recibido una gran adopción y comentarios. En esta versión, ampliamos características adicionales 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 si puede subir hacia y desde fuentes privadas y con ámbito de proyecto.

Create fuentes con ámbito de proyecto desde el portal

Cuando publicamos fuentes públicas, también publicamos fuentes con á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 son proyecto y cuáles tienen ámbito de colección en el selector de fuentes.

Mejoras de rendimiento de npm

Hemos realizado cambios en el 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 10 veces en la latencia para algunas de las API usadas más altas para npm.

Mejoras de accesibilidad

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

• experiencia de fuente de Create
• Experiencia de configuración de fuentes globales
• Conexión a la experiencia de fuente

Wiki

Edición enriquecida 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.

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

A medida que escuchamos sus comentarios, hemos oído que usa wiki para capturar documentos de lluvia de ideas, documentos de planificación, ideas sobre características, documentos de especificación, minutos 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 el modificador de contexto, ya que no sale del ámbito 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 colaborar en el contenido y obtener preguntas respondiera a un desafío, ya que las conversaciones tenían que ocurrir a través de canales de correo o chat. Con comentarios, ahora puede colaborar con otros usuarios directamente dentro de la wiki. Puede aprovechar la @mention funcionalidad de los usuarios dentro de los comentarios para llamar la atención de otros miembros del equipo. Esta característica se ha priorizado en función de esta incidencia 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 pensadas para ocultarse, se muestren en el árbol wiki. Ahora, todos los archivos y carpetas a partir de un punto permanecerán ocultos en el árbol wiki, lo que reduce el desorden innecesario.

Esta característica se ha priorizado en función de esta incidencia 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 wiki de Bienvenida a 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 esta incidencia de sugerencia de característica de la Developer Community.

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. Al desplazarse por un lado, se desplazará automáticamente el otro lado para asignar las secciones correspondientes. Puede deshabilitar el desplazamiento sincrónico con el botón de alternancia.

Nota

El estado del botón de alternancia de desplazamiento sincrónico se guarda por usuario y cuenta.

Visitas a páginas wiki

Ahora puede obtener información sobre las visitas de 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 las páginas más vistas de la parte superior n.

También verá un recuento agregado de visitas de página 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.

Notificación

Informes de duración y errores de canalización

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

1. El informe de errores de canalización muestra la tasa de pasos de compilación y la tendencia de error. Además, también mostrará la tendencia de errores de tareas para proporcionar información sobre qué tarea de la canalización contribuye al número máximo de errores.

2. El informe de duración de la canalización muestra la tendencia del tiempo necesario para que se ejecute una canalización. También muestra qué tareas de la canalización tardan más tiempo.

Mejora en el widget Resultados de la consulta

El widget de resultados de la consulta es uno de nuestros widgets más populares y por un buen motivo. El widget muestra los resultados de una consulta directamente en el panel y resulta útil en muchas situaciones.

Con esta actualización hemos incluido muchas mejoras a largo plazo:

• 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, se guardará el ancho de columna.
• Puede expandir el widget a la vista de pantalla completa. Cuando se expanda, mostrará todas las columnas devueltas por la consulta.

Widgets de tiempo de cliente potencial y ciclo avanzados de filtrado

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

Hasta ahora, los widgets de tiempo de cliente potencial y ciclo no admitieron criterios de filtro avanzados para formular 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 la calle del panel.

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

Su Sprint Burndown ahora puede quemar por Stories. Esto aborda los comentarios de la Developer Community.

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

1. Seleccionar trabajos pendientes de casos
2. Seleccione para quemar en Sum of Story Points (Suma de puntos de historia)

Un widget de Sprint Burndown con todo lo que ha estado pidiendo

El nuevo widget Sprint Burndown admite la grabación por puntos de historia, recuento de tareas o sumando campos personalizados. Incluso puede crear una grabación de sprint para características o epopeyas. El widget muestra el promedio de agotamiento, % completado y aumento del ámbito. Puede configurar el equipo, lo que le permite mostrar quemaduras de sprint para varios equipos en el mismo panel. Con toda esta excelente información para mostrar, le permitimos cambiar el tamaño hasta 10x10 en el panel.

Para probarlo, puede agregarlo desde el catálogo de widgets o editando la configuración del widget Sprint Burndown existente y activando 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 reducción de sprint insertada

¡El Sprint Burndown vuelve! Hace unos cuantos sprint, 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 de la quema 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 quemarse en función de historias, puntos de historia o recuento de tareas, en lugar de solo la cantidad de trabajo restante.

Create un panel sin un equipo

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

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 los 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 que nos diera su opinión. Puede notificar un problema o proporcionar una idea y realizar un seguimiento de él a través de Developer Community y obtener consejos sobre Stack Overflow.

---

Principio de página