Notas de la versión de Azure DevOps Server 2022 Update 1

---

| Developer Community Configuración del sistema | ytérminos | de licencia de compatibilidad | DevOps Blog | SHA-256 Hashes |

---

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

Para obtener más información sobre cómo instalar o actualizar una implementación de Azure DevOps Server, consulte .

Para descargar Azure DevOps Server productos, visite la página descargas de Azure DevOps Server.

La actualización directa a Azure DevOps Server 2022 Update 1 es compatible con Azure DevOps Server 2019 o Team Foundation Server 2015 o versiones posteriores. Si la implementación de TFS está en TFS 2013 o versiones anteriores, debe realizar algunos pasos provisionales antes de actualizar a Azure DevOps Server 2022. Consulte la página Instalar para obtener más información.

---

Azure DevOps Server 2022 Update 1 Patch 3 Fecha de lanzamiento: 12 de marzo de 2024

Archivo	Hash SHA-256
devops2022.1patch3.exe	E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Hemos publicado la revisión 3 para Azure DevOps Server actualización 2022 1 que incluye correcciones para lo siguiente.

• Se ha resuelto un problema por el que el servidor proxy dejaba de funcionar después de instalar la revisión 2.
• Se ha corregido un problema de representación en la página de detalles de la extensión que afectaba a los idiomas que no eran inglés.

Azure DevOps Server 2022 Update 1 Patch 2 Release Date: 13 de febrero de 2024

Archivo	Hash SHA-256
devops2022.1patch2.exe	59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

Hemos publicado la revisión 2 para Azure DevOps Server 2022 Update 1 que incluye correcciones para lo siguiente.

• Corrección del problema de representación de páginas de detalles en la extensión de búsqueda.
• Se ha corregido un error por el que el espacio en disco utilizado por la carpeta de caché de proxy se calculaba incorrectamente y la carpeta no se limpiaba correctamente.
• CVE-2024-20667: Azure DevOps Server vulnerabilidad de ejecución remota de código.

Azure DevOps Server 2022 Update 1 Patch 1 Release Date: 12 de diciembre de 2023

Archivo	Hash SHA-256
devops2022.1patch1.exe	9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

Hemos publicado la revisión 1 para Azure DevOps Server 2022 Update 1 que incluye correcciones para lo siguiente.

• Impedir la configuración requested for al poner en cola una ejecución de canalización.

Azure DevOps Server fecha de lanzamiento de la actualización 1 de Azure DevOps Server 2022: 28 de noviembre de 2023

Nota

Hay dos problemas conocidos con esta versión:

1. La versión del agente no se actualiza después de actualizar a Azure DevOps Server 2022.1 y mediante El agente de actualización en la configuración del grupo de agentes. Actualmente estamos trabajando en una revisión para resolver este problema y compartiremos actualizaciones en el Developer Community a medida que avancemos. Mientras tanto, puede encontrar una solución alternativa para este problema en este vale de Developer Community.
2. Compatibilidad con Maven 3.9.x. Maven 3.9.x introdujo cambios importantes con Azure Artifacts mediante la actualización del transporte predeterminado de Maven Resolver a HTTP nativo desde Wagon. Esto provoca problemas de autenticación 401 para los clientes que usan http, en lugar de https. Puede encontrar más detalles sobre este problema aquí. Como solución alternativa, puede seguir usando Maven 3.9.x con la propiedad -Dmaven.resolver.transport=wagon. Este cambio obliga a Maven a usar el transporte de resolución de carros. Consulte la documentación aquí para obtener más detalles.

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

Nota

Hay un problema conocido con la compatibilidad de Maven 3.9.x. Maven 3.9.x introdujo cambios importantes con Azure Artifacts mediante la actualización del transporte predeterminado de Maven Resolver a HTTP nativo desde Wagon. Esto provoca problemas de autenticación 401 para los clientes que usan http, en lugar de https. Puede encontrar más detalles sobre este problema aquí.

Como solución alternativa, puede seguir usando Maven 3.9.x con la propiedad -Dmaven.resolver.transport=wagon. Este cambio obliga a Maven a usar el transporte de resolución de carros. Consulte la documentación aquí para obtener más detalles.

Azure DevOps Server 2022 Update 1 RC2 Fecha de lanzamiento: 31 de octubre de 2023

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

Nota

Hay un problema conocido con la compatibilidad de Maven 3.9.x. Maven 3.9.x introdujo cambios importantes con Azure Artifacts mediante la actualización del transporte predeterminado de Maven Resolver a HTTP nativo desde Wagon. Esto provoca problemas de autenticación 401 para los clientes que usan http, en lugar de https. Puede encontrar más detalles sobre este problema aquí.

Como solución alternativa, puede seguir usando Maven 3.9.x con la propiedad -Dmaven.resolver.transport=wagon. Este cambio obliga a Maven a usar el transporte de resolución de carros. Consulte la documentación aquí para obtener más detalles.

Se ha corregido lo siguiente con esta versión:

• Se ha corregido un problema en las fuentes locales en las que las entradas ascendentes no resolvían los cambios de nombre para mostrar.
• Se produjo un error inesperado al cambiar las pestañas de Código a otra pestaña de la página Buscar.
• Error al crear un nuevo tipo de elemento de trabajo con ideógrafos unificados chinos, japoneses y coreanos (CJK). Se mostró un signo de interrogación en el registro RAW en el registro gated cuando el nombre o los archivos del proyecto de equipo incluían CJK.
• Se ha corregido un problema durante la instalación de la búsqueda en la que la máquina virtual Java (JVM) no podía asignar memoria suficiente al proceso de búsqueda elástica. El widget de configuración de búsqueda usará ahora el Kit de desarrollo de Java (JDK) que se incluye con Elastic Search y, por tanto, elimina la dependencia de cualquier entorno en tiempo de ejecución de Java (JRE) preinstalado en el servidor de destino.

Azure DevOps Server fecha de lanzamiento de la actualización 1 RC1 de Azure DevOps Server 2022: 19 de septiembre de 2023

Azure DevOps Server 2022.1 RC1 incluye muchas características nuevas. Entre los aspectos destacados se incluyen:

• Todas las API rest públicas admiten ámbitos pat granulares
• Última columna a la que se ha accedido en la página Planes de entrega
• Visualización de todas las dependencias en los planes de entrega
• macro de @CurrentIteration en planes de entrega
• El proyecto actual se establece como ámbito predeterminado para el token de acceso de compilación en canalizaciones clásicas.
• Mostrar elemento primario en el widget de resultados de la consulta
• Copiar panel
• Compatibilidad con tipos de diagrama adicionales en páginas wiki
• Las conexiones del servicio Container Registry ahora pueden usar identidades administradas de Azure

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

