Azure DevOps Server de la versión de 2019


| Developer Community
| Compatibilidad y requisitos del sistema
| Términos de licencia
| Blog de DevOps
| Hash SHA-1 |


En este artículo, encontrará información sobre la versión más reciente de Azure DevOps Server 2019. Para descargar Azure DevOps Server productos, visite la página Azure DevOps Server descargas.

Para obtener más información sobre Azure DevOps Server 2019, consulte Azure DevOps Server Requirements. Visite la página visualstudio.com/downloads para descargar Team Foundation Server productos.

La actualización directa a Azure DevOps Server se admite desde Team Foundation Server 2012 y versiones más recientes. 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. Consulte la página Instalar para obtener más información.


Azure DevOps Server 2019.0.1 Revisión 10 Fecha de lanzamiento: 13 de abril de 2021

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

Para aplicar la revisión 10, tendrá que instalar la AzureResourceGroupDeploymentV2 tarea.

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 en una nueva carpeta del equipo. Por ejemplo: AzureResourceGroupDeploymentV2.

  2. Descargue e instale Node.js 14.15.1 y npm (incluido con el Node.js descargar) según la 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 de inicio de sesión de tfx.

  2. Ejecute lo siguiente desde el símbolo del sistema. 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 del paso 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server lanzamiento de la revisión 9 de 2019.0.1: 8 de diciembre de 2020

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

  • CVE-2020-1325: vulnerabilidad Azure DevOps Server suplantación de seguridad
  • CVE-2020-17135: vulnerabilidad Azure DevOps Server suplantación de seguridad
  • CVE-2020-17145: vulnerabilidad de Azure DevOps Server y Team Foundation Server suplantación de seguridad
  • Corrección de un problema con TFVC que no procesa todos los resultados

Importante

Lea las instrucciones completas que se proporcionan a continuación antes de instalar esta revisión.

Instalación general de revisiones

Si ha Azure DevOps Server 2019.0.1, debe instalar Azure DevOps Server 2019.0.1 Patch 9.

Comprobación de la instalación

  • Opción 1: ejecute , devops2019.0.1patch9.exe es el archivo que devops2019.0.1patch9.exe CheckInstall 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 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll . Azure DevOps Server 2019 está instalado en c:\Program Files\Azure DevOps Server 2019 de forma predeterminada. Después de instalar Azure DevOps Server 2019.0.1 Revisión 9, la versión será 17.143.30723.4.

Instalación de la tarea AzurePowerShellV4

Nota

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

Requisitos previos

  1. Instale Azure PowerShell módulo Az de Azure PowerShell en la máquina del agente privado.

  2. Cree una canalización con la tarea AzurePowerShellV4. Solo verá un error de error estándar en la tarea.

Instalar

  1. Extraiga el AzurePowerShellV4.zip en una carpeta denominada AzurePowerShellV4.

  2. Descargue e instale Node.js 14.15.1 y npm (incluidos con Node.js descarga) según la 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 de inicio de sesión de tfx.

  2. Ejecute lo siguiente desde el símbolo del sistema. 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. La ruta de acceso del paquete extraído será D:\tasks (1)\AzurePowerShellv4.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server versión de la revisión 8 de 2019.0.1: 8 de septiembre de 2020

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

  • DTS 1713492: comportamiento inesperado al agregar grupos de AD a permisos de seguridad.

Azure DevOps Server versión de la revisión 7 de 2019.0.1: 14 de julio de 2020

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

  • CVE-2020-1326: Vulnerabilidad de scripting entre sitios
  • La canalización de compilación muestra una conexión incorrecta para usuarios no autorizados al seleccionar Otro origen de Git.
  • Se corrija el error al cambiar Herencia a On u Off en la definición de compilación XAML.

Azure DevOps Server lanzamiento de la revisión 6 de 2019.0.1: 10 de junio de 2020

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

  • CVE-2020-1327: Asegúrese de que Azure DevOps Server las entradas del usuario
  • Agregar compatibilidad con SHA2 en SSH en Azure DevOps

Azure DevOps Server lanzamiento de la revisión 5 de 2019.0.1: 10 de marzo de 2020

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

Azure DevOps Server de lanzamiento de la revisión 3 de 2019.0.1: 10 de septiembre de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige los siguientes errores. Consulte la entrada de blog para obtener más información.

  • CVE-2019-1305 : vulnerabilidad de scripting entre sitios (XSS) en Repos
  • CVE-2019-1306 : vulnerabilidad de ejecución remota de código en Wiki

Azure DevOps Server lanzamiento de la revisión 2 de 2019.0.1: 13 de agosto de 2019

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

  • Hemos agregado información a las conexiones de servicio para aclarar que están autorizadas para todas las canalizaciones de forma predeterminada.

Azure DevOps Server lanzamiento de la revisión 1 de 2019.0.1: 9 de julio de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige los siguientes errores. Consulte la entrada de blog para obtener más información.

  • CVE-2019-1072 : vulnerabilidad de ejecución remota en el seguimiento de elemento de trabajo
  • CVE-2019-1076 : Vulnerabilidad de scripting entre sitios (XSS) en solicitudes de incorporación de cambios

Azure DevOps Server 2019.0.1 Fecha de lanzamiento: 21 de mayo de 2019

Azure DevOps Server 2019.0.1 es una succión de correcciones de errores. Incluye todas las correcciones de las revisiones de Azure DevOps Server 2019 publicadas anteriormente. Puede instalar directamente Azure DevOps Server 2019.0.1 o actualizar desde Azure DevOps Server 2019 o Team Foundation Server 2012 o posterior.

Nota

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

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

Azure Boards

  • "Los criterios de campo para este plan tienen un error". al configurar un plan. Se notifica a Developer Community.
  • apiwitcontroller.exequery produce una excepción cuando una consulta tiene la misma columna varias veces.
  • En el modelo de objetos de cliente que usa el vso.work_full oauth, se produce un error en WorkItemServer.DownloadFile().
  • Copiar una imagen incrustada de un campo de elemento de trabajo a otro campo de elemento de trabajo en un proyecto diferente puede crear una imagen rota.

Azure Repos

  • "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

  • La pestaña Análisis de pruebas tiene una estrella (*) que indica la versión preliminar, aunque esta característica no esté en versión preliminar.
  • En la pestaña Versiones, la acción para administrar la seguridad ahora se muestra a todos los usuarios con independencia de si pueden cambiar los permisos o no.
  • En las páginas de aterrizaje de versiones, la acción iniciar versión de borrador creaba una nueva versión, pero ahora inicia la versión de borrador.

Azure Test Plans

  • El filtro de 1 hora en TestRuns y TestResults CompletedDate es demasiado granular.
  • En el tipo de elemento de trabajo Caso de prueba, el tipo ,"Caso de prueba", no debe localizarse.
  • Los casos de prueba no se muestran en MTM ni en un explorador.
  • Error "Fase de validación: no tiene permiso para desencadenar versiones en la canalización de versión asociada" al ejecutar pruebas automatizadas desde un plan de pruebas. Se notifica a Developer Community.
  • Mediante la API eliminar casos de prueba,los casos de prueba se pueden eliminar de otros proyectos. Se notifica a Developer Community.
  • Al hacer clic en un vínculo de elemento de trabajo Test Runner se abre la dirección URL del elemento de trabajo Test Runner en lugar del explorador predeterminado.
  • El estado del caso de prueba no se está actualizando para los usuarios que han de cerrar sesión Test Runner.
  • El nombre de usuario y la dirección de correo electrónico no se muestran en la lista desplegable de usuarios Test Runner.

Azure Artifacts

  • Subir y Bajar no se localizan en ascendentes.

Análisis

  • Los informes de Analytics pueden mostrar datos incompletos porque el modelo se marca como "listo" antes de que se complete realmente.
  • Los widgets de velocidad, de grabación y de grabación muestran diferentes trabajos planeados para los usuarios en distintas zonas horarias.
  • Se puede colocar una retención en la ingesta de datos de Analytics mientras se hace mantenimiento, lo que puede provocar informes obsoletos.

General

  • Los elementos de navegación izquierdo se apretan en IE cuando no hay suficiente espacio.

Administración

  • Se ha agregado un registro adicional a la actualización de recopilación para ayudar a depurar problemas.
  • Cuando se produce un error en TfsConfig offlineDetach, el mensaje de error no es utilizable.
  • El servicio TfsJobAgent se bloquea.
  • La extensión search no se instala una vez completada la configuración.
  • La consola de administración deja de responder cuando la base de datos de configuración está dañada.
  • Es posible que los enlaces de servicio no procese correctamente las notificaciones.
  • Code Search la indexación no se inicia después de configurar la búsqueda.
  • Hay cadenas sin localizar en los resultados de las páginas de búsqueda.

Esta versión incluye la siguiente actualización:

Compatibilidad con Visual Studio 2019 (VS2019) en Visual Studio test

Hemos agregado compatibilidad con Visual Studio 2019 a la tarea Visual Studio test en canalizaciones. Para ejecutar pruebas mediante la plataforma de pruebas para Visual Studio 2019, seleccione las opciones Más reciente o Visual Studio 2019 en la lista desplegable Versión de la plataforma de prueba.

Captura de pantalla de la sección Opciones de ejecución que muestra la lista desplegable Versión de la plataforma de prueba seleccionada con la opción Más Visual Studio 2019 seleccionada.


Azure DevOps Server versión de la revisión 2 de 2019: 14 de mayo de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019 que corrige los errores siguientes. Consulte la entrada de blog para obtener más información.

  • CVE-2019-0872 : Vulnerabilidad de scripting entre sitios (XSS) en Test Plans
  • CVE-2019-0971 : Vulnerabilidad de divulgación de información en Repos API
  • CVE-2019-0979 : Vulnerabilidad de scripting entre sitios (XSS) en el centro Usuario

