Azure DevOps Server de la versión de 2020

Desarrollador Community | Requisitos del sistema | Términos de licencia | DevOps blog | Hash sha-1

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 Azure DevOps Server, consulte Azure DevOps Server requisitos. Para descargar Azure DevOps productos, visite la página Azure DevOps Server descargas.

La actualización directa a Azure DevOps Server 2020 se admite desde Azure DevOps Server 2019 o Team Foundation Server 2015 o posterior. 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 Azure DevOps local.


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

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

  • Anteriormente, Azure DevOps Server podía crear conexiones a GitHub Enterprise Server. Con esta revisión, los administradores de proyectos pueden crear conexiones entre Azure DevOps Server repositorios y en GitHub.com. Puede encontrar esta configuración en la página de conexiones GitHub en Project Configuración.
  • 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 el problema con la Project resumen de información general no se puede cargar.
  • Se ha corregido el problema con los correos electrónicos que no se envían para confirmar la actualización del producto.

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

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

  • Corrección Artifacts error de descarga y carga.
  • Resuelva el problema con datos de Resultados de pruebas incoherentes.

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

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

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

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

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

  • Se ha corregido el problema con la importación de datos. La importación de datos tardaba mucho tiempo para 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, hemos quitado referencias a casos de prueba obsoletos para ayudar a acelerar el proceso de importación de datos.

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

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

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

Si ha 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 desde el vínculo anterior. La salida del comando dirá 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 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.

Para implementar correcciones para esta revisión, tendrá que seguir los pasos que se indican a continuación para las instalaciones de tareas de instalación de revisiones generales, AzureResourceGroupDeploymentV2 y AzureResourceManagerTemplateDeploymentV3.

Instalación general de revisiones

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 desde el vínculo anterior. La salida del comando dirá 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 AzureResourceGroupDeploymentV2.zip paquete en una nueva carpeta 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
  1. 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.

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

  1. 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 AzureResourceManagerTemplateDeploymentV3.zip paquete en una nueva carpeta del equipo. Por ejemplo:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

  2. Descargue e instale Node.js 14.15.1 y npm (incluidos con el Node.js descargar) según corresponda para el equipo.

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

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

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

Azure DevOps Server versión de la revisión 3 de 2020: 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.

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

Azure DevOps Server 2020.0.1 es una succión 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 Azure DevOps Server 2020, Azure DevOps Server 2019 y Team Foundation Server 2012 o posterior.

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

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

Azure DevOps Server versión de la revisión 2 de 2020: 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 revisión 1 de 2020 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 succión de correcciones de errores. Incluye todas las características del Azure DevOps Server 2020 RC2 publicado 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 una versión candidata para lanzamiento de Azure DevOps 2020 e instalar en el mismo directorio que la versión anterior, el ensamblado no se Microsoft.TeamFoundation.Git.dll instalará. Puede comprobar que ha alcanzado el problema si busca Microsoft.TeamFoundation.Git.dll en <Install Dir>\Version Control Proxy\Web Services\bin las <Install Dir>\Application Tier\TFSJobAgent carpetas y <Install Dir>\Tools . Si falta el archivo, puede ejecutar una reparación para restaurar los archivos que faltan.

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

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

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

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

Se ha reenlazado Azure DevOps Server 2020 RC1 para corregir esta entrada de comentarios Community desarrollador.

Anteriormente, después de actualizar de Azure DevOps Server 2019 Update 1.1 a Azure DevOps Server 2020 RC1, no podía ver los archivos en Repos, Pipelines 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 se ha corregido este problema. Consulte la entrada de blog para obtener más información.

Azure DevOps Server lanzamiento de 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:

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


General

Azure DevOps Disponibilidad general de la CLI

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

Para obtener más información sobre Azure DevOps CLI, 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 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 de 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".

Captura de pantalla que muestra el nuevo filtro Elemento de trabajo primario.

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

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

Captura de pantalla que muestra el cuadro de diálogo Campos que faltan que aparece al hacer clic en el mensaje de error rojo.

Recarga en directo de elementos de trabajo

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

Vídeo corto que muestra cómo funciona la recarga en directo del elemento de trabajo.

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

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

Columna primaria de 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 en el trabajo pendiente de sprint. Para habilitar esta característica, vaya a Opciones de columna en el trabajo pendiente deseado y agregue la columna Principal.

Captura de pantalla de un trabajo pendiente con la Opciones de columna seleccionada.

Cambio del proceso utilizado por un proyecto

Las herramientas deben cambiar a medida que 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 Agile a Scrum o Básico a Agile. Puede encontrar documentación detallada aquí.

Captura de pantalla de la pestaña Proyectos con la opción Cambiar proceso seleccionada.

Ocultar campos personalizados del diseño

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

Captura de pantalla que muestra la opción Ocultar del diseño.

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

No se puede corregir lo que no se puede ver. Por lo tanto, quiere estar atento al estado y el estado de sus procesos de trabajo. Con estos informes, le estamos facilitando el seguimiento de métricas importantes con un esfuerzo mínimo en Azure Boards.

Los tres nuevos informes interactivos son: Burndown, Cumulative Flow Diagram (CFD) y Velocity. Puede ver los informes en la nueva pestaña análisis.

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

  • ¿Cuánto trabajo queda en este sprint? ¿Estamos en camino de completarlo?
  • ¿Qué paso del proceso de desarrollo está tardando más tiempo? ¿Podemos hacer algo al respecto?
  • 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 le permiten ajustarlos según sus necesidades. Puede encontrar los nuevos informes en la pestaña Análisis de cada centro.

  • El gráfico de grabación se puede encontrar en el centro Sprints.

    Captura de pantalla del gráfico de grabación en la pestaña Análisis.

  • Se puede acceder a los informes CFD y Velocity desde la pestaña Analytics (Análisis) en Boards y Backlogs (Trabajo pendiente) haciendo clic en la tarjeta correspondiente.

    Captura de pantalla del informe Flow diagrama acumulativo y el informe de velocidad en la pestaña Análisis.

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

  • Los informes 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 de la aplicación de sprint sin que ello afecte a las fechas del proyecto. Por lo tanto, si el equipo suele dedicar el primer día de cada planeamiento de sprint, ahora puede hacer coincidir el gráfico para reflejarlo.
  • El gráfico de burndown ahora tiene una marca de agua que muestra los fines de semana.
  • El informe CFD le permite quitar columnas de placa como Diseño para centrarse más en el flujo sobre 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 casos.

Captura de pantalla del diagrama Flow en la pestaña Análisis.

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 se admiten requisitos. Este es un ejemplo de un informe de velocidad para las últimas 6 iteraciones del trabajo pendiente características.

Captura de pantalla del gráfico Velocidad en la pestaña Análisis.

Personalización de columnas del panel de tareas

Nos complace anunciar que hemos agregado una opción para que pueda 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.

Captura de pantalla de un panel de tareas con Opciones de columna opción seleccionada.

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

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

Muchas veces, al refinar el trabajo pendiente, solo desea 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 la alternancia está activa, 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.

Vídeo corto que muestra cómo mostrar u ocultar elementos secundarios en el 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 correcta a los elementos de trabajo.

Captura de pantalla que muestra las etiquetas usadas más recientes al etiquetar un elemento de trabajo.

Reglas de solo lectura y necesarias para la pertenencia a grupos

Las reglas de elementos de trabajo permiten establecer acciones específicas en los campos de elementos de trabajo para automatizar su comportamiento. Puede crear una regla para establecer un campo en de solo lectura o necesario 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 y, al mismo tiempo, que sea de solo lectura para todos los demás.

Captura de pantalla del cuadro de diálogo Nueva regla de elemento de trabajo que muestra la sección Condiciones y la sección Acciones.

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

Ahora puede personalizar los valores de cualquier lista desplegable del sistema (excepto el campo de motivo), como Gravedad, Actividad, Prioridad, etc. El ámbito de las personalizaciones de la lista desplegable es que puede administrar valores diferentes para el mismo campo para cada tipo de elemento de trabajo.

Vídeo corto que muestra cómo personalizar los valores de la lista desplegable del sistema.

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

Comparta vínculos a elementos de trabajo con el contexto de la placa o el trabajo pendiente con nuestro nuevo parámetro de dirección URL de elemento de trabajo. Ahora puede abrir un cuadro de diálogo de elemento de trabajo en la experiencia de tabla, trabajo pendiente o sprint anexando el parámetro a ?workitem=[ID] la dirección URL.

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

Mencione personas, elementos de trabajo y puntos de referencia en campos de texto

A medida que escuchamos sus comentarios, escuchamos que quería la capacidad de mencionar personas, elementos de trabajo y puntos de trabajo en el área de descripción de elementos 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 quiere resaltar una PR 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 PR en todos los campos de texto largo del elemento de trabajo.