• General
• Boards
• Repos
• Canalizaciones
• Artefactos
• Informes
• Wiki

---

General

Todas las API rest públicas admiten ámbitos pat granulares

Anteriormente, una serie de API REST de Azure DevOps documentadas públicamente no estaban asociadas a ámbitos (por ejemplo, lectura de elementos de trabajo) que llevaron a los clientes a usar ámbitos completos para consumir estas API a través de mecanismos de autenticación no interactivos, como tokens de acceso personal (PAT). El uso de un token de acceso personal de ámbito completo aumenta el riesgo cuando pueden llegar a manos de un usuario malintencionado. Esta es una de las principales razones por las que muchos de nuestros clientes no aprovecharon al máximo las directivas del plano de control para restringir el uso y el comportamiento del PAT.

Ahora, todas las API REST públicas de Azure DevOps ahora están asociadas y admiten un ámbito pat granular. Si actualmente usa un PAT de ámbito completo para autenticarse en una de las API rest de Azure DevOps públicas, considere la posibilidad de migrar a un PAT con el ámbito específico aceptado por la API para evitar el acceso innecesario. Los ámbitos de PAT granulares admitidos para una API REST determinada se pueden encontrar en la sección Seguridad de las páginas de documentación. Además, hay una tabla de ámbitos aquí.

Las extensiones deben mostrar sus ámbitos

Al instalar extensiones en la colección de Azure DevOps, puede revisar los permisos que necesita la extensión como parte de la instalación. Sin embargo, una vez instalados, los permisos de extensión no son visibles en la configuración de la extensión. Esto ha planteado un desafío para los administradores que necesitan realizar una revisión periódica de las extensiones instaladas. Ahora, hemos agregado los permisos de extensión a la configuración de extensión para ayudarle a revisar y tomar una decisión informada sobre si desea mantenerlos o no.

Boards

Última columna a la que se ha accedido en la página Planes de entrega

La página del directorio Planes de entrega proporciona una lista de los planes definidos para el proyecto. Puede ordenar por: Nombre, Creado por, Descripción, Última configuración o Favoritos. Con esta actualización, hemos agregado una columna Última a la que se ha accedido a la página del directorio. Esto proporciona visibilidad sobre cuándo se abrió por última vez un plan de entrega y se miró. Como resultado, es fácil identificar los planes que ya no se usan y se pueden eliminar.

Visualización de todas las dependencias en los planes de entrega

Los planes de entrega siempre han proporcionado la capacidad de ver las dependencias entre los elementos de trabajo. Puede visualizar las líneas de dependencia, una por una. Con esta versión, hemos mejorado la experiencia al permitirle ver todas las líneas de dependencia en todos los elementos de trabajo en la pantalla. Simplemente haga clic en el botón de alternancia dependencias en la parte superior derecha del plan de entrega. Vuelva a hacer clic en él para desactivar las líneas.

Nuevos límites de revisión de elementos de trabajo

En los últimos años, hemos visto que las colecciones de proyectos con herramientas automatizadas generan decenas de miles de revisiones de elementos de trabajo. Esto crea problemas con el rendimiento y la facilidad de uso en el formulario del elemento de trabajo y las API REST de informes. Para mitigar el problema, hemos implementado un límite de revisión de elemento de trabajo de 10 000 en Azure DevOps Service. El límite solo afecta a las actualizaciones que usan la API REST, no al formulario del elemento de trabajo.

Haga clic aquí para obtener más información sobre el límite de revisiones y cómo controlarlo en las herramientas automatizadas.

Aumentar el límite del equipo de planes de entrega de 15 a 20

Los planes de entrega le permiten ver varios trabajos pendientes y varios equipos en la colección de proyectos. Anteriormente, podía ver 15 trabajos pendientes de equipo, incluida una combinación de trabajos pendientes y equipos de proyectos diferentes. Con esta versión hemos aumentado el límite máximo de 15 a 20.

Se ha corregido un error en la API de obtención de vínculos de elementos de trabajo de informes.

Se ha corregido un error en la API Get de vínculos de elementos de trabajo de informes para devolver el valor remoteUrl correcto para System.LinkTypes.Remote.Related los tipos de vínculo. Antes de esta corrección, devolvíamos el nombre de la colección de proyectos incorrecto y un identificador de proyecto que faltaba.

Creación de un punto de conexión REST de consulta temporal

Hemos visto varias instancias de autores de extensiones que intentan ejecutar consultas no guardadas pasando la instrucción Del lenguaje de consulta de elementos de trabajo (WIQL) a través de la cadena de consulta. Esto funciona bien a menos que tenga una instrucción WIQL grande que alcance los límites del explorador en la longitud de la cadena de consulta. Para resolver esto, hemos creado un nuevo punto de conexión REST para permitir que los autores de herramientas generen una consulta temporal. El uso del identificador de la respuesta para pasar a través de querystring elimina este problema.

Obtenga más información en la página de documentación de la API rest de consultas temporales.

API de eliminación por lotes

Actualmente, la única manera de quitar elementos de trabajo de la papelera de reciclaje es usar esta API REST para eliminarlos de uno en uno. Esto puede ser un proceso lento y está sujeto a limitación de velocidad al intentar realizar cualquier tipo de limpieza masiva. En respuesta, hemos agregado un nuevo punto de conexión de la API REST para eliminar o destruir elementos de trabajo por lotes.

@CurrentIteration macro en Planes de entrega

Con esta actualización, hemos agregado compatibilidad con la @CurrentIteration macro para los estilos en Planes de entrega. Esta macro le permitirá obtener la iteración actual del contexto de equipo de cada fila del plan.

Lógica de cambio de tamaño de tarjeta en planes de entrega

No todos usan la fecha de destino o la fecha de inicio al realizar el seguimiento de características y epopeyas. Algunos eligen usar una combinación de fechas y ruta de acceso de iteración. En esta versión, se ha mejorado la lógica para establecer correctamente las combinaciones de ruta de acceso de iteración y campo de fecha en función de cómo se usen.

Por ejemplo, si no se usa la fecha de destino y cambia el tamaño de la tarjeta, se establece la nueva ruta de acceso de iteración en lugar de actualizar la fecha de destino.

Mejoras en la actualización por lotes

