Personalización del nombre de rama predeterminado

  • Artículo

En este sprint, hemos introducido una nueva opción que permite a los clientes establecer un nombre de rama predeterminado personalizado para todos los repositorios nuevos.

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

Características

Azure Boards

Azure Repos

Azure Pipelines

Azure Boards

Las partes interesadas pueden mover elementos de trabajo entre columnas (versión preliminar privada)

Las partes interesadas siempre han podido cambiar el estado de los elementos de trabajo. Pero cuando van al panel Kanban, no pueden mover los elementos de trabajo de una columna a otra. En su lugar, las partes interesadas tendrían que abrir cada elemento de trabajo, de uno en uno y actualizar el valor de estado. Esto ha sido un punto problemático para los clientes y estamos encantados de anunciar una vista previa privada de este sprint que permitirá a las partes interesadas mover elementos de trabajo a través de columnas a bordo. Si está interesado en participar en la versión preliminar privada, envíenos un correo electrónico directamente con el nombre de su organización (ejemplo: dev.azure.com/{nombre de la organización}).

Azure Repos

Preferencia de nombre de rama predeterminada

Azure Repos ahora ofrece un nombre de rama predeterminado personalizable para Git. En la configuración del repositorio, puede elegir cualquier nombre de rama legal que se usará cuando se inicialice un repositorio. Azure Repos siempre ha admitido el cambio del nombre de rama predeterminado para un repositorio existente. Visite Administración de ramas para obtener más detalles.

 default-branch-name

Nota: si no habilita esta característica, los repositorios se inicializarán con el nombre predeterminado de Azure Repos. En este momento, ese valor predeterminado es master. Para respetar el compromiso de Microsoft y las solicitudes de los clientes para el lenguaje inclusivo, nos uniremos al mismo nivel del sector al cambiar este valor predeterminado a principal. Ese cambio se producirá más adelante este verano. Si desea seguir usando master, debe activar esta característica ahora y establecerla en master.

Azure Pipelines

Anuncios de imágenes de canalizaciones

Nota

Estamos trabajando constantemente para mejorar su experiencia mediante Azure Pipelines. Para obtener más información sobre las próximas actualizaciones en nuestras actualizaciones de imágenes de Windows,Linux/macOS, consulte aquí:

Las imágenes de Azure Pipelines se actualizan continuamente en un esfuerzo para proporcionar a los usuarios la mejor experiencia posible. Estas actualizaciones rutinarias están dirigidas principalmente a solucionar errores o software obsoleto. A menudo no tendrán ningún impacto en las canalizaciones, pero esto no siempre es así. La canalización puede verse afectada si toma una dependencia de un fragmento de software que se ha quitado o actualizado en la imagen.

Para obtener más información sobre las próximas actualizaciones en nuestras imágenes de Windows y Linux, lea los siguientes anuncios:

Para ver las notas de la versión para los próximos cambios (versión preliminar) e implementados, suscríbase a las siguientes notas de la versión:

Desencadenadores de varios repositorios

Puede especificar varios repositorios en un archivo YAML y hacer que una canalización se desencadene mediante actualizaciones en cualquiera de los repositorios. Esta característica es útil, por ejemplo, en los escenarios siguientes:

  • Se consume una herramienta o una biblioteca de un repositorio diferente. Quiere ejecutar pruebas para la aplicación siempre que se actualice la herramienta o biblioteca.
  • El archivo YAML se mantiene en un repositorio independiente del código de la aplicación. Quiere desencadenar la canalización cada vez que se inserta una actualización en el repositorio de aplicaciones.

Con esta actualización, los desencadenadores de varios repositorios solo funcionarán para los repositorios de Git en Azure Repos. No funcionan para los recursos del repositorio de GitHub o Bitbucket.

Este es un ejemplo que muestra cómo definir varios recursos de repositorio en una canalización y cómo configurar desencadenadores en todos ellos.

trigger:
  - main

resources:
  repositories:
    - repository: tools
      type: git
      name: MyProject/tools
      ref: main
      trigger:
        branches:
          include:
            - main
            - release

La canalización de este ejemplo se desencadenará si hay alguna actualización para:

  • main rama en el self repositorio que contiene el archivo YAML
  • main o release ramas en el tools repositorio

Para más información, consulte Varios repositorios en la canalización.

imagen de Novedades a macOS 10.14 (Mojave)

En las próximas semanas, actualizaremos la versión de Node.js en la imagen de macOS 10.14 (Mojave) de 6 a 8. Si todavía necesita usar node.js versión 6, considere la posibilidad de usar la tarea del instalador de herramientas de node.js aquí.

Además de estos cambios, la imagen de macOS 10.14 se agregará al repositorio de entorno virtual y comenzará a recibir actualizaciones de herramientas mensuales en lugar de semanales.

Las solicitudes de incorporación de cambios de borrador de GitHub no desencadenan canalizaciones

Al crear una solicitud de incorporación de cambios de borrador en Azure Repos, no desencadenaríamos una canalización de validación de solicitudes de incorporación de cambios configurada en la directiva de rama. Consideramos que una solicitud de incorporación de cambios de borrador es simplemente eso: un borrador para el que no deberíamos ejecutar automáticamente validaciones. Aunque este caso de uso funcionaba para Azure Repos, el mismo comportamiento no tenía repositorios de GitHub.

Con este cambio, también hacemos que la experiencia sea coherente con los repositorios de GitHub. Al crear una solicitud de incorporación de cambios de borrador en GitHub, no se iniciará automáticamente una canalización aunque configure un desencadenador de solicitud de incorporación de cambios para la rama de destino. Para validar los cambios en una solicitud de incorporación de cambios de borrador, puede iniciar manualmente una canalización que apunte a de ref la solicitud de incorporación de cambios.

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.

Hacer una sugerencia

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

Gracias,

Aaron Hallberg