Azure Artifacts simplifica la integración con otros servicios

Con esta actualización, hemos facilitado la autenticación de Azure Artifacts con otros administradores de paquetes populares. Busque más detalles sobre la implementación real a continuación.

Características

Azure Boards

• Agregar el filtro "Elemento de trabajo principal" al panel de tareas y al trabajo pendiente de sprints
• Mejora de la experiencia de control de errores: campos obligatorios en Error/Tarea

Azure Pipelines

• Agentes de conjunto de escalado en versión preliminar
• Ubuntu 20.04 en versión preliminar para los grupos hospedados de Azure Pipelines
• Compatibilidad con paquetes de GitHub en las canalizaciones YAML

Azure Artifacts

• Notificaciones de orígenes ascendentes deshabilitados
• Expresiones de licencia y licencias integradas
• Tareas de autenticación ligeras

Azure Boards

Agregar el filtro "Elemento de trabajo principal" al panel de tareas y al trabajo pendiente de sprints

Hemos agregado un nuevo filtro tanto a la placa Sprint como al trabajo pendiente de Sprint. Esto le permite filtrar los elementos de trabajo pendiente de nivel de requisitos (primera columna a la izquierda) por su elemento primario. Por ejemplo, en la captura de pantalla siguiente, hemos filtrado la vista para mostrar solo casos de usuario en los que el elemento primario es "Mi gran característica".

Mejora de la experiencia de control de errores: campos obligatorios en Error/Tarea

Históricamente, desde el panel Kanban, si movió un elemento de trabajo de una columna a otra donde el cambio de estado desencadenó las reglas de campo, la tarjeta solo mostraría un mensaje de error rojo que le obligará a abrir el elemento de trabajo para comprender la causa principal. En sprint 170, hemos mejorado la experiencia para que ahora pueda hacer clic en el mensaje de error rojo para ver los detalles del error sin tener que abrir el propio elemento de trabajo.

Azure Pipelines

Agentes de conjunto de escalado en versión preliminar

Estamos previsualizar una nueva característica denominada agentes de conjunto de escalado que emparejan la comodidad y la capacidad elástica de los agentes hospedados por Microsoft con el control y la flexibilidad de los agentes autohospedados. Con esta versión preliminar, ahora le permite administrar agentes a su especificación, completamente automatizada, en su suscripción de Azure. Es posible que quiera considerar el uso de agentes de conjunto de escalado en lugar de agentes autohospedados o autohospedados de Microsoft cuando:

• necesita más memoria, más procesador, más almacenamiento o más E/S que lo que ofrecemos en agentes hospedados en Microsoft nativos
• no desea permitir la lista de un gran número de direcciones IP dentro del firewall corporativo para permitir que los agentes hospedados por Microsoft se comuniquen con los servidores.
• necesita más agentes hospedados por Microsoft de los que podemos proporcionar para satisfacer sus necesidades a gran escala.
• necesita la capacidad de crear particiones de trabajos paralelos hospedados por Microsoft en proyectos o equipos individuales de su organización.
• no desea ejecutar agentes dedicados a lo largo del reloj, sino desaprovisionar máquinas de agente que no se usan activamente.

Para usar agentes de conjunto de escalado, primero creará un conjunto de escalado de máquinas virtuales en la suscripción de Azure y, a continuación, creará un grupo de agentes en Azure Pipelines para que apunte a ese conjunto de escalado. Azure Pipelines escalará automáticamente este grupo en función del número de trabajos pendientes y del número de máquinas inactivas que desea mantener en todo momento. Azure Pipelines también instalará el agente automáticamente en estas máquinas virtuales. Para obtener más información, consulte Agentes de conjunto de escalado. A medida que obtenga una vista previa de la característica, incluya sus comentarios en la página de documentación.

Ubuntu 20.04 en versión preliminar para los grupos hospedados de Azure Pipelines

La imagen de Ubuntu 20.04 ya está disponible en versión preliminar para los grupos hospedados de Azure Pipelines. Para usar esta imagen, actualice el archivo YAML para incluir vmImage: "ubuntu-20.04". Tenga en cuenta que la etiqueta de imagen más reciente de Ubuntu seguirá apuntando a ubuntu-18.04 hasta que ubuntu-20.04 salga de la versión preliminar más adelante este año.

Tenga en cuenta que, puesto que la imagen de ubuntu 20.04 está en versión preliminar, actualmente no admite todas las herramientas disponibles en ubuntu-18.04 . Más información

Compatibilidad con paquetes de GitHub en las canalizaciones YAML