Hemos realizado varios cambios en la versión 7.1 de la API de actualización por lotes de elementos de trabajo. Entre ellas se incluyen mejoras de rendimiento menores y el control de errores parciales. Es decir, si se produce un error en una revisión, pero las demás no, las demás se completarán correctamente.

Haga clic aquí para obtener más información sobre la API REST de actualización por lotes.

API de eliminación por lotes

Este nuevo punto de conexión de la API REST para eliminar o destruir elementos de trabajo en lote ahora está disponible públicamente. Haga clic aquí para más información.

Impedir la edición de campos de listas de selección que se pueden compartir

Los campos personalizados se comparten entre procesos. Esto puede crear un problema para los campos de lista desplegable porque se permite que los administradores de procesos agreguen o quiten valores del campo. Al hacerlo, los cambios afectan a ese campo en cada proceso que lo usa.

Para solucionar este problema, hemos agregado la posibilidad de que el administrador de la colección "bloquee" un campo de que se edite. Cuando el campo picklist está bloqueado, el administrador del proceso local no puede cambiar los valores de esa lista de selección. Solo pueden agregar o quitar el campo del proceso.

Nuevo permiso para guardar comentarios

La capacidad de guardar solo los comentarios de elementos de trabajo ha sido una solicitud principal en la comunidad de desarrolladores. Nos complace informarle de que hemos implementado esta característica. Para empezar, vamos a revisar el escenario más común:

"Quiero impedir que algunos usuarios editen campos de elementos de trabajo, pero les permita contribuir a la discusión".

Para ello, debe ir a Configuración > del proyecto Ruta de acceso del área de configuración > del proyecto. A continuación, seleccione la ruta de acceso de área que prefiera y haga clic en Seguridad.

Observe el nuevo permiso "Editar comentarios de elementos de trabajo en este nodo". De forma predeterminada, el permiso se establece en No establecido. Es decir, el elemento de trabajo se comportará exactamente igual que antes. Para permitir que un grupo o usuarios guarden comentarios, seleccione ese grupo o usuarios y cambie el permiso a Permitir.

Cuando el usuario abra el formulario de elemento de trabajo en esta ruta de acceso de área, podrá agregar comentarios, pero no podrá actualizar ninguno de los demás campos.

Esperamos que amas esta característica tanto como nosotros. Como siempre, si tiene algún comentario o sugerencia, háganoslo saber.

Informes de paneles interactivos

Los informes interactivos, ubicados en el centro de paneles, han sido accesibles durante varios años en nuestra versión hospedada del producto. Reemplazan los antiguos diagramas de flujo acumulativo, Velocidad y Evolución del sprint. Con esta versión, estamos haciendo que estén disponibles.

Para ver estos gráficos, haga clic en la ubicación de la pestaña Análisis en las páginas Panel Kanban, Trabajo pendiente y Sprints.

Repos

Eliminación del permiso "Editar directivas" al creador de la rama

Anteriormente, al crear una nueva rama, se le concede permiso para editar directivas en esa rama. Con esta actualización, estamos cambiando el comportamiento predeterminado para que no se conceda este permiso aunque la configuración "Administración de permisos" esté activada para el repositorio.

Necesitará que se le conceda el permiso "Editar directivas" explícitamente (ya sea manualmente o a través de la API de REST) mediante la herencia de permisos de seguridad o a través de la pertenencia a grupos.

Pipelines

El proyecto actual se establece como ámbito predeterminado para el token de acceso de compilación en canalizaciones clásicas

Azure Pipelines usa tokens de acceso de trabajo para acceder a otros recursos de Azure DevOps en tiempo de ejecución. Un token de acceso de trabajo es un token de seguridad generado dinámicamente por Azure Pipelines para cada trabajo en tiempo de ejecución. Anteriormente, al crear una canalización clásica, el valor predeterminado para el token de acceso se estableció en Project Collection. Con esta actualización, se establece el ámbito de autorización del trabajo en el proyecto actual como predeterminado al crear una nueva canalización clásica.

Puede encontrar más detalles sobre los tokens de acceso al trabajo en la documentación de repositorios, artefactos y otros recursos de Access.

Cambio en el ámbito predeterminado de los tokens de acceso en canalizaciones de compilación clásicas

Para mejorar la seguridad de las canalizaciones de compilación clásicas, al crear una nueva, el ámbito de autorización del trabajo de compilación será Project de forma predeterminada. Hasta ahora, solía ser Colección de proyectos. Obtenga más información sobre los tokens de acceso al trabajo. Este cambio no afecta a ninguna de las canalizaciones existentes. Solo afecta a las nuevas canalizaciones de compilación clásicas que se crean desde este punto.

Compatibilidad de Azure Pipelines con las versiones de San Diego, Tokio & Utah de ServiceNow

Azure Pipelines tiene una integración existente con ServiceNow. La integración se basa en una aplicación de ServiceNow y una extensión en Azure DevOps. Ahora hemos actualizado la aplicación para trabajar con las versiones de San Diego, Tokio & Utah de ServiceNow. Para asegurarse de que esta integración funciona, actualice a la nueva versión de la aplicación (4.215.2) desde el almacén de ServiceNow.

Para obtener más información, consulte la documentación integración con La administración de cambios de ServiceNow.

Uso de direcciones URL de proxy para la integración de GitHub Enterprise

Azure Pipelines se integra con servidores de GitHub Enterprise locales para ejecutar compilaciones continuas de integración y pr. En algunos casos, GitHub Enterprise Server está detrás de un firewall y requiere que el tráfico se enrute a través de un servidor proxy. Para admitir este escenario, las conexiones de servicio de GitHub Enterprise Server en Azure DevOps le permiten configurar una dirección URL de proxy. Anteriormente, no todo el tráfico de Azure DevOps se enrutaba a través de esta dirección URL del proxy. Con esta actualización, nos aseguramos de que enrutamos el siguiente tráfico desde Azure Pipelines para pasar por la dirección URL del proxy:

• Obtención de ramas
• Obtención de información de solicitud de incorporación de cambios
• Notificar estado de la compilación

Las conexiones del servicio Container Registry ahora pueden usar identidades administradas de Azure

Puede usar una identidad administrada asignada por el sistema al crear conexiones de servicio del Registro de Docker para Azure Container Registry. Esto le permite acceder a Azure Container Registry mediante una identidad administrada asociada a un agente de Azure Pipelines autohospedado, lo que elimina la necesidad de administrar las credenciales.

Nota

La identidad administrada que se usa para acceder a Azure Container Registry necesitará la asignación de Access Control basada en roles de Azure (RBAC), por ejemplo, el rol AcrPull o AcrPush adecuado.

