Nuevo widget de reducción de sprint y seguridad mejorada de canalizaciones: actualización de Sprint 160

En la actualización sprint 160 de Azure DevOps, hemos agregado un nuevo widget de reducción de sprint que admite la grabación por puntos de historia, el recuento de tareas y la suma de campos personalizados. Además, se ha mejorado la seguridad de las canalizaciones mediante la restricción del ámbito de los tokens de acceso.

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

Novedades de Azure DevOps

Características

Azure Repos:

• Administración de directivas de rama entre repositorios

Azure Pipelines:

• Experiencia de usuario de canalizaciones de varias fases
• Orquestación de la estrategia de implementación controlada en el entorno para Kubernetes
• Directivas de aprobación para canalizaciones de YAML
• ACR como un recurso de canalización de primera clase
• Metadatos de recursos de canalización como variables predefinidas
• Rastreabilidad de canalizaciones y recursos de ACR
• Autorización de recursos simplificada en canalizaciones de YAML
• Mejora de la seguridad de la canalización mediante la restricción del ámbito de los tokens de acceso
• Evaluación de la comprobación de artefactos
• Compatibilidad con Markdown en mensajes de error de prueba automatizada
• Diagnóstico de programaciones cron en YAML
• Novedades a la tarea de implementación de plantillas de ARM
• Seguridad de nivel de proyecto para conexiones de servicio
• Grupo de Ubuntu 18.04
• Implementaciones controladas basadas en la interfaz de Service Mesh en la tarea KubernetesManifest
• ReviewApp in Environment

Azure Artifacts:

• Se ha actualizado la experiencia de conexión a la fuente
• Las fuentes públicas ahora están disponibles con carácter general con compatibilidad ascendente
• Creación de fuentes con ámbito de proyecto desde el portal

Informes:

• Un widget de Sprint Burndown con todo lo que ha estado pidiendo

Wiki:

• Desplazamiento sincrónico para editar páginas wiki
• Visitas a páginas wiki

Azure Repos

Administración de directivas de rama entre repositorios

Las directivas de rama son una de las características eficaces de Azure Repos que le ayudan a proteger ramas importantes. Aunque la capacidad de establecer directivas en el nivel de proyecto existe en la API REST, no había ninguna interfaz de usuario para ella. Ahora, los administradores pueden establecer directivas en una rama específica o en la rama predeterminada en todos los repositorios de su proyecto. Por ejemplo, un administrador podría requerir dos revisores mínimos para todas las solicitudes de incorporación de cambios realizadas en cada rama principal en todos los repositorios de su proyecto. Puede encontrar la característica Agregar protección de rama en la configuración del proyecto de repositorios.

Azure Pipelines

Experiencia de usuario de canalizaciones de varias fases

Hemos estado trabajando en una experiencia de usuario actualizada para administrar las canalizaciones. Estas actualizaciones hacen que las canalizaciones sean modernas y coherentes con la dirección de Azure DevOps. Además, estas actualizaciones reúnen canalizaciones de compilación clásicas y canalizaciones YAML de varias fases en una única experiencia. Por ejemplo, las siguientes funcionalidades se incluyen en la nueva experiencia; ver y administrar varias fases, aprobar ejecuciones de canalización, capacidad para desplazarse hasta atrás en los registros mientras una canalización sigue en curso y el estado por rama de una canalización.

Gracias a todos los que han probado la nueva experiencia. Si no lo ha probado, habilite las canalizaciones de varias fases en las características en versión preliminar. Para más información sobre las canalizaciones de varias fases, consulte la documentación aquí .

Gracias a sus comentarios, hemos abordado lo siguiente en las dos últimas actualizaciones.

1. Detectabilidad de la vista de carpetas.
2. Salto en la vista de registros.
3. Mostrar fácilmente los registros de tareas anteriores y actuales incluso cuando una ejecución está en curso.
4. Facilitar la navegación entre tareas al revisar los registros.

Nota

En la siguiente actualización, tenemos previsto activar esta característica de forma predeterminada para todos los usuarios. Todavía tendrá la opción de no participar en la versión preliminar. Unas semanas después, la característica estará disponible con carácter general.

Orquestación de la estrategia de implementación controlada en el entorno para Kubernetes

Una de las principales ventajas de la entrega continua de actualizaciones de aplicaciones es la capacidad de insertar rápidamente actualizaciones en producción para microservicios específicos. Esto le ofrece la capacidad de responder rápidamente a los cambios en los requisitos empresariales. El entorno se introdujo como un concepto de primera clase que permite orquestar estrategias de implementación y facilitar cero versiones de tiempo de inactividad. Anteriormente, se admitía la estrategia runOnce que ejecutó los pasos una vez secuencialmente. Con la compatibilidad con la estrategia controlada en canalizaciones de varias fases, ahora puede reducir el riesgo mediante la implementación lenta del cambio en un pequeño subconjunto. A medida que obtenga más confianza en la nueva versión, puede empezar a implementarla en más servidores de la infraestructura y enrutar a más usuarios a ella.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