Azure DevOps Server versión de la revisión 1 de 2019: 9 de abril de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019 que corrige los errores siguientes. Consulte la entrada de blog para obtener más información.

  • CVE-2019-0857: vulnerabilidad de suplantación de seguridad en wiki
  • CVE-2019-0866 : vulnerabilidad de ejecución remota de código en Pipelines
  • CVE-2019-0867 : vulnerabilidad de scripting entre sitios (XSS) en Pipelines
  • CVE-2019-0868 : vulnerabilidad de scripting entre sitios (XSS) en Pipelines
  • CVE-2019-0869: vulnerabilidad de inyección de código HTML en canalizaciones
  • CVE-2019-0870 : vulnerabilidad de scripting entre sitios (XSS) en Pipelines
  • CVE-2019-0871 : vulnerabilidad de scripting entre sitios (XSS) en Pipelines
  • CVE-2019-0874: Vulnerabilidad de scripting entre sitios (XSS) en Canalizaciones
  • CVE-2019-0875: Vulnerabilidad de elevación de privilegios en Boards

Azure DevOps Server de lanzamiento de 2019: 5 de marzo de 2019

Nota

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


RC2 Fecha de lanzamiento: 22 de enero de 2019

Resumen de las novedades de Azure DevOps Server 2019 RC2

Hemos agregado las siguientes características a RC2:


RC1 Fecha de lanzamiento: 19 de noviembre de 2018

Resumen de las novedades de Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 presenta una nueva experiencia de navegación y muchas características nuevas. Entre los aspectos destacados se incluyen:

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


General

Anuncio de Azure DevOps Server

El 10 de septiembre, anunciamos Azure DevOps como la evolución de Visual Studio Team Services y Team Foundation Server. Azure DevOps Server 2019 es nuestra primera versión local con esta nueva marca. Puede encontrar más información en nuestra entrada de blog.

Nueva experiencia de navegación

Presentamos una nueva navegación para modernizar la experiencia del usuario. Esta nueva navegación se ha lanzado al servicio Azure DevOps y ahora está disponible en Azure DevOps Server 2019. Consulte nuestro blog para obtener más información.

Nueva navegación

Cambios en artefactos y licencias Release Management canalización de implementación

En función de los comentarios de los usuarios, estamos realizando dos cambios clave en nuestras licencias con Azure DevOps Server 2019. En primer lugar, los clientes ya no tendrán que adquirir la extensión Artefacto para usar Artefactos. Ahora se incluirá un uso de licencia de Artefactos en la licencia básica. Todos los usuarios que tengan una licencia básica asignada ahora podrán usar artefactos. En segundo lugar, los clientes ya no tendrán que comprar Release Management deployment pipelines. Al igual que las canalizaciones de compilación, Release Management las canalizaciones de implementación de compilación ahora se incluyen Azure DevOps Server 2019.

Compatibilidad con Azure SQL Database

Para simplificar la experiencia de ejecución de Azure DevOps 2019 en Azure, hemos habilitado la compatibilidad con Azure SQL Database (De uso general S3 y posteriores). Esto le permitirá aprovechar las amplias características de copia de seguridad y las opciones de escalado para satisfacer sus necesidades, a la vez que reduce la sobrecarga administrativa de ejecutar el servicio. Tenga en cuenta que la máquina virtual host debe encontrarse en la misma región de Azure que la base de datos para mantener una latencia baja. Consulte la documentación para más información.

El elemento de trabajo & probar las API SOAP del modelo de objetos de cliente en versiones futuras

Azure DevOps Server 2019 sigue siendo compatible con la API SOAP de seguimiento de elementos de trabajo y el modelo de objetos de cliente. Sin embargo, se marcará como en desuso en versiones futuras de Azure DevOps Server. Puede encontrar más información en nuestra documentación.

Procesar la herencia en nuevas colecciones

La herencia de procesos ahora está disponible en nuevas colecciones. Los usuarios tendrán que tomar una decisión acertada sobre el modelo de proceso al crear una nueva colección. Consulte nuestra documentación sobre qué es el modelo de herencia y cómo es diferente de XML.

Herencia de procesos

Somos conscientes de la importancia de la búsqueda y estamos recuperando el cuadro de búsqueda expandido en el encabezado del producto. Además, ahora puede invocar el cuadro de búsqueda haciendo clic en "/" en cualquier página de servicio de Azure DevOps. Esta característica se ha priorizado en función de la siguiente voz del usuario.

Este es el cuadro de búsqueda predeterminado:

Cuadro de búsqueda predeterminado

Una vez que escriba "/", verá el cuadro de búsqueda expandido:

Cuadro de búsqueda expandido

Mi menú desplegable de trabajo

Una nueva característica que nos complace presentar es el menú desplegable mi trabajo. Hemos recibido comentarios que nos informan de que, cuando se encuentra en una parte del producto y quiere información de otra parte, no quiere perder el contexto. Con esta nueva característica, puede acceder a este control flyout desde cualquier lugar del producto y le dará un vistazo rápido a información fundamental, incluidos los elementos de trabajo, las solicitudes de extracción y todos los favoritos. Con este nuevo control flyout, si está en Repos (Repositorios) se dirige hacia abajo en el código, pero después quiere comprobar rápidamente en qué elemento de trabajo debe trabajar a continuación, simplemente haga clic en el control desplegable y vea los elementos de trabajo que tiene asignados y elija el siguiente elemento.

A continuación, puede ver el menú desplegable Mi trabajo que muestra los elementos de trabajo asignados a mí:

Mi menú desplegable de trabajo

Aquí puede ver el segundo pivote que muestra los puntos de control asignados a mí. En el control desplegable, también tiene acceso con un solo clic para ver más solicitudes de extracción:

My work flyout PR

Aquí puede ver el último pivote, que es todo lo que ha favorito. Esto incluye sus equipos favoritos, paneles, paneles, trabajo pendiente, consultas y repositorios:

Mis favoritos del menú desplegable de trabajo

Boards

Los equipos que usan GitHub Enterprise código y desean funcionalidades de administración de proyectos enriquecciones ahora pueden integrar sus repositorios con Azure Boards. Al conectar GitHub y Azure Boards, puede obtener todas las características como trabajos pendientes, paneles, herramientas de planeamiento de sprint, varios tipos de elementos de trabajo y seguir teniendo un flujo de trabajo que se integra con flujos de trabajo de desarrollador en GitHub.

Vincular confirmaciones y solicitudes de extracción a elementos de trabajo es fácil. Mencione el elemento de trabajo mediante la sintaxis siguiente:

AB#{work item ID}

Mencione un elemento de trabajo en un mensaje de confirmación, el título de la solicitud de extracción o la descripción de la solicitud de extracción, y Azure Boards creará un vínculo a ese artefacto. Por ejemplo, considere un mensaje de confirmación como este:

Adds support for deleting connections. Fixes AB#20.

Esto creará un vínculo desde el elemento de trabajo #20 a la confirmación en GitHub, que aparecerá en la sección Desarrollo del elemento de trabajo.

Captura de pantalla Azure DevOps con la sección Desarrollo llamada.

Si las palabras "fix", "fixes" o "fixed" preceden a la mención del elemento de trabajo (como se muestra anteriormente), el elemento de trabajo se mueve al estado completado cuando la confirmación se combina con la rama predeterminada.

Los equipos que usan Azure Pipelines para compilar código en GitHub también verán los elementos de trabajo vinculados a sus confirmaciones de GitHub en el resumen de compilación.

Nuevo centro de elementos de trabajo

El centro de elementos de trabajo es nuestro nuevo centro que servirá como el hogar de los elementos de trabajo. Aquí, tiene muchas vistas de lista diferentes de los elementos de trabajo que están limitados por usted. Puede ver Asignado a para ver rápidamente todo el trabajo que se le ha asignado o Actualizado recientemente, que muestra todos los elementos de trabajo del proyecto que se han actualizado más recientemente. Todas las opciones de la lista se pueden ver a continuación:

Centro de elementos de trabajo

Si desea tener aún más ámbito en las listas, puede filtrar por tipo, asignado a, estado, área, etiquetas y palabra clave. Una vez que tenga la vista de lista deseada, puede ordenar los elementos de trabajo simplemente haciendo clic en el encabezado de la columna. Si una columna es demasiado estrecha para ver todo el contenido de la columna, puede cambiar fácilmente el tamaño de la columna en el área de encabezado. Estas experiencias se pueden ver a continuación:

Lista de concentradores de elementos de trabajo

Nuevos centros de paneles, backlogs y sprints

El centro de trabajo pendiente se dividió en tres centros distintos para mejorar la experiencia del usuario. Aunque es eficaz, el centro de backlogs antiguo era el hogar de demasiadas características. Esto a menudo dificultaba la búsqueda de la característica o funcionalidad que los usuarios buscaban. Para solucionar este problema, hemos dividido el centro de trabajo pendiente en:

  • El centro de backlogs ahora es solo el hogar de los trabajo pendientes de un proyecto. Un trabajo pendiente es una lista de tareas prioritarias para el equipo. Los trabajos pendientes proporcionan herramientas de planeamiento, como la jerarquía de elementos de trabajo, la previsión y la nueva experiencia de planeamiento de sprint.
  • El nuevo centro boards es el hogar de todos los paneles kanban para un proyecto. Los paneles se usan para comunicar el estado y el flujo. Las tarjetas (elementos de trabajo) se mueven de izquierda a derecha a través del panel a través de las columnas definidas por el equipo.
  • El nuevo centro sprints es el hogar de las características que se usan para planear y ejecutar un incremento del trabajo. Cada sprint contiene un trabajo pendiente de sprint, un panel de tareas y una vista para administrar y establecer la capacidad del equipo.

Centro de paneles

Nuevo centro de consultas

El nuevo centro de consultas simplifica muchas de las características de consultas existentes desde el centro anterior con un aspecto más moderno, así como proporciona nuevas funcionalidades para facilitar el acceso a las consultas que son importantes para usted. Algunos aspectos destacados de la nueva experiencia incluyen:

  • Páginas de directorio con la última modificación por información y la capacidad de buscar consultas
  • Ruta de navegación con direcciones URL únicas para carpetas para marcar grupos importantes de consultas
  • Acceso rápido a sus consultas favoritas desde la página de resultados

Obtenga más información sobre estas interesantes actualizaciones en nuestro blog de DevOps.

Mover elementos de trabajo a otro proyecto y cambiar un tipo de elemento de trabajo

