Nuevos informes de análisis y aplicación de Azure Boards para Slack: actualización de Sprint 155

  • Artículo

En la actualización Sprint 155 de Azure DevOps, hemos agregado nuevos informes de Azure Boards para que sea más fácil realizar seguimiento de las métricas importantes del equipo. Los nuevos informes aparecerán en la pestaña Analytics de los centros de conectividad de Boards, Trabajos pendientes y Sprint. Estos informes son completamente interactivos y le permiten ajustarlos según sus necesidades.

Además, nos complace anunciar la nueva aplicación de Azure Boards para Slack. La aplicación le permite supervisar la actividad de elementos de trabajo y crearlos desde su canal de Slack.

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

Novedades de Azure DevOps

Características

General:

Azure Boards:

Azure Repos:

Azure Artifacts:

Azure Pipelines:

   Canalizaciones de varias fases basadas en YAML

  Máquinas virtuales hospedadas

Kubernetes

Prueba

  Experiencias de Azure

Integraciones

General

Invite colaboradores de GitHub a Azure DevOps

Ahora puede invitar a colaboradores de GitHub a Azure DevOps cuando haya iniciado sesión con la identidad de GitHub. Puede buscar e invitar a otros usuarios de GitHub desde la página principal del proyecto y desde la página Usuarios de la configuración de la organización.

Invite GitHub collaborators into Azure DevOps.

Esta funcionalidad debe estar habilitada para las organizaciones existentes a través de una configuración en Directivas en la configuración de la organización. Sin embargo, está activado de forma predeterminada para las organizaciones creadas por una identidad de GitHub.

Enable for existing organizations.

Nota:

Esta característica no está disponible para los usuarios que no son de GitHub, incluso si la directiva está activada.

Para más información sobre cómo invitar a miembros del equipo, consulte la documentación aquí. Si tiene problemas para conectarse a Azure DevOps mediante GitHub, consulte las preguntas más frecuentes sobre la autenticación e invitación de usuarios de GitHub.

Azure Boards

Obtenga conclusiones sobre el estado de su equipo con tres informes nuevos de Azure Boards

No puedes corregir lo que no puedes ver. Por lo tanto, desea mantener un ojo cercano al estado y el estado de sus procesos de trabajo. Con estos informes, facilitamos el seguimiento de las métricas importantes con un esfuerzo mínimo en Azure Boards.

Los tres nuevos informes interactivos son: Burndown, Diagrama de flujo acumulativo (CFD) y Velocidad. Puede ver los informes en la nueva pestaña análisis.

Las métricas como la reducción del sprint, el flujo de trabajo y la velocidad del equipo le proporcionan la visibilidad del progreso del equipo y ayudan a responder preguntas como:

  • ¿Cuánto trabajo hemos dejado en este sprint? ¿Estamos en camino para completarlo?
  • ¿Qué paso del proceso de desarrollo tarda más? ¿Podemos hacer algo al respecto?
  • En función de las iteraciones anteriores, ¿cuánto trabajo deberíamos planear para el siguiente sprint?

Nota:

Los gráficos mostrados anteriormente en los encabezados se han reemplazado por estos informes mejorados.

Los nuevos informes son totalmente interactivos y permiten ajustarlos para sus necesidades. Puede encontrar los nuevos informes en la pestaña Análisis de cada centro.

  • El gráfico de agotamiento se puede encontrar en el centro de Sprints .

    Analytics tab in Sprint hub.

  • Se puede acceder a los informes cfd y velocidad desde la pestaña Análisis en Paneles y Trabajos pendientes haciendo clic en la tarjeta correspondiente.

    CFD and velocity reports in boards.

Con los nuevos informes tiene más control e información sobre su equipo. Estos son algunos ejemplos:

  • Los informes Sprint Burndown y Velocity se pueden establecer para usar el recuento de elementos de trabajo o la suma del trabajo restante.
  • Puede ajustar el período de tiempo de la quema de sprint sin afectar a las fechas del proyecto. Por lo tanto, si su equipo normalmente pasa el primer día de cada planeamiento de sprint, ahora puede coincidir con el gráfico para reflejarlo.
  • El gráfico Burndown ahora tiene una marca de agua que muestra los fines de semana.
  • El informe CFD le permite quitar columnas de placa como Diseño para obtener más atención sobre el flujo en el que los equipos tienen control.