La estrategia controlada para Kuberenetes implementará primero los cambios con un 10 % de pods seguidos del 20 % al supervisar el estado durante postRouteTraffic. Si todo va bien, promoverá al 100%.

Estamos buscando comentarios anticipados sobre la compatibilidad con el recurso de máquina virtual en entornos y la realización de una estrategia de implementación gradual en varias máquinas. Póngase en contacto con nosotros para inscribirse .

Directivas de aprobación para canalizaciones de YAML

En las canalizaciones de YAML, se sigue una configuración de aprobación controlada por el propietario del recurso. Los propietarios de recursos configuran aprobaciones en el recurso y en todas las canalizaciones que usan la pausa de recursos para las aprobaciones antes de comenzar la fase que consume el recurso. Es habitual que los propietarios de aplicaciones basadas en SOX restrinjan al solicitante de la implementación de aprobar sus propias implementaciones.

Ahora puede usar opciones de aprobación avanzadas para configurar directivas de aprobación, como el solicitante, no debe aprobar, requerir aprobación de un subconjunto de usuarios y tiempo de espera de aprobación.

ACR como un recurso de canalización de primera clase

Si necesita consumir una imagen de contenedor publicada en ACR (Azure Container Registry) como parte de la canalización y desencadenar la canalización cada vez que se publique una nueva imagen, puede usar el recurso de contenedor de ACR.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

Además, se puede acceder a los metadatos de imagen de ACR mediante variables predefinidas. En la lista siguiente se incluyen las variables de ACR disponibles para definir un recurso de contenedor de ACR en la canalización.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Metadatos de recursos de canalización como variables predefinidas

Hemos agregado variables predefinidas para los recursos de canalizaciones de YAML en la canalización. Esta es la lista de las variables de recursos de canalización disponibles.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

Rastreabilidad de canalizaciones y recursos de ACR

Garantizamos la rastreabilidad completa de E2E cuando se usan canalizaciones y recursos de contenedor de ACR en una canalización. Para cada recurso consumido por la canalización de YAML, puede realizar un seguimiento de las confirmaciones, los elementos de trabajo y los artefactos.

En la vista de resumen de ejecución de canalización, puede ver:

• Versión del recurso que desencadenó la ejecución. Ahora, la canalización se puede desencadenar tras la finalización de otra ejecución de canalización de Azure o cuando se inserta una imagen de contenedor en ACR.

  

• Confirmaciones consumidas por la canalización. También puede encontrar el desglose de las confirmaciones por cada recurso consumido por la canalización.

  

• Elementos de trabajo asociados a cada recurso consumido por la canalización.

• Los artefactos que están disponibles para su uso por la ejecución.

  

En la vista de implementaciones del entorno, puede ver las confirmaciones y los elementos de trabajo de cada recurso implementado en el entorno.

Autorización simplificada de recursos en canalizaciones de YAML

Un recurso es todo lo que usa una canalización que está fuera de la canalización. Los recursos deben estar autorizados para poder usarse. Anteriormente, al usar recursos no autorizados en una canalización YAML, se produjo un error de autorización de recursos. Tenía que autorizar los recursos desde la página de resumen de la ejecución con errores. Además, se produjo un error en la canalización si usaba una variable a la que se hacía referencia a un recurso no autorizado.

Ahora facilitamos la administración de las autorizaciones de recursos. En lugar de que se produce un error en la ejecución, la ejecución esperará los permisos en los recursos al principio de la fase que consume el recurso. Un propietario de recursos puede ver la canalización y autorizar el recurso desde la página Seguridad.

Mejora de la seguridad de la canalización mediante la restricción del ámbito de los tokens de acceso

Cada trabajo que se ejecuta en Azure Pipelines 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, cargar registros, resultados de pruebas, artefactos 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, hemos agregado las siguientes mejoras.