Ahora puede cambiar el tipo de elemento de trabajo o mover elementos de trabajo a otro proyecto dentro de una colección de proyectos. Estas características requieren que el almacenamiento de datos esté deshabilitado. Con el almacenamiento de datos deshabilitado, puede usar el servicio Analytics para satisfacer sus necesidades de informes. Para obtener más información sobre cómo deshabilitar el almacenamiento de datos, vea Deshabilitar el almacenamiento de datos y el cubo.

Características de planeamiento de sprint

Las nuevas características de planeamiento de sprint ayudan a acelerar y mejorar la experiencia de planeamiento de sprint.

  • Cree el siguiente sprint o suscríbase a una programación de sprint existente directamente desde el centro Sprints.
  • Use el nuevo panel Planeamiento del trabajo pendiente para arrastrar y colocar elementos de trabajo en sprints futuros. El panel Planeamiento incluye fechas de sprint, recuentos de elementos de trabajo y esfuerzo planeado.
  • Agregue los requisitos a la parte superior del panel de tareas o use la creación rápida para agregar a la parte superior, inferior o fila que prefiera en el trabajo pendiente de sprint.
  • Use filtros para el asignador, el tipo de elemento de trabajo, el estado y las etiquetas para adaptar las vistas a sus necesidades.

Planeación de un sprint

Páginas de nuevo directorio

Todos los centros nuevos, incluidos los backlogs, boards y sprints, ahora tienen nuevas páginas de directorio organizadas con las secciones siguientes:

  • Continuar donde lo dejó En esta nueva sección se proporciona un vínculo rápido directamente al último (board | Trabajo pendiente | Sprint) en el que estaba.
  • Favoritos Todos sus paneles favoritos, sprints y trabajo pendiente en todos los equipos.
  • My Todos los paneles, los trabajo pendientes y los sprints de los equipos a los que pertenece.
  • Todos Una lista completa de todos los paneles, los trabajo pendientes y los sprints.

Páginas de directorio

Menú Opciones de nueva vista

Los nuevos centros, incluidos los backlogs, boards y sprints, tienen un nuevo menú Ver opciones. Esta es una nueva página principal para todas las acciones para personalizar el diseño y el contenido de la página. Use Opciones de vista para habilitar vistas adicionales, como mostrar la jerarquía en trabajos pendientes o cambiar la opción Agrupar por en un panel de tareas, activar el panel lateral para asignar y planear sprints o explorar gráficos de detalles de trabajo.

Ver las opciones

Obtenga más información sobre estas actualizaciones interesantes, el nuevo panel Perfil de equipo y Favoritos en nuestro blog de DevOps.

Las anotaciones de tarjeta incluyen errores y tipos de elementos de trabajo personalizados

Las anotaciones de tarjeta son muy amadas por la interacción y la vista intuitivas de la lista de comprobación. Anteriormente, las anotaciones de tarjeta se limitaban a los tipos de nivel de trabajo pendiente predeterminados y no eran compatibles con errores o tipos personalizados. Con la nueva versión, se ha eliminado la restricción de los tipos de elementos de trabajo y se ha agregado la capacidad de mostrar errores y cualquier tipo de elemento de trabajo personalizado como una anotación de tarjeta.

La configuración del tablero para las anotaciones de tarjeta se expandió para incluir todos los tipos de elementos de trabajo disponibles para ese nivel de trabajo pendiente.

Configuración de anotación

Cuando se habilitan las anotaciones para el elemento de trabajo, los recuentos de ese tipo de elemento de trabajo se incluyen en la tarjeta como una lista de comprobación independiente.

Elemento de trabajo Annotation

La creación rápida de tipos de elementos de trabajo habilitados también está disponible a través del menú contextual de la tarjeta.

Creación rápida de anotaciones

Traslado del trabajo mediante áreas e iteraciones sugeridas

Puede ser habitual trabajar en la misma área o iteración y examinar repetidamente las jerarquías al mover elementos de trabajo. Los controles Área e Ruta de acceso de iteración ahora incluyen una lista de valores usados recientemente como Sugerencias, lo que le proporciona acceso rápido para establecer y avanzar.

Lista desplegable de áreas

Además, las fechas de iteración se incluyen a la derecha del nombre para que pueda considerar rápidamente cuándo se debe entregar un elemento de trabajo.

Lista desplegable iteración

Trabajo de consulta en la programación de iteración con +/- @CurrentIteration

La @CurrentIteration macro que ayuda al equipo a realizar un seguimiento del trabajo en función de la programación de iteración ahora admite el desplazamiento de enteros. Mantenga fácilmente las pestañas sobre el trabajo que no se cerró con - 1, o bien mire con antelación el trabajo planeado para futuras iteraciones @CurrentIteration con @CurrentIteration + 1. Consulte la @CurrentIteration publicación en el blog de Microsoft DevOps para obtener más información. Esta característica se ha priorizado en función de cuál es actualmente #12 sugerencia más votada con 456 votos.

Aclaración de las programaciones de iteración de consultas con el @CurrentIteration parámetro Team

Si ha estado usando la macro en consultas en el pasado, es posible que haya observado que los resultados pueden variar si el contexto del equipo cambia en Teams con diferentes programaciones @CurrentIteration de iteración. Ahora, cuando cree o modifique una consulta con la macro , también tendrá que seleccionar el equipo con la programación de iteración pertinente @CurrentIteration para la consulta. Con el parámetro Team, puede usar la @CurrentIteration macro en la misma consulta, pero entre equipos. Un ejemplo puede ser una consulta de elementos de trabajo en dos proyectos de equipo diferentes que usan nombres de iteración diferentes e incluso programaciones. Esto significa que ya no tiene que actualizar las consultas a medida que cambian los sprints. Consulte la @CurrentIteration publicación en el blog de Microsoft DevOps para obtener más información. Esta característica se ha priorizado por una sugerencia.

Parámetro de equipo

Trabajo de consulta en las rutas de acceso de área de un equipo con la nueva @TeamAreas macro

En la configuración de un equipo, puede asociar una o varias rutas de acceso de área, lo que le ayuda a centrar trabajos pendientes, paneles, planes, incluso paneles, solo al trabajo de ese equipo. Sin embargo, si quisiera escribir una consulta para un equipo, tenía que enumerar las rutas de acceso de área específicas para ese equipo en las cláusulas de consulta. Ahora, hay disponible una nueva macro para que pueda hacer referencia fácilmente a las rutas de acceso @TeamAreas de área que pertenecen al equipo especificado.

macro de áreas de equipo en el editor de consultas

Consulta de campos de texto enriquecido vacíos

Busque elementos de trabajo que tengan un campo de texto enriquecido vacío, como Descripción, mediante el nuevo operador de consulta IsEmpty.

Encontrar fácilmente elementos de trabajo existentes en las experiencias de vinculación y mención

Si desea vincular dos elementos de trabajo existentes, ahora puede encontrar fácilmente el elemento que es importante para usted mediante nuestro nuevo control de búsqueda de elementos de trabajo. El selector de consultas se ha reemplazado por sugerencias insertadas basadas en los elementos de trabajo a los que se ha accedido recientemente, así como un punto de entrada para buscar un elemento de trabajo específico por identificador o título.

Vinculación de elementos de trabajo

Anteriormente, no se podía abrir un elemento de trabajo desde la página de resultados de búsqueda si el panel de vista previa del elemento de trabajo estaba desactivado. Esto dificultaría la profundización en los resultados de la búsqueda. Ahora puede hacer clic en el título del elemento de trabajo para abrir los elementos de trabajo en una ventana modal. Esta característica se ha priorizado desde UserVoice.

Repos

Selector de rama mejorado

La mayoría de las experiencias Azure Repos requieren que seleccione un repositorio y, a continuación, una rama en ese repositorio. Para mejorar esta experiencia para organizaciones con un gran número de ramas, estamos implementando un nuevo selector de ramas. El selector ahora le permite seleccionar sus ramas favoritas o buscar rápidamente una rama.

Selector de ramas

Recibir notificaciones cuando se omiten las directivas de solicitud de extracción

En el caso de los equipos que usan solicitudes de extracción (SOLICITUDES) y directivas de rama ,puede haber ocasiones en las que los usuarios necesiten invalidar y omitir esas directivas; por ejemplo, al implementar una revisión en un problema de producción en plena noche. Tiene sentido confiar en que los desarrolladores hagan lo correcto y usen la funcionalidad de invalidación con moderación. Al mismo tiempo, los equipos necesitan una manera de comprobar que esas invalidaciones de directiva se usan en las situaciones correctas. Para admitir esto, hemos agregado un nuevo filtro de notificación para permitir que los usuarios y equipos reciban alertas por correo electrónico cada vez que se omite una directiva. Comience con la plantilla A pull request is created or updated (Se crea o actualiza una solicitud de extracción) y seleccione Policy Bypass (Omitir directiva) en la lista de filtros. Seleccione Directivas que se omitieron como valor y se le notificará cada vez que se complete una solicitud de cambio y se omitan las directivas.

Omitir notificación de directiva

<a name="allow-bypassing-branch-policies-without-giving-up-push-protection">Permitir omitir directivas de rama sin perder la protección de inserción

Hay muchos escenarios en los que tiene la necesidad ocasional de omitir una directiva de rama: revertir un cambio que produjo una interrupción de la compilación, aplicar una revisión en mitad de la noche, etc. Anteriormente, se ofrecía un permiso ("Exento del cumplimiento de directivas") para ayudar a los equipos a administrar qué usuarios tenían la capacidad de omitir las directivas de rama al completar una solicitud de extracción. Sin embargo, ese permiso también concedió la capacidad de insertar directamente en la rama, omitiendo completamente el proceso de solicitud de inserción.

Para mejorar esta experiencia, hemos dividido el permiso anterior para ofrecer más control a los equipos que conceden permisos de omisión. Hay dos nuevos permisos para reemplazar el anterior:

  1. Omitir directivas al completar las solicitudes de extracción. Los usuarios con este permiso podrán usar la experiencia "Invalidar" para las solicitudes de extracción.
  2. Omitir directivas al insertar. Los usuarios con este permiso podrán insertar directamente en ramas que tengan configuradas directivas necesarias.