Este es un ejemplo del informe cfd que muestra el flujo durante los últimos 30 días del trabajo pendiente de historias.

Example of the CFD report.

Ahora se puede realizar el seguimiento del gráfico de velocidad para todos los niveles de trabajo pendiente. Por ejemplo, ahora puede agregar características y epopeyas, mientras que antes del gráfico anterior solo admitía requisitos. Este es un ejemplo de un informe de velocidad para las últimas 6 iteraciones del trabajo pendiente características.

Example of a velocity report.

Aplicación de Azure Boards para Slack

Nos complace anunciar la nueva aplicación de Azure Boards para Slack. Con esta aplicación puede supervisar la actividad del elemento de trabajo y crear elementos de trabajo desde el canal de Slack.

La aplicación permite configurar y administrar suscripciones de eventos, incluidas la creación y las actualizaciones de elementos de trabajo, y para obtener notificaciones de estos eventos en el canal de Slack. Las conversaciones en el canal de Slack se pueden usar para crear elementos de trabajo. También recibirá notificaciones personales cuando se le asignen elementos de trabajo. Además, las versiones preliminares de las direcciones URL del elemento de trabajo le permitirán iniciar discusiones.

Azure Boards app for Slack.

Para instalar la aplicación Azure Boards, haga clic aquí.

Personalizar columnas del Panel de tareas

Nos complace anunciar que hemos agregado una opción para permitirle personalizar las columnas en el Panel de tareas. Ahora puede agregar, quitar, cambiar el nombre y reordenar las columnas.

Para configurar las columnas en el Panel de tareas, vaya a Opciones de columna.

Customizing columns on the taskboard.

Esta característica se ha priorizado en función de una sugerencia de la Comunidad de desarrolladores.

Active o desactive la función para mostrar u ocultar los elementos de trabajo secundarios completados en el trabajo pendiente

Muchas veces, al refinar el trabajo pendiente, solo quiere ver los elementos que no se han completado. Ahora, tiene la capacidad de mostrar u ocultar los elementos secundarios completados en el trabajo pendiente.

Si el botón de alternancia está activado, verá todos los elementos secundarios en un estado completado. Cuando el botón de alternancia está desactivado, todos los elementos secundarios en un estado completado se ocultarán del trabajo pendiente.

Show or hide child items on the backlog.

Ahora puede acceder fácilmente a los paneles, trabajos pendientes, consultas y sprints recientemente visitados desde el cuadro de búsqueda activando el cuadro de búsqueda en Azure Boards.

Activate the instant search box.

Además, puede buscar los paneles, trabajos pendientes, consultas y sprints en el proyecto escribiendo el nombre del panel en el cuadro de búsqueda. Ahora, las tablas que más le importan son solo un clic.

Search for a board name.

Se muestran las etiquetas más recientes cuando etiqueta un elemento de trabajo

Al etiquetar un elemento de trabajo, la opción autocompletar ahora mostrará hasta cinco de las etiquetas usadas más recientemente. Esto facilitará la adición de la información correcta a los elementos de trabajo.

Most recent used tags displayed when tagging a work item.

Azure Repos

Opciones mejoradas para filtrar la búsqueda de códigos

Anteriormente, la búsqueda de código admitía filtros de búsqueda de código 39, como comentario: y def:. Los datos sugieren que había muchos filtros que no se usan, por lo que estamos quitando algunos filtros y combinando otros. Con esta actualización hemos reducido el número de filtros a 19. Esto ayudará a hacer que las consultas de búsqueda de código sean más eficaces y reduzcan el desorden en la interfaz.

Code search filter options.

Por ejemplo, ahora func: se asigna a method:, es decir, si busca func:Account Administración, los resultados se asignarán a method:Account Administración. De forma similar , macrodef: y macroref: se asignan a macro:. Por otro lado, los filtros como union: y org: han quedado en desuso debido a la falta de uso.

Métricas de cobertura de código y directiva de rama para solicitudes de incorporación de cambios

