Disponibilidad general de Planes de entrega 2.0

Estamos muy encantados de anunciar que Planes de entrega 2.0 está disponible con carácter general! Los planes de entrega 2.0 ofrecen tres escenarios clave: una vista de escala de tiempo del plan, el progreso del trabajo y el seguimiento de las dependencias.

Eche un vistazo a las siguientes descripciones de las características para obtener más información.

Azure Boards

• Los planes de entrega 2.0 están disponibles con carácter general
• Nueva API REST de capacidad de iteración
• El panel de copia ya está disponible en versión preliminar pública

Azure Pipelines

• Cambio en la directiva de preinstalación del SDK de .NET en agentes de Ubuntu hospedados por Microsoft
• Permisos y comprobaciones en grupos de variables y archivos seguros
• Vista previa de la compatibilidad de plantillas en el editor de YAML
• Ubuntu-16.04 se quitará de los grupos hospedados por Microsoft en septiembre de 2021

Azure Boards

Los planes de entrega 2.0 están disponibles con carácter general

Nos complace anunciar que planes de entrega 2.0 está disponible con carácter general. Ofrece tres escenarios clave:

• Vista de escala de tiempo del plan
• Progreso del trabajo
• Seguimiento de dependencias

Estos escenarios funcionan en equipos y proyectos. Los planes de entrega 2.0 ahora son nativos del producto, por lo que ya no se requiere una extensión. Los planes creados con la extensión Planes originales seguirán funcionando en Planes de entrega.

Esta es una comparación rápida de las diferencias entre planes y planes de entrega

Característica	Planes 1.0 (extensión)	Delivery Plans 2.0
Número de equipos	El límite es 10	El límite es 15
Período de tiempo del elemento de trabajo	Solo iteraciones	Fecha de inicio/destino e iteración
Visualización	Vista de tarjeta completa	Vistas condensadas y expandidas
Información de acumulación	None	% hecho de elementos secundarios y vinculados
Seguimiento de dependencias	None	Sí
Visualización de la hora de inicio	No, solo donde finaliza el elemento de trabajo	Sí, fechas de inicio y destino
Estilo de tarjeta	No	Sí

Características de planes de entrega

A continuación se muestran las características principales. El filtrado, los marcadores y los criterios de campo también forman parte de los planes de entrega.

Hay dos vistas principales: condensadas y expandidas

Los planes de entrega 2.0 permiten ver todos los elementos de trabajo del plan en una escala de tiempo, mediante fechas de inicio y destino o fechas de iteración. El orden de prioridad es las fechas de inicio y destino, seguidas de la iteración. Esto le permite agregar elementos de trabajo de nivel de cartera como Epic, que a menudo no se definen en una iteración.

Hay dos vistas principales, la vista condensada y la vista expandida. También puede acercar y alejar el plan haciendo clic en la lupa en el lado derecho del plan.

• Vista condensada

  La vista condensada muestra todas las tarjetas de elemento de trabajo contraídas , lo que significa que no se muestra toda la información de tarjeta. Esta vista es útil para una vista general del trabajo en el plan. Para contraer los campos de la tarjeta, haga clic en el icono de tarjeta situado junto a los iconos de aumento en el lado derecho del plan.

  Este es un ejemplo de un plan que alterna entre las vistas condensadas y expandidas.

  

• Vista expandida

  La vista expandida muestra el progreso de un elemento de trabajo contando el número de elementos secundarios y vinculados y mostrando el porcentaje completado. El progreso actual viene determinado por el recuento de elementos de trabajo.

  Este es un ejemplo de un plan mediante una vista expandida. Anote las barras de progreso y el porcentaje completados.

  

Seguimiento de dependencias

El seguimiento de dependencias se basa en los vínculos predecesores y sucesores que se definen en los elementos de trabajo. Si esos vínculos no están definidos, no se mostrará ninguna línea de dependencia. Cuando hay un problema de dependencia con un elemento de trabajo, el icono del vínculo de dependencia se colorea de color rojo.