Tokens automáticos creados para la conexión de Kubernetes Service

Desde Kubernetes 1.24, los tokens ya no se crearon automáticamente al crear una nueva conexión de Kubernetes Service. Hemos vuelto a agregar esta funcionalidad. Sin embargo, se recomienda usar la conexión de servicio de Azure al acceder a AKS, para más información, consulte la entrada de blog Guía de conexión de servicio para clientes de AKS que usan tareas de Kubernetes.

Las tareas de Kubernetes ahora admiten kubelogin

Hemos actualizado las tareas de KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 y AzureFunctionOnKubernetes@1 para admitir kubelogin. Esto le permite dirigirse a Azure Kubernetes Service (AKS) configurado con la integración de Azure Active Directory.

Kubelogin no está preinstalado en imágenes hospedadas. Para asegurarse de que las tareas mencionadas anteriormente usan kubelogin, instálela insertando la tarea KubeloginInstaller@0 antes de la tarea que depende de ella:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Mejoras en la experiencia de los permisos de canalización

Hemos mejorado la experiencia sobre la administración de permisos de canalización para que el sistema de permisos recuerde si una canalización había usado previamente un recurso protegido, como una conexión de servicio.

En el pasado, si desactivó "Conceder permiso de acceso a todas las canalizaciones" al crear un recurso protegido, pero después restringió el acceso al recurso, la canalización necesitaba una nueva autorización para usar el recurso. Este comportamiento era incoherente con el acceso de apertura y cierre posteriores al recurso, donde no se requería una nueva autorización. Esto se ha corregido.

Nuevo ámbito pat para administrar la autorización y las aprobaciones de canalización y comprobaciones

Para limitar los daños causados por la pérdida de un token PAT, hemos agregado un nuevo ámbito pat, denominado Pipeline Resources. Puede usar este ámbito pat al administrar la autorización de canalización mediante un recurso protegido, como una conexión de servicio, o para administrar aprobaciones y comprobaciones de ese recurso.

Las siguientes llamadas API REST admiten el nuevo ámbito PAT de la siguiente manera:

• Actualizar una aprobación admite el ámbito Pipeline Resources Use
• Administrar comprobaciones admite el ámbito Pipeline Resources Use and Manage
• Actualizar permisos de canalización para recursos admite el ámbito Pipeline Resources Use and Manage
• Autorizar recursos de definición admite el ámbito Pipeline Resources Use and Manage
• Autorizar recursos del proyecto admite el ámbito Pipeline Resources Use and Manage

Restricción de la apertura de recursos protegidos a los administradores de recursos

Para mejorar la seguridad de los recursos críticos para la capacidad de compilar e implementar aplicaciones de forma segura, Azure Pipelines ahora requiere el rol de administrador de tipo de recurso al abrir el acceso a un recurso a todas las canalizaciones.

Por ejemplo, se requiere un rol de administrador de Connections de servicio general para permitir que cualquier canalización use una conexión de servicio. Esta restricción se aplica al crear un recurso protegido o al editar su configuración de seguridad.

Además, al crear una conexión de servicio y no tiene derechos suficientes, la opción Conceder permiso de acceso a todas las canalizaciones está deshabilitada.

También, al intentar abrir el acceso a un recurso existente y no tiene derechos suficientes, obtendrá un que no está autorizado para abrir el acceso para este mensaje de recurso.

Mejoras en la seguridad de la API REST de canalizaciones

La mayoría de las API REST de Azure DevOps usan tokens pat con ámbito. Sin embargo, algunos de ellos requieren tokens pat de ámbito completo. En otras palabras, tendría que crear un token PAT seleccionando "Acceso completo" para usar algunas de estas API. Estos tokens suponen un riesgo de seguridad, ya que se pueden usar para llamar a cualquier API rest. Hemos realizado mejoras en Azure DevOps para quitar la necesidad de tokens de ámbito completo mediante la incorporación de cada API REST a un ámbito específico. Como parte de este esfuerzo, la API REST para actualizar los permisos de canalización de un recurso ahora requiere un ámbito específico. El ámbito depende del tipo de recurso que se autoriza para su uso:

• Code (read, write, and manage) para los recursos de tipo repository
• Agent Pools (read, manage) o Environment (read, manage) para los recursos de tipo queue y agentpool
• Secure Files (read, create, and manage) para los recursos de tipo securefile
• Variable Groups (read, create and manage) para los recursos de tipo variablegroup
• Service Endpoints (read, query and manage) para los recursos de tipo endpoint
• Environment (read, manage) para los recursos de tipo environment

Para editar de forma masiva los permisos de canalizaciones, seguirá necesitando un token pat de ámbito completo. Para más información sobre cómo actualizar los permisos de canalización para los recursos, consulte la documentación Permisos de canalización: actualizar permisos de canalización para recursos .

Administración de acceso específica para grupos de agentes

Los grupos de agentes permiten especificar y administrar las máquinas en las que se ejecutan las canalizaciones.

Anteriormente, si usaba un grupo de agentes personalizado, administrando las canalizaciones a las que se puede acceder era general. Podría permitir que todas las canalizaciones la usen, o bien podría requerir que cada canalización solicite permiso. Desafortunadamente, una vez que concedió un permiso de acceso de canalización a un grupo de agentes, no se pudo revocar mediante la interfaz de usuario de canalizaciones.

Azure Pipelines ahora proporciona una administración de acceso específica para los grupos de agentes. La experiencia es similar a la que se usa para administrar permisos de canalización para Service Connections.

Impedir la concesión de acceso a todas las canalizaciones a recursos protegidos

Al crear un recurso protegido, como una conexión de servicio o un entorno, tiene la opción de activar la casilla Conceder permiso de acceso a todas las canalizaciones . Hasta ahora, esta opción se ha activado de forma predeterminada.

Aunque esto facilita que las canalizaciones usen nuevos recursos protegidos, lo contrario es que favorece la concesión accidental de demasiadas canalizaciones al derecho de acceder al recurso.

Para promover una opción segura de forma predeterminada, Azure DevOps deja ahora la casilla desactivada.

Capacidad de deshabilitar el enmascaramiento para secretos cortos

Azure Pipelines enmascara los secretos en los registros. Los secretos pueden ser variables marcadas como secretas, variables de grupos de variables vinculados a Azure Key Vault o elementos de una conexión de servicio marcadas como secretas por el proveedor de conexión de servicio.