Ahora puede ver las métricas de cobertura de código para ver los cambios en la vista de solicitud de incorporación de cambios (PR). Esto garantiza que haya probado adecuadamente los cambios a través de pruebas automatizadas. El estado de cobertura aparecerá como comentario en la información general de la solicitud de incorporación de cambios. Puede ver los detalles de la información de cobertura de cada línea de código que se cambia en la vista de diferencias de archivo.

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

Además, los propietarios de repositorios ahora pueden establecer directivas de cobertura de código y evitar que los cambios grandes y no probados se combinen en una rama. Los umbrales de cobertura deseados se pueden definir en un azurepipelines-coverage.yml archivo de configuración que está protegido en la raíz del repositorio y la directiva de cobertura se pueden definir mediante la configuración existente de una directiva de rama para la funcionalidad de servicios adicionales en Azure Repos.

Define coverage thresholds.

Filtre las notificaciones de comentarios de las solicitudes de incorporación de cambios

Los comentarios en las solicitudes de incorporación de cambios a menudo pueden generar mucho ruido debido a las notificaciones. Hemos agregado una suscripción personalizada que le permite filtrar las notificaciones de comentario a las que se suscribe por edad de comentario, comentario, comentario eliminado, usuarios mencionados, autor de solicitudes de incorporación de cambios, rama de destino y participantes de subprocesos. Para crear estas suscripciones de notificación, haga clic en el icono de usuario de la esquina superior derecha y vaya a Configuración del usuario.

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

Enlaces de servicio para comentarios de solicitudes de incorporación de cambios

Ahora puede crear enlaces de servicio para comentarios en una solicitud de incorporación de cambios basada en el repositorio y la rama de destino.

Service hooks for pull request comments.

Azure Artifacts

Comparta sus paquetes de forma pública con fuentes públicas (versión preliminar)

Ahora puede crear y almacenar los paquetes dentro de fuentes públicas. Los paquetes almacenados en fuentes públicas están disponibles para todos los usuarios de Internet sin autenticación, independientemente de si están en su organización o incluso han iniciado sesión en una organización de Azure DevOps. Obtenga más información sobre las fuentes públicas en nuestra documentación de fuentes o vaya directamente a nuestro tutorial para compartir paquetes públicamente.

Share your packages with public feeds.

Azure Pipelines

kustomize y kompose como opciones de simulación mediante "bake" en la tarea KubernetesManifest

kustomize (parte de Kubernetes sig-cli) le permite personalizar archivos YAML sin procesar y sin plantilla para varios propósitos y deja el ARCHIVO YAML original intacto. Se ha agregado una opción para kustomize en la acción bake de la tarea KubernetesManifest para que cualquier carpeta que contenga archivos kustomization.yaml se pueda usar para generar los archivos de manifiesto usados en la acción de implementación de la tarea KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose transformará los archivos de Docker Compose en un recurso de Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Soporte técnico para credenciales de administrador de clúster en tareas de HelmDeploy

Anteriormente, la tarea HelmDeploy usaba las credenciales de usuario del clúster para las implementaciones. Esto dio lugar a solicitudes de inicio de sesión interactivas y canalizaciones con errores para un clúster habilitado para RBAC basado en Azure Active Directory. Para solucionar este problema, se ha agregado una casilla que le permite usar las credenciales de administrador del clúster en lugar de las credenciales de usuario del clúster.

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

Administre variables de canalizaciones en el editor basado en YAML

Hemos actualizado la experiencia para administrar variables de canalización en el editor de YAML. Ya no tiene que ir al editor clásico para agregar o actualizar variables en las canalizaciones de YAML.

Manage pipeline variables in YAML editor.

Nuevas variables predefinidas en canalizaciones basadas en YAML

Las variables proporcionan una manera cómoda de obtener los bits de clave de los datos en distintas partes de la canalización. Con esta actualización, hemos agregado algunas variables predefinidas a un trabajo de implementación. El sistema establece automáticamente estas variables, cuyo ámbito es el trabajo de implementación específico y es de solo lectura.

  • Environment.Id: el identificador del entorno.
  • Environment.Name: el nombre del entorno destinado al trabajo de implementación.
  • Environment.ResourceId: el identificador del recurso en el entorno destinado al trabajo de implementación.
  • Environment.ResourceName: el nombre del recurso en el entorno destinado al trabajo de implementación.

