Nuevas mejoras en los planes de entrega 2.0

En este sprint, estamos mejorando los planes de entrega 2.0 con nuevas vistas condensadas e información de acumulación. También presentamos validación manual y una nueva uses instrucción para declarar previamente recursos en canalizaciones yaML.

Consulte la lista de características que se muestra a continuación para obtener más información.

Azure Boards

Azure Pipelines

Azure Boards

Planes de entrega: información de acumulación

Como parte de la versión preliminar pública de Delivery Plans 2.0, la información de acumulación ahora está disponible. Al tratar con elementos de trabajo de nivel superior, como Epopeyas o Características, puede que desee ver más detalles. Roll-up muestra el progreso de los elementos de trabajo secundarios subyacentes, revelando la historia completa. Para habilitar esta característica, vaya a la configuración del plan, luego Campos y seleccione Mostrar datos acumulativos secundarios.


Planes de entrega: información de acumulación

Planes de entrega: vistas condensadas

Como parte de la versión preliminar pública de Delivery Plans 2.0, los clientes ahora pueden cambiar entre las vistas Normal y Condensada. Las tarjetas con campos adicionales pueden ocupar mucho espacio vertical. Esto hace que sea difícil ver más de unas pocas tarjetas en la pantalla a la vez, incluso cuando se aleja completamente. Hemos creado una vista de tarjeta contraída que oculta todos los campos de las tarjetas y solo muestra el icono y el título del tipo de elemento de trabajo. Ocultar y mostrar todos los campos ahora es solo un clic de distancia.


planes de entrega

Azure Pipelines

Instrucción "uses" para declarar previamente los recursos

Cuando una canalización ejecuta un trabajo en un agente, ese agente recibe un token de acceso para volver a llamar a las API REST de Azure Pipelines y descargar recursos como repositorios. En el caso de las canalizaciones de YAML, hemos agregado recientemente una configuración para restringir el token a solo los repositorios consumidos realmente en un trabajo. Sin embargo, algunos clientes estaban usando repositorios sin usar explícitamente un checkout paso, por ejemplo, si usaban un paso de script para llamar directamente a Git. Estos clientes no pudieron habilitar la característica de restricción de tokens, ya que Azure Pipelines no pudo determinar con precisión qué repositorios se necesitaban para el trabajo.

Con esta actualización, hemos agregado una manera alternativa de indicar a Azure Pipelines que un trabajo quiere usar un repositorio sin usar el checkout paso . En su lugar, puede usar la palabra clave new uses , de la siguiente manera:

resources:
  repositories:
  - repository: myrepo
    type: git
    name: MyProject/MyRepo

jobs:
- job: myjob
  uses:
    repositories:
    - myrepo
  steps:
  # without the preceding "uses" statement, if you have the
  # new limit-repositories feature turned on, then Azure Pipelines
  # won't include this repo in the access token and you'll
  # get an access error at runtime (also, in a real pipeline
  # you must include the auth token header as an argument to Git)
  - script: git clone https://dev.azure.com/MyOrg/MyProject/_git/MyRepo

Esta característica también resuelve un problema relacionado (aunque menos común). Si usa la matrix palabra clave para generar varios trabajos y estos trabajos usan grupos especificados en el paso de matriz, es posible que haya tenido problemas para autorizar esos grupos para la canalización. La causa principal es la misma: porque las matrices se calculan en tiempo de ejecución, el sistema de autorización de recursos inicial no puede determinar con precisión qué grupos se usan. Con uses, puede declarar qué grupos usarán los trabajos para que se puedan autorizar por adelantado.

jobs:
- job: mtrx
  strategy:
    matrix:
      windows:
        mypoolname: Private-Windows
      mac:
        mypoolname: Private-Mac
  pool: $(mypoolname)
  # without the following "uses" statement, "pool" won't see
  # the pool names until it's too late, and you'll get an error
  # at runtime
  uses:
    pools:
    - Private-Windows
    - Private-Mac

Validación manual para canalizaciones de YAML

Con la tarea Validación manual recién publicada, puede pausar una canalización de YAML a mitad de fase. Esto le permite realizar actividades manuales o sin conexión y, a continuación, reanudar (o rechazar) la ejecución. Esto es especialmente útil en escenarios en los que desea pausar una canalización y permitir que un elemento del mismo nivel valide las opciones de configuración, el paquete de compilación, etc. antes de pasar a un trabajo de ejecución prolongada y de proceso intensivo. Más información.


validación manual

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.

Hacer una sugerencia

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

Gracias,

Matt Cooper