• Impedir que el token acceda a recursos fuera de un proyecto de equipo

  Hasta ahora, el ámbito predeterminado de todas las canalizaciones era la colección de proyectos de equipo. Puede cambiar el ámbito para que sea el proyecto de equipo en canalizaciones de compilación clásicas. Sin embargo, no tenía ese control para las canalizaciones de YAML o de versión clásica. Con esta actualización se presenta una configuración de organización para forzar que cada trabajo obtenga un token con ámbito de proyecto, independientemente de lo que esté configurado en la canalización. También hemos agregado la configuración en el nivel de proyecto. Ahora, todos los nuevos proyectos y organizaciones que cree tendrán activada automáticamente esta configuración.

  Nota

  La configuración de la organización invalida la configuración del proyecto.

  Activar esta configuración en proyectos y organizaciones existentes puede provocar un error en determinadas canalizaciones si las canalizaciones acceden a los recursos que están fuera del proyecto de equipo mediante tokens de acceso. Para mitigar los errores de canalización, puede conceder explícitamente acceso a la cuenta de servicio de compilación del proyecto al recurso deseado. Se recomienda encarecidamente activar esta configuración de seguridad.

• Eliminación de determinados permisos para el token de acceso

  De forma predeterminada, se conceden varios permisos al token de acceso; uno de estos permisos es Las compilaciones de cola. Con esta actualización, hemos quitado este permiso para el token de acceso. Si las canalizaciones necesitan este permiso, puede concederla explícitamente a la cuenta de servicio de compilación de proyectos o a la cuenta de servicio de compilación de la colección de proyectos, en función del token que use.

Evaluación de la comprobación de artefactos

Ahora puede definir un conjunto de directivas y agregar la evaluación de directivas como comprobación en un entorno para artefactos de imagen de contenedor. Cuando se ejecuta una canalización, la ejecución se detiene antes de iniciar una fase que usa el entorno. La directiva especificada se evalúa con los metadatos disponibles para la imagen que se va a implementar. La comprobación pasa cuando la directiva se realiza correctamente y marca la fase como errónea si se produce un error en la comprobación.

Compatibilidad con Markdown en mensajes de error de prueba automatizadas

Ahora se admite Markdown en mensajes de error para pruebas automatizadas. Puede dar formato fácilmente a los mensajes de error para la ejecución de pruebas y el resultado de la prueba para mejorar la legibilidad y facilitar la solución de problemas del error en Azure Pipelines. La sintaxis de Markdown admitida se puede encontrar aquí.

Diagnóstico de programaciones cron en YAML

Hemos observado un aumento constante en el uso de la sintaxis cron para especificar programaciones en las canalizaciones de YAML. A medida que escuchamos sus comentarios, hemos oído que era difícil determinar si Azure Pipelines había procesado correctamente la sintaxis. Anteriormente, tendría que esperar el tiempo real de la ejecución programada para depurar problemas de programación. Para ayudarle a diagnosticar errores de rama o sintaxis, hemos agregado un nuevo menú de acción para la canalización. Las ejecuciones programadas en el menú Ejecutar canalización le proporcionarán una vista previa de las próximas ejecuciones programadas de la canalización para ayudarle a diagnosticar errores con las programaciones cron.

Novedades a la tarea de implementación de plantillas de ARM

Anteriormente, no filtramos las conexiones de servicio en la tarea de implementación de plantillas de ARM. Esto puede provocar un error en la implementación si selecciona una conexión de servicio de ámbito inferior para realizar implementaciones de plantillas de ARM en un ámbito más amplio. Ahora, hemos agregado el filtrado de conexiones de servicio para filtrar las conexiones de servicio con ámbito inferior en función del ámbito de implementación que elija.

Seguridad de nivel de proyecto para conexiones de servicio

Con esta actualización, hemos agregado seguridad de nivel central para las conexiones de servicio. Ahora, puede agregar o quitar usuarios, asignar roles y administrar el acceso en un lugar centralizado para todas las conexiones de servicio.

Grupo de Ubuntu 18.04

Azure Pipelines ahora admite la ejecución de los trabajos en Ubuntu 18.04. Hemos actualizado el grupo de Azure Pipelines hospedado por Microsoft para incluir la imagen ubuntu-18.04. Ahora, cuando haga referencia al ubuntu-latest grupo en las canalizaciones de YAML, significará ubuntu-18.04 y no ubuntu-16.04. Todavía puede tener como destino 16.04 imágenes en los trabajos mediante ubuntu-16.04 explícitamente.

Implementaciones controladas basadas en la interfaz de Service Mesh en la tarea KubernetesManifest

Anteriormente, cuando se especificaba la estrategia de valor controlado en la tarea KubernetesManifest, la tarea crearía cargas de trabajo de línea base y de valor controlado cuyas réplicas equivalen a un porcentaje de las réplicas usadas para cargas de trabajo estables. Esto no era exactamente lo mismo que dividir el tráfico hasta el porcentaje deseado en el nivel de solicitud. Para abordar esto, hemos agregado compatibilidad con implementaciones controladas basadas en la interfaz de Service Mesh a la tarea KubernetesManifest.