Recientemente hemos introducido un nuevo tipo de recurso denominado paquetes que agrega compatibilidad para consumir paquetes NuGet y npm de GitHub como un recurso en canalizaciones YAML. Como parte de este recurso, ahora puede especificar el tipo de paquete (NuGet o npm) que desea consumir desde GitHub. También puede habilitar desencadenadores de canalización automatizados tras la versión de una nueva versión del paquete. En la actualidad, la compatibilidad solo está disponible para consumir paquetes de GitHub, pero en el futuro tenemos previsto ampliar la compatibilidad para consumir paquetes de otros repositorios de paquetes, como NuGet, npm, AzureArtifacts y muchos más. Consulte el ejemplo siguiente para obtener más información:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # GitHub service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Nota: En la actualidad, los paquetes de GitHub solo admiten la autenticación basada en PAT, lo que significa que la conexión de servicio de GitHub en el recurso del paquete debe ser de tipo PAT. Una vez que se levante esta limitación, proporcionaremos compatibilidad con otros tipos de autenticación.

De forma predeterminada, los paquetes no se descargan automáticamente en los trabajos, por lo que hemos introducido una macro getPackage que permite consumir el paquete definido en el recurso. Consulte el ejemplo siguiente para obtener más información:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Azure Artifacts

Notificaciones de orígenes ascendentes deshabilitados

La interfaz web de Azure Artifacts ahora le notifica cuando uno o varios de los orígenes ascendentes de la fuente no funcionan. Los orígenes ascendentes permiten apuntar una fuente (fuente A) a otra fuente (fuente B) y permitir que los consumidores de la fuente A accedan a paquetes desde la fuente B sin necesidad de conectarse directamente a él. Para más información sobre los orígenes ascendentes, consulte la documentación de Azure Artifacts. Es posible que los orígenes ascendentes no funcionen si están deshabilitados en el origen, por ejemplo, si se elimina la fuente B de forma silenciosa, los clientes no podrán capturar paquetes de él a través de la fuente A. En el pasado, esta situación podría producirse sin advertencia y provocar problemas operativos difíciles de diagnosticar, como interrupciones repentinas de compilación debido a dependencias que faltan (es decir, paquetes procedentes de la fuente B en el ejemplo anterior). Ahora, Azure Artifacts le proporcionará una advertencia cuando haya problemas con los orígenes ascendentes de las fuentes. Cuando exista un problema, verá un banner (flecha roja a continuación) en la página de detalles de la fuente de Azure Artifacts.

Al hacer clic en el vínculo del banner se abrirá una página que muestra el estado de cada origen ascendente de la fuente. Además de información sobre cada origen ascendente de la fuente actual, puede ver el estado actual en la columna "Última sincronización". Los orígenes ascendentes que funcionan correctamente mostrarán una marca de verificación verde con la última vez que se comprobó el estado del origen. Los orígenes ascendentes que están rotos mostrarán una X roja junto con la hora en que se ha comprobado. Los orígenes ascendentes que están pendientes de comprobación mostrarán un icono de información azul.

Al hacer clic en la última hora de sincronización de un origen ascendente roto, se abrirá un cuadro de diálogo para compartir más detalles sobre la causa principal del problema (si está disponible). Por ejemplo, en la imagen siguiente, el origen ascendente en cuestión no funciona porque se eliminó la fuente de destino. El cuadro de diálogo también contiene un vínculo al registro de auditoría, para ayudarle a comprender quién ha realizado los cambios pertinentes recientemente. Los vínculos a la configuración de permisos y la documentación de Azure Artifacts también se pueden usar para ayudar a investigar la causa principal.

Expresiones de licencia y licencias integradas

Ahora puede ver los detalles de la información de licencia de los paquetes NuGet almacenados en Azure Artifacts durante la exploración de paquetes en Visual Studio. Esto se aplica a las licencias que se representan mediante expresiones de licencia o licencias insertadas. Ahora puede ver un vínculo a la información de licencia en la página de detalles del paquete de Visual Studio (flecha roja en la imagen siguiente).

Al hacer clic en el vínculo, se le llevará a una página web donde puede ver los detalles de la licencia. Esta experiencia es la misma para las expresiones de licencia y las licencias insertadas, por lo que puede ver los detalles de licencia de los paquetes almacenados en Azure Artifacts en un solo lugar (para paquetes que especifican información de licencia y son compatibles con Visual Studio).

Tareas de autenticación ligeras

Ahora puede autenticarse con administradores de paquetes populares de Azure Pipelines mediante tareas de autenticación ligeras. Esto incluye NuGet, npm, PIP, Twine y Maven. Anteriormente, podría autenticarse con estos administradores de paquetes mediante tareas que proporcionan una gran cantidad de funcionalidad, incluida la capacidad de publicar y descargar paquetes. Sin embargo, esto requiere el uso de estas tareas para todas las actividades que interactúan con los administradores de paquetes. Si tuviera sus propios scripts para ejecutar tareas como publicar o descargar paquetes, no podría usarlos en la canalización. Ahora, puede usar scripts de su propio diseño en la canalización YAML y realizar la autenticación con estas nuevas tareas ligeras. Ejemplo con npm:

El uso del comando "ci" y "publish" en esta ilustración es arbitrario, podría usar los comandos admitidos por YAML de Azure Pipelines. Esto le permite tener un control completo de la invocación de comandos y facilita el uso de scripts compartidos en la configuración de la canalización. Para obtener más información, consulte la documentación de la tarea de autenticación nuGet, npm, PIP, Twine y Maven .

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