Todas las apariciones del valor secreto se enmascaran. Enmascarar secretos cortos, por ejemplo, '1', '2', 'Dev' facilita la adivinación de sus valores, por ejemplo, en una fecha: 'Jan 3, 202***'
Ahora está claro que '3' es un secreto. En tales casos, es posible que prefiera no enmascarar el secreto por completo. Si no es posible no marcar el valor como secreto (por ejemplo, el valor se toma de Key Vault), puede establecer el AZP_IGNORE_SECRETS_SHORTER_THAN perilla en un valor de hasta 4.

Tarea de descarga del ejecutor de nodos

Al adoptar versiones de agente que excluyen el ejecutor de tareas de Node 6 , es posible que tenga que ejecutar tareas ocasionales que no se han actualizado para usar un ejecutor de Nodos más reciente. En este escenario se proporciona un método para seguir usando tareas dependientes de los ejecutores de fin de vida del nodo, consulte la entrada de blog Guía del ejecutor de nodos.

La tarea siguiente es un método para instalar el ejecutor Just-In-Time de Node 6, por lo que una tarea antigua todavía se puede ejecutar:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

Validación actualizada del ejecutor de nodos de TFX

Los autores de tareas usan la herramienta de empaquetado de extensiones (TFX) para publicar extensiones. TFX se ha actualizado para realizar validaciones en las versiones del ejecutor de Node. Consulte la entrada de blog Guía del ejecutor de nodos.

Las extensiones que contienen tareas que usan el ejecutor de Node 6 verán esta advertencia:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Instrucciones para la preinstalación manual de Node 6 en agentes de canalización

Si usa la fuente del pipeline- agente, no tiene el nodo 6 incluido en el agente. En algunos casos, cuando una tarea de Marketplace todavía depende del nodo 6 y el agente no puede usar la tarea NodeTaskRunnerInstaller (por ejemplo, debido a restricciones de conectividad), deberá preinstalar el nodo 6 de forma independiente. Para ello, consulte las instrucciones sobre cómo instalar el ejecutor del nodo 6 manualmente.

Registro de cambios de tareas de canalización

Ahora publicamos cambios en las tareas de canalización en este registro de cambios. Contiene la lista completa de los cambios realizados en las tareas de canalización integradas. Hemos publicado de forma retroactiva los cambios anteriores, por lo que el registro de cambios proporciona un registro histórico de las actualizaciones de tareas.

Las tareas de versión usan Microsoft Graph API

Hemos actualizado nuestras tareas de versión para usar microsoft Graph API. Esto quita el uso del Graph API de AAD de nuestras tareas.

Windows PowerShell mejora del rendimiento de tareas

Puede usar tareas para definir la automatización en una canalización. Una de estas tareas es la PowerShell@2 tarea de utilidad que le permite ejecutar scripts de PowerShell en la canalización. Para usar el script de PowerShell para tener como destino un entorno de Azure, puede usar la AzurePowerShell@5 tarea . Algunos comandos de PowerShell que pueden imprimir actualizaciones de progreso, por ejemplo Invoke-WebRequest, ahora se ejecutan más rápido. La mejora es más significativa si tiene muchos de estos comandos en el script o cuando se ejecutan de forma prolongada. Con esta actualización, la progressPreference propiedad de las PowerShell@2 tareas y AzurePowerShell@5 ahora está establecida SilentlyContinue en de forma predeterminada.

Agente de canalizaciones v3 en .NET 6

El agente de canalización se ha actualizado para usar .NET 3.1 Core a .NET 6 como entorno de ejecución. Esto presenta compatibilidad nativa con Apple Silicon y Windows Arm64.

El uso de .NET 6 afecta a los requisitos del sistema para el agente. En concreto, eliminamos la compatibilidad con los siguientes sistemas operativos: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Consulte la documentación de la versión 3 del software del agente.

Este script se puede usar para identificar canalizaciones que usan agentes con sistemas operativos no admitidos.

Importante

Tenga en cuenta que los agentes que se ejecutan en cualquiera de los sistemas operativos anteriores ya no se actualizarán o producirán errores una vez que implementemos el agente basado en .NET 6.

Especificación de la versión del agente en la extensión de máquina virtual del agente

Las máquinas virtuales de Azure se pueden incluir en grupos de implementación mediante una extensión de máquina virtual. La extensión de máquina virtual se ha actualizado para especificar opcionalmente la versión deseada del agente que se va a instalar:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Nuevas alternancias para controlar la creación de canalizaciones clásicas

Azure DevOps ahora le permite asegurarse de que la colección de proyectos solo usa canalizaciones YAML, ya que deshabilita la creación de canalizaciones de compilación clásicas, canalizaciones de versión clásicas, grupos de tareas y grupos de implementación. Las canalizaciones clásicas existentes seguirán ejecutándose y podrá editarlas, pero no podrá crear otras nuevas.

Azure DevOps ahora le permite asegurarse de que su organización solo usa canalizaciones YAML, ya que deshabilita la creación de canalizaciones de compilación clásicas, canalizaciones de versión clásicas, grupos de tareas y grupos de implementación. Las canalizaciones clásicas existentes seguirán ejecutándose y podrá editarlas, pero no podrá crear otras nuevas.

Puede deshabilitar la creación de canalizaciones clásicas en el nivel de colección de proyectos o en el nivel de proyecto activando los botóns de alternancia correspondientes. Los botóns de alternancia se pueden encontrar en Project/Project Settings - Pipelines -> Settings (Configuración del proyecto/ Canalizaciones:> configuración). Hay dos alternancias: una para canalizaciones de compilación clásicas y otra para canalizaciones de versión clásicas, grupos de implementación y grupos de tareas.

El estado de alternancia está desactivado de forma predeterminada y necesitará derechos de administrador para cambiar el estado. Si el botón de alternancia está activado en el nivel de organización, se aplica la deshabilitación para todos los proyectos. De lo contrario, cada proyecto es libre de elegir si se debe aplicar o no la deshabilitación.

Al deshabilitar la creación de canalizaciones clásicas, se producirá un error en las API REST relacionadas con la creación de canalizaciones clásicas, grupos de tareas y grupos de implementación. Las API REST que crean canalizaciones YAML funcionarán.

Novedades al evento de enlace de servicio "Run stage state changed" (Ejecutar estado de fase cambiado)

Los enlaces de servicio permiten ejecutar tareas en otros servicios cuando se producen eventos en el proyecto en Azure DevOps, el estado de fase de ejecución cambiado es uno de estos eventos. El evento Run stage state changed debe contener información sobre la ejecución, incluido el nombre de la canalización. Anteriormente, solo incluía información sobre el identificador y el nombre de la ejecución. Con esta actualización, hemos realizado cambios en el evento para incluir información que falta.