Actualmente, puede vincular automáticamente elementos de trabajo con compilaciones clásicas. Sin embargo, esto no era posible con canalizaciones YAML. Con esta actualización, hemos solucionado esta brecha. Cuando se ejecuta correctamente una canalización mediante código de una rama especificada, Azure Pipelines asociará automáticamente la ejecución a todos los elementos de trabajo (que se deducen a través de las confirmaciones de ese código). Al abrir el elemento de trabajo, podrá ver las ejecuciones en las que se creó el código de ese elemento de trabajo. Para configurarlo, use el panel de configuración de una canalización.

Cancele una fase en la ejecución de una canalización de varias fases basada en YAML

Al ejecutar una canalización YAML de varias fases, ahora puede cancelar la ejecución de una fase mientras está en curso. Esto resulta útil si sabe que se producirá un error en la fase o si tiene otra ejecución que desea iniciar. Esta característica también es un requisito previo para admitir el reintento de una fase con errores en el futuro.

Aprobaciones en canalizaciones de varias fases basadas en YAML

Seguimos mejorando las canalizaciones YAML de varias fases, ya que ahora le permite agregar aprobaciones manuales a estas canalizaciones. Los propietarios de la infraestructura pueden proteger sus entornos y buscar aprobaciones manuales antes de que una fase de cualquier canalización se implemente en ellos. Con la segregación completa de roles entre los propietarios de la infraestructura (entorno) y la aplicación (canalización), se asegurará de que se cierre la sesión manual para la implementación en una canalización determinada y obtenga el control central para aplicar las mismas comprobaciones en todas las implementaciones al entorno.

Approvals in multi-stage YAML pipelines.

La canalización ejecuta la implementación en dev se detendrá para su aprobación al principio de la fase.

Pipeline runs deploying to dev will stop for approval.

Actualizaciones a las imágenes de canalizaciones alojadas

Hemos realizado actualizaciones en varias de las imágenes de máquina virtual hospedadas de Azure Pipelines. Puede encontrar más detalles sobre las versiones más recientes aquí. Los siguientes cambios se agregaron como parte de esta actualización:

  • Para VS2017 y VS2019:

  • Para Ubuntu 16.04:

    • Helm actualizado para extraer siempre la versión más reciente (ya no anclada en la versión 2.14.0)
    • Se han agregado varios contenedores populares de Docker.
    • Se ha actualizado Python a las versiones 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
    • Se cambiaron las rutas de acceso predeterminadas de Rust y las variables de entorno

  • Para todas las imágenes, se ha agregado una ImageVersion variable de entorno para la versión de la imagen.

Para obtener una lista completa de las herramientas disponibles para una imagen determinada, vaya a Configuración > detalles de los grupos > de agentes.

Mejoras al Proyecto de DevOps para máquinas virtuales

En esta actualización, hemos mejorado el flujo de trabajo de máquina virtual (VM) de DevOps Projects para incluir las máquinas virtuales que no cumplen la restricción de cuota por ubicación. Anteriormente, tenía que elegir la máquina virtual por nombre y oferta. Ahora, tiene una vista a petición con más detalles sobre las ofertas de máquina virtual, como el costo/mes, la RAM, los discos de datos, etc. Esto facilita la selección de la máquina virtual que necesita.

Enhancements to DevOps Project for virtual machine.

Grupo hospedado único

En el último sprint, se ha comunicado que estamos implementando un nuevo grupo hospedado denominado Azure Pipelines para reemplazar todos los demás grupos hospedados: Hosted, Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 con VS2019, Hosted macOS y Hosted macOS High Sierra. Este cambio se implementará con esta versión.

Tener varios grupos hospedados puede resultar confuso en ocasiones. No obtiene una imagen precisa de dónde se consume la simultaneidad. Por ejemplo, si tiene una simultaneidad de 10 trabajos paralelos, verá 10 agentes virtuales en cada uno de los grupos hospedados, que no es preciso. Cuando el trabajo está esperando un grupo hospedado específico (por ejemplo, HOSTED VS2017) con todos los agentes inactivos, puede pensar que el servicio Azure Pipelines se interrumpe sin darse cuenta de que la simultaneidad se consume posiblemente en otros grupos hospedados (por ejemplo, Hosted Ubuntu 1604).