Al conceder el primer permiso y denegar el segundo, un usuario podrá usar la opción de omisión cuando sea necesario, pero seguirá teniendo la protección de insertar accidentalmente en una rama con directivas.

Nota

Este cambio no introduce ningún cambio de comportamiento. A los usuarios a los que anteriormente se les concedió Permitir para "Exentos del cumplimiento de directivas", se les concederá Permiso para ambos permisos nuevos, por lo que podrán invalidar la finalización en los PR e insertar directamente en ramas con directivas.

Para obtener más información, consulte la documentación sobre cómo establecer permisos de rama.

Describir rápidamente las solicitudes de extracción mediante mensajes de confirmación

La escritura de mensajes de confirmación descriptivos agrega valor al historial de cualquier repositorio de Git. Para fomentar mensajes de confirmación de calidad, las nuevas solicitudes de extracción (PR) que tienen varias confirmaciones requerirán que los colaboradores escriban un título manualmente.

Las descripciones de las solicitudes de incorporación de cambios seguirán estando vacías de forma predeterminada, pero una nueva característica facilitará la incorporación de los mensajes de confirmación de las confirmaciones de solicitud de incorporación de cambios en la descripción de la solicitud de incorporación de cambios. Para agregar los mensajes de confirmación, simplemente haga clic en Agregar mensajes de confirmación para anexar los mensajes de confirmación al final del texto de descripción de la pr.

Creación de solicitudes de extracción sin un equipo predeterminado como revisor

Cuando iniciamos por primera vez la experiencia de solicitud de extracción (PR), creemos que tendría sentido asignar todas las solicitudes de solicitud al contexto de equipo que había seleccionado al crear la solicitud de solicitud. Este comportamiento ha sido un punto de frustración, ya que muchas personas no se han dado cuenta de la conexión entre el contexto del equipo y la asignación de pr. De hecho, esta ha sido una de nuestras principales sugerencias de UserVoice.

Como parte de los nuevos cambios de navegación, aprovechamos la oportunidad de cambiar esta asociación predeterminada con los equipos. Observará dos cambios:

  1. Al crear una pr, no se agrega ningún revisor de forma predeterminada. La lista de revisores tiene una característica para facilitar la adición de usuarios y grupos que se agregaron recientemente a las PR. La directiva de revisores requerida también puede ayudar a los equipos que desean asegurarse de que se agregan revisores específicos para revisar su código.
  2. El centro de solicitudes de extracción tiene una nueva sección personalizable. De forma predeterminada, en esta sección se muestran las OPCIONES "Asignadas a mis equipos", lo que proporciona una funcionalidad equivalente a la sección anterior. Sin embargo, si pertenece a varios equipos, en esta sección se mostrarán las PR asignadas a cualquiera de los equipos. La sección también es personalizable: simplemente haga clic en la acción "Personalizar esta vista" cerca del encabezado de sección.

Estandarización de descripciones de solicitudes de extracción mediante plantillas

Escribir descripciones de solicitudes de extracción correctas es una excelente manera de ayudar a los revisores a saber qué esperar al revisar el código. También son una excelente manera de ayudar a realizar un seguimiento de las cosas que deben realizarse para cada cambio, como las pruebas, la adición de pruebas unitarias y la actualización de la documentación. Muchos de los usuarios han solicitado que agreguemos plantillas de solicitud de extracción para facilitar a los equipos la escritura de descripciones excelentes, y ahora hemos agregado esa característica.

Además de admitir una plantilla de descripción de pr predeterminada, los equipos pueden agregar varias plantillas, que se presentan en un menú de la página Crear PR. Simplemente haga clic en el botón Agregar una plantilla para elegir entre cualquier plantilla del repositorio para anexarla a la descripción de la pr.

Agregar plantilla para la pr

También se admiten plantillas específicas de rama si desea aplicar una plantilla diferente para una solicitud de solicitud de cambios en una rama específica o en una carpeta de rama. Por ejemplo, si desea tener una plantilla específica para todas las ramas que comienzan por "revisión/", puede agregar una plantilla que se usará para todas las PR en esas ramas.

Consulte la documentación de plantillas de solicitud de extracción para obtener más información sobre cómo crear y usar plantillas.

Cambio de la rama de destino de una solicitud de extracción

Para la mayoría de los equipos, casi todas las solicitudes de extracción tienen como destino la misma rama, como main o develop . Sin embargo, en el caso de que necesite tener como destino una rama diferente, es fácil olvidarse de cambiar la rama de destino del valor predeterminado. Con la nueva característica para cambiar la rama de destino de una solicitud de extracción activa, se trata ahora de una acción sencilla. Solo tiene que hacer clic en el icono de lápiz situado cerca del nombre de la rama de destino en el encabezado de la solicitud de extracción.

Cambiar la rama de destino

Además de corregir errores, la característica para cambiar las ramas de destino también facilita la "redestinación" de una solicitud de extracción cuando la rama de destino se ha combinado o eliminado. Considere un escenario en el que tiene una PR destinada a una rama de características que contiene alguna característica de la que dependen los cambios. Quiere revisar los cambios dependientes de forma aislada de otros cambios en la rama de características, por lo que inicialmente tiene como destino features/new-feature . A continuación, los revisores pueden ver solo los cambios y dejar los comentarios adecuados.

Ahora, considere lo que ocurriría si la rama de características también tuviera una pr. activa y se combinara con main antes de los cambios? Anteriormente, tendría que abandonar los cambios y crear una nueva pr en , o combinar la PR en y, a continuación, crear otra PR main features/new-feature de a features/new-feature main . Con esta nueva acción para actualizar la rama de destino, simplemente puede cambiar la rama de destino de la pr. de a , conservando todo el contexto features/new-feature main y los comentarios. El cambio de la rama de destino incluso crea una nueva actualización de la pr., lo que facilita la mirada hacia atrás en las diferencias anteriores antes de que cambie la rama de destino.

Actualización de la rama de destino

Los autores de extensiones pueden consultar el contexto sobre el repositorio actual

Uno de los desafíos para un autor de una extensión de control de versiones es obtener el contexto del repositorio que se muestra al usuario, como el nombre, el identificador y la dirección URL. Para ayudar con esto, agregamos VersionControlRepositoryService como un servicio accesible desde la extensión. Con esto, un autor de la extensión puede consultar información sobre el contexto actual del repositorio de Git dentro de la interfaz de usuario web. Actualmente tiene un método, getCurrentGitRepository().

  • Si se selecciona un repositorio git, se devuelve un objeto GitRepository con datos básicos sobre el repositorio (nombre, identificador y dirección URL)
  • Si se selecciona un repositorio TFVC o se accede al servicio fuera de las Azure Repos, se devolverá null.

Esta es una extensión de ejemplo que usa este servicio.

Procesos

Administración de canalizaciones de compilación mediante la nueva página Compilaciones

Estamos realizando varias mejoras e implementando una nueva versión de la página Compilaciones. Esta nueva versión combina el directorio de todas las canalizaciones de compilación y la lista de compilaciones actuales para que pueda navegar rápidamente por las compilaciones del proyecto para ver su estado. También incluye una versión preliminar de análisis de pruebas para la canalización seleccionada.

Página Nuevas compilaciones

Administrar mejor los correos electrónicos de finalización de compilación e implementación mediante un formato mejorado

Los correos electrónicos de finalización de compilación e implementación se han actualizado para que sean más filtrables mediante reglas de correo electrónico. Ahora la línea de asunto incluye información más relevante de un vistazo, el cuerpo contiene más detalles y su estilo se ha actualizado con la marca más reciente.