La abstracción de la interfaz de Service Mesh permite la configuración de plug-and-play con proveedores de malla de servicio como Linkerd e Istio. Ahora, la tarea KubernetesManifest quita el trabajo duro de asignar los objetos TrafficSplit de SMI a los servicios estables, de línea base y controlados durante el ciclo de vida de la estrategia de implementación. La división porcentual deseada del tráfico entre estable, base de referencia y valor controlado es más precisa, ya que la división de tráfico porcentual se controla en las solicitudes del plano de malla de servicio.

A continuación se muestra un ejemplo de cómo realizar implementaciones controladas basadas en SMI de forma gradual.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

ReviewApp en el entorno

ReviewApp implementa todas las solicitudes de incorporación de cambios del repositorio de Git en un recurso de entorno dinámico. Los revisores pueden ver el aspecto de esos cambios, así como trabajar con otros servicios dependientes antes de combinarlos en la rama principal e implementarlos en producción. Esto le permitirá crear y administrar recursos de reviewApp y beneficiarse de todas las funcionalidades de seguimiento y diagnóstico de las características del entorno. Mediante la palabra clave reviewApp , puede crear un clon de un recurso (crear dinámicamente un nuevo recurso basado en un recurso existente en un entorno) y agregar el nuevo recurso al entorno.

A continuación se muestra un fragmento de código YAML de ejemplo de uso de reviewApp en entornos.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

Azure Artifacts

Se ha actualizado la experiencia de conexión a fuente.

El cuadro de diálogo Conectar a fuente es la entrada al uso de Azure Artifacts; contiene información sobre cómo configurar clientes y repositorios para insertar y extraer paquetes de fuentes en Azure DevOps. Hemos actualizado el cuadro de diálogo para agregar información detallada sobre la configuración y ampliar las herramientas para las que proporcionamos instrucciones.

Las fuentes públicas ahora están disponibles con carácter general con compatibilidad ascendente

La versión preliminar pública de las fuentes públicas ha recibido una gran adopción y comentarios. En esta actualización, hemos ampliado características adicionales a la disponibilidad general. Ahora, puede establecer una fuente pública como origen ascendente desde una fuente privada. Puede simplificar los archivos de configuración si puede subir hacia y desde fuentes privadas y de ámbito de proyecto.

Creación de fuentes con ámbito de proyecto desde el portal

Cuando publicamos fuentes públicas, también publicamos fuentes con ámbito de proyecto. Hasta ahora, las fuentes con ámbito de proyecto se podrían crear a través de las API REST o mediante la creación de una fuente pública y, a continuación, la activación del proyecto en privado. Ahora, puede crear fuentes con ámbito de proyecto directamente en el portal desde cualquier proyecto si tiene los permisos necesarios. También puede ver qué fuentes son proyecto y cuáles son el ámbito de la organización en el selector de fuentes.

Informes

Un widget sprint burndown con todo lo que ha estado pidiendo

El nuevo widget Sprint Burndown admite la grabación por puntos de historia, recuento de tareas o sumando campos personalizados. Incluso puede crear una reducción de sprint para características o epopeyas. El widget muestra la evolución media, el porcentaje completado y el aumento del ámbito. Puede configurar el equipo, lo que le permite mostrar las quemaduras de sprint para varios equipos en el mismo panel. Con toda esta excelente información para mostrar, le permitimos cambiar el tamaño hasta 10x10 en el panel.

Para probarlo, puede agregarlo desde el catálogo de widgets o editando la configuración del widget Sprint Burndown existente y activando el cuadro Probar la nueva versión ahora .

Nota

El nuevo widget usa Analytics. Hemos mantenido el Sprint Burndown heredado en caso de que no tenga acceso a Analytics.

Wiki

Desplazamiento sincrónico para editar páginas wiki

La edición de páginas wiki ahora es más fácil con el desplazamiento sincrónico entre la edición y el panel de vista previa. Al desplazarse por un lado, se desplazará automáticamente el otro lado para asignar las secciones correspondientes. Puede deshabilitar el desplazamiento sincrónico con el botón de alternancia.

Nota

El estado del botón de alternancia de desplazamiento sincrónico se guarda por usuario y organización.

Visitas a páginas wiki

Ahora puede obtener información sobre las visitas de la página para las páginas wiki. La API REST le permite acceder a la información de visitas de la página en los últimos 30 días. Puede usar estos datos para crear informes para las páginas wiki. Además, puede almacenar estos datos en el origen de datos y crear paneles para obtener información específica, como las páginas más vistas de la parte superior n.

También verá un recuento agregado de visitas de página durante los últimos 30 días en cada página.

Nota

Una visita de página se define como una vista de página por parte de un usuario determinado en un intervalo de 15 minutos.

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,

Jeff Beehler