Con este cambio, verá un único grupo hospedado que le proporcionará una imagen precisa del número de trabajos que se ejecutan en ese grupo. Tenemos previsto implementar este cambio en los próximos sprints. No tendrá que realizar ningún cambio en las canalizaciones, ya que redirigiremos automáticamente los trabajos de los grupos hospedados antiguos a la imagen adecuada en el nuevo grupo unificado.

Muestre la información del grupo correcto en cada trabajo

Anteriormente, al usar una matriz para expandir trabajos o una variable para identificar un grupo, teníamos problemas para mostrar la información correcta del grupo en las páginas de registros. Con esta actualización, se han corregido los problemas que provocaba que se mostrara información de grupo incorrecta para determinados trabajos.

Soporte técnico en el producto para la administración de pruebas no confiables

Las pruebas flaky pueden afectar a la productividad de los desarrolladores, ya que es posible que los errores de prueba no estén relacionados con los cambios sometidos a prueba. También pueden afectar a la calidad del código enviado. Este es el motivo por el que se ha agregado compatibilidad en el producto para la administración de pruebas poco confiables. Esta funcionalidad admite el ciclo de vida de un extremo a otro con detección, generación de informes y resolución. La administración de pruebas no confiables admite la detección personalizada y del sistema.

La detección del sistema está disponible a través de la funcionalidad de reejecución de tareas vsTest. Una prueba no confiable es aquella que proporciona resultados diferentes, como correcta o incorrecta, incluso cuando no hay cambios en el código fuente o el entorno de ejecución. Todas las ejecuciones adicionales de la prueba para la misma rama también se marcan poco a poco hasta que se resuelve y se desmarcan. También puede conectar el mecanismo de detección personalizado mediante nuestras API. Una vez que una prueba se identifica como despeja, puede obtener los detalles del informe de prueba en contexto de la canalización. Después, puede decidir si las pruebas poco eficaces afectan al error de la canalización. De forma predeterminada, la información de prueba es poco clara disponible como metadatos adicionales.

In-product support for flaky test management.

Este es un ejemplo de un informe con el resumen de pruebas.

Example of a report with the test summary.

Para obtener más información sobre la administración de pruebas poco confiables, consulte la documentación aquí.

Mejoras en el Centro de implementación para WebApp en Azure Portal

Hemos mejorado el Centro de implementación para WebApp en Azure Portal con compatibilidad con canalizaciones con varios artefactos. Ahora, si se implementa un artefacto no principal de Azure Pipelines en la aplicación web, obtendrá detalles relevantes de Azure Portal. También tendrá un vínculo profundo al repositorio implementado para navegar directamente al repositorio desde Azure Portal. El repositorio se puede hospedar en Azure Repos o en GitHub.

Desencadenadores de CI para ramas nuevas

Ha sido una solicitud pendiente larga para no desencadenar compilaciones de CI cuando se crea una nueva rama y cuando esa rama no tiene cambios. Considere los siguientes ejemplos:

  • Use la interfaz web para crear una nueva rama basada en una rama existente. Esto desencadenaría inmediatamente una nueva compilación de CI si el filtro de rama coincide con el nombre de la nueva rama. Esto no es deseado porque el contenido de la nueva rama es el mismo cuando se compara con la rama existente.
  • Tiene un repositorio con dos carpetas: aplicación y documentos. Configure un filtro de ruta de acceso para que ci coincida con "app". En otras palabras, no desea crear una nueva compilación si se ha insertado un cambio en la documentación. Cree una nueva rama localmente, realice algunos cambios en los documentos y, a continuación, inserte esa rama en el servidor. Hemos usado para desencadenar una nueva compilación de CI. Esto no es deseado, ya que se le pidió explícitamente que no busque cambios en la carpeta docs. Sin embargo, debido a la forma en que controlamos un nuevo evento de rama, parecería que también se ha realizado un cambio en la carpeta de la aplicación.

Ahora, tenemos una mejor manera de controlar ci para las nuevas ramas para solucionar estos problemas. Al publicar una nueva rama, buscamos explícitamente nuevas confirmaciones en esa rama y comprobamos si coinciden con los filtros de ruta de acceso.