• Visualización de dependencias

  Las dependencias específicas se ven a través del panel de dependencias que muestra todas las dependencias de ese elemento de trabajo, incluida la dirección. Una signo de exclamación roja indica un problema de dependencia. Para abrir el panel, simplemente haga clic en el icono del vínculo de dependencia en la esquina superior derecha de la tarjeta. Estos son ejemplos de dependencias.

  

  

• Líneas de dependencia

  Las dependencias entre los elementos de trabajo se visualizan con líneas de flecha direccionales entre los elementos de trabajo respectivos. Varias dependencias se mostrarán como varias líneas. Una línea de color rojo indica un problema.

  Estos son algunos ejemplos.

  

  Este es un ejemplo de un elemento de trabajo con varias dependencias y funciona también con la vista condensada.

  

  Cuando hay un problema, el color de línea es rojo y, por tanto, es el icono de dependencia.

  Este es un ejemplo.

  

Estilo de tarjeta

Ahora se puede aplicar estilo a las tarjetas mediante reglas, como los paneles Kanban. Abra la configuración del plan y haga clic en Estilos. En el panel Estilos, haga clic en + Agregar regla de estilo para agregar la regla y, a continuación, haga clic en Guardar. Puede haber hasta 10 reglas y cada regla puede tener hasta 5 cláusulas.

• Antes

• Después

El panel de copia ya está disponible en versión preliminar pública

Con esta versión, ahora se puede copiar un panel de equipo o proyecto en el mismo proyecto o en un nuevo proyecto. Los widgets y el diseño del panel se copiarán, pero los widgets deberán configurarse con nuevas consultas y configuraciones.

Para obtener una vista previa de esta característica, simplemente active la marca de características denominada Copy Dashboard Experience (en características en versión preliminar).

Estos son los pasos para copiar un panel:

1. Vaya al panel que desea copiar. Desde allí, haga clic en el menú para abrir Copiar panel y, a continuación, haga clic en él.

2. Escriba el nombre y la descripción del nuevo panel y, a continuación, seleccione el tipo de panel, Equipo o Proyecto. Al seleccionar un panel de equipo, el nuevo proyecto y el equipo se seleccionan en los cuadros desplegables del proyecto y del equipo, respectivamente. En el caso de un panel del proyecto, solo se requiere el proyecto.

Nueva API REST de capacidad de iteración

Ahora puede obtener la capacidad total de todos los equipos en una iteración mediante la nueva API REST iteracióncapacities . Proporcione y iterationId la API devolverán la capacidad total de cada equipo asociado a la iteración, así como un total global. Esta característica facilitará el planeamiento de la capacidad para un incremento. Para obtener más información sobre iteracióncapacities, consulte la documentación aquí.

Azure Pipelines

Cambio en la directiva de preinstalación del SDK de .NET en agentes de Ubuntu hospedados por Microsoft

Estamos cambiando las versiones del SDK de .NET preinstaladas en agentes de Ubuntu hospedados por Microsoft. Actualmente, instalamos todas las versiones disponibles y compatibles del SDK de .NET (2.1.x, 3.1.x, 5.0.x). Este enfoque se cambiará a favor de instalar la versión de revisión más reciente para cada versión de característica. Este cambio se realiza para proporcionarle más espacio libre y para las nuevas solicitudes de herramientas.

¿Qué significa?

La versión del SDK se compone de las siguientes partes: x.y.znn. z es la versión de la característica y nn es la versión de revisión. Por ejemplo, para la versión 2.1.302, la versión de la característica es 3 y 02 es la versión de revisión. Según el nuevo enfoque, solo se instalará la versión de revisión más reciente para cada versión de característica, es decir, solo se instalará 2.1.302 para 2.1.3x, solo 2.1.403 para 2.1.4x, etc. Todas las versiones del SDK de .NET que no son las versiones de revisión más recientes se quitarán de las imágenes de Ubuntu el 14 de junio. Este cambio afecta a todas las versiones de Ubuntu en agentes hospedados por Microsoft.

Fecha objetivo

La implementación de imágenes actualizadas comenzará el 14 de junio y tardará entre 3 y 4 días.