Deshabilitación que muestra el último mensaje de confirmación para una ejecución de canalización

Anteriormente, la interfaz de usuario de Pipelines usaba para mostrar el último mensaje de confirmación al mostrar la ejecución de una canalización.

Este mensaje puede resultar confuso, por ejemplo, cuando el código de la canalización de YAML reside en un repositorio diferente del que contiene el código que está compilando. Hemos oído sus comentarios de la Developer Community nos pide una manera de habilitar o deshabilitar la anexión del mensaje de confirmación más reciente al título de cada ejecución de canalización.

Con esta actualización, hemos agregado una nueva propiedad YAML, denominada appendCommitMessageToRunName, que le permite hacer exactamente eso. De forma predeterminada, la propiedad se establece en true. Cuando se falseestablece en , la ejecución de la canalización solo mostrará .BuildNumber

Se han aumentado los límites de Azure Pipeline para alinearse con el tamaño máximo de plantilla de Azure Resource Manager (ARM) de 4 MB.

Puede usar la tarea Implementación de plantillas de Azure Resource Manager para crear la infraestructura de Azure. En respuesta a sus comentarios, hemos aumentado el límite de integración de Azure Pipelines de 2 MB a 4 MB. Esto se alineará con el tamaño máximo de las plantillas de ARM de 4 MB resolviendo restricciones de tamaño durante la integración de plantillas grandes.

Icono de información general sobre el estado de ejecución de la canalización

Con esta versión, es más fácil conocer el estado general de una ejecución de canalización.

En el caso de las canalizaciones YAML que tienen muchas fases, solía ser difícil conocer el estado de una ejecución de canalización, es decir, si todavía se está ejecutando o ha finalizado. Y si ha finalizado, cuál es el estado general: correcto, erróneo o cancelado. Hemos corregido este problema agregando un icono de información general de estado de ejecución.

Panel lateral fases de canalización

Las canalizaciones yaML pueden tener decenas de fases y no todas ellas caben en la pantalla. Aunque el icono de información general de la ejecución de la canalización indica el estado general de la ejecución, sigue siendo difícil saber qué fase ha fallado o qué fase todavía se está ejecutando, por ejemplo.

En esta versión, hemos agregado un panel lateral de fases de canalización que le permite ver rápidamente el estado de todas las fases. A continuación, puede hacer clic en una fase y acceder directamente a sus registros.

Buscar fases en el panel lateral

Hemos facilitado la búsqueda de las fases que busca en el panel lateral de las fases. Ahora puede filtrar rápidamente las fases en función de su estado, por ejemplo, las fases en ejecución o las que requieren intervención manual. También puede buscar fases por su nombre.

Fase de acciones rápidas

La pantalla Ejecuciones de una canalización proporciona acceso rápido a todas las fases de ejecución. En esta versión, hemos agregado un panel de fases desde donde puede realizar acciones para cada fase. Por ejemplo, puede volver a ejecutar fácilmente trabajos con errores o volver a ejecutar toda la fase. El panel está disponible cuando no todas las fases caben en la interfaz de usuario, como puede ver en la captura de pantalla siguiente.

Al hacer clic en el inicio de sesión "+" en la columna fases, se muestra el panel de fases y, a continuación, puede realizar acciones de fase.

Comprueba las mejoras de la experiencia del usuario.

Estamos haciendo que la lectura de los registros sea más fácil. Los registros de comprobaciones proporcionan información crítica para el éxito de la implementación. Pueden avisarle si olvidó cerrar un vale de elemento de trabajo, o si necesita actualizar un vale en ServiceNow. Anteriormente, sabiendo que una comprobación proporcionó dicha información crítica era difícil.

Ahora, la página de detalles de la ejecución de la canalización muestra el registro de comprobación más reciente. Esto es solo para comprobaciones que siguen nuestro uso recomendado.

Para evitar aprobaciones aprobadas por error, Azure DevOps muestra las instrucciones para los aprobadores en el panel del lado Aprobaciones y comprobaciones de la página de detalles de una ejecución de canalización.

Deshabilitar una comprobación

Hemos realizado comprobaciones de depuración menos tediosas. A veces, una comprobación invocar la función de Azure o invocar la API REST no funciona correctamente y debe corregirla. Anteriormente, tenía que eliminar estas comprobaciones para evitar que bloquearan erróneamente una implementación. Una vez que corrigió la comprobación, tenía que volver a agregarla y configurarla correctamente, asegurándose de que todos los encabezados necesarios están establecidos o de que los parámetros de consulta son correctos. Esto es tedioso.

Ahora, puede deshabilitar una comprobación. La comprobación deshabilitada no se ejecutará en las evaluaciones posteriores del conjunto de comprobaciones.

Una vez que corrija la comprobación errónea, puede habilitarla.

Recursos consumidos y parámetros de plantilla en pipelines Runs REST API

La API REST Pipelines Runs ahora devuelve más tipos de artefactos usados por una ejecución de canalización y los parámetros que se usan para desencadenar esa ejecución. Se ha mejorado la API para devolver los container recursos y pipeline y los parámetros de plantilla usados en una ejecución de canalización. Ahora puede, por ejemplo, escribir comprobaciones de cumplimiento que evalúen los repositorios, contenedores y otras ejecuciones de canalización usadas por una canalización.

Este es un ejemplo del nuevo cuerpo de respuesta.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Compatibilidad con plantillas de disponibilidad general en el editor de YAML

Las plantillas son una característica que se usa habitualmente en las canalizaciones YAML. Son una manera sencilla de compartir fragmentos de código de canalización. También son un mecanismo eficaz para comprobar o aplicar la seguridad y la gobernanza a través de la canalización.

Azure Pipelines admite un editor YAML, que puede resultar útil al editar la canalización. Sin embargo, el editor no admitía plantillas hasta ahora. Los autores de canalizaciones yaML no pudieron obtener ayuda a través de IntelliSense al usar una plantilla. Los autores de plantillas no pudieron usar el editor de YAML. En esta versión, vamos a agregar compatibilidad con plantillas en el editor de YAML.

A medida que edita el archivo YAML principal de Azure Pipelines, puede incluir o extender una plantilla. Al escribir el nombre de la plantilla, se le pedirá que valide la plantilla. Una vez validado, el editor de YAML comprende el esquema de la plantilla, incluidos los parámetros de entrada.

Después de la validación, puede elegir navegar a la plantilla. Podrá realizar cambios en la plantilla con todas las características del editor de YAML.

