API de vista previa de YAML mejorada y configuración del origen ascendente para paquetes universales

En este sprint, estamos implementando un nuevo punto de conexión de API que le permite recuperar el cuerpo de YAML finalizado. También nos complace anunciar que estamos agregando la capacidad de configurar su origen ascendente para paquetes universales con esta versión.

Consulte la lista de características siguiente para obtener más información.

Características

Azure Boards

Azure Pipelines

Azure Artifacts

Azure Boards

Tipos de elementos de trabajo del sistema en registros de trabajo pendiente y paneles

Hemos iniciado una versión preliminar privada de una característica que permite agregar un tipo de elemento de trabajo del sistema al nivel de trabajo pendiente de elección. Históricamente, estos tipos de elementos de trabajo solo han estado disponibles en las consultas.

Proceso Tipo de elemento de trabajo
Ágil Problema
Scrum Impedimento
CMMI Solicitud de cambio
Problema
Revisar
Riesgo

Nos complace anunciar que la característica está ahora fuera de la versión preliminar y está disponible con carácter general para todas las organizaciones. Agregar un tipo de elemento de trabajo del sistema a un nivel de trabajo pendiente es sencillo. Simplemente vaya al proceso personalizado y haga clic en la pestaña Niveles de trabajo pendiente. Seleccione el nivel de trabajo pendiente de elección (ejemplo: Trabajo pendiente de requisitos) y elija la opción editar. A continuación, agregue el tipo de elemento de trabajo.

backlogs

Evento de los registros de auditoría

Hemos agregado un nuevo evento a los registros de auditoría para ayudar a los clientes a realizar un seguimiento de los cambios relacionados con el proceso. Se registrará un evento cada vez que se cambien los valores de una lista de selección. Los cambios en los campos de la lista de selección suelen ser los cambios más comunes realizados en un proceso. Con este nuevo evento, los administradores de la organización pueden realizar un seguimiento mejor de cuándo y quién realizó cambios en esos campos.

audit-logs

Aumento del límite de repositorios de la aplicación Azure Boards en GitHub (versión preliminar privada)

Si usa la aplicación Azure Boards desde El marketplace de GitHub, hay un límite de 100 repositorios de GitHub a los que puede conectarse.  Esto se convierte en un bloqueador para organizaciones grandes que pueden tener más de 100 repositorios. En este sprint, hemos cambiado la forma en que Azure Boards se conecta a los repositorios de GitHub para admitir más de 100. Si actualmente alcanza el límite de 100 repositorios, háganoslo saber y podemos habilitar la característica para aumentar ese límite y desbloquearlo. Envíenos un correo electrónico directamente con el nombre de su organización (dev.azure.com/{organización}).

Estado personalizado de los elementos de trabajo cuando se fusiona mediante combinación una solicitud de incorporación de cambios (versión preliminar privada)

No todos los flujos de trabajo son los mismos. Algunos clientes quieren cerrar sus elementos de trabajo relacionados cuando se completa una solicitud de incorporación de cambios. Otros quieren establecer los elementos de trabajo en otro estado que se va a validar antes de cerrar. Deberíamos permitir ambos.

A partir del sprint 174, tenemos una nueva característica que permite establecer los elementos de trabajo en el estado deseado cuando la solicitud de incorporación de cambios se combina y se completa. Para ello, examinamos la descripción de la solicitud de incorporación de cambios y buscamos el valor de estado seguido del #mention de los elementos de trabajo. En este ejemplo, estamos estableciendo dos casos de usuario en Resuelto y cerrando dos tareas.

work-item-state

Esta característica ha llegado mucho tiempo y estamos encantados de ver lo que piensa. Para empezar, simplemente estamos examinando la descripción de la solicitud de incorporación de cambios y no incluye ningún cambio en la interfaz de usuario. Queríamos recibir sus comentarios antes de invertir más.