Puede ver un ejemplo aquí.

Captura de pantalla que muestra que puede mencionar personas, elementos de trabajo y puntos de trabajo en el área Descripción del elemento de trabajo.

  • Para usar menciones de personas, escriba el signo y el nombre de @ la persona que desea mencionar. @mentions en los campos de elemento de trabajo generará notificaciones por correo electrónico como lo que hace para los comentarios.
  • Para usar menciones de elementos 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 pr, agregue una . seguido del identificador o el nombre de la pr.

Reacción en los comentarios de discusión

Uno de nuestros objetivos principales es hacer que los elementos de trabajo sea más colaborativo para los equipos. Recientemente hemos realizado un sondeo en Twitter para averiguar qué características de colaboración desea en los debates sobre el elemento de trabajo. Al hacer reaccionar a los comentarios, ganamos el sondeo, así que los agregamos. Estos son los resultados del sondeo de Twitter.

Captura de pantalla del Azure DevOps de Twitter que muestra que el 35 % de los encuestados desea la característica Reacción en comentarios.

Puede agregar reacción a cualquier comentario y hay dos maneras de agregar sus reacción: 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 reacción si lo desea, o solo una o dos. Para quitar la reacción, haga clic en la reacción en la parte inferior del comentario y se quitará. A continuación puede ver la experiencia de agregar una reacción, así como el aspecto de las reacción en un comentario.

Captura de pantalla que muestra que puede agregar reacción a los comentarios de dos maneras diferentes.

Anclar Azure Boards informes al panel

En la actualización sprint 155, incluímos las versiones actualizadas de los informes CFD y Velocity. Estos informes están disponibles en la pestaña Analytics (Análisis) de Boards y Backlogs (Trabajo pendiente). Ahora puede anclar los informes directamente al panel. Para anclar los informes, mantenga el puntero sobre el informe y seleccione los puntos suspensivos "..." y Copiar en el panel.

Captura de pantalla que muestra la opción Copiar en el panel.

Realizar un seguimiento del progreso de los elementos primarios mediante acumulación Boards trabajo pendiente

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

Por ejemplo, aquí se muestra Progress by Work Items (Progreso por elementos de trabajo), que muestra las barras de progreso de los elementos de trabajo ascendentes en función del porcentaje de elementos descendientes que se han cerrado. Los elementos descendientes de 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.

Captura de pantalla de elementos de trabajo en un trabajo pendiente.

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 muevan 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 elegir una columna Acumulación de la lista Rápida; sin embargo, si desea realizar la acumulación en campos numéricos que no forman parte de la plantilla de proceso estándar, 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 paquete acumulativo de paquetes acumulativos personalizados.

    Captura de pantalla de la lista desplegable Agregar una columna de acumulación.

  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 llevará de nuevo al panel de opciones de columna, donde puede reordenar la nueva columna personalizada.

Captura de pantalla del panel de opciones de columna que muestra 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 en función de la condición

Hemos agregado una nueva regla al motor de reglas heredado para que se oculte campos en un formulario de elemento de trabajo. Esta regla ocultará los campos en función de la pertenencia al grupo 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 personalizada de notificaciones de elementos de trabajo

Mantenerse al día con 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 los proyectos y se asegura de que todas las partes correctas estén implicadas. Sin embargo, las distintas partes interesadas tienen distintos niveles de inversión en diferentes esfuerzos y creemos que esto debe reflejarse en su capacidad para 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 todos los cambios realizados en el elemento de trabajo. Después de considerar sus comentarios, estamos haciendo que seguir 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 siguientes.

Captura de pantalla de la esquina superior derecha de un elemento de trabajo con el cursor sobre el icono de engranaje.

En Notification Configuración, puede elegir entre tres opciones de notificación. En primer lugar, se puede cancelar la suscripción por completo. En segundo lugar, puede estar totalmente suscrito, donde recibe notificaciones de todos los cambios de elementos de trabajo. Por último, puede optar por recibir notificaciones de algunos de los eventos de cambio de elementos de trabajo principales y cruciales. Puede seleccionar solo una o las tres opciones. Esto permitirá que los miembros del equipo sigan los elementos de trabajo en un nivel superior y no se distraiga con cada cambio que se realice. Con esta característica, eliminaremos los mensajes de correo electrónico innecesarios y le permitiremos centrarse en las tareas fundamentales que tenemos a mano.

Captura de pantalla del cuadro Configuración de diálogo Notificaciones que muestra el botón de radio Personalizado seleccionado junto con la opción Cambio de estado y la opción Iteración cambiada.

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

Captura de pantalla que muestra el control Implementación en el formulario de elemento de trabajo.

Importación de elementos de trabajo desde un archivo CSV

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

Vídeo corto que muestra cómo importar elementos de trabajo desde un archivo CSV.

Adición de un campo primario a las tarjetas de elemento de trabajo

El contexto primario ahora está disponible en el panel Kanban como un campo nuevo 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.

Captura de pantalla que muestra una tarjeta de elemento de trabajo con la opción Principal seleccionada.

Adición de un campo primario al trabajo pendiente y las consultas

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

Captura de pantalla de la sección Opciones de columna con la opción Principal seleccionada.

Repos

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

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

Captura de pantalla que muestra que puede ver las métricas de cobertura de código para los cambios dentro de la vista de solicitud de extracción (PR).

Captura de pantalla de una diferencia de solicitud de extracción que muestra una nueva línea de código agregada a un archivo.

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

Captura de pantalla de la opción Agregar directiva de estado seleccionada y la sección Agregar directiva de estado que aparece al seleccionar la opción.

Filtrar las notificaciones de comentarios de las solicitudes de extracción

Los comentarios de las solicitudes de extracción a menudo pueden generar mucho ruido debido a las notificaciones. Hemos agregado una suscripción personalizada que permite filtrar las notificaciones de comentario a las que se suscribe por edad de comentario, comentario, comentario eliminado, usuarios mencionados, autor de la solicitud de extracción, rama de destino y participantes del subproceso. 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.

Captura de pantalla que muestra cómo filtrar las notificaciones de comentarios de las solicitudes de extracción.

Captura de pantalla que muestra la página Criterios de filtro y el contenido de la lista desplegable Campo.

Enlaces de servicio para comentarios de solicitud de extracción

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

Captura de pantalla del Asistente para nueva suscripción de enlaces de servicio.

Directiva para bloquear archivos con patrones especificados

Los administradores ahora pueden establecer una directiva para evitar que las confirmaciones se insertan 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.

Captura de pantalla que muestra la sección Directivas con la opción Validación de nombre de archivo establecida en Activa.

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 corregir, corregir o corregir. Por ejemplo, puede escribir "este cambio corregido #476" en el mensaje de confirmación y el elemento de trabajo 476 se completará cuando la confirmación se inserta o se combina 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 recursos, solo se requería una aprobación del grupo que se agregó. Ahora puede establecer directivas que requieren más de un revisor de un equipo para aprobar una solicitud de incorporación de incorporación de actualizaciones al agregar revisores automáticos. Además, puede agregar una directiva para evitar que los solicitantes aprueben sus propios cambios.

Captura de pantalla que muestra el cuadro de diálogo Incluir automáticamente revisores.

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, se usaba una Azure Resource Manager conexión. 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 cuenta 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 diferencia en paralelo de la solicitud de extracción

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

Captura de pantalla que muestra un archivo Markdown en un proyecto con las opciones Vista y Vista previa llamadas.

Expiración de la directiva 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 las políticas 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.

Captura de pantalla del cuadro de diálogo Agregar directiva de compilación con la sección Expiración de la compilación.

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

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

Captura de pantalla que muestra directivas para todos los repositorios de Git en la pestaña Directivas con la opción Confirmar validación de correo electrónico del autor establecida en Activa.

Esta característica se ha priorizado en función de una sugerencia del desarrollador Community ofrecer una experiencia similar. Seguiremos teniendo la entrada abierta y animaremos a los usuarios a que nos digan qué otros tipos de directivas de inserción le gustaría ver.

Marcar los archivos como revisados en una solicitud de extracción

En ocasiones, debe revisar las solicitudes de extracción 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 extracción.

Para marcar un archivo como revisado, use el menú desplegable situado junto a un nombre de archivo o mantenga el puntero y haga clic en el nombre del archivo.

Nota

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

Captura de pantalla que muestra un proyecto con las opciones Ver en el explorador de archivos y Marcar como opciones revisadas visibles.

Esta característica se ha priorizado en función de una sugerencia del desarrollador Community.

Nueva interfaz de usuario web para Azure Repos de aterrizaje

Ahora puede probar nuestras nuevas páginas de aterrizaje modernas, rápidas y fáciles de usar para dispositivos móviles en Azure Repos. Estas páginas están disponibles como Nuevas Repos de aterrizaje. Las páginas de aterrizaje incluyen todas las páginas excepto los detalles de la solicitud de extracción, los detalles de confirmación y la comparación de ramas.

