Validación de seguridad y cumplimiento de canalización: actualización de Sprint 141

En la actualización de Sprint 141 de Azure DevOps Services, ahora puede incluir validaciones de cumplimiento y seguridad en Azure Pipelines. En Azure Repos, puede cambiar la rama de destino de las solicitudes de incorporación de cambios.

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

Características

General:

Azure Pipelines:

Azure Repos:

Administración:

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Obtenga información sobre las nuevas características que aparecen a continuación y diríjase a Azure DevOps Services para probarlas usted mismo.

General

En junio de este año, hemos implementado la primera iteración de nuestro nuevo modelo de navegación. Hemos pasado el verano mejorando esa experiencia en función de los comentarios que muchos de ustedes han proporcionado. ¡Gracias! Nuestro siguiente paso consiste en pasar del nuevo modelo que es una versión preliminar, a convertirse en la navegación del producto. Lea nuestra entrada de blog que describe los cambios recientes junto con nuestra programación para incorporar el nuevo modelo a todas las organizaciones.

Entendemos la importancia de la búsqueda y estamos devolviendo el cuadro de búsqueda expandido en el encabezado del producto. Además, ahora puede invocar el cuadro de búsqueda haciendo clic en "/" en cualquier página de servicio de Azure DevOps. Esta característica se ha priorizado en función de una sugerencia de voz del usuario.

Este es el cuadro de búsqueda predeterminado:

Cuadro de búsqueda predeterminado

Una vez que escriba "/", verá el cuadro de búsqueda expandido:

Cuadro de búsqueda expandido

Azure Pipelines

Azure Policy validaciones de seguridad y cumplimiento en canalizaciones

Queremos garantizar la estabilidad y la seguridad del software al principio del proceso de desarrollo, al tiempo que reúne el desarrollo, la seguridad y las operaciones. Para ello, hemos agregado compatibilidad con Azure Policy.

Azure Policy le ayuda a administrar y evitar problemas de TI con definiciones de directivas que aplican reglas y efectos a los recursos. Al usar Azure Policy, los recursos cumplen los estándares corporativos y los contratos de nivel de servicio.

Para cumplir con las directrices de cumplimiento y seguridad como parte del proceso de versión, hemos mejorado nuestra experiencia de implementación del grupo de recursos de Azure. Ahora, se produce un error en la tarea de implementación del grupo de recursos de Azure con errores relacionados con directivas pertinentes en caso de infracciones al implementar plantillas de ARM.

Azure Policy

Además, hemos agregado Azure Policy plantilla de definición de versión. Esto permitirá a los usuarios crear directivas de Azure y asignarlas a recursos, suscripciones o grupos de administración desde la propia definición de versión.

plantilla de Azure Policy

Entrega continua simplificada a máquinas virtuales de Azure

En esta versión, hemos agregado un nuevo asistente para simplificar el proceso de configuración de la entrega continua en Azure Virtual Machines. Una vez que especifique una organización de Azure DevOps y un grupo de implementación para registrar la máquina virtual, se creará automáticamente una canalización de versión con un paso de script de ejemplo. Si necesita aprovisionar recursos adicionales de Azure, ejecutar scripts, actualizar la aplicación o ejecutar pruebas de validación adicionales, puede personalizar fácilmente esta canalización de versión.

CI a máquinas virtuales de Azure

La tarea Xcode admite Xcode 10 recién publicada

Al coincidir con la versión de Xcode 10 de Apple, ahora puede establecer los proyectos para compilar o probarse específicamente con Xcode 10. La canalización también puede ejecutar trabajos en paralelo con una matriz de versiones de Xcode. Puede usar el grupo de agentes macOS hospedado por Microsoft para ejecutar estas compilaciones. Consulte las instrucciones para usar Xcode en Azure Pipelines.

Xcode 10

Mejoras de rendimiento al poner en cola una compilación

Cuando se usa un agente hospedado, se obtiene una máquina virtual nueva para cada trabajo. Esto proporciona una capa adicional de seguridad y control. Nunca tiene que preocuparse por una compilación anterior dejando salidas o haciendo algo malintencionado en la máquina. Sin embargo, las actividades de inicio por primera vez significaban retrasos entre cuando hace clic en Poner en cola una compilación y cuando la canalización se está ejecutando realmente. Hemos investigado y corregido muchos de estos retrasos y ahora estamos viendo una velocidad de 5X en la hora de cola a inicio en los grupos hospedados. Ahora puede comenzar las compilaciones más rápido, lo que significa que puede iterar más rápido.

Creación de una conexión de servicio de Azure con la entidad de servicio que se autentica con un certificado

Ahora puede definir una conexión de servicio de Azure en Azure Pipelines o Team Foundation Server (TFS) con una entidad de servicio y un certificado para la autenticación. Con la conexión de servicio de Azure ahora admite la entidad de servicio que se autentica con un certificado, ahora puede implementar en Azure Stack configurado con AD FS. Para crear una entidad de servicio con autenticación de certificado, consulte el artículo sobre cómo crear una entidad de servicio que se autentique con un certificado.

Conectarse a la entidad de servicio

Visualización del análisis de pruebas en Canalizaciones

El seguimiento de la calidad de las pruebas a lo largo del tiempo y la mejora de la garantía de pruebas es clave para mantener una canalización correcta. La característica de análisis de pruebas proporciona visibilidad casi en tiempo real de los datos de prueba para compilaciones y canalizaciones de versión. Ayuda a mejorar la eficacia de la canalización mediante la identificación de problemas repetitivos y de alta calidad de impacto.