Si está interesado en participar en la versión preliminar privada, envíenos un correo electrónico directamente. No olvide incluir su organización (dev.azure.com/{organization}).

Azure Pipelines

Anuncios de imágenes de Pipelines

Nota:

Las imágenes de Azure Pipelines se actualizan continuamente con el fin de proporcionar a los usuarios la mejor experiencia posible. Estas actualizaciones rutinarias se dirigen principalmente a solucionar errores o software obsoleto. A menudo no tendrán ningún impacto en las canalizaciones, pero esto no siempre es así. La canalización puede verse afectada si toma una dependencia de un fragmento de software que se ha quitado o actualizado en la imagen.

Para obtener más información sobre las próximas actualizaciones en nuestras imágenes de Windows, Linux y macOS, lea los siguientes anuncios:

Para ver las notas de la versión para los próximos cambios (versión preliminar) e implementados, suscríbase a las siguientes notas de la versión:

Mejora de la carga de registros de los agentes

Cuando un agente deja de comunicarse con el servidor de Azure Pipelines, el trabajo que se estaba ejecutando se abandona. Si ha visto los registros de la consola de streaming, es posible que haya obtenido algunas pistas sobre lo que el agente estaba justo antes de dejar de responder. Pero si no lo estaba, o si actualizó la página, esos registros de consola se han ido. Con esta versión, si el agente deja de responder antes de enviar sus registros completos, mantendremos los registros de la consola como lo mejor. Los registros de consola están limitados a 1000 caracteres por línea y, ocasionalmente, pueden estar incompletos, pero son mucho más útiles que mostrar nada. Examinar estos registros puede ayudarle a solucionar problemas de sus propias canalizaciones y, sin duda, ayudará a nuestros ingenieros de soporte técnico cuando le ayuden a solucionar problemas.

Montaje opcional de los volúmenes de contenedor solo para lectura