Existen limitaciones conocidas:

• Si la plantilla tiene parámetros necesarios que no se proporcionan como entradas en el archivo YAML principal, se produce un error en la validación y se le pide que proporcione esas entradas. En una experiencia ideal, la validación no debe bloquearse y debe poder rellenar los parámetros de entrada mediante IntelliSense.
• No se puede crear una nueva plantilla desde el editor. Solo puede usar o editar plantillas existentes.

Nueva variable de sistema predefinida

Se introdujo una nueva variable del sistema predefinida, denominada Build.DefinitionFolderPath, cuyo valor es la ruta de acceso de carpeta de una definición de canalización de compilación. La variable está disponible en las canalizaciones de compilación YAML y clásicas.

Por ejemplo, si la canalización se hospeda en la FabrikamFiber\Chat carpeta de Azure Pipelines, el valor de Build.DefinitionFolderPath es FabrikamFiber\Chat.

Se ha agregado compatibilidad con la función de división de cadenas en las expresiones de plantilla de YAML.

Las canalizaciones de YAML proporcionan formas cómodas de reducir la duplicación de código, como recorrer en bucle each el valor de una lista o propiedad de un objeto.

A veces, el conjunto de elementos que se va a recorrer en iteración se representa como una cadena. Por ejemplo, cuando la cadena define integration1, integration2la lista de entornos en los que se va a implementar .

A medida que escuchamos sus comentarios de la Developer Community, hemos oído que quería una función de cadena split en expresiones de plantilla de YAML.

Ahora, puede split realizar una cadena y iterar sobre each sus subcadenas.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Expresiones de plantilla en la definición de recursos del repositorio

Se ha agregado compatibilidad con expresiones de plantilla al definir la ref propiedad de un repository recurso en una canalización YAML. Esta fue una característica muy solicitada por nuestra Developer Community.

Existen casos de uso cuando desea que la canalización consulte diferentes ramas del mismo recurso de repositorio.

Por ejemplo, supongamos que tiene una canalización que compila su propio repositorio y, para ello, debe desactive una biblioteca de un repositorio de recursos. Además, supongamos que quiere que la canalización consulte la misma rama de biblioteca que usa. Por ejemplo, si la canalización se ejecuta en la main rama, debe desactive la main rama del repositorio de biblioteca. Si las canalizaciones se ejecutan en la dev rama, debe desactive la rama de dev biblioteca.

Hasta hoy, tenía que especificar explícitamente la rama que se va a desactive y cambiar el código de canalización cada vez que cambie la rama.

Ahora, puede usar expresiones de plantilla para elegir la rama de un recurso de repositorio. Consulte el ejemplo siguiente de código YAML que se va a usar para las ramas que no son principales de la canalización:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Al ejecutar la canalización, puede especificar la rama para desactive el library repositorio.

Especificar la versión de una plantilla que se va a extender en tiempo de cola de compilación

Las plantillas representan una excelente manera de reducir la duplicación de código ymejorar la seguridad de las canalizaciones.

Un caso de uso popular es hospedar plantillas en su propio repositorio. Esto reduce el acoplamiento entre una plantilla y las canalizaciones que lo extienden y facilita la evolución de la plantilla y las canalizaciones de forma independiente.

Considere el ejemplo siguiente, en el que se usa una plantilla para supervisar la ejecución de una lista de pasos. El código de plantilla se encuentra en el Templates repositorio.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Supongamos que tiene una canalización YAML que extiende esta plantilla, ubicada en el repositorio FabrikamFiber. Hasta hoy, no era posible especificar dinámicamente la ref propiedad del recurso del templates repositorio al usar el repositorio como origen de plantilla. Esto significaba que tenía que cambiar el código de la canalización si quería que la canalización: ampliar una plantilla de otra rama extienda una plantilla desde el mismo nombre de rama que la canalización, independientemente de la rama que ejecutó la canalización.

Con la introducción de expresiones de plantilla en la definición de recursos del repositorio, puede escribir la canalización de la siguiente manera:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Al hacerlo, la canalización extenderá la plantilla en la misma rama que la rama en la que se ejecuta la canalización, por lo que puede asegurarse de que las ramas de la canalización y de la plantilla siempre coincidan. Es decir, si ejecuta la canalización en una rama dev, extenderá la plantilla especificada por el template.yml archivo en la dev rama del templates repositorio.

O bien, puede elegir, en tiempo de cola de compilación, qué rama de repositorio de plantillas usar, escribiendo el siguiente código YAML.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

Ahora, puede hacer que la canalización en la rama main extienda una plantilla desde una rama dev en una ejecución y amplíe una plantilla desde una rama main en otra ejecución, sin cambiar el código de la canalización.

Al especificar una expresión de plantilla para la ref propiedad de un recurso de repositorio, puede usar parameters y variables predefinidas por el sistema, pero no puede usar variables definidas por la interfaz de usuario de YAML o Pipelines.

Expresiones de plantilla en la definición de recursos de contenedor

Se ha agregado compatibilidad con expresiones de plantilla al definir las endpointpropiedades , volumes, portsy options de un recurso en una container canalización YAML. Esta fue una característica muy solicitada por nuestra Developer Community.

Ahora, puede escribir canalizaciones YAML como las siguientes.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Puede usar parameters. y variables. en las expresiones de plantilla. En el caso de las variables, solo puede usar las definidas en el archivo YAML, pero no las definidas en la interfaz de usuario de Canalizaciones. Si vuelve a definir la variable, por ejemplo, mediante comandos de registro del agente, no tendrá ningún efecto.

Mejoras de compilaciones programadas

Se ha corregido un problema que provocaba que la información de programación de una canalización estuviera dañada y que la canalización no se cargara. Esto se produjo por ejemplo, cuando el nombre de la rama superó un número determinado de caracteres.

Mensaje de error mejorado al no cargar canalizaciones

Azure Pipelines proporciona varios tipos de desencadenadores para configurar cómo se inicia la canalización. Una manera de ejecutar una canalización es mediante desencadenadores programados. A veces, la información de ejecución programada de una canalización se daña y puede provocar un error en la carga. Anteriormente, se mostraba un mensaje de error engañoso, que indica que no se encontró la canalización. Con esta actualización, se ha resuelto este problema y se devuelve un mensaje de error informativo. En el futuro, recibirá el mensaje similar a: Los datos de programación de compilación están dañados si una canalización no se puede cargar.

No sincronizar etiquetas al capturar un repositorio de Git

