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, recuento de tareas y sumando campos personalizados. Además, hemos mejoramos la seguridad de las canalizaciones mediante la restricción del alcance 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:
Azure Pipelines:
- Canalizaciones de varias fases UX
- Orquestar 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
- Mejorar la seguridad de las canalizaciones mediante la restricción del alcance de los tokens de acceso
- Evaluar la comprobación de artefactos
- Compatibilidad con Markdown en mensajes de error de prueba automatizada
- Diagnósticos de programaciones CRON en YAML
- Actualizaciones de 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 Service Mesh Interface en la tarea KubernetesManifest
- ReviewApp en el entorno
Azure Artifacts:
- Experiencia actualizada de Conectar a la fuente
- Las fuentes públicas ahora están disponibles con carácter general con compatibilidad ascendente
- Crear fuentes de ámbito de proyecto desde el portal
Informes:
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
Canalizaciones de varias fases UX
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 sola 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 hacia 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 de versión preliminar. Para más información sobre las canalizaciones de varias fases, consulte la documentación aquí .
Gracias a sus comentarios, abordamos lo siguiente en las dos últimas actualizaciones.
- Detectabilidad de la vista de carpetas.
- Salto en la vista de registros.
- Mostrar fácilmente los registros de las tareas anteriores y actuales incluso cuando una ejecución está en curso.
- 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 de eso, la característica estará disponible con carácter general.
Orquestar 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 la orquestación de estrategias de implementación y facilita 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 de valor controlado en canalizaciones de varias fases, ahora puede reducir el riesgo implementando lentamente el cambio en un subconjunto pequeño. 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 de valor controlado para Kuberenetes implementará primero los cambios con un 10 % de pods seguidos del 20 % al supervisar el estado durante postRouteTraffic. Si todo va bien, se promoverá al 100%.
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 todas las canalizaciones que usan la pausa del recurso para las aprobaciones antes de comenzar la fase que consume el recurso. Es habitual que los propietarios de aplicaciones basadas en SOX restrinjan que el solicitante de la implementación apruebe 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
Se garantiza 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.
Los elementos de trabajo asociados a cada recurso consumido por la canalización.
Artefactos que la ejecución va a usar.
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 de recursos simplificada 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 de 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 se usaba una variable que hacía referencia a un recurso no autorizado.
Ahora estamos haciendo que sea más fácil administrar las autorizaciones de recursos. En lugar de generar 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.
Mejorar la seguridad de las canalizaciones mediante la restricción del alcance 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, se usa 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 versión clásica o YAML. Con esta actualización se presenta una configuración de organización para forzar a cada trabajo a obtener un token con ámbito de proyecto, independientemente de lo que esté configurado en la canalización. También se ha agregado la configuración en el nivel de proyecto. Ahora, todos los proyectos y organizaciones nuevos 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 Queue builds. Con esta actualización, hemos quitado este permiso al token de acceso. Si las canalizaciones necesitan este permiso, puede concederlo explícitamente a la cuenta de servicio de compilación de proyecto o a la cuenta de servicio de compilación de la colección de proyectos, según el token que use.
Evaluar 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 pausa 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 automatizada
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ósticos de programaciones CRON en YAML
Hemos visto un aumento constante en el uso de la sintaxis cron para especificar programaciones en las canalizaciones de YAML. A medida que escuchamos sus comentarios, oímos que era difícil determinar si Azure Pipelines había procesado la sintaxis correctamente. Anteriormente, tendría que esperar al tiempo real de la ejecución programada para depurar problemas de programación. Para ayudarle a diagnosticar errores de bifurcación o sintaxis, se ha 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.
Actualizaciones de 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 dar lugar a 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, se ha 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, se ha agregado seguridad de nivel de concentrador 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 imágenes 16.04 en los trabajos mediante ubuntu-16.04 explícitamente.
Implementaciones controladas basadas en Service Mesh Interface 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 igual que dividir el tráfico hasta el porcentaje deseado en el nivel de solicitud. Para abordar esto, se ha agregado compatibilidad con las 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 objetos TrafficSplit de SMI a los servicios estables, de línea de base y de valor controlado durante el ciclo de vida de la estrategia de implementación. La división de porcentaje deseado del tráfico entre estable, línea base y valor controlado son más precisas, 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 cómo se ven 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 toda la capacidad 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
Experiencia actualizada de Conectar a la fuente
El cuadro de diálogo Conectar a la 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 de configuración y expandimos 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, ampliamos 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 al poder subir hacia y desde fuentes privadas y con ámbito de proyecto.
Crear fuentes de á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, convertir el 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.
Generación de informes
Un widget Sprint Burndown con todo lo que has 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 grabación de sprint para características o epopeyas. El widget muestra el promedio de agotamiento, % completado y 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 gran información para mostrar, le permitimos cambiar su 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. El desplazamiento en un lado 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 a 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 de visitas de página agregadas 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.
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