Posible impacto

Si usa un archivo global.json, la compilación se verá afectada en los casos siguientes:

Se producirá un error en la compilación, si el archivo global.json contiene la propiedad y la rollForward: disable versión del SDK que no es la versión de revisión más reciente. Por ejemplo:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

La versión del SDK de .NET se cambiará automáticamente a la revisión más reciente si el archivo global.json contiene la rollForward: patch propiedad . Por ejemplo:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

Si el campo no se especifica en el rollForward archivo global.json, no habrá ningún cambio. Se usa el nivel de revisión instalado más reciente.

Si necesita usar la versión exacta del SDK de .NET que no es la revisión más reciente, use UseDotNet la tarea para instalarla como parte de la compilación:

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

Permisos y comprobaciones en grupos de variables y archivos seguros

Puede usar diferentes tipos de recursos compartidos en canalizaciones YAML. Algunos ejemplos son las conexiones de servicio, los grupos de variables, los archivos seguros, los grupos de agentes, los entornos o los repositorios. Para proteger una canalización de acceso a un recurso, el propietario del recurso puede configurar permisos y comprobaciones en ese recurso. Cada vez que una canalización intenta acceder al recurso, se evalúan todos los permisos y comprobaciones configurados. Estas protecciones han estado disponibles en conexiones de servicio, entornos y grupos de agentes durante un tiempo. Se agregaron recientemente a los repositorios. Con esta versión, vamos a agregar las mismas protecciones a grupos de variables y archivos seguros.

Para restringir el acceso a un grupo de variables o a un archivo seguro a un pequeño conjunto de canalizaciones, use la característica Permisos de canalizaciones.

Para configurar comprobaciones o aprobaciones que se deben evaluar cada vez que se ejecuta una canalización, use el Aprobaciones y compruebe la característica Biblioteca.

Vista previa de la compatibilidad de plantillas en el editor de YAML

Las plantillas son una característica que se usa habitualmente en las canalizaciones YAML. Son una manera fácil 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 ser útil al editar la canalización. Anteriormente, el editor no admitía plantillas. Los autores de canalizaciones YAML no pudieron obtener ayuda de IntelliSense al usar una plantilla. Con esta versión, se ofrece una vista previa de la compatibilidad con plantillas en el editor de YAML. Para habilitar esta versión preliminar, vaya a características en versión preliminar en la organización de Azure DevOps y habilite el editor de plantillas 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 optar por navegar a la plantilla. Podrá realizar cambios en la plantilla con todas las características del editor de YAML.

Tenga en cuenta que esta característica está en versión preliminar. Hay limitaciones conocidas, algunas de las cuales estamos trabajando para abordar. 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 debería poder rellenar los parámetros de entrada mediante intellisense. Además, no puede crear una nueva plantilla desde el editor. Solo puede usar o editar plantillas existentes.

Ubuntu-16.04 se quitará de los grupos hospedados por Microsoft en septiembre de 2021

La compatibilidad tradicional de 5 años de Ubuntu 16.04 por Canonical finaliza en abril de 2021. Para mantener nuestro entorno actualizado y protegido, quitaremos Ubuntu 16.04 el 20 de septiembre de 2021.

Deberá migrar flujos de trabajo de ubuntu-16.04 a ubuntu-18.04 o ubuntu-latest, que se ejecutarán en Ubuntu 20.04 LTS.

Para asegurarnos de que todos conozcan este cambio, hemos programado dos brownouts cortos. Las compilaciones de Ubuntu 16.04 producirán un error durante el período de brownout. Por lo tanto, se recomienda migrar las canalizaciones antes del 6 de septiembre de 2021.

Los brownouts están programados provisionalmente para las fechas y horas siguientes. Actualizaremos estos tiempos a medida que nos acercamos a este período.

6 de septiembre de 2021 5:00 UTC – 10:00 UTC

14 de septiembre de 2021 5:00 UTC : 10:00 UTC

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.

Vaya a Azure DevOps.

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.

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

Gracias,

Aaron Hallberg