La tarea de desprotección usa --tags la opción para capturar el contenido de un repositorio de Git. Esto hace que el servidor recupere todas las etiquetas, así como todos los objetos a los que apuntan esas etiquetas. Esto aumenta el tiempo para ejecutar la tarea en una canalización, especialmente si tiene un repositorio grande con una serie de etiquetas. Además, la tarea de desprotección sincroniza las etiquetas incluso cuando se habilita la opción de captura superficial, lo que posiblemente anula su propósito. Para reducir la cantidad de datos capturados o extraídos de un repositorio de Git, ahora hemos agregado una nueva opción a la tarea para controlar el comportamiento de las etiquetas de sincronización. Esta opción está disponible tanto en canalizaciones clásicas como en YAML.

YAML

Este comportamiento se puede controlar desde el archivo YAML o desde la interfaz de usuario.

Para no participar en la sincronización de las etiquetas a través del archivo YAML, agregue al fetchTags: false paso de desprotección. Cuando no se especifica la fetchTags opción, es la misma que si fetchTags: true se usa.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Si desea cambiar el comportamiento de las canalizaciones YAML existentes, puede ser más conveniente establecer esta opción en la interfaz de usuario en lugar de actualizar el archivo YAML. Para ir a la interfaz de usuario, abra el editor de YAML para la canalización, seleccione Desencadenadores, después Proceso y, a continuación, el paso Desprotección.

Si especifica esta configuración tanto en el archivo YAML como en la interfaz de usuario, el valor especificado en el archivo YAML tiene prioridad.

Clásico

Para no participar en la sincronización de las etiquetas, desactive la casilla Sincronizar etiquetas en el paso Obtener orígenes.

Para todas las canalizaciones nuevas que cree (YAML o clásico), las etiquetas se siguen sincronizando de forma predeterminada. Esta opción no cambia el comportamiento de las canalizaciones existentes. Las etiquetas se seguirán sincronizando en esas canalizaciones a menos que cambie explícitamente la opción como se ha descrito anteriormente.

Artifacts

Se han actualizado los permisos de fuente predeterminados.

Las cuentas del servicio de compilación de colecciones de proyectos ahora tendrán el rol Colaborador de forma predeterminada cuando se cree una nueva fuente de Azure Artifacts con ámbito de colección de proyectos, en lugar del rol Colaborador actual.

Nueva interfaz de usuario para la búsqueda de paquetes ascendentes

Anteriormente, podía ver paquetes ascendentes si tenía una copia de la fuente. El punto problemático era que no podía buscar paquetes que están disponibles en la cadena ascendente y que aún no se han guardado en la fuente. Ahora, puede buscar paquetes ascendentes disponibles con la nueva interfaz de usuario de fuente.

Azure Artifacts ahora proporciona una interfaz de usuario que le permite buscar paquetes en los orígenes ascendentes y guardar las versiones de los paquetes en la fuente. Esto se alinea con el objetivo de Microsoft de mejorar nuestros productos y servicios.

Notificación

Mostrar elemento primario en el widget de resultados de la consulta

El Widget de resultados de la consulta ahora admite el nombre del elemento primario y un vínculo directo a ese elemento primario.

Copiar panel

Con esta versión se incluye Copy Dashboard.

Fecha de último acceso a los paneles y modificadas por

Uno de los desafíos de permitir que los equipos creen varios paneles es la administración y limpieza de las obsoletas y sin usar. Saber cuándo se visitó o modificó por última vez un panel es una parte importante para comprender cuáles se pueden quitar. En esta versión, hemos incluido dos columnas nuevas en la página del directorio Paneles. Última fecha de acceso realizará un seguimiento de cuándo se visitó el panel más recientemente. Modified By realiza un seguimiento de cuándo se editó por última vez el panel y por quién.

La información Modified By también se mostrará en la propia página del panel.

Esperamos que estos nuevos campos ayuden a los administradores del proyecto a comprender el nivel de actividad de los paneles para tomar una decisión educada si deben quitarse o no.

Las vistas de Analytics ya están disponibles

La característica Vistas de Analytics se encuentra en un estado de versión preliminar durante un período de tiempo prolongado en nuestra versión hospedada del producto. Con esta versión estamos encantados de anunciar que esta característica ya está disponible para todas las colecciones de proyectos.

En la navegación, las vistas de Analytics se movieron de la pestaña Información general a la pestaña Paneles .

Una vista analytics proporciona una manera simplificada de especificar los criterios de filtro para un informe de Power BI basado en los datos de Analytics. Si no está familiarizado con las vistas de Analytics, esta es una documentación que le ayudará a ponerse al día:

• Acerca de las vistas de Analytics
• Creación de una vista de Analytics en Azure DevOps
• Administrar vistas de análisis
• Creación de un informe de Power BI con una vista de Análisis predeterminada
• Conexión a Analytics con el conector de datos de Power BI

El widget de solicitud de incorporación de cambios para varios repositorios ya está disponible

Estamos encantados de anunciar que el widget de solicitud de incorporación de cambios para varios repositorios está disponible en Azure DevOps Server 2022.1. Con este nuevo widget, puede ver sin esfuerzo las solicitudes de incorporación de cambios de hasta 10 repositorios diferentes en una sola lista simplificada, lo que facilita que nunca permanezca encima de las solicitudes de incorporación de cambios.

Vale de sugerencia de la comunidad

Presentación de la resolución como completada en los gráficos de evolución y evolución

Entendemos la importancia de reflejar con precisión el progreso del equipo, incluidos los elementos resueltos como completados en los gráficos. Con una opción de alternancia simple, ahora puede elegir mostrar los elementos resueltos como completados, lo que proporciona un verdadero reflejo del estado de agotamiento del equipo. Esta mejora permite un seguimiento y un planeamiento más precisos, lo que permite a los equipos tomar decisiones fundamentadas en función del progreso real. Experiencia de mejora de la transparencia y mejor información con los gráficos de evolución y evolución actualizados en Informes.

Wiki

Compatibilidad con tipos de diagrama adicionales en páginas wiki

Hemos actualizado la versión de los gráficos de sirena usados en páginas wiki a 8.13.9. Con esta actualización, ahora puede incluir los siguientes diagramas y visualizaciones en las páginas wiki de Azure DevOps:

• Diagrama de flujo
• Diagramas de secuencia
• Gráficos de Gantt
• Gráficos circulares
• Diagramas de requisitos
• Diagramas de estado
• Recorrido del usuario

No se incluyen diagramas que están en modo experimental, como la relación de entidad y Git Graph. Para obtener más información sobre las nuevas características, consulte las notas de la versión de sirena.

---

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