Web

Captura de pantalla de la nueva interfaz de usuario web para Azure Repos de aterrizaje.

Móvil

Captura de pantalla de la nueva interfaz de usuario móvil para Azure Repos de aterrizaje.

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 extracción realizadas en cada rama principal de cada repositorio de su proyecto. Puede encontrar la característica Agregar protección de rama en el Repos Project Configuración.

Captura de pantalla del cuadro de diálogo Agregar protección de rama.

Nuevas páginas de aterrizaje de conversión de plataforma web

Hemos actualizado la experiencia de usuario Repos páginas de aterrizaje 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; seguiremos actualizando otras páginas en futuras actualizaciones.

Experiencia web:

Captura de pantalla de las páginas de aterrizaje de conversión de plataforma web.

Experiencia móvil:

Captura de pantalla de la página Archivos de conversión de plataforma móvil.

Captura de pantalla de la página Confirmaciones de conversión de plataforma móvil.

Compatibilidad con el lenguaje Kotlin

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

Captura de pantalla de un archivo Kotlin que se muestra en la interfaz de usuario.

Suscripción de notificación personalizada para las solicitudes de extracción de borrador

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

Captura de pantalla del cuadro de diálogo Nueva suscripción que muestra que Draft se ha agregado como opción a la característica Criterios de filtro.

Mejora de la capacidad de acción de la PR

Cuando tiene muchas solicitudes de extracción que revisar, comprender dónde debe tomar medidas primero puede ser difícil. Para mejorar la capacidad de acción de la solicitud de extracción, ahora puede crear varias consultas personalizadas en la página de lista de solicitudes de extracción 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 extracción a la que se agregó a través del menú Votar o el menú contextual de la página de lista de solicitudes de extracción. En las secciones personalizadas, ahora verá pestañas independientes para las solicitudes de extracción en las que ha proporcionado una revisión o que ha rechazado revisar. Estas consultas personalizadas funcionarán entre repositorios en la pestaña "Mis solicitudes de extracción" de la página principal de la colección. Si desea volver a una solicitud de extracción, puede marcarla y se mostrarán en la parte superior de la lista. Por último, las solicitudes de extracción que se han establecido en autocompletar se marcarán con una tableta que dice "Autocompletar" en la lista.

Canalizaciones

Canalizaciones de varias fases

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

Las siguientes funcionalidades se incluyen en la nueva experiencia:

  • ver y administrar varias fases
  • aprobar ejecuciones de canalización
  • desplazarse hasta el final en los registros mientras una canalización todavía está en curso
  • mantenimiento por rama de una canalización.

Implementación continua en YAML

Nos complace proporcionar características de CD Azure Pipelines YAML. 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:

Si está listo para empezar a compilar, consulte la documentación o el blog para crear 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.

Captura de pantalla que muestra el cuadro de diálogo Variables.

Aprobación de versiones directamente desde el centro de versiones

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

Captura de pantalla que muestra cómo aprobar versiones directamente desde el centro de versiones.

Integración de Bitbucket y otras mejoras en la introducción a las canalizaciones

La experiencia del asistente de introducción para Pipelines se ha actualizado para funcionar con repositorios de Bitbucket. Azure Pipelines analizará ahora el contenido del repositorio de Bitbucket y recomendará una plantilla YAML para que lo haga.

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

Por último, tendrá más control al registrar el archivo en otra rama, ya que puede optar por omitir la creación de una solicitud de extracción azure-pipelines.yml desde esa rama.

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

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

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

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

La respuesta contendrá el YAML representado.

Programaciones cron en YAML

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

  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 capacidad expresiva a la hora de definir programaciones que lo que pudo hacer con la interfaz de usuario. Por ejemplo, es más fácil especificar una única programación que inicie 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 facilitado el diagnóstico de problemas con las programaciones cron. Las ejecuciones programadas del menú Ejecutar canalización le ofrecerán una vista previa de las próximas ejecuciones programadas de la canalización para ayudarle a diagnosticar errores con las programaciones cron.

Captura de pantalla que muestra el menú Ejecutar canalización con la opción Ejecuciones programadas seleccionada.

Actualizaciones de la interfaz de usuario de conexiones de servicio

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

Captura de pantalla del cuadro de diálogo Nueva conexión de servicio.

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 y aprobaciones y comprobaciones de canalizaciones.

Captura de pantalla que muestra el menú Editar en una canalización de YAML con la opción Aprobaciones y comprobaciones visible.

La nueva experiencia del usuario se desactivará de forma predeterminada con esta actualización. Seguirá teniendo la opción de no participar en la versión preliminar.

Nota

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

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 cuidado al omitir las fases. Por ejemplo, si la primera fase genera determinados artefactos necesarios para las fases posteriores, no debe omitir la primera fase. El panel de ejecución presenta una advertencia genérica cada vez que se omiten las fases que tienen dependencias de nivel inferior. Le queda por determinar si esas dependencias son verdaderas dependencias de artefacto o si solo están presentes para la secuenciación de implementaciones.

Captura de pantalla que muestra la sección Ejecutar canalización con la opción Fases para ejecutar seleccionada.

Omitir una fase equivale a volver awiring las dependencias entre 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 se 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.

Captura de pantalla que muestra la sección Fases para ejecutar con la opción de desarrollo y la opción de implementación seleccionada.

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 incluye varias características críticas para admitir canalizaciones de CD de YAML de varias fases, como aprobaciones, autorizaciones y uso compartido entre proyectos.

Captura de pantalla del cuadro de diálogo Ejecutar canalización.

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

Selector de la versión del recurso de canalización en el cuadro de diálogo crear ejecución

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

Captura de pantalla del cuadro de diálogo Fases que se ejecutarán.

azMejoras de la CLI para Azure Pipelines

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

Puede ser complicado portar canalizaciones basadas en YAML de un proyecto a otro, ya que debe configurar manualmente las variables de canalización y los grupos de variables. Sin embargo, con los comandos de administración de variables y grupos de variables de canalización, ahora puede crear scripts para la configuración y administración de variables de canalización y grupos de variables que, a su vez, se pueden controlar por 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 pr.

Al crear una solicitud de cambio, puede ser difícil validar si los cambios pueden 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 solicitud de cambios, ahora puede validar y visualizar los cambios que se van a realizar ejecutándose en la canalización de destino. Consulte la documentación del comando az pipelines run y az pipelines build queue para obtener 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 defectuosa debido a diversos motivos: la infraestructura no está lista o necesita crear y actualizar grupos de variables o variables, etc. Con Azure DevOps CLI, ahora puede omitir la primera ejecución de canalización automatizada al crear una canalización mediante la inclusión del parámetro --skip-first-run. Consulte la documentación del comando az pipeline create para obtener más información.

Mejora del comando del punto de conexión de servicio

Los comandos de la CLI de 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 de file y proporciona comandos optimizados: az devops service-endpoint github y az devops service-endpoint azurerm, que proporcionan compatibilidad de primera clase para crear puntos de conexión de servicio de estos tipos. Consulte la documentación del comando para obtener más información.

Trabajos de implementación

Un trabajo de implementación es un tipo especial de trabajo que se usa para implementar la aplicación en un entorno. Con esta actualización, hemos agregado compatibilidad con las referencias de paso 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 al 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 cancelarlo automáticamente
  • cancelTimeoutInMinutes: cuánto tiempo se debe dar a "ejecutar siempre aunque se cancelen tareas" antes de terminarlas.
  • condition: ejecución condicional del trabajo
  • variables: se puede agregar directamente valores codificados, o grupos de variables,se puede hacer referencia a un grupo de variables con el respaldo de 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 incluso si se produce un error en este trabajo de implementación; el valor predeterminado es "false"

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

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

Hemos agregado compatibilidad a los detalles de las canalizaciones de YAML de CD en los que las canalizaciones de CI se conocen 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.

Captura de pantalla que muestra la información de canalizaciones de CD asociadas en canalizaciones de CI.

Compatibilidad con paquetes GitHub en canalizaciones 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 el lanzamiento de una nueva versión del paquete. En la actualidad, la compatibilidad solo está disponible para el consumo de paquetes de GitHub, pero más adelante, 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

Hoy GitHub paquetes solo admiten la autenticación basada en PAT, lo que significa que la conexión del servicio GitHub en el recurso de paquete debe ser de tipo PAT. Una vez que se haya lifted esta limitación, se proporcionará 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 que se define 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

Hemos agregado un vínculo a la vista de recursos de los entornos de Kubernetes para que pueda navegar a la hoja de Azure del clúster correspondiente. Esto se aplica a los entornos que están asignados a espacios de nombres en Azure Kubernetes Service clústeres.

