Experiencia de solicitud de incorporación de cambios mejorada

En este sprint, vamos a agregar varias mejoras a la experiencia de solicitud de incorporación de cambios. Esto incluye hacer que las comprobaciones opcionales sean más visibles, lo que permite hacer clics con Ctrl para abrir una nueva pestaña, agregar la ubicación a las anotaciones y mejorar el diseño del filtrado de comentarios.

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

Características

Azure Boards

• Quitar la regla "Asignada a" en el tipo de elemento de trabajo De error

Azure Repos

• Un lote de mejoras en la experiencia de solicitud de incorporación de cambios

Azure Pipelines

• Actualización de Node en el agente de Azure Pipelines
• Guardar un agente incorrecto para la investigación en agentes del conjunto de escalado
• Las canalizaciones más recientes de Ubuntu pronto usarán Ubuntu-20.04

Azure Boards

Quitar la regla "Asignada a" en el tipo de elemento de trabajo De error

Hay varias reglas del sistema ocultas en todos los diferentes tipos de elementos de trabajo en Agile, Scrum y CMMI. Estas reglas han existido durante más de una década y generalmente han funcionado bien sin ninguna queja. Sin embargo, hay un par de reglas que han agotado su bienvenida. Una regla en particular ha causado mucho dolor para los clientes nuevos y existentes y hemos decidido que era hora de eliminarlo. Esta regla existe en el tipo de elemento de trabajo Error en el proceso de Agile.

"Establezca el valor Asignado en Creado por cuando se cambia el estado a Resuelto"

Hemos recibido muchos comentarios sobre esta regla. En respuesta, hemos ido adelante y quitamos esta regla del tipo de elemento de trabajo Bug en el proceso agile. Este cambio afectará a cada proyecto mediante un proceso de Agile heredado heredado o un proceso de Agile heredado personalizado. Para aquellos clientes que quieran y dependan de esta regla actual, consulte nuestra entrada de blog sobre los pasos que puede seguir para volver a agregar la regla mediante reglas personalizadas.

Azure Repos

Un lote de mejoras en la experiencia de solicitud de incorporación de cambios

La nueva experiencia de solicitud de incorporación de cambios se encuentra en versión preliminar durante unos meses. Hemos estado abordando los comentarios que recibimos de muchos de ustedes. Nos complace anunciar las siguientes mejoras que verá con la implementación de este sprint:

Hacer que las comprobaciones opcionales sean más visibles

Los clientes usan comprobaciones opcionales para llamar la atención de un desarrollador a posibles problemas. En la experiencia anterior, solía ser obvio cuando se produce un error en estas comprobaciones. Sin embargo, no es el caso en la experiencia de versión preliminar. Una marca de verificación grande y verde en las comprobaciones necesarias enmascara los errores en comprobaciones opcionales. Los usuarios solo podían detectar que se produjo un error en las comprobaciones opcionales abriendo el panel de comprobaciones. Los desarrolladores no suelen hacerlo cuando no hay ninguna indicación de un problema. En esta implementación, hemos hecho que el estado de las comprobaciones opcionales sea más visible en el resumen.

Ctrl-clics en elementos de menú

Los menús de tabulación de una solicitud de incorporación de cambios no admitieron ctrl-clic. Los usuarios suelen abrir nuevas pestañas del explorador a medida que revisan una solicitud de incorporación de cambios. Esto se ha solucionado.

Ubicación de la anotación [+]

La lista de árboles de archivos de una solicitud de incorporación de cambios muestra una anotación [+] para ayudar a los autores y revisores a identificar nuevos archivos. Puesto que la anotación estaba después de los puntos suspensivos, a menudo no era visible para nombres de archivo más largos.

La lista desplegable de actualizaciones de solicitud recupera la información de tiempo

La lista desplegable para seleccionar actualizar y comparar archivos en una solicitud de incorporación de cambios perdió un elemento importante en la experiencia de versión preliminar. No se mostró cuando se realizó esa actualización. Esto se ha solucionado.

Diseño mejorado del filtro de comentarios

Al filtrar comentarios en la página de resumen de una solicitud de incorporación de cambios, la lista desplegable estaba a la derecha, pero el texto estaba alineado a la izquierda. Esto se ha solucionado.

Tenemos más mejoras planeadas en los dos sprints siguientes.

Azure Pipelines

Actualización de Node en el agente de Azure Pipelines