Puede agrupar los resultados de las pruebas por varios elementos, identificar pruebas clave para los archivos de rama o de prueba, o explorar en profundidad una prueba específica para ver tendencias y comprender los problemas de calidad, como la flakiness.

Vea análisis de pruebas para compilaciones y versiones, versión preliminar a continuación:

Análisis de pruebas

Para obtener más información, vea la documentación.

Azure Repos

Cambio de la rama de destino de una solicitud de incorporación de cambios

Para la mayoría de los equipos, casi todas las solicitudes de incorporación de cambios se dirigen a la misma rama, como master o develop. Sin embargo, en el caso de que necesite tener como destino una rama diferente, es fácil olvidar cambiar la rama de destino del valor predeterminado. Con la nueva característica para cambiar la rama de destino de una solicitud de incorporación de cambios activa, ahora es una acción sencilla. Solo tiene que hacer clic en el icono de lápiz cerca del nombre de la rama de destino en el encabezado de solicitud de incorporación de cambios.

Cambiar rama de destino

Además de corregir errores, la característica para cambiar las ramas de destino también facilita la "retarget" de una solicitud de incorporación de cambios cuando se ha combinado o eliminado la rama de destino. Considere un escenario en el que tiene una solicitud de incorporación de cambios dirigida a una rama de características que contiene algunas características en las que dependen los cambios. Quiere revisar los cambios dependientes de forma aislada de otros cambios en la rama de características, por lo que inicialmente tiene como destino features/new-feature. A continuación, los revisores pueden ver solo los cambios y dejar los comentarios adecuados.

Ahora, tenga en cuenta lo que sucedería si la rama de características también tuviera una solicitud de incorporación de cambios activa y se combinara master antes de los cambios? Anteriormente, tendría que abandonar los cambios y crear una nueva solicitud de incorporación de cambios en master, o combinarla en features/new-featurey, a continuación, crear otra solicitud de incorporación de cambios de features/new-feature a master. Con esta nueva acción para actualizar la rama de destino, simplemente puede cambiar la rama de destino de la solicitud de incorporación de cambios de features/new-feature a master, conservando todo el contexto y los comentarios. Al cambiar la rama de destino, incluso se crea una nueva actualización de la solicitud de incorporación de cambios, lo que facilita la búsqueda de diferencias anteriores antes del cambio de rama de destino.

Actualización de la rama de destino

Protección de repositorios de Git con la configuración de compatibilidad multiplataforma

Dado que Git es una tecnología multiplataforma, es posible que los archivos o directorios encuentren su camino a un sistema de archivos en el que pueden ser incompatibles en una plataforma específica. Puede ver detalles sobre estas incompatibilidades en nuestra documentación.

Para ayudar a los equipos a proteger su repositorio y sus desarrolladores, hemos agregado una nueva configuración de repositorio para bloquear las inserciones que contienen confirmaciones con archivos o directorios que no son compatibles con una o varias plataformas del sistema operativo. Obtenga más información sobre esta configuración.

Administración

Compatibilidad con usuarios de AAD en cuentas de MSA

Azure DevOps ahora admite usuarios de AzureAD (AAD) que acceden a organizaciones respaldadas por MSA. Para los administradores, esto significa que si la organización de Azure DevOps usa MSAs para usuarios corporativos, ahora puede tener acceso a nuevos empleados mediante sus credenciales de AAD en lugar de crear una nueva identidad de MSA únicamente para su uso con Azure DevOps.

Todavía creemos que la mejor experiencia es para que los usuarios corporativos conecten Azure DevOps a AAD, pero hemos aprendido a principios de este año que los administradores necesitaban más tiempo para realizar esa conversión. Al permitir a los usuarios de AAD en organizaciones respaldadas por MSA, los nuevos usuarios podrán acceder a Azure DevOps una vez que Azure DevOps haya impedido la creación de nuevos usuarios de MSA con nombres de dominio personalizados respaldados por AzureAD al final del mes.

En el caso de las organizaciones que ya usan identidades de AAD con Azure DevOps, esta característica no se aplica. En el caso de las organizaciones que actualmente usan identidades de MSA, tenga en cuenta que todos los usuarios existentes pueden seguir iniciando sesión con sus identidades de MSA como lo hacen actualmente. Esto solo se aplica a los usuarios agregados en el futuro (que potencialmente no pueden crear una MSA con su dirección de correo electrónico corporativa).

Este es un escenario de ejemplo en el que esta experiencia puede ser útil: Dorothy es el propietario de la organización de Azure DevOps para su empresa, Fabrikam. Ella y su equipo de 10 miembros del equipo inician sesión en Azure DevOps con identidades de MSA que usan su dirección de correo electrónico corporativa, por ejemplo, Dorothy@fabrikam.com. Sam es un nuevo miembro del equipo que se unió hoy a la empresa. Dorothy lo invita a Azure DevOps mediante su correo electrónico, sam@fabrikam.com. Al hacer clic en el vínculo unirse ahora en el correo electrónico, puede iniciar sesión en Azure DevOps con la misma identidad de AAD que se le dio para acceder a su correo electrónico con Microsoft 365. Esto permite a Sam colaborar con sus 11 compañeros y le da a Dorothy la libertad de conectar su organización de Azure DevOps a AAD cuando esté lista.

Consulte nuestra entrada de blog para obtener más información.

Cómo enviar sus comentarios

Nos encantaría saber lo que piensas sobre estas características. Use el menú de comentarios para notificar un problema o proporcionar una sugerencia.

Hacer una sugerencia

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

Gracias,

Gopinath Chigakkagari (Twitter)