Al ejecutar un trabajo de contenedor en Azure Pipelines, varios volúmenes que contienen el área de trabajo, las tareas y otros materiales se asignan como volúmenes. Estos volúmenes tienen como valor predeterminado acceso de lectura y escritura. Para aumentar la seguridad, puede montar los volúmenes de solo lectura modificando la especificación del contenedor en YAML. Cada clave de se mountReadOnly puede establecer true en para solo lectura (el valor predeterminado es false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Control pormenorizado del inicio y la detención de los contenedores

En general, se recomienda permitir que Azure Pipelines administre el ciclo de vida de los contenedores de trabajos y servicios. Sin embargo, en algunos escenarios poco comunes, es posible que quiera iniciarlos y detenerlos usted mismo. Con esta versión, hemos creado esa funcionalidad en la tarea docker.

Esta es una canalización de ejemplo mediante la nueva funcionalidad:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Además, se incluye la lista de contenedores en una variable de canalización, Agent.ContainerMapping. Puede usarlo si desea inspeccionar la lista de contenedores de un script, por ejemplo. Contiene un objeto JSON con cadena que asigna el nombre del recurso ("builder" del ejemplo anterior) al identificador de contenedor que administra el agente.

Descompresión de lotes de tareas para cada paso

Cuando el agente ejecuta un trabajo, primero descarga todos los conjuntos de tareas requeridos por los pasos del trabajo. Normalmente, para el rendimiento, descomprime las tareas una vez por trabajo incluso si la tarea se usa en varios pasos. Si tiene dudas sobre el código que no es de confianza al modificar el contenido descomprimido, puede cambiar un poco de rendimiento haciendo que el agente descomprima la tarea en cada uso. Para habilitar este modo, pase --alwaysextracttask al configurar el agente.

Mayor seguridad de las versiones al restringir el ámbito de los tokens de acceso

Basándonos en nuestra iniciativa para mejorar la configuración de seguridad de Azure Pipelines, ahora se admite restringir el ámbito de los tokens de acceso para las versiones.

Cada trabajo que se ejecuta en versiones obtiene un token de acceso. Las tareas y los scripts usan el token de acceso para volver a llamar a Azure DevOps. Por ejemplo, usamos el token de acceso para obtener código fuente, descargar artefactos, cargar registros, resultados de pruebas o realizar llamadas REST a Azure DevOps. Se genera un nuevo token de acceso para cada trabajo y expira una vez completado el trabajo.

Con esta actualización, se basa en la mejora de la seguridad de la canalización mediante la restricción del ámbito de los tokens de acceso y la extensión de la misma a las versiones clásicas.

Esta característica estará activada de forma predeterminada para los nuevos proyectos y organizaciones. Para las organizaciones existentes, debe habilitarla en La organización Configuración > canalizaciones > Configuración. > Limite el ámbito de autorización del trabajo al proyecto actual para las canalizaciones de versión. Obtenga más información aquí.

Mejoras en la API de vista previa de YAML

Hace unos sprints, se introdujo la capacidad de obtener una vista previa del CÓDIGO YAML completo de una canalización sin ejecutarlo. Con esta actualización, hemos creado una nueva dirección URL dedicada para la funcionalidad de versión preliminar. Ahora puede POST para https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview recuperar el cuerpo de YAML finalizado. Esta nueva API toma los mismos parámetros que la puesta en cola de una ejecución, pero ya no requiere el permiso "Queue builds".

Azure Artifacts

Configuración de orígenes ascendentes para paquetes universales

Ahora puede configurar las fuentes de Azure Artifacts para descargar automáticamente paquetes universales de orígenes ascendentes a petición.

Anteriormente, podía configurar orígenes ascendentes en la fuente para paquetes NuGet, Python, Maven y npm, pero no para paquetes universales. Esto se debe a una diferencia en la tecnología de almacenamiento usada para paquetes universales, que admiten paquetes mucho más grandes que otros tipos de paquetes admitidos.

Ahora puede configurar orígenes ascendentes para paquetes universales de la misma manera que para otros tipos de paquete; abra la configuración de la fuente, haga clic en Orígenes ascendentes ->Agregar origen ascendente>- y elija el tipo de origen adecuado para usted. Verá Paquetes universales (UPack) como una nueva opción en la vista siguiente (consulte la imagen siguiente). Para obtener más información, consulte la documentación de configuración de orígenes ascendentes.

upack

Tenga en cuenta que los paquetes universales de orígenes ascendentes solo se admiten entre fuentes de la misma organización de DevOps.

Disponibilidad de la API REST “Update Package Version” para los paquetes Maven

Ahora puede usar la API REST "Update Package Version" de Azure Artifacts para actualizar las versiones del paquete de Maven. Anteriormente, podría usar la API REST para actualizar las versiones de paquetes para NuGet, Maven, npm y Paquetes universales, pero no paquetes de Maven.

Para actualizar los paquetes de Maven, use el comando HTTP PATCH como se indica a continuación.

PATCH https://pkgs.dev.azure.com/{organization}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Puede establecer lo siguiente:

Parámetros de URI

Nombre In Obligatorio Tipo Descripción
artifactId path VERDADERO string Identificador de artefacto del paquete
feed path VERDADERO string Nombre o identificador de la fuente
groupId path VERDADERO string Id. de grupo del paquete
organization path VERDADERO string Nombre de la organización de Azure DevOps
version path VERDADERO string Versión del paquete
proyecto path string Id. de proyecto o nombre del proyecto
api-version Query VERDADERO string Versión de la API que se va a usar. Debe establecerse en "5.1-preview.1" para usar esta versión de la API.

Cuerpo de la solicitud

Nombre Tipo Descripción
views JsonPatchOperation Vista a la que se agregará la versión del paquete.

Para obtener más información, consulte la documentación de la API REST a medida que se actualiza.

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Cómo enviar sus comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

Make a suggestion

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

Gracias,

Aaron Hallberg