Actualización de lo que se publicó originalmente: debido a una incompatibilidad con Red Hat Enterprise Linux 6 y Node 14, hemos suspendido el trabajo en el nodo 14 y primero nos centraremos en llegar al nodo 10.

En esta versión, hemos empezado a alejarnos del nodo 6 y a una versión de Nodo compatible como el entorno de ejecución preferido para las tareas de Azure Pipelines. Hemos actualizado el primer lote de tareas incorporadas para que se ejecuten en el nodo 10. Este cambio marca el inicio de un proceso para quitar el nodo 6 del agente de forma predeterminada. El nodo 6 ha salido de la compatibilidad a largo plazo y a menudo se marca como un riesgo de seguridad por parte de los escáneres automatizados. Aunque creemos que es poco probable que el uso de Node 6 esté sujeto a la mayoría de los posibles errores, es importante que obtengamos tareas en un entorno de ejecución compatible. En el año natural 2021, tenemos previsto empezar a enviar una versión del agente sin Node 6.

Si usa cualquiera de las tareas habilitadas para Node 10, los agentes autohospedados se actualizarán para ejecutar las nuevas versiones de tareas. Aparte de eso, no debería haber ningún impacto para la mayoría de los clientes. Por otro lado, si es el autor de cualquier tarea, debe empezar a actualizarlas para que se ejecuten en el nodo 10. task.jsonEn , en execution, puede actualizar de Node a Node10. Si necesita admitir versiones anteriores del servidor, puede dejar el Node punto de entrada. Las instancias de Azure DevOps que comprenden el controlador de Node 10 la elegirán de forma predeterminada y las que no volverán a la implementación del nodo 6.

Guardar un agente incorrecto para la investigación en agentes del conjunto de escalado

Cuando se usan agentes de conjuntos de escalado, Azure Pipelines administra el escalado y la reducción vertical de instancias de agente. Cuando Azure Pipelines detecta una máquina virtual incorrecta en el conjunto de escalado, registrará el problema en la interfaz de usuario de diagnóstico del grupo e intentará eliminar la máquina virtual. Hay muchas razones por las que una máquina virtual puede estar en mal estado: es posible que la configuración de red del conjunto de escalado haya impedido que la extensión de Azure Pipelines descargue el agente más reciente, es posible que se haya producido un error en la extensión de script personalizado o que la imagen de máquina virtual del conjunto de escalado tenga un reinicio pendiente o pendiente de Windows Novedades.

Al eliminar máquinas virtuales con estado incorrecto, Azure Pipelines mantiene optimizado el grupo de agentes para ejecutar trabajos de CI/CD. En algunos casos, es posible que pueda usar la página de diagnóstico de Azure Pipelines (mostrada anteriormente) o la página diagnósticos de Azure para depurar este problema. Sin embargo, en muchos casos, la mejor manera de diagnosticar el problema es iniciar sesión en la máquina virtual y revisar los registros del agente y los registros del visor de eventos. En la actualidad, esto no es fácil de hacer, ya que la máquina virtual incorrecta se elimina automáticamente.

Con esta versión, hemos mejorado la capacidad de diagnóstico de máquinas virtuales incorrectas, ya que le proporcionamos la capacidad de guardar un agente incorrecto para su investigación.

Cuando se guarda un agente incorrecto, puede conectarse a la máquina virtual, depurar y recuperar los registros que necesite. Cuando haya terminado, puede liberar el agente y la máquina virtual asociada. Para obtener más información, consulte la sección sobre la solución de problemas de agentes incorrectos.

ubuntu-latest Las canalizaciones pronto usarán Ubuntu-20.04

Ubuntu 20.04 pronto será la versión predeterminada de la ubuntu-latest etiqueta en Azure Pipelines. Este cambio se implementará durante un período de varias semanas a partir del 30 de noviembre.

Si ve algún problema con las canalizaciones de Ubuntu:

• Archivo de un problema en el repositorio de entornos virtuales
• Vuelva a Ubuntu 18.04 especificando ubuntu-18.04 como en la vmImage canalización. Seguiremos admitiendo Ubuntu 18.04.

Tenga en cuenta que ubuntu-18.04 y ubuntu-20.04 pueden diferir tanto en las herramientas preinstaladas como en las versiones predeterminadas de las herramientas. Para obtener información sobre todas las diferencias, vea https://github.com/actions/virtual-environments/issues/1816.

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 saber lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

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

Gracias,

Matt Cooper