Captura de pantalla de la vista de recursos del entorno de Kubernetes con el Azure Kubernetes Service cluster seleccionado.

Filtros de carpetas de versión en suscripciones de notificación

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

Captura de pantalla de los filtros de la carpeta de versión en las suscripciones de notificación.

Actualmente, puede vincular automáticamente elementos de trabajo con compilaciones clásicas. Sin embargo, esto no era posible con las canalizaciones de YAML. Con esta actualización hemos solucionado 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 creó el código para ese elemento de trabajo. Para configurarlo, use el panel de configuración de una canalización.

Cancelación de una fase en una ejecución de canalización de YAML de varias fases

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

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 error sin tener que empezar desde el principio. Con esta actualización, vamos a agregar una gran parte de esta funcionalidad.

Ahora puede reintentar una fase de canalización cuando se produce un error en la ejecución. Todos los trabajos con errores en el primer intento y los que dependen transitivamente de esos trabajos con errores se intentan de nuevo.

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 las pruebas de una plataforma no se realizan correctamente mientras otras pasan, puede ahorrar tiempo si no vuelve a ejecutar los trabajos que se han superado. Como otro ejemplo, es posible que se haya producir un error en una fase de implementación debido a una conexión de red desaprobada. Reintentar 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 infraestructuras 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 infraestructura (entorno) y de aplicación (canalización), garantizará el inicio de sesión manual para la implementación en una canalización determinada y tendrá un control central para aplicar las mismas comprobaciones en todas las implementaciones al entorno.

Captura de pantalla del menú Agregar recursos con la opción Comprobaciones subrayada.

Las ejecuciones de canalización que se implementan en dev se detendrán para su aprobación al principio de la fase.

Captura de pantalla que muestra que una implementación está esperando aprobación.

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

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 hemos aumentado 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 nueva, la plantilla recomendaba insertar la imagen en un Azure Container Registry e implementarla en un Azure Kubernetes Service. Hemos agregado una nueva plantilla para que le permita compilar una imagen con el agente sin necesidad de insertarla en un registro de contenedor.

Captura de pantalla del cuadro de diálogo docker.

Nueva tarea para configurar la configuración Azure App Service 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 Azure Pipelines de Azure App Service Configuración que admite la configuración de estos valores de forma masiva mediante la sintaxis JSON en la aplicación web o en 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 función o cualquier otra aplicación en contenedores App Services.

Captura de pantalla que muestra Azure App Service Configuración cuadro de diálogo.

Azure App Service ahora admite el intercambio con versión preliminar

Azure App Service ahora admite el intercambio con versión preliminar en sus ranuras de implementación. Esta es una buena manera de validar la aplicación con la configuración de producción antes de que la aplicación se intercambie realmente de un espacio de ensayo a un espacio de producción. Esto también garantizaría que el espacio de destino o producción no experimente tiempo de inactividad.

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

  • Iniciar intercambio con versión preliminar: inicia un intercambio con una versión preliminar (intercambio de varias fases) y aplica la configuración de la 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.

Captura de pantalla que muestra Azure App Service cuadro de diálogo Administrar con la nueva configuración de intercambio de varias fases en la lista desplegable Acción.

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

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

Captura de pantalla que muestra que puede usar expresiones regulares en el nivel de ensayo.

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 aprueba manualmente.

Captura de pantalla que muestra la pestaña Directivas con la página Usar aprobaciones manuales y la opción Crear visible.

Compatibilidad con pruebas de estructura de contenedor en Azure Pipelines

El uso de contenedores en las aplicaciones está aumentando y, por tanto, la necesidad de pruebas y validación sólidas. Azure Pipelines ahora proporciona compatibilidad con las 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 archivo y pruebas de metadatos. Puede usar los resultados de la canalización para tomar decisiones de ir o no ir. Los datos de prueba están disponibles en la ejecución de la canalización con un mensaje de error para ayudarle a solucionar mejor los errores.

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

Captura de pantalla que muestra la página Prueba de estructura de contenedor.

Datos de prueba y resumen

Captura de pantalla que muestra que hay disponible un resumen y datos de prueba.

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 respaldando decoradores para compilaciones y canalizaciones YAML, con clientes que los usan para controlar de forma centralizada los pasos de sus trabajos. Ahora ampliamos también 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 Azure Resource Manager (ARM) en el nivel de suscripción y grupo de administración

Anteriormente, solo se admiten implementaciones 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á al 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 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, se presenta pipelines como un recurso. En yaml, ahora puede hacer referencia a otra canalización y también habilitar los 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 de datos controlados en el entorno de Kubernetes

Una de las principales ventajas de la entrega continua de actualizaciones de aplicaciones es la capacidad de insertar actualizaciones rápidamente 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 la orquestación de estrategias de implementación y facilita las versiones sin tiempo de inactividad. Anteriormente, se admite la estrategia runOnce que ejecutaba los pasos una vez secuencialmente. Gracias a la compatibilidad con la estrategia de valor canario 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 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 canario de Kuberenetes implementará primero los cambios con un 10 % de pods seguidos de un 20 % mientras supervisa el estado durante postRouteTraffic. Si todo va bien, se promoverá al 100 %.

Estamos buscando comentarios anticipados sobre la compatibilidad con los recursos 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 las aprobaciones en el recurso y todas las canalizaciones que usan la pausa del recurso para las aprobaciones antes del inicio de la fase que consume el recurso. Es habitual que los propietarios de aplicaciones basadas en SOX restrinjan al solicitante de la implementación la aprobación de sus propias implementaciones.

Ahora puede usar opciones avanzadas de aprobación para configurar directivas de aprobación como que el solicitante no debe aprobar, requerir la aprobación de un subconjunto de usuarios y el tiempo de espera de aprobación.

Captura de pantalla que muestra el cuadro de diálogo Crear aprobaciones.

ACR como 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 imágenes 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 a partir 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.

Captura de pantalla que muestra el cuadro de diálogo Evaluar artefacto con la opción Usar plantillas subrayada.

Captura de pantalla que muestra el cuadro de diálogo Configurar directiva de artefactos con la opción Whitelist sources (Lista blanca de orígenes) y la opción Azure pipelines built images (Imágenes compiladas de Azure Pipelines) seleccionada.

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 sintaxis siguiente.

  • Para la estrategia runOnce:$[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
  • Para la estrategia de los canarios: $[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 las implementaciones programadas para las actualizaciones periódicas. Sin embargo, 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 planteaba un desafío, ya que la implementación manual se revertiría cuando las implementaciones se reanudaran según la programación. Muchos de los usuarios han notificado 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 cola está seleccionada como "Implementar la versión más reciente y cancelar otras".

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 de YAML, se produjo un error de autorización de recursos. Tenía que autorizar los recursos desde la página de resumen de la ejecución con errores. Además, se ha producido un error en la canalización si usaba una variable que hace referencia a un recurso no autorizado.

Ahora estamos facilitando la administración de autorizaciones de recursos. En lugar de dar error a la ejecución, la ejecución esperará permisos en los recursos al principio de la fase que consume el recurso. Un propietario del recurso puede ver la canalización y autorizar el recurso desde la página Seguridad.

Captura de pantalla que muestra que una fase de desarrollo está en estado En espera con un indicador que indica que se necesita permiso.

Evaluación de la comprobación de artefactos

Ahora puede definir un conjunto de directivas y agregar la evaluación de directivas como una comprobación en un entorno de 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 se supera cuando la directiva se realiza correctamente y marca la fase como con errores si se produce un error en la comprobación.

Captura de pantalla del cuadro de diálogo Evaluar directivas de artefacto.

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

Anteriormente, no filtramos las conexiones de servicio en la tarea de implementación de plantillas de ARM. Esto puede 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 de ámbito inferior en función del ámbito de implementación que elija.

ReviewApp in Environment

ReviewApp implementa todas las solicitudes de extracción 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 combinarse en la rama principal e implementarse en producción. Esto le permitirá crear y administrar fácilmente reviewApp resources y beneficiarse de toda la funcionalidad 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 del 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: MasterNamespace

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

Ahora puede habilitar la recopilación automática y de metadatos especificada por el usuario a partir de tareas de canalización. Puede usar metadatos para aplicar la directiva de artefactos en un entorno mediante la comprobación de evaluar artefacto.

Captura de pantalla del cuadro de diálogo General con la opción Publicar metadatos desde canalizaciones activada.

Implementaciones de máquinas virtuales con entornos

Una de las características más solicitadas en Entornos fue las implementaciones de máquinas virtuales. Con esta actualización, se habilita el recurso máquina virtual en entornos. Ahora puede organizar las implementaciones en varias máquinas y realizar actualizaciones graduales mediante canalizaciones yaml. También puede instalar el agente en cada uno de los servidores de destino directamente e impulsar la implementación gradual en esos servidores. Además, puede usar el catálogo de tareas completo en las máquinas de destino.

Captura de pantalla del cuadro de diálogo Nuevo entorno con la opción Máquinas virtuales seleccionada y seleccionada.

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, la implementación gradual actualiza 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 implementa. 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 el enlace de ciclo deploy de vida. Sin embargo, puede elegir descargar si especifica la tarea Descargar artefacto de canalización. Hay algunas lagunas conocidas en esta característica. Por ejemplo, al reintentar una fase, volverá a ejecutar la implementación en todas las máquinas virtuales, no solo en 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 desde hace 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 directivas automatizadas checks para comprobar la seguridad y la 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 estar seguro de que todas las implementaciones destinadas a los recursos son seguras, independientemente de la canalización de YAML que realiza 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:

  • Invoque cualquier API REST y realice la validación en función del cuerpo de la respuesta o una devolución de llamada del servicio externo.
  • Invocación de una función de Azure y validación en función de la respuesta o una devolución de llamada de la función
  • Consulta de Azure Monitor para alertas activas
  • Asegúrese de que la canalización extiende una o varias plantillas de YAML.

Captura de pantalla del cuadro de diálogo Agregar casilla.

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, se envía a los aprobadores una notificación por correo electrónico para la aprobación pendiente. Los usuarios y propietarios de equipos pueden rechazar o configurar suscripciones personalizadas mediante la configuración de notificación.

Captura de pantalla de una notificación de aprobación.

Configurar estrategias de implementación desde Azure Portal

Con esta funcionalidad, le hemos facilitado la configuración de canalizaciones que usan la estrategia de implementación que prefiera, por ejemplo, Rolling, Canary o Blue-Green. Con estas estrategias rápidas, 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 implementa el paquete seleccionado en esta máquina virtual.

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

Captura de pantalla que muestra el cuadro de diálogo Entrega continua.

Parámetros en tiempo de ejecución

Los parámetros en tiempo de ejecución permiten tener más control sobre los valores que 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 a scripts y tareas en tiempo de ejecución
  • Tipos de parámetros de control, intervalos permitidos y valores predeterminados
  • Selección dinámica de trabajos y fases con expresión de plantilla

Para 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 factoriza en plantillas, lo que promueve la reutilización y reduce la reutilizable. La estructura general de la canalización todavía estaba definida por el archivo YAML raíz. Con esta actualización, hemos agregado una manera más estructurada de usar plantillas de canalización. 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 qué segmentos son fijos. También hemos mejorado los parámetros de canalización con tipos de datos para dejar claros los enlaces que puede proporcionar.

En este ejemplo se muestra cómo puede proporcionar enlaces sencillos para que lo use el autor de la canalización. La plantilla siempre ejecutará una compilación, ejecutará opcionalmente pasos adicionales proporcionados por la canalización y, a continuación, ejecutará un paso de prueba opcional.


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

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

Variables de control que se pueden invalidar en tiempo de cola

Anteriormente, 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 determinadas variables como , el sistema no lo ha hecho, ni ha impedido que se _settable at queue time_ 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 dará 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 las colecciones existentes, pero estará desactivada de forma predeterminada al crear una nueva Azure DevOps colección.

Nuevas variables predefinidas en la canalización de YAML

Las variables le dan una manera cómoda de obtener los bits clave de datos en varias 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, con el ámbito del 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: el nombre del recurso en el entorno de destino del trabajo de implementación.

Desprotección de varios repositorios

Pipelines a menudo se basan en varios repositorios. Puede tener repositorios diferentes con código fuente, herramientas, scripts u otros elementos que necesite para compilar el código. Anteriormente, tenía que agregar estos repositorios como submódulos o como scripts manuales para ejecutar git checkout. Ahora puede capturar y comprobar otros repositorios, además del que se usa para almacenar la canalización de YAML.

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

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

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

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

Azure Repos Se admiten los repositorios git, GitHub y Bitbucket Cloud. Para obtener más información, vea 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 desprotecciones de varios repositorios, es posible que también quiera conocer el repositorio, la rama y la confirmación que se han desprotebrado 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 Azure Repos recopilaciones

Anteriormente, al hacer referencia a repositorios en una canalización de YAML, todos los repositorios de 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

MyServiceConnectionapunta a otra Azure DevOps colección y tiene credenciales que pueden tener acceso al repositorio en otro proyecto. Tanto los repositorios como self otherrepo , terminarán desproteyécdos.

Importante

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

Captura de pantalla de Project Configuración página con la Azure Repos/Team Foundation Server opción resaltada.

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 bake como opciones de "bake" en la tarea KubernetesManifest

kustomize (parte de sig-cli de Kubernetes) le permite personalizar archivos YAML sin procesar y sin plantilla para varios propósitos y deja intacto el YAML original. 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)

transforme un archivo 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. Como resultado, se generaron mensajes de inicio de sesión interactivos y canalizaciones con error para un clúster Azure Active Directory rbac basado en rol. Para solucionar este problema, hemos agregado una casilla que le permite usar credenciales de administrador de clúster en lugar de credenciales de usuario de clúster.

Captura de pantalla de los gráficos de Helm de paquete e implementación que muestra la casilla usar credenciales de administrador de clústeres.

Entrada de argumentos en Docker Compose tarea

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

Captura de pantalla de Docker Compose tarea que muestra el nuevo cuadro de texto Argumentos.

GitHub de la tarea de versión

Hemos realizado varias mejoras en la tarea GitHub lanzamiento. 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 correspondiente.

Captura de pantalla que muestra GitHub la tarea de versión con las secciones Versión de tarea y Patrón de etiquetas que se han llamado.

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. La versión Comparar con puede ser la última versión completa (excluye las versiones preliminares), la última versión no borrador o cualquier versión anterior que coincida con la etiqueta de versión proporcionada. Además, la tarea proporciona el campo de tipo changelog 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 PUNTOS clasificados en función de las etiquetas.

Captura de pantalla que muestra GitHub la tarea de versión con las secciones Comparar con y Cambiar tipo de registro resaltadas.

Abrir la tarea instalador del agente de directiva

Open Policy Agent es un motor de directivas de código abierto de uso general que permite la aplicación de directivas unificadas y contextuales. Hemos agregado la tarea Desabrir el instalador del agente de directiva. Es especialmente útil para la aplicación de directivas en 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 CLI de Azure tarea

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

Captura de pantalla de la CLI de Azure que muestra que PowerShell y Powershell Core son opciones de la lista desplegable Tipo de script.

Implementaciones de control de datos de la interfaz de Service Mesh basadas en la tarea KubernetesManifest

Anteriormente, cuando se especificaba la estrategia de valor canario en la tarea KubernetesManifest, la tarea creaba cargas de trabajo de línea base y de valor canario 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 este problema, hemos agregado compatibilidad con implementaciones de valor canario 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 de base y de valor canario durante el ciclo de vida de la estrategia de implementación. La división de porcentaje deseada del tráfico entre estable, línea de base y valor controlado es más precisa, ya que la división del porcentaje de tráfico se controla en las solicitudes en el 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'

La 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 o máquinas virtuales (VM) de Microsoft. La tarea usa AzCopy, la compilación de la utilidad de línea de comandos 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. Entre ellas se incluyen las siguientes:

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

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

  • Símbolos comodín en el nombre de archivo o ruta de acceso del origen
  • Inferir el tipo de contenido en función de la extensión de archivo cuando no se proporciona ningún argumento
  • Definición del nivel de detalle del registro para el archivo de registro pasando un argumento

Mejora de la seguridad de las canalizaciones 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 las canalizaciones de compilación clásicas. Sin embargo, no tenía ese control para la versión clásica o las canalizaciones YAML. Con esta actualización, vamos a introducir una configuración de recopilación para forzar a cada trabajo a obtener 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 automáticamente esta configuración.

    Nota

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

    La activación de esta configuración en los proyectos y colecciones existentes puede hacer que se producirá un error en determinadas canalizaciones si las canalizaciones acceden a recursos que están fuera del proyecto de equipo mediante tokens de acceso. Para mitigar los errores de canalización, puede conceder explícitamente Project cuenta de servicio de compilación al recurso deseado. Se recomienda encarecidamente activar esta configuración de seguridad.

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

    Al basarse en la mejora de la seguridad de la canalización mediante la restricción del ámbito del token de acceso, Azure Pipelines ahora puede limitar el acceso 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 se filtrara, solo podría ver los repositorios usados en la canalización. Anteriormente, el token de acceso era bueno para cualquier repositorio Azure Repos del proyecto o, posiblemente, para toda la colección.

    Esta característica estará en modo predeterminado para nuevos proyectos y colecciones. Para las colecciones existentes, debe habilitarla en Colecciones Configuración > Pipelines > Configuración. Cuando se usa 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 Compilaciones de cola. Con esta actualización, se ha quitado este permiso al token de acceso. Si las canalizaciones necesitan este permiso, puede concederlo explícitamente a la cuenta de servicio de compilación de Project o a la cuenta de servicio de compilación de recopilación de Project según el token que use.

Project nivel de seguridad para las 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.

Captura de pantalla de la página Conexiones de servicio con la opción Seguridad seleccionada.

Destino de pasos y aislamiento de comandos

Azure Pipelines trabajos en ejecución en contenedores o en el host del agente. Anteriormente, se estableció un trabajo completo en uno de esos dos destinos. Ahora, se pueden ejecutar pasos individuales (tareas o scripts) 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 creado específicamente.

Los contenedores pueden actuar como límites de aislamiento, lo que impide que el código realice cambios inesperados en el equipo host. La forma en que los pasos se comunican con los servicios y acceden a los servicios desde el agente no se ve afectada por el aislamiento de los pasos de un contenedor. Por lo tanto, también vamos a introducir un modo de restricción de comandos que puede usar con destinos de paso. Al activarlo, se restringirán los servicios que un paso puede solicitar al 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 tomarían el nuevo valor. Con esta actualización, se reforzará la seguridad en torno a las variables de canalización para que las variables del sistema y del tiempo de cola sea de solo lectura. Además, puede hacer que una variable YAML sea de solo lectura si la marca como se muestra 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 mediante grupos Azure DevOps definidos previamente, como administradores de puntos de conexión y creadores de puntos de conexión.

Como parte de este trabajo, hemos introducido los nuevos roles 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.

Captura de pantalla que muestra el acceso basado en roles para las conexiones de servicio.

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

Uso compartido entre proyectos de conexiones de servicio

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

Captura de pantalla que muestra el uso compartido entre proyectos de conexiones de servicio.

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

Rastreabilidad de canalizaciones y recursos de ACR

Garantizamos 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 de. Ahora, la canalización se puede desencadenar tras la finalización de otra ejecución de canalización de Azure o cuando se inserta una imagen de contenedor en ACR.

    Captura de pantalla que muestra que una canalización se desencadenó automáticamente.

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

    Captura de pantalla que muestra las confirmaciones en la sección Canalización actual.

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

  • Artefactos que están disponibles para que los utilice la ejecución.

    Captura de pantalla que muestra Artifacts página de la canalización.

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

Captura de pantalla de la sección Implementación por en la que se muestra la pestaña Workitems .

Compatibilidad con datos adjuntos de prueba grandes

La tarea publicar resultados de pruebas en Azure Pipelines permite publicar resultados de pruebas cuando se ejecutan pruebas para proporcionar una experiencia completa de análisis y informes 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, se ha 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 devuelve un error 403 o 407 en los registros. Si usa compilaciones auto hospedadas 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.

Captura de pantalla que muestra un error 403 devuelto en los registros.

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 auto-hospedados 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 se usaba una matriz para expandir trabajos o una variable para identificar un grupo, a veces se resolvía información incorrecta del grupo en las páginas de registros. Estos problemas se han resuelto.

Desencadenadores de CI para nuevas ramas

Ha sido una solicitud pendiente desde hace mucho tiempo para no desencadenar compilaciones de CI cuando se crea una 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 en comparación con la rama existente.
  • Tiene un repositorio con dos carpetas: app y docs. 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 insertar un cambio en la documentación. Cree una rama localmente, realice algunos cambios en los documentos y, a continuación, la insertará en el servidor. Hemos usado para desencadenar una nueva compilación de CI. Esto no es deseado, ya que ha pedido explícitamente que no busque cambios en la carpeta docs. Sin embargo, debido a la forma en que controlemos un nuevo evento de rama, también parecería que se ha realizado un cambio en la carpeta de la aplicación.

Ahora, tenemos una mejor manera de controlar la ci.c. de nuevas ramas para solucionar estos problemas. Al publicar una nueva rama, se buscan explícitamente nuevas confirmaciones en esa rama y se comprueba si coinciden con los filtros de ruta de acceso.

Los trabajos pueden acceder a variables de salida de fases anteriores

Las variables de salida ahora se pueden usar en todas las fases de una canalización basada en YAML. Esto le ayuda a pasar información útil, como una decisión de ir o no ir 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á disponible.

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

Nota

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

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 conectado al grupo, se producirá un error en las canalizaciones con un mensaje de error claro en lugar de solicitar a los agentes que se actualicen. Esta característica es principalmente de interés para los clientes con grupos auto hospedados y requisitos muy estrictos de control de cambios. Las actualizaciones automáticas están habilitadas de forma predeterminada y no se recomienda que la mayoría de los clientes las deshabilite.

Sceenshot of the Default Configuración page with the Agent update settings option turned on and called out (La configuración de actualización del agente está activada y desactivada).

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. Mediante el uso de eventos de enlaces 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 entrada del departamento de soporte técnico cuando se requiere 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 la 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.

Captura de pantalla del asistente NEW SERVICE HOOKS SUBSCRIPTION (Nueva suscripción de SERVICE HOOKS) que muestra el desencadenador en la lista desplegable de este tipo de eventos con las opciones De fase de ejecución llamadas.

Integración optimizado

Optimizely es una plataforma eficaz de pruebas A/B y marca de características 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, a la vez que obtiene todas las ventajas DevOps de Azure Pipelines.

La extensión Optimizely para Azure DevOps agrega pasos de implementación de marca de características y experimentación a las canalizaciones de compilación y versión, para que pueda iterar, lanzar y revertir las características continuamente mediante Azure Pipelines.

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

Optimizely

Agregar una versión GitHub como origen de artefacto

Ahora puede vincular las versiones de GitHub como origen del artefacto en Azure DevOps canalizaciones de versión. Esto le permitirá consumir la versión 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 GitHub versión. Puede proporcionar la conexión de servicio y el repositorio GitHub para consumir la versión GitHub servicio. También puede elegir una versión predeterminada para que la versión GitHub consuma como versión de etiqueta específica más reciente o seleccionarla en el momento de la creación de la versión. Una vez GitHub una versión de lanzamiento, se descarga automáticamente y está disponible en los trabajos de versión.

Captura de pantalla del cuadro de diálogo Agregar un artefacto con la GitHub release seleccionada y seleccionada.

Integración de Terraform con Azure Pipelines

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

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

Captura de pantalla de la integración de Terraform con Azure Pipelines.

Integración con Google Analytics

El marco de experimentos de Google Analytics 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 desea que los usuarios completen (por ejemplo, realizar una compra, registrarse para obtener un boletín) o métricas que quiera mejorar (por ejemplo, ingresos, duración de la sesión, tasa de rebotón). 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, aprender e implementar continuamente a un ritmo acelerado administrando los experimentos de forma continua, a la vez que obtiene todas las ventajas de DevOps de Azure Pipelines.

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

Captura de pantalla que muestra la tarea Experimentos de Google Analytics.

Se ha actualizado la integración de ServiceNow con Azure Pipelines

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

Creación Azure Pipelines desde VSCode

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

Captura de VS Code con una alerta en la esquina inferior derecha que indica: La canalización se ha configurado correctamente.

Administración y resolución de errores desalida

Hemos introducido la administración de pruebas desa pruebas para admitir el ciclo de vida de un extremo a otro con detección, informes y resolución. Para mejorarlo aún más, vamos a agregar la resolución y la administración de errores de pruebas desa pruebas.

Al investigar la prueba desasignada, puede crear un error mediante la acción Error que, a continuación, se puede asignar a un desarrollador para investigar aún más la causa principal de la prueba desasignada. 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 no activa.

Establecer que las tareas de VSTest no se ejecuten 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 del usuario o en el adaptador de prueba pueden dar lugar a casos en los que las pruebas no se detectan y solo se ejecuta un subconjunto de las pruebas esperadas. Esto puede dar lugar a 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 ayudar a 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 la tarea se pase.

Captura de pantalla que muestra la opción Fail the task if a minimum number of tests are not run (Error en la tarea si no se ejecuta un número mínimo de pruebas).

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 le permita configurar una carpeta diferente para almacenar los resultados de las pruebas. Ahora las tareas posteriores que necesiten los archivos en una ubicación determinada pueden usarlas.

Captura de pantalla que muestra el cuadro de texto Carpeta de resultados de pruebas.

Compatibilidad con Markdown en mensajes de error de prueba automatizados

Hemos agregado compatibilidad con Markdown a los mensajes de error para 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í.

Captura de pantalla que muestra la compatibilidad con Markdown en mensajes de error de prueba automatizadas.

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 los trabajos de implementación. Puede tener cualquier paso personalizado (por ejemplo, escáner de vulnerabilidades) que se inserta automáticamente en cada ejecución del enlace del ciclo de vida de cada trabajo de implementación. Puesto 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 segura.

Además, los trabajos de implementación se pueden ejecutar como un trabajo de contenedor junto con el coche lateral de los servicios, si se definen.

Test Plans

Página Nuevo plan de prueba

Hay una nueva página Test Plans (Test Plans *) disponible para todas Azure DevOps colecciones. La nueva página proporciona vistas simplificadas que le ayudarán a centrarse en la tarea en la mano: planeamiento, creación o ejecución de pruebas. También es sin desorden y coherente con el resto de la Azure DevOps oferta.

Captura de pantalla que muestra dos planes de prueba con nombre idential que comparten un almacén de back-end.

Ayúdeme a comprender la nueva página

página de información general del plan de pruebas

La nueva página Test Plans cuenta con un total de 6 secciones de las cuales las cuatro primeras son nuevas, mientras que las secciones & Extensibilidad son la funcionalidad existente.

  1. Encabezado del plan de prueba: use esta opción para buscar, favoritos, editar, copiar o clonar un plan de prueba.
  2. Árbol de conjuntos de pruebas: use esta opción para agregar, administrar, exportar u ordenar conjuntos de pruebas. Aproveche esta opción para asignar también configuraciones y realizar pruebas de aceptación del usuario.
  3. Pestaña Definir: intercalar, agregar y administrar casos de prueba en un conjunto de pruebas de su elección 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 en el que 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.

Veamos una amplia vista de trazo de estas nuevas secciones a continuación.

1. Encabezado del plan de prueba

página de encabezado del plan de prueba

Tareas

El encabezado Plan de prueba permite realizar las siguientes tareas:

  • Marcar un plan de prueba como favorito
  • Desmarcar un plan de prueba favorito
  • Navegar fácilmente entre sus planes de prueba favoritos
  • Vea la ruta de iteración del plan de prueba, lo 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 all/mine Test Plans

Opciones del menú contextual

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

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

Copiar plan de prueba (nueva funcionalidad)

página copiar plan de prueba

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

2. Árbol de conjuntos de pruebas

página de árbol de conjuntos de pruebas

Tareas

El encabezado conjunto de pruebas permite realizar las siguientes tareas:

  • Expandir o contraer: estas opciones de la barra de herramientas le permiten expandir o contraer el árbol de jerarquía del conjunto de acciones.
  • Mostrar puntos de prueba de los 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 de pruebas dado y sus elementos secundarios en una vista para facilitar la administración de los puntos de prueba sin tener que navegar a conjuntos individuales de uno en uno.
  • Conjuntos de pedidos: puede arrastrar y 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:

  • Crear nuevos conjuntos: puede crear tres tipos diferentes de conjuntos como se muestra a continuación:
    • Use el conjunto estático o el conjunto de carpetas para organizar las pruebas.
    • Use el conjunto basado en requisitos para vincular directamente a los requisitos o casos de usuario para un seguimiento sin problemas.
    • Use basado en consultas para organizar dinámicamente los casos de prueba que cumplen los criterios de una consulta.
  • Asignar configuraciones: puede asignar configuraciones para el conjunto (por ejemplo: Chrome, Firefox, EdgeCroium) y, a continuación, se aplicarían a todos los casos de prueba existentes o nuevos casos de prueba que agregue más adelante a este conjunto.
  • Exportar como pdf/correo electrónico: exporte las propiedades del plan de 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 le permite editar el formulario Elemento de trabajo del conjunto de pruebas para administrar los campos de elemento de trabajo.
  • Asignar evaluadores para ejecutar todas las pruebas: esta opción es muy útil para escenarios de pruebas de aceptación del usuario (UAT) en los que varios evaluadores deben ejecutar o ejecutar la misma prueba, normalmente pertenecientes a diferentes departamentos.
  • Cambiar nombre o eliminar: estas opciones le permiten administrar el nombre del conjunto o quitar el conjunto de aplicaciones y su contenido del plan de prueba.

3. Pestaña Definir

definir página de pestañas

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 nivel de acceso Básico + Test Plans o equivalente. Todo lo demás debe ser ejecible 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 le 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.
  • Agregar nuevo caso de prueba mediante cuadrícula: esta opción le permite crear uno o varios casos de prueba mediante la vista de cuadrícula de casos de prueba. Los casos de prueba creados se agregarán automáticamente al conjunto.
  • 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 mediante arrastrar y colocar: 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 a otro: con arrastrar y colocar, puede mover los 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 modo de pantalla completa con esta opción.
  • Filtrado: mediante la barra de filtros, puede filtrar la lista de casos de prueba mediante los campos "título del caso de prueba", "asignado a" y "estado". También puede ordenar la lista haciendo clic en los encabezados de columna.
  • Opciones de columna: puede administrar la lista de columnas visibles en la pestaña Definir mediante "Opciones de columna". La lista de columnas disponibles para la selección son principalmente los campos del formulario de elemento de trabajo del caso de prueba.

Opciones del menú contextual

definir la página del menú contextual de la pestaña

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

  • Abrir o editar el 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 de elemento de trabajo, incluidos los pasos de prueba.
  • Editar casos de prueba: esta opción le permite editar de forma masiva campos de elemento de trabajo caso de prueba. Sin embargo, no puede usar esta opción para editar los pasos de prueba de forma masiva.
  • Editar casos de prueba en 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 le permite quitar los casos de prueba del conjunto de pruebas determinado. Sin embargo, no cambia el elemento de trabajo del caso de prueba subyacente.
  • Crear una copia o clonación de casos de prueba: esta opción permite crear una copia o clonación de casos de prueba seleccionados. Consulte a continuación para más información.
  • Ver elementos vinculados: esta opción le permite consultar los elementos vinculados para un caso de prueba determinado. Consulte a continuación para más información.

Copiar o clonar casos de prueba (nueva funcionalidad)

página definir casos de prueba de copia de tabulación

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

Visualización de elementos vinculados (nueva funcionalidad)

definir la página de elementos vinculados de la vista de pestaña

La rastreabilidad entre artefactos de prueba, requisitos y errores es una propuesta de valor fundamental del Test Plans producto. 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 y los planes de prueba donde se ha usado este caso de prueba y todos los errores que se han presentado como parte de la ejecución de pruebas.

4. Pestaña Ejecutar

página de la 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. Al agregar un caso de prueba a un conjunto de pruebas, se generan puntos de prueba. Un punto de prueba es una combinación única de casos de prueba, conjunto de pruebas, configuración y evaluador. Ejemplo: si tiene un caso de prueba como "Funcionalidad de inicio de sesión de prueba" y le agrega dos configuraciones 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 pruebas (historial de ejecución), puede ver todas las ejecuciones de un punto de prueba. La ejecución más reciente para el punto de prueba es lo que se 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, se determina la calidad del producto o servicio que se está desarrollando.

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

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

Tareas

La pestaña Ejecutar permite realizar las siguientes tareas:

  • 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 a la vez.
  • Ejecutar puntos de prueba: esta opción le permite ejecutar los casos de prueba de forma individual pasando por cada paso de prueba y marcando su superación o error mediante un ejecutor de pruebas. En función de la aplicación que está probando, puede usar el "Ejecutor web" 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 en 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 modo de pantalla completa con esta opción.
  • Filtrado: con la barra de filtros, puede filtrar la lista de puntos de prueba mediante los campos "test case title", "assigned to", "state", "test outcome", "Tester" y "Configuration". También puede ordenar la lista haciendo clic en los encabezados de columna.

Opciones del menú contextual

Página del menú contextual de la pestaña ejecutar

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 le permite restablecer el resultado de la prueba a activo, omitiendo así el último resultado del punto de prueba.
  • Abrir o editar el 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 de elemento de trabajo, incluidos los pasos de prueba.
  • Asignar evaluador: esta opción le permite asignar los puntos de prueba a los evaluadores para la ejecución de pruebas.
  • Ver resultado de la prueba: esta opción le permite ver los detalles más recientes del resultado de la prueba, incluido el resultado de cada paso de prueba, los comentarios agregados o los errores que se han presentado.
  • Ver historial de ejecución: esta opción le permite ver todo el historial de ejecución del punto de prueba seleccionado. Se abre una nueva página en la que puede ajustar los filtros para ver el historial de ejecución no solo del punto de prueba seleccionado, sino también para todo el caso de prueba.

Test Plans Informe de progreso

Este informe de configuración rápida 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.

Captura de pantalla de la Test Plans con la opción Informe de progreso resaltada.

Las tres secciones del informe incluyen las siguientes:

  1. Resumen: muestra una vista consolidada de los planes de prueba seleccionados.
  2. Tendencia de resultados: representa una instantánea diaria para proporcionar 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 le proporciona análisis importantes para cada conjunto de pruebas.

Captura de pantalla del informe Progreso.

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 se encuentran en la papelera de reciclaje, restáurelas desde la papelera de reciclaje antes de iniciar la importación de datos.

Expresiones de licencia y licencias insertadas

Ahora puede ver los detalles de la información de licencia de los paquetes NuGet almacenados en Azure Artifacts mientras explora 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 Visual Studio detalles del paquete (flecha roja en la imagen siguiente).

Captura de pantalla del paquete de NuGet Newtonsoft.Json con una flecha roja que apunta a la licencia del paquete.

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

Captura de pantalla de una ventana del explorador que desmonta el texto de la licencia MIT

Tareas de autenticación ligeras

Ahora puede autenticarse con administradores de paquetes populares 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 proporcionaba una gran cantidad de funcionalidad, incluida la capacidad de publicar y descargar paquetes. Sin embargo, esto requería el uso de estas tareas para todas las actividades que interactúan con los administradores de paquetes. Si tuviera sus propios scripts para ejecutar tareas como publicar o descargar paquetes, no podría usarlos 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. Un ejemplo con npm:

Captura de pantalla de un ejemplo de una tarea de autenticación ligera.

El uso del comando "ci" y "publish" en esta ilustración es arbitrario, puede usar cualquier comando compatible con Azure Pipelines YAML. Esto le permite tener un control completo de la invocación de comandos y facilita el uso de scripts compartidos en la configuración de la canalización. Para obtener más información, consulte la documentación de la NuGetde autenticación de , npm, PIP, Twiney 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. De media, los tiempos de carga de la página de fuente han disminuido un 10 %. Las fuentes más grandes han visto la mayor mejora en el tiempo de carga de la página de la fuente de percentil 99 (tiempos de carga en el 99 % más alto de todas las fuentes) reducido 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 no, o incluso han iniciado sesión en una Azure DevOps datos. 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.

Captura de pantalla que muestra la página PublicFeed de los paquetes.

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

Ahora puede agregar una fuente en otra colección asociada al inquilino de Azure Active Directory (AAD) como origen ascendente a la fuente Artifacts origen. La fuente puede buscar 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 AAD inquilino. Vea cómo configurarlo en la documentación.

Use la Python Credential Provider para autenticar pip y twine con Azure Artifacts fuente

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

Azure Artifacts fuentes en el Visual Studio Administrador de paquetes

Ahora se muestran iconos, descripciones y autores de paquetes en Visual Studio NuGet Administrador de paquetes paquetes que se sirven desde Azure Artifacts fuente. Anteriormente, la mayoría de estos metadatos no se proporcionaba a VS.

Actualización de Conectar para la experiencia de fuente

El Conectar que se va a alimentar 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 de Azure DevOps. Se ha actualizado el cuadro de diálogo para agregar información de configuración detallada y se han ampliado las herramientas para las que se proporcionan 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, hemos ampliado las características adicionales a la disponibilidad general. Ahora, puede establecer una fuente pública como origen ascendente desde una fuente privada. Puede hacer que los archivos de configuración sean sencillos si puede realizar la subida hacia y desde fuentes privadas y de ámbito de proyecto.

Creación de fuentes con ámbito de proyecto desde el portal

Cuando lanzamos fuentes públicas, también lanzamos fuentes con ámbito de proyecto. Hasta ahora, las fuentes con ámbito de proyecto se podí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 de proyecto y cuáles tienen ámbito de colección en el selector de fuentes.

Mejoras de rendimiento de npm

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

Mejoras de accesibilidad

Hemos implementado correcciones para solucionar problemas de accesibilidad en nuestra página de fuentes. Entre las correcciones se incluyen las siguientes:

  • Creación de una experiencia de fuente
  • Experiencia de configuración de fuente global
  • Conectar para la experiencia de fuente

Wiki

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

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

Ahora puede editar una página wiki de códigos en el editor en paralelo dentro de wiki. Esto le permite usar la barra de herramientas completa de Markdown para crear el contenido, lo que hace 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 Repos en el menú contextual.

Captura de pantalla que muestra el menú Editar con la opción Editar en Repos opción seleccionada.

Creación e inserción de elementos de trabajo desde una página wiki

Mientras escuchamos sus comentarios, escuchamos que usa wiki para capturar documentos de lluvia de ideas, documentos de planeamiento, 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 planeamiento 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 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 cambio de contexto, ya que no sale del ámbito wiki.

Vídeo corto que muestra cómo crear e insertar elementos de trabajo desde una página wiki.

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

Comentarios en páginas wiki

Anteriormente, no tenía una manera de interactuar con otros usuarios de wiki dentro de la wiki. Esto hizo que la colaboración en contenido y la obtención de preguntas respondieron a un desafío, ya que las conversaciones tenían que producirse a través de canales de correo o chat. Con los comentarios, ahora puede colaborar con otros usuarios directamente dentro de la wiki. Puede aprovechar la funcionalidad @mention 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 entrada de sugerencia. Para obtener más información sobre los comentarios, consulte nuestra documentación aquí.

Captura de pantalla que muestra cómo agregar comentarios en páginas wiki.

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

Hasta ahora, el árbol wiki mostraba todas las carpetas y archivos a partir de un punto (.) en el árbol wiki. En escenarios de wiki de código, esto provocaba que carpetas como .vscode, que están pensadas para estar ocultas, 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 entrada de sugerencia.

Direcciones URL de página wiki cortas y legibles

Ya no tiene que usar una dirección URL multilínea para compartir vínculos a páginas wiki. Estamos aprovechando los iDs de página en la dirección URL para quitar parámetros, lo que hace que la dirección URL sea más corta y fácil de leer.

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

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

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

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 entrada de sugerencias de características de 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 el panel de edición y el panel de vista previa. Al desplazarse por un lado, se desplazará automáticamente por el otro lado para asignar las secciones correspondientes. Puede deshabilitar el desplazamiento sincrónico con el botón de alternancia.

Captura de pantalla de la barra de herramientas wiki con el icono de desplazamiento synchronus llamado y el botón de alternancia Deshabilitar desplazamiento sincronizado situado encima de ella.

Nota

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

Visitas a páginas de páginas wiki

Ahora puede obtener información sobre las visitas a páginas de las páginas wiki. La API REST le permite acceder a la información de visitas a 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.

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

Captura de pantalla que muestra las visitas anteriores de una página wiki.

Nota

Un usuario determinado define una visita de página como una vista de página en un intervalo de 15 minutos.

Notificación

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

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

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

Captura de pantalla en la que se muestra la pestaña Análisis que muestra el distintivo Velocidad de paso de canalización, el distintivo Velocidad de paso de prueba y el distintivo Duración de la canalización.

Captura de pantalla que muestra el informe de errores de canalización.

  1. El informe de duración de la canalización muestra la tendencia del tiempo que se necesita 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 una buena razón. El widget muestra los resultados de una consulta directamente en el panel y es útil en muchas situaciones.

Con esta actualización hemos incluido muchas mejoras esperadas:

  • Ahora puede seleccionar tantas columnas como desee mostrar en el widget. Ya no hay 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 expande, mostrará todas las columnas devueltas por la consulta.

Filtrado avanzado de widgets de tiempo de ciclo y cliente potencial

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

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

Con esta actualización, las preguntas como esta se pueden responder mediante el filtrado en la calle board.

Captura de pantalla en la que se muestra el cuadro de diálogo Configuración con la sección Calle a la que se ha llamado.

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

Captura de pantalla que muestra el cuadro de diálogo Configuración con la sección Criterios de campo que se ha llamado.

Desmontaje de sprint en línea mediante puntos de historia

Ahora, sprint burndown puede grabarse por casos. Esto aborda los comentarios del desarrollador Community.

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

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

Captura de pantalla que muestra el sprint en línea con puntos de historia.

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

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

Sceenshot que muestra el nuevo widget Sprint Burndown.

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

Nota

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

Miniatura de desmontaje de sprint en línea

El Sprint Burndown ha vuelto. Hace unos cuantos sprints, quitamos el sprint en contexto de los encabezados Sprint Burndown y Taskboard. En función de sus comentarios, hemos mejorado y regenerado la miniatura de desmontaje de sprint.

Captura de pantalla que muestra la miniatura de la grabación de sprint en línea.

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 que se base en historias, puntos de historia o por recuento de tareas, en lugar de solo la cantidad de trabajo restante.

Creación de un panel sin un equipo

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

Captura de pantalla que muestra el cuadro de diálogo Crear un panel con la Project panel seleccionada y seleccionada.

Un Project 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 Azure DevOps widgets que requieren un contexto de equipo se han actualizado para que pueda seleccionar un equipo en su configuración. Puede agregar estos widgets a Project paneles y seleccionar el equipo específico que desee.

Captura de pantalla de la lista desplegable Equipo.

Nota

En el caso de widgets personalizados o de terceros, Project panel 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 que pueda 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 a través de developer Community y obtener consejos sobre Stack Overflow.


Principio de página