Los elementos del nuevo formato son:

  • [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
  • [Deployment result] [pipeline name] > [release name] : [stage name]

Estos son algunos ejemplos:

  • [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
  • [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Siga la nueva terminología de Azure Pipelines unificada

A lo largo de las compilaciones y versiones, se han usado términos diferentes históricamente para conceptos similares. En otros casos, los significados de los términos eran imprecisos. Por ejemplo, la diferencia entre un grupo de agentes y una cola de agentes.

La terminología se ha unificado en Azure Pipelines para aclarar sus conceptos. Ahora verá los siguientes términos unificados:

Término anterior Término unificado Significado
Agente hospedado Agente hospedado por Microsoft Un agente de compilación o versión que se ejecuta en una infraestructura hospedada en la nube administrada por Microsoft.
Agente privado Agente autohospedado Un agente de compilación o versión que se ejecuta en una máquina proporcionada y administrada por usted.
Grupo de agentes Grupo de agentes Un conjunto de máquinas de agente de nivel de organización que pueden ejecutar compilaciones o versiones.
Cola del agente Grupo de agentes Conjunto de máquinas de agente de nivel de proyecto que pueden ejecutar compilaciones o versiones. Está vinculado a un grupo de agentes de nivel de organización.
Definición de compilación Canalización de compilación Un conjunto completo de pasos de compilación para una aplicación.
Build Build Instancia de una canalización de compilación que se está ejecutando o se ha ejecutado.
Fase Trabajo Una serie de tareas que se ejecutan secuencialmente o en paralelo en un agente. Una canalización de compilación o versión puede contener un trabajo o un gráfico de varios trabajos.
Definición de versión Canalización de versión Un conjunto completo de pasos de versión para que una aplicación se implemente en varias fases.
Release Release Instancia de una canalización de versión que se está ejecutando o que se ha ejecutado.
Entorno Fase Una entidad lógica e independiente que representa dónde desea implementar una versión generada a partir de una canalización de versión.
Trabajo o canalización simultáneos Trabajo paralelo Un trabajo paralelo le ofrece la capacidad de ejecutar un único trabajo de compilación o versión a la vez en su organización. Con más trabajos paralelos disponibles, puede ejecutar más trabajos de compilación y versión al mismo tiempo.
Punto de conexión de servicio Conexión de servicio Un grupo de configuraciones, como las credenciales, que se usan para conectarse a servicios externos para ejecutar tareas en una compilación o versión.

Consulte la documentación de conceptos para obtener más información.

Administración de canalizaciones de versión mediante la nueva página Versiones

Hay disponible una experiencia de usuario nueva y totalmente rediseñada para la página de aterrizaje de la versión. Consulte una lista de las canalizaciones de versión que publica a menudo a la izquierda. También puede buscar las canalizaciones y agregarlas como favoritas.

Página de aterrizaje de la versión

Cambie a la vista de carpetas para crear carpetas para la organización y la seguridad. La seguridad se puede establecer en el nivel de carpeta.

Carpetas de versión

Visualización del progreso de la versión

La nueva vista de progreso de la versión proporciona actualizaciones en directo del progreso de la implementación y acceso con un solo clic para obtener más detalles. La nueva vista visualiza la canalización de versión, lo que facilita la información sobre lo que sucede y muestra los detalles y las acciones adecuados en las distintas fases de la versión.

Vista Canalización de versión

Canalización, detalles de la versión y entornos

La vista Canalización muestra los artefactos de la versión y los entornos donde se implementarán. El área Versión proporciona detalles de la versión, como el desencadenador de versión, las versiones de artefacto y las etiquetas.

Los entornos se modelan de una manera que ayuda a comprender su estado, junto con el progreso detallado. En cualquier momento, puede acceder a los registros haciendo clic en el vínculo de estado dentro del entorno.

Entornos

Antes y después de la implementación

Si se han establecido condiciones previas o posteriores a la implementación para un entorno, se indica en el entorno con la presencia de las aprobaciones y puertas. El progreso de las aprobaciones y las puertas también se muestra en el estado del entorno. Puede realizar acciones o ver más detalles haciendo clic en el icono de condición del entorno que se encuentra a la derecha o a la izquierda del entorno.

Acciones de entorno de versión

Confirmaciones y elementos de trabajo

Con cada nueva versión, puede ver la lista de confirmaciones y elementos de trabajo asociados para cada entorno por separado haciendo clic en el entorno. Si la lista es larga, use filtros para buscar una confirmación o un elemento de trabajo que le interese.

Confirmaciones de versión y elementos de trabajo

Progreso y registros de implementación

Los entornos muestran actualizaciones en vivo para las implementaciones en curso, incluido el número de fases y tareas completadas y el tiempo de ejecución. Al hacer clic en el estado del entorno, se abre una vista que contiene los registros, con el foco en lo que está activo actualmente.

Puede hacer clic en los registros para especificar una vista centrada.

Detalles del registro de versión

Impacto de la actualización a Azure DevOps Server 2019 en las tareas: Copia de archivos de máquina Windows y PoweShell en la máquina de destino

Los grupos de máquinas de Test Hub han quedado en desuso en TFS 2017 RTM. Con Azure DevOps Server 2019, el servicio Grupos de máquinas ya no está disponible. Esto afectará a los usuarios de la tarea "Copia de archivos de máquina Windows" versión 1.* y de la tarea "PowerShell en las máquinas de destino", versión 1.*. Para que las canalizaciones sigan funcionando,

  • Tiene que cambiar a la tarea "Copia de archivos de máquina Windows" versión 2.* y proporcionar el fqdn completo para la máquina de destino en lugar de solo el nombre de la máquina.
  • Cambie a la tarea "Powershell en la máquina de destino" versión 2.* o posterior y proporcione el fqdn completo del nombre de máquina o máquina seguido de los puertos Administración remota de Windows (http/https). Por ejemplo, targetMachine:5985 o targetMachine:5986

Extensibilidad y resultados de pruebas

Los resultados de la ejecución de pruebas también se muestran para cada entorno. Al hacer clic en los resultados de la prueba se abre una vista que contiene detalles de pruebas, incluidos los resultados de otras extensiones que contribuyen al proceso.

Resultados de pruebas de versión

Las extensiones existentes funcionan en esta nueva vista, además de que hay nuevos puntos de extensibilidad para permitir que las extensiones desarrollen para mostrar aún más información para un entorno. Consulte la documentación de contribuciones y extensiones para obtener más información.

Configuración de compilaciones mediante YAML

Las canalizaciones de compilación basadas en YAML están disponibles en el Azure DevOps Server. Automatice la canalización de integración continua mediante un archivo YAML registrado en el repositorio. Puede encontrar una referencia completa para el esquema YAML aquí.

Para admitir canalizaciones de compilación basadas en YAML de forma más fluida, hemos cambiado el comportamiento predeterminado de todos los nuevos recursos que cree (por ejemplo, conexiones de servicio, grupos de variables, grupos de agentes y archivos seguros) para que se puedan usar en todas las canalizaciones de ese proyecto. Si desea un control más estricto de los recursos, puede deshabilitar el modelo de autorización predeterminado (consulte la ilustración siguiente). Al hacerlo, alguien con permisos para usar el recurso debe guardar explícitamente la canalización en el editor web después de agregar una referencia de recursos al archivo YAML.

YAML

Los productos grandes tienen varios componentes que dependen entre sí. Estos componentes a menudo se construyen de forma independiente. Cuando cambia un componente ascendente (una biblioteca, por ejemplo), las dependencias de nivel inferior se deben volver a generar y volver a validar. Normalmente, los equipos administran estas dependencias manualmente.

Ahora puede desencadenar una compilación tras la finalización correcta de otra compilación. Los artefactos generados por una compilación ascendente se pueden descargar y usar en la compilación posterior, y también puede obtener datos de estas variables: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Consulte la documentación de desencadenadores de compilación para obtener más información.

Configuración del encadenamiento de compilación

Tenga en cuenta que, en algunos casos, una única compilación de varias fases podría satisfacer sus necesidades. Sin embargo, un desencadenador de finalización de compilación es útil si sus requisitos incluyen diferentes opciones de configuración, opciones o un equipo diferente para poseer el proceso dependiente.

Actualización local del agente

Las tareas que se instalan desde la Galería a veces requieren una versión más reciente del agente de canalizaciones. Si el Azure DevOps Server puede conectarse a Internet, las versiones más recientes se descargan automáticamente. Si no es así, tendrá que actualizar manualmente cada agente. A partir de esta versión, puede configurar el Azure DevOps Server para buscar los archivos del paquete del agente en su disco local en lugar de en Internet. Esto le ofrece flexibilidad y control sobre qué versiones de agente pone a disposición, sin tener que exponer sus Azure DevOps Server a Internet.

Nueva dirección URL de distintivo de estado de compilación

Los distintivos de compilación insertados en la página principal de un repositorio son una manera común de mostrar el estado del repositorio. Aunque hasta ahora teníamos distintivos de compilación, había algunos problemas:

  • La dirección URL no era intuitiva
  • El distintivo no era específico de una rama
  • No había ninguna manera de que un usuario haga clic en el distintivo para llevar al usuario a la compilación más reciente de esa definición.

Ahora estamos implementando una nueva API para distintivos de compilación que solucione estos problemas. La nueva API permite a los usuarios publicar un estado por rama y llevar a los usuarios a la última compilación de la rama seleccionada. Puede obtener markdown para la nueva dirección URL de distintivo de estado seleccionando la acción de menú Distintivo de estado en la nueva página Compilaciones.

Por compatibilidad con versiones anteriores, seguiremos respetando también las direcciones URL de distintivo de compilación anteriores.

Agregar contadores de compilación personalizados a las compilaciones

Los contadores de compilación proporcionan una manera única de numerar y etiquetar compilaciones. Anteriormente, podía usar la variable especial $(rev:r) para lograr esto. Ahora puede definir sus propias variables de contador en la definición de compilación que se incrementan automáticamente cada vez que se ejecuta una compilación. Esto se hace en la pestaña variables de una definición. Esta nueva característica ofrece más potencia de las siguientes maneras:

  • Puede definir un contador personalizado y establecer su valor de valor de ed. Por ejemplo, puede iniciar el contador en 100. $(rev:r) siempre comienza en 0.
  • Puede usar su propia lógica personalizada para restablecer un contador. $(rev:r) está vinculado a la generación de números de compilación y se restablece automáticamente cada vez que hay un nuevo prefijo en el número de compilación.
  • Puede definir varios contadores por definición.
  • Puede consultar el valor de un contador fuera de una compilación. Por ejemplo, puede contar el número de compilaciones que se han ejecutado desde el último restablecimiento mediante un contador.

Consulte la documentación sobre variables definidas por el usuario para obtener más información sobre los contadores de compilación.

Azure Policy y validaciones de seguridad en canalizaciones

Queremos garantizar la estabilidad y la seguridad del software al principio del proceso de desarrollo, a la vez que se unen el desarrollo, la seguridad y las operaciones. Para ello, hemos agregado compatibilidad con Azure Policy.

Azure Policy le ayuda a administrar y evitar problemas de TI con definiciones de directivas que aplican reglas y efectos a los recursos. Cuando se usa Azure Policy, los recursos se mantienen compatibles con los estándares corporativos y los acuerdos de nivel de servicio.

Para cumplir las directrices de cumplimiento y seguridad como parte del proceso de lanzamiento, hemos mejorado nuestra experiencia de implementación del grupo de recursos de Azure. Ahora, se producen errores en la tarea de implementación del grupo de recursos de Azure con errores relacionados con la directiva pertinentes en caso de infracciones al implementar plantillas de ARM.

Azure Policy

Además, hemos agregado una plantilla de definición Azure Policy versión. Esto permitirá a los usuarios crear directivas de Azure y asignar estas directivas a recursos, suscripciones o grupos de administración desde la propia definición de versión.

Azure Policy plantilla

Compilación en plataformas Linux/ARM y Windows de 32 bits

El Azure Pipelines de código abierto multiplataforma siempre se admite en Windows, macOS y Linux de 64 bits (x64). Con esta versión, presentamos dos nuevas plataformas compatibles: Linux/ARM y Windows/32 bits. Estas nuevas plataformas le dan la posibilidad de crear plataformas menos comunes, pero no menos importantes, como Raspberry Pi, una máquina Linux o ARM.

Experiencias mejoradas para pruebas en canalizaciones

La pestaña Pruebas ahora tiene una experiencia moderna que proporciona información de pruebas enriquecciones en contexto para canalizaciones. La nueva experiencia proporciona una vista de prueba en curso, una experiencia de depuración de página completa, en el historial de pruebas de contexto, la generación de informes de la ejecución de prueba anulada y el resumen de nivel de ejecución.

Nuevo centro de pruebas

Visualización de la ejecución de pruebas en curso

Las pruebas, como la integración y las pruebas funcionales, se pueden ejecutar durante mucho tiempo, por lo que es importante ver la ejecución de pruebas en un momento dado. Con el In-Progress Vista de pruebas, ya no tiene que esperar a que se complete la ejecución de pruebas para conocer el resultado de la prueba. Los resultados están disponibles casi en tiempo real a medida que se ejecutan, lo que le ayuda a realizar acciones con mayor rapidez. Puede depurar un error o anularlo, presentar un error o anular la canalización. La característica está disponible actualmente para la canalización de compilación y versión mediante la tarea de prueba de VS en la fase de varios agentes, mediante la tarea Publicar Resultados de pruebas o la publicación de resultados de pruebas mediante API. En el futuro, tenemos previsto ampliar esta experiencia para la ejecución de pruebas mediante agente único.

En la vista siguiente se muestra In-Progress resumen de pruebas en la nueva vista de progreso de la versión, que informa del número total de pruebas y el número de errores de prueba en un momento dado.

Vista de prueba en curso

Al hacer clic en In-Progress resumen de prueba anterior, puede ver el resumen de pruebas detallado junto con la información de prueba con errores o anulada en Test Plans. El resumen de prueba se actualiza a intervalos periódicos con la capacidad de actualizar la vista de detalles a petición, en función de la disponibilidad de los nuevos resultados.

Resumen detallado de pruebas

Ver los detalles de depuración de la ejecución de pruebas en la página completa

Los mensajes de error y los seguimientos de pila son largos por naturaleza y necesitan suficiente espacio real para ver los detalles durante la depuración. Para tener una experiencia de depuración inmersiva, ahora puede expandir la vista de ejecución de pruebas o pruebas a la vista de página completa, a la vez que puede realizar las operaciones de contexto necesarias, como la creación de errores o la asociación de requisitos para el resultado de la prueba actual.

Depuración de página completa

Visualización del historial de pruebas en contexto

Históricamente, los equipos tendrían que ir al centro De ejecuciones para ver el historial de un resultado de prueba. Con la nueva experiencia, el historial de pruebas se encuentra en contexto dentro Test Plans pestaña de compilación y versión. La información del historial de pruebas se proporciona de forma progresiva a partir de la definición o el entorno de compilación actual para la prueba seleccionada, seguido de otras ramas y entornos para la compilación y la versión respectivamente.

Historial de pruebas en contexto

Visualización de pruebas anuladas

La ejecución de pruebas puede anularse debido a varios motivos, como código de prueba no correcto, código fuente sometido a prueba y problemas del entorno. Independientemente del motivo de la anulación, es importante diagnosticar el comportamiento e identificar la causa principal. Ahora puede ver las pruebas anuladas y las ejecuciones de prueba, junto con las ejecuciones completadas en Test Plans. La característica está disponible actualmente para la canalización de compilación y versión mediante la tarea prueba de VS en la fase de varios agentes o la publicación de resultados de pruebas mediante API. En el futuro, tenemos previsto ampliar esta experiencia para la ejecución de pruebas mediante agente único.

Visualización de pruebas anuladas

Compatibilidad con entornos de versión y rastreabilidad de pruebas en el historial de pruebas

Estamos agregando compatibilidad para ver el historial de una prueba automatizada agrupada por varios entornos de versión en los que se ejecuta la prueba. Si está modelando entornos de versión como canalizaciones de versión o entornos de prueba, y está ejecutando pruebas en estos entornos, puede averiguar si una prueba está pasando en el entorno de desarrollo, pero con errores en el entorno de integración. Puede averiguar si está pasando la configuración regional en inglés, pero con errores en un entorno que tenga la configuración regional turco. Para cada entorno, encontrará el estado del resultado de la prueba más reciente y, si se ha realizado un error en ese entorno, también encontrará la versión desde la que se ha dado error en la prueba.

Revisión de los resultados resumidos de las pruebas

Durante la ejecución de pruebas, una prueba podría generar varias instancias de pruebas que contribuyen al resultado general. Algunos ejemplos son: pruebasque se vuelvan a ejecutar debido a errores, pruebas compuestas de una combinación ordenada de otras pruebas (por ejemplo, pruebas ordenadas) o pruebas con instancias diferentes basadas en el parámetro de entrada proporcionado (pruebas controladas por datos). Dado que estas pruebas están relacionadas, deben informarse junto con el resultado general derivado en función de los resultados de prueba individuales. Con esta actualización, presentamos una versión mejorada de los resultados de pruebas presentados como una jerarquía en la pestaña Pruebas de una versión. Veamos un ejemplo.

Anteriormente, se introdujo la capacidad de volver a ejecutar pruebas con errores en la tarea Prueba de VS. Sin embargo, solo informamos sobre el último intento de una prueba, lo que limitaba ligeramente la utilidad de esta característica. Ahora hemos ampliado esta característica para notificar cada instancia de la ejecución de prueba como un intento. Además, test API de Administración ahora admite la capacidad de publicar y consultar los resultados jerárquicos de las pruebas. Consulte la documentación de la API de resultados de pruebas para obtener más información.

Depuración de resumen de pruebas

Nota

Las métricas de la sección de resumen de pruebas (por ejemplo, Total de pruebas, Superadas, etc.) se calculan mediante el nivel raíz de la jerarquía en lugar de cada iteración individual de las pruebas.

Visualización de análisis de pruebas en canalizaciones

El seguimiento de la calidad de las pruebas a lo largo del tiempo y la mejora de la garantía de las pruebas es clave para mantener una canalización en buen estado. La característica de análisis de pruebas proporciona visibilidad casi en tiempo real de los datos de prueba para compilaciones y canalizaciones de versión. Ayuda a mejorar la eficacia de la canalización mediante la identificación de problemas repetitivos y de calidad de alto impacto.

Puede agrupar los resultados de las pruebas por varios elementos, identificar las pruebas clave de la rama o los archivos de prueba, o explorar en profundidad una prueba específica para ver tendencias y comprender los problemas de calidad, como la flakiness.

Vea análisis de pruebas para compilaciones y versiones, versiónpreliminar a continuación:

Análisis de pruebas

Para obtener más información, vea la documentación.

Simplificación de definiciones con varias tareas sin agente

Las tareas de una fase sin agente se orquestan mediante y se ejecutan en el servidor. Las fases sin agente no requieren un agente ni ningún equipo de destino. A diferencia de las fases del agente, solo se podría agregar una tarea a cada fase sin agente en las definiciones. Esto significaba que había que agregar varias fases cuando había más de una tarea sin agente en el proceso, lo que hacía que la definición fuera masiva. Hemos relajado esta restricción, que permite mantener varias tareas en fases sin agente. Las tareas de la misma fase se ejecutarían secuencialmente, igual que en las fases del agente. Consulte la documentación de las fases del servidor para obtener más información.

Exposición progresiva y fase de implementaciones mediante puertas de versión

Con las puertas de lanzamiento, puede especificar los criterios de mantenimiento de la aplicación que deben cumplirse antes de que una versión se promueve al siguiente entorno. Todas las puertas especificadas se evalúan periódicamente antes o después de cualquier implementación, hasta que se realizan correctamente. Hay cuatro tipos de puertas disponibles de forma automática y puede agregar más puertas desde Marketplace. Podrá auditar que se cumplen todos los criterios necesarios para una implementación. Vea la documentación sobre validaciones de versión para obtener más información.

Panel Puertas de lanzamiento

Mantener las implementaciones hasta que las puertas se realiza correctamente de forma coherente

Las puertas de lanzamiento habilitan la evaluación automática de los criterios de mantenimiento antes de promover una versión al siguiente entorno. De forma predeterminada, la versión progresa después de que se haya recibido una muestra correcta para todas las puertas. Incluso si una puerta es errática y la muestra correcta recibida es ruido, la versión progresa. Para evitar estos tipos de problemas, ahora puede configurar la versión para comprobar la coherencia del estado durante un período mínimo antes de avanzar. En tiempo de ejecución, la versión garantizaría que las evaluaciones consecutivas de las puertas se realizaron correctamente antes de permitir la promoción. El tiempo total para la evaluación depende del "tiempo entre reevaluación" y normalmente sería mayor que la duración mínima configurada. Consulte la documentación Control de implementación de versiones mediante puertas para obtener más información.

Configuración de retención de Puertas

Implementación automática en nuevos destinos de un grupo de implementación

Anteriormente, cuando se agregaban nuevos destinos a un grupo de implementación, se requería una implementación manual para asegurarse de que todos los destinos tienen la misma versión. Ahora puede configurar el entorno para implementar automáticamente la última versión correcta en los nuevos destinos. Consulte la documentación de grupos de implementación para obtener más información.

Grupos de implementación

Implementación continua de compilaciones etiquetadas por el procesamiento posterior a la compilación

Los desencadenadores de implementación continua crean una versión al finalizar la compilación. Sin embargo, a veces las compilaciones se procesan posteriormente y la compilación solo debe publicarse una vez completado ese procesamiento. Ahora puede aprovechar las etiquetas de compilación, que se asignarían durante el procesamiento posterior, en los filtros de desencadenador de la versión.

desencadenador de etiqueta de compilación

Establecer una variable en tiempo de lanzamiento

En una definición de versión, ahora puede elegir las variables que desea establecer al crear la versión.

Variable de versión

El valor proporcionado para la variable cuando se crea la versión solo se usa para esa versión. Esta característica le ayudará a evitar varios pasos para Crear en borrador, actualizar las variables en borrador y desencadenar la versión con la variable .

Variable de versión en versión

Pasar variables de entorno a tareas

Los autores de tareas de CI/CD pueden establecer una nueva propiedad, showEnvironmentVariables, en el task.jsen para pasar variables de entorno a tareas. Al hacerlo, se representa un control adicional en la tarea en el editor de compilación. Está disponible para las tareas de PowerShell, Cmd y Bash.

Pasar variables de entorno

Esto permite dos escenarios:

  • Una tarea requiere una variable de entorno con mayúsculas y minúsculas en el nombre de la variable. Por ejemplo, en el ejemplo anterior, la variable de entorno que se pasa a la tarea sería "foo" y no "FOO".
  • Permite que los valores de secretos se pasen de forma segura a los scripts. Esto es preferible a pasar los secretos como argumentos a los scripts, ya que el sistema operativo del agente puede registrar la invocación de procesos, incluidos sus argumentos.

Clonación de grupos de variables

Hemos agregado compatibilidad con la clonación de grupos de variables. Siempre que quiera replicar un grupo de variables y actualizar solo algunas de las variables, no es necesario pasar por el tedioso proceso de agregar variables una a una. Ahora puede realizar rápidamente una copia del grupo de variables, actualizar los valores adecuadamente y guardarlos como un nuevo grupo de variables.

Clonar grupo de variables

Nota

Los valores de la variable secreta no se copian al clonar un grupo de variables. Debe actualizar las variables cifradas y, a continuación, guardar el grupo de variables clonadas.

Omitir una puerta de lanzamiento para una implementación

Las puertas de lanzamiento habilitan la evaluación automática de los criterios de mantenimiento antes de promover una versión al siguiente entorno. De forma predeterminada, la canalización de versión solo progresa cuando todas las puertas están en buen estado al mismo tiempo. En determinadas situaciones, como al acelerar una versión o después de comprobar manualmente el estado, es posible que un aprobador quiera omitir una puerta y permitir que la versión progrese incluso si esa puerta todavía no se ha evaluado como correcta. La documentación de las puertas de versión para obtener más información.

Omitir puertas

Realización de pruebas adicionales mediante un desencadenador de versión de solicitud de extracción

Ha podido desencadenar una compilación basada en una solicitud de extracción (PR) y obtener los comentarios rápidos antes de una combinación durante un tiempo. Ahora también puede configurar un desencadenador de pr. para una versión. El estado de la versión se volverá a publicar en el repositorio de código y se puede ver directamente en la página de la pr. Esto resulta útil si desea realizar pruebas manuales o funcionales adicionales como parte del flujo de trabajo de pr.

Desencadenador de PR en versión

Creación de una conexión de servicio de Azure con una entidad de servicio que se autentica con un certificado

Ahora puede definir una conexión de servicio de Azure con una entidad de servicio y un certificado para la autenticación. Con la conexión de servicio de Azure que ahora admite la entidad de servicio que se autentica con un certificado, ahora puede implementar en Azure Stack configurado con AD FS. Para crear una entidad de servicio con autenticación de certificado, consulte el artículo sobre cómo crear una entidad de servicio que se autentique con un certificado.

Conectarse a la entidad de servicio

Ejecutar desde el paquete admitido en Azure App Service implementaciones

La Azure App Service deploy (4.*) ahora admite RunFromPackage (anteriormente denominado RunFromZip).

App Service admite una serie de técnicas diferentes para implementar los archivos, como msdeploy (también conocido como WebDeploy), git, ARM, etc. Pero todas estas técnicas tienen una limitación. Los archivos se implementan en la carpeta wwwroot (específicamente d:\home\site\wwwroot) y el tiempo de ejecución ejecuta los archivos desde allí.

Con Ejecutar desde el paquete, ya no hay un paso de implementación que copie los archivos individuales en wwwroot. En su lugar, simplemente apunte a un archivo ZIP y el archivo zip se monta en wwwroot como un sistema de archivos de solo lectura. Esto presenta varias ventajas:

  • Se reduce el riesgo de problemas de bloqueo de copia de archivos.
  • Se pueden implementar en una aplicación de producción (con reinicio).
  • Puede estar seguro de los archivos que se ejecutan en la aplicación.
  • Mejora el rendimiento de Azure App Service implementaciones.
  • Puede reducir los tiempos de arranque en frío, especialmente para las funciones de JavaScript con árboles de paquete de npm grandes.

Implementación de contenedores de Linux con la tarea de implementación de App Server

La versión 4.* de la tarea Azure App Service Implementar ahora admite la implementación de su propio contenedor personalizado para Azure Functions en Linux.

El modelo de hospedaje de Linux para Azure Functions se basa en contenedores de Docker que aportan mayor flexibilidad en términos de empaquetado y aprovechamiento de dependencias específicas de la aplicación. Las funciones en Linux se pueden hospedar en dos modos diferentes:

  1. Imagen de contenedor integrada: Traiga el código de Function App y Azure proporciona y administra el contenedor (modo de imagen integrada), por lo que no se requiere ningún conocimiento específico relacionado con Docker. Esto se admite en la versión existente de App Service Implementar tarea.
  2. Imagen de contenedor personalizada: Hemos mejorado la tarea App Service implementar para admitir la implementación de imágenes de contenedor personalizadas en Azure Functions en Linux. Cuando las funciones necesitan una versión de lenguaje específica o requieren una dependencia o configuración específica que no se proporciona dentro de la imagen integrada, puede compilar e implementar una imagen personalizada en Azure Function en Linux mediante Azure Pipelines.

La tarea Xcode admite Xcode 10 recién publicado

Coincidiendo con la versión de Xcode 10 de Apple, ahora puede establecer los proyectos para compilar o probarse específicamente con Xcode 10. La canalización también puede ejecutar trabajos en paralelo con una matriz de versiones de Xcode. Puede usar el grupo de agentes de macOS hospedado por Microsoft para ejecutar estas compilaciones. Consulte las instrucciones para usar Xcode en Azure Pipelines.

Xcode 10

Simplificación de la implementación en Kubernetes mediante Helm

Helm es una herramienta que simplifica la instalación y administración de aplicaciones de Kubernetes. También ha obtenido mucha popularidad y soporte técnico de la comunidad en el último año. Ahora hay disponible una tarea de Helm en la versión para empaquetar e implementar gráficos de Helm en Azure Container Service (AKS) o en cualquier otro clúster de Kubernetes.

Con la adición de esta tarea de Helm, ahora puede configurar una canalización de CI/CD basada en Helm para entregar contenedores en un clúster de Kubernetes. Consulte La implementación mediante Kubernetes para Azure Container Service documentación para obtener más información.

tareas de helm

Control de la versión de Helm usada en la versión

La tarea Instalador de herramientas de Helm adquiere una versión específica de Helm desde Internet o la caché de herramientas y la agrega a la ruta de acceso del agente (hospedada o privada). Use esta tarea para cambiar la versión de Helm usada en tareas posteriores, como la tarea de la CLI de .NET Core. Agregar esta tarea antes de la tarea Helm Deploy en una definición de compilación o versión garantiza que empaqueta e implementa la aplicación con la versión correcta de Helm. Esta tarea también ayuda a instalar opcionalmente la herramienta kubectl, que es un requisito previo para que Helm funcione.

Implementación continua en Azure Database for MySQL

Ahora puede implementar continuamente en Azure Database for MySQL: base de datos MySQL de Azure como servicio. Administre los archivos de script de MySQL en el control de versiones e impleméntese continuamente como parte de una canalización de versión mediante una tarea nativa en lugar de scripts de PowerShell.

Uso de tareas mejoradas basadas en PowerShell remotos de Windows

Hay disponibles nuevas y mejoradas tareas basadas en PowerShell remotas de Windows. Estas mejoras incluyen varias correcciones de rendimiento y admiten registros en directo y comandos de salida de consola, como Write-Host y Write-Output.

PowerShell en la tarea de destino (versión: 3.*): puede agregar script en línea, modificar las opciones de PSSession, controlar "ErrorActionPreference" y generar un error estándar.

Tarea de copia de archivos de Azure (versión: 2.*): se suministra con la versión más reciente de AzCopy (v7.1.0) que soluciona un problema de GitHub.

Filtrar ramas para artefactos GitHub Enterprise git externos o externos

Al liberar desde GitHub Enterprise repositorios git externos o externos, ahora puede configurar las ramas específicas que se publicarán. Por ejemplo, puede que desee implementar solo compilaciones procedentes de una rama específica en producción.

filtros de rama

Compilación de aplicaciones escritas en Go

Use la tarea Instalador de la herramienta Go para instalar una o varias versiones de la herramienta Go sobre la marcha. Esta tarea adquiere una versión específica de la herramienta Go que necesita el proyecto y la agrega a la ruta de acceso del agente de compilación. Si la versión de la herramienta go de destino ya está instalada en el agente, esta tarea omitirá el proceso de descargarla e instalarla de nuevo.

La tarea Go le ayuda a descargar dependencias, compilar o probar la aplicación. También puede usar esta tarea para ejecutar un comando Go personalizado de su elección.

Ejecución de scripts de Python en línea o basados en archivos en la canalización

Una nueva tarea Script de Python simplifica la ejecución de scripts de Python en la canalización. La tarea ejecutará un script desde un archivo de Python (.py) en el repositorio, o puede escribir manualmente un script en la configuración de la tarea para guardarlo como parte de la canalización. La tarea usará la versión de Python en la ruta de acceso o puede especificar una ruta de acceso absoluta a un intérprete de Python para su uso.

Aprovechamiento de la compilación mejorada de Xcode y la salida de prueba de xcpretty

xcpretty mejora la legibilidad de la salida de xcodebuild y genera los resultados de las pruebas en formato JUnit. La tarea de compilación de Xcode ahora usa automáticamente xcpretty cuando está disponible en el equipo del agente, como en los agentes macOS hospedados. Aunque la salida de xcpretty puede ser diferente y menos detallada que la salida de xcodebuild, hacemos que los registros de xcodebuild completos estén disponibles con cada compilación.

Test Plans

Test Runner cliente (Azure Test Plans) para que ejecute pruebas manuales para aplicaciones de escritorio

Ahora puede usar el cliente Test Runner (Azure Test Plans) para ejecutar pruebas manuales para aplicaciones de escritorio. Esto le ayudará a pasar de Microsoft Test Manager a Azure Test Plans. Consulte nuestras instrucciones aquí. Con el Test Runner, puede ejecutar las pruebas manuales y registrar los resultados de cada paso de prueba. También tiene funcionalidades de recopilación de datos, como captura de pantalla, registro de acciones de imagen y grabación de vídeo de audio. Si encuentra un problema al realizar pruebas, use Test Runner para crear un error con pasos de prueba, capturas de pantalla y comentarios incluidos automáticamente en el error.

Test Runner (Azure Test Plans) requiere una descarga e instalación únicas del ejecutor. Seleccione Ejecutar para la aplicación de escritorio como se muestra a continuación.

Azure Test Runner

Azure Test Runner instalación

Artifacts

Orígenes de nivel superior

Azure DevOps Server 2019 ofrece actualizaciones sustanciales de los orígenes ascendentes disponibles en las fuentes Azure Artifacts fuente:

  • Puede agregar orígenes nuget.org ascendentes a fuentes existentes creadas en versiones anteriores de TFS. Busque el banner encima de los paquetes de la fuente para obtener más información, incluidos los cambios de comportamiento que debe tener en cuenta antes de actualizar.
  • Puede agregar otras fuentes Azure DevOps Server como orígenes ascendentes a la fuente, lo que significa que puede usar paquetes NuGet y npm de esas fuentes a través de la fuente.

También hemos introducido un nuevo rol en Azure Artifacts: "Colaborador". Un colaborador puede guardar paquetes de un origen ascendente, pero no puede publicar paquetes directamente en la fuente (por ejemplo, mediante nuget publish). Esto le permite restringir la publicación de paquetes a un usuario de confianza o al sistema de compilación, al tiempo que permite a los ingenieros usar nuevos paquetes de los orígenes ascendentes.

Seguimiento de paquetes

Hemos hecho que sea incluso más fácil configurar las notificaciones con un nuevo botón Seguir directamente en cada paquete. El botón Seguir también es compatible con las vistas de versión. Si sigue un paquete mientras lo mira a través de una vista, solo se obtienen actualizaciones para las nuevas versiones que se promueven a esa vista.

Cambiar la configuración de fuente sin tener que guardar manualmente

Se han mejorado algunas de las interacciones de la página de configuración de fuente. Ahora, los cambios que realice, como agregar un nivel superior o un permiso, se guardan inmediatamente. Esto significa que no tiene que preocuparse de perder los cambios al cambiar entre los pivotes de configuración.

Simplifica la autenticación con el nuevo proveedor de credenciales para distintas plataformas de NuGet

La interacción con fuentes de NuGet autenticadas ha mejorado mucho. La nueva aplicación basada en .NET Core Azure Artifacts Proveedor de credenciales con msbuild, dotnet y nuget(.exe) en Windows, macOS y Linux. Siempre que quiera usar paquetes de una fuente de Azure Artifacts, el Proveedor de credenciales adquirirá y almacenará automáticamente un token en nombre del cliente NuGet que está usando. Ya no es necesario almacenar y administrar manualmente un token en un archivo de configuración.

Para obtener el nuevo proveedor, diríjase a GitHub y siga las instrucciones para el cliente y la plataforma.

Comprime símbolos cuando publica en un archivo compartido

Hemos actualizado la tarea Index & Publish Symbols para admitir la compresión de símbolos cuando se publican en un recurso compartido de archivos.

Comprimir símbolos

Wiki

Publicación de archivos Markdown desde un repositorio de Git como wiki

Los desarrolladores crean documentación para "API", "SDK" y "documentos de ayuda que explican el código" en repositorios de código. A continuación, los lectores deben realizar un rejeje en el código para encontrar la documentación adecuada. Ahora puede simplemente publicar archivos markdown desde repositorios de código y hospedarlos en Wiki.

código público como acción wiki

Desde wiki, haga clic en Publicar código como wiki. A continuación, puede especificar una carpeta en un repositorio de Git que se debe promover.

cuadro de diálogo publicar páginas

Una vez que haga clic en Publicar, todos los archivos markdown de la carpeta seleccionada se publicarán como una wiki. Esto también asignará el responsable de la rama a la wiki para que los cambios que realice en el repositorio de Git se reflejen inmediatamente.

Consulte la entrada de blog de documentación del producto para obtener más información.

Ahora puede hacer clic en el icono de vínculo situado junto a cualquier encabezado de sección de una página wiki para generar una dirección URL directamente a esa sección. A continuación, puede copiar esa dirección URL y compartirla con los miembros del equipo para vincularlas directamente a esa sección. Esta característica se ha priorizado por una sugerencia.

Dirección URL del encabezado wiki

Adjuntar archivos e imágenes en carpetas

Al editar páginas wiki sin conexión, puede ser más fácil agregar archivos adjuntos e imágenes en el mismo directorio que la página wiki. Ahora, puede agregar un archivo adjunto o una imagen en cualquier carpeta de la wiki y vincularlo a la página. Esta característica se ha priorizado por una sugerencia.

Imagen de wiki en la carpeta del repositorio de Git

Inserta un video en la wiki

Ahora puede insertar vídeos en una página wiki desde servicios en línea como Microsoft Stream y YouTube. Puede agregar la dirección URL del vídeo insertado mediante la sintaxis siguiente:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Inserción de vídeo en wiki

Cambiar el nombre de una wiki

Ahora puede cambiar el nombre de la wiki en la interfaz de usuario wiki y usar las API REST. En el menú Más, haga clic en Cambiar nombre de wiki para dar a la wiki un nombre fácil de recordar.

Cambiar el nombre de wiki

Abrir página en la nueva pestaña

Ahora puede hacer clic con el botón derecho en una página wiki y abrirla en una nueva pestaña o simplemente presionar CTRL + clic izquierdo en una página wiki para abrirla en una nueva pestaña.

Nueva pestaña wiki

Conservar caracteres especiales en los títulos de la página Wiki

Ahora puede crear páginas wiki con caracteres especiales, como : < > * ? | - . Ahora páginas con títulos como "¿Preguntas más frecuentes?" o "Guía de configuración" se pueden crear en wiki. Los caracteres siguientes se traducen a sus cadenas codificadas en UTF-8:

Carácter Cadena codificada
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D

Todos los vínculos de una wiki que no estén vinculados correctamente aparecerán en un color rojo distintivo y un icono de vínculo roto, lo que le ofrece una pista visual de todos los vínculos rotos en una página wiki.

Vínculos rotos de wiki

Los vínculos a páginas rotas son una de las principales causas de una calidad de página deficiente en cualquier solución de documentación. Anteriormente en Wiki, al mover una página dentro de la estructura de árbol o cambiar el nombre de una página, podría interrumpir los vínculos a la página desde otras páginas y elementos de trabajo. Ahora, puede buscar y corregir vínculos antes de que se rompa.

Importante

Recuerde usar la sintaxis de Markdown para los vínculos de las páginas y el tipo de vínculo de página Wiki en elementos de trabajo para permitir que Wiki encuentre y corrija estos vínculos potencialmente []() rotos. Esta característica no recogerá las direcciones URL de texto sin formato ni los hipervínculos de los elementos de trabajo.

Al cambiar el nombre o mover una página, se le pedirá que compruebe si hay vínculos absolutos o relativos afectados.

Cuadro de diálogo Mover página

A continuación, se mostrará una lista de los vínculos de página y los elementos de trabajo afectados antes de tomar medidas.

Mover vínculos de página

Creación de una tabla de contenido para páginas wiki

A veces, las páginas wiki pueden ser largas, con contenido organizado en varios encabezados. Ahora puede agregar una tabla de contenido a cualquier página que tenga al menos un encabezado mediante la [[_TOC_]] sintaxis .

Tabla de contenido de wiki

También puede insertar la tabla de contenido haciendo clic en el botón adecuado en el panel de formato al editar la página.

Inserción de LA C TOC de wiki

Consulte la documentación de la guía de Markdown para obtener más información sobre el uso de Markdown en Azure DevOps.

Metadatos de Surface para páginas wiki y vista previa de código mediante etiquetas YAML

La adición de metadatos a la documentación puede ayudar a los lectores y a los índices de búsqueda a seleccionar y a presentar contenido significativo. En esta actualización, cualquier archivo que contenga un bloque YAML al principio del archivo se transformará en una tabla de metadatos de un encabezado y una fila. El bloque YAML debe tener la forma de un conjunto de YAML válido entre líneas de tres guiones. Admite todos los tipos de datos básicos, list y object como valor. La sintaxis se admite en wiki y en la versión preliminar del archivo de código.

Ejemplo de etiquetas YAML:

---
tag: post
title: Hello world
---

Tabla YAML

Ejemplo de etiquetas YAML con lista:

---
tags:
- post
- code
- web
title: Hello world
---

Tabla YAML con lista

Publicación de código como wiki con permisos de contribución

Anteriormente, solo los usuarios que tenían el permiso Crear repositorio en un repositorio git eran capaces de publicar código como wiki. Esto hizo que los administradores o creadores del repositorio se convertira en un cuello de botella para las solicitudes de publicación de archivos Markdown hospedados en repositorios git como wikis. Ahora, puede publicar código como wiki si solo tiene el permiso Contribuir en el repositorio de código.

Generación de informes

La extensión de Marketplace de Analytics para informes ya está disponible

La extensión Analytics Marketplace ya está disponible para Azure DevOps Server. Analytics es el futuro de la generación de informes Azure DevOps y Azure DevOps Server. La instalación de la extensión analytics proporciona widgetsavanzados, Power BI integración yacceso a OData.

Para obtener más información, consulte ¿Qué es Analytics y la hoja de ruta de informes? Analytics está en versión preliminar pública. Actualmente contiene datos para paneles y resultados de pruebas automatizadas a través de canalizaciones. Consulte Datos disponibles en el servicio Analytics.

Investigación del historial de compilación a través de un nuevo widget de panel de compilación

Tenemos un widget de historial de compilación nuevo y mejorado que puede agregar a los paneles. Con este widget, ahora puede ver un historial de compilaciones de una rama específica en el panel y configurarlo en un proyecto público para visitantes anónimos.

Importante

Si busca información sobre las compilaciones XAML, siga usando el widget anterior y lea sobre cómo migrar de compilaciones XAML a nuevas compilaciones. De lo contrario, se recomienda pasar al widget más reciente.


Comentarios

Nos encantaría que nos diera su opinión. Puede notificar un problema o proporcionar una idea y realizar un seguimiento de Developer Community y obtener consejos sobre Stack Overflow.


Principio de página