Integración de Terraform con Azure Pipelines

Terraform es una herramienta de código abierto para desarrollar, cambiar y crear versiones de la infraestructura de forma segura y eficaz. Terraform codifica las API en archivos de configuración declarativos, lo que le permite definir y aprovisionar la infraestructura mediante un lenguaje de configuración de alto nivel. Puede usar la extensión de Terraform para crear recursos en todos los principales proveedores de infraestructura: Azure, Amazon Web Services (AWS) y Google Cloud Platform (GCP).

Para más información sobre la extensión de Terraform, consulte la documentación aquí.

Terraform integration with Azure Pipelines.

Integración con Google Analytics

El marco de experimentos de Google Analytics le permite probar casi cualquier cambio o variación en un sitio web o aplicación para medir su impacto en un objetivo específico. Por ejemplo, es posible que tenga actividades que quiera que completen los usuarios (por ejemplo, realizar una compra, suscribirse a un boletín) o métricas que quiera mejorar (por ejemplo, ingresos, duración de la sesión, tasa de rebote). Estas actividades le permiten identificar los cambios que merece la pena implementar en función del impacto directo que tienen en el rendimiento de la característica.

La extensión de experimentos de Google Analytics para Azure DevOps agrega pasos de experimentación a las canalizaciones de compilación y versión, por lo que puede iterar e implementar continuamente a un ritmo acelerado mediante la administración de los experimentos de forma continua mientras obtiene todas las ventajas de DevOps de Azure Pipelines.

Puede descargar la extensión de experimentos de Google Analytics desde Marketplace.

Integration with Google Analytics.

Almacenamiento en caché de canalización (versión preliminar pública)

El almacenamiento en caché de canalizaciones le permite guardar los resultados de una operación de ejecución prolongada, como una restauración de paquetes o una compilación de dependencias, y restaurarlos de nuevo durante la siguiente ejecución de una canalización. Esto puede dar lugar a compilaciones más rápidas.

Para obtener más información, consulte la entrada de blog con el anuncio completo aquí.

Comandos de administración de variables y grupos de variables de canalizaciones

Puede ser difícil migrar canalizaciones basadas en YAML de un proyecto a otro, ya que es necesario configurar manualmente las variables de canalización y los grupos de variables. Sin embargo, con el grupo de variables de canalización y los comandos de administración de variables, ahora puede crear scripts para configurar y administrar variables de canalización y grupos de variables que, a su vez, pueden controlar la versión, lo que le permite compartir fácilmente las instrucciones para mover y configurar canalizaciones de un proyecto a otro.

Ejecución de una canalización para una rama PR

Al crear una solicitud de incorporación de cambios, puede resultar difícil validar si los cambios podrían interrumpir la ejecución de la canalización en la rama de destino. Sin embargo, con la capacidad de desencadenar una ejecución de canalización o poner en cola una compilación para una rama de PR, ahora puede validar y visualizar los cambios que van ejecutándolo en la canalización de destino. Consulte la documentación del comando az pipelines run y az pipelines build queue para más información.

Omitir la primera ejecución de canalización

Al crear canalizaciones, a veces quiere crear y confirmar un archivo YAML y no desencadenar la ejecución de la canalización, ya que puede dar lugar a una ejecución errónea debido a una variedad de motivos: la infraestructura no está lista ni necesita crear y actualizar grupos de variables o variables, etc. Con la CLI de Azure DevOps, ahora puede omitir la primera ejecución de canalización automatizada en la creación de una canalización mediante la inclusión del parámetro --skip-first-run. Consulte la documentación del comando az pipeline create para más información.

Mejora del comando de punto de conexión de servicio

Los comandos de la CLI del punto de conexión de servicio solo admiten la configuración y administración de puntos de conexión de servicio de Azure rm y github. Sin embargo, con esta versión, los comandos de punto de conexión de servicio permiten crear cualquier punto de conexión de servicio proporcionando la configuración a través del archivo y proporciona comandos optimizados: az devops service-endpoint github y az devops service-endpoint azurerm, que proporcionan compatibilidad de primera clase para crear puntos de conexión de servicio de estos tipos. Consulte la documentación del comando para obtener más información.

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 comentarios 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,

Sam Guckenheimer