Notas de la versión de Azure DevOps Server 2019

Comunidad de Desarrolladores | Requisitos del Sistema | Términos de Licencia | Blog DevOps | SHA-1 Hashes

En este artículo encontrará información sobre la versión más reciente de Azure DevOps Server.

Para más información sobre cómo instalar o actualizar una implementación de Azure DevOps Server, consulte Requisitos de Azure DevOps Server. Para descargar productos de Azure DevOps, visite la página Descargas de Azure DevOps Server.

La actualización directa a Azure DevOps Server 2020 es compatible con Azure DevOps Server 2019 o Team Foundation Server 2015 o versiones posteriores. Si la implementación de TFS está en TFS 2010 o versiones anteriores, debe realizar algunos pasos provisionales antes de actualizar a Azure DevOps Server 2019. Para más información, consulte Instalación y configuración de Azure DevOps local.

---

Actualización segura de Azure DevOps Server 2019 a Azure DevOps Server 2020

Azure DevOps Server 2020 presenta un nuevo modelo de retención de ejecución de canalización (compilación) que funciona en función de la configuración de nivel de proyecto.

Azure DevOps Server 2020 controla la retención de compilación de manera distinta, en función de las directivas de retención a nivel de canalización. Algunas configuraciones de directiva llevan a que las ejecuciones de canalización se eliminen después de la actualización. Las ejecuciones de canalización que se han conservado manualmente o que se conservan mediante un lanzamiento no se eliminarán después de la actualización.

Lea nuestra entrada de blog para más información sobre cómo actualizar de forma segura desde Azure DevOps Server 2019 a Azure DevOps Server 2020.

Fecha de lanzamiento de la revisión 16 de Azure DevOps Server 2019.0.1: 14 de noviembre de 2023

Hemos publicado una revisión para Azure DevOps Server 2019 Update 1.2 que incluye correcciones para lo siguiente.

• Se ha ampliado la lista de caracteres permitidos de las tareas de PowerShell para habilitar la validación de parámetros de argumentos de tareas de shell.

Nota:

Para implementar correcciones para esta revisión, tendrá que seguir varios pasos para actualizar manualmente las tareas.

Instalación de revisiones

Importante

Publicamos actualizaciones del agente de Azure Pipelines con el parche 15, publicado el 12 de septiembre de 2023. Si no instaló las actualizaciones del agente como se describe en las notas de la versión de Patch 15, se recomienda instalar estas actualizaciones antes de instalar patch 16. La nueva versión del agente después de instalar patch 15 será 3.225.0.

Configuración de TFX

1. Siga los pasos descritos en la documentación cargar tareas en la colección de proyectos para instalar e iniciar sesión con tfx-cli.

Actualización de tareas mediante TFX

Archivo	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Descargue y extraiga Tasks20231103.zip.
2. Cambie el directorio a los archivos extraídos.
3. Ejecute los siguientes comandos para cargar las tareas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Requisitos de canalización

Para utilizar el nuevo comportamiento, se debe establecer una variable AZP_75787_ENABLE_NEW_LOGIC = true en las canalizaciones que utilizan las tareas afectadas.

• Sobre clásico:

  Defina la variable en la pestaña de variables de la canalización.

• Ejemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Fecha de lanzamiento de la revisión 15 de Azure DevOps Server 2019.0.1: 12 de septiembre de 2023

Hemos publicado una revisión para Azure DevOps Server 2019.0.1 que corrige lo siguiente.

• CVE-2023-33136: Vulnerabilidad de ejecución remota de código de Azure DevOps Server.
• CVE-2023-38155: Vulnerabilidad de elevación de privilegios de Azure DevOps Server y Team Foundation Server.

Importante

Implemente la revisión en un entorno de prueba y asegúrese de que las canalizaciones del entorno funcionan según lo previsto antes de aplicar la corrección a producción.

Nota:

Para implementar correcciones para esta revisión, tendrá que seguir varios pasos para actualizar manualmente el agente y las tareas.

Instalación de revisiones

1. Descargue e instale la revisión 15 de Azure DevOps Server 2019.0.1.

Actualización del agente de Azure Pipelines

1. Descargue el agente desde: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Siga los pasos descritos en la documentación de agentes de Windows autohospedados para implementar el agente.  

Nota:

AZP_AGENT_DOWNGRADE_DISABLED debe establecerse en “true” para evitar que el agente sea degradado. En Windows, se puede utilizar el siguiente comando en un símbolo del sistema con privilegios de administrador, seguido de un reinicio. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configuración de TFX

1. Siga los pasos descritos en la documentación cargar tareas en la colección de proyectos para instalar e iniciar sesión con tfx-cli.

Actualización de tareas mediante TFX

1. Descargar y extraer Tasks_20230825.zip.
2. Cambie el directorio a los archivos extraídos.
3. Ejecute los siguientes comandos para cargar las tareas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Requisitos de canalización

Para utilizar el nuevo comportamiento, se debe establecer una variable AZP_75787_ENABLE_NEW_LOGIC = true en las canalizaciones que utilizan las tareas afectadas.

• Sobre lo clásico

  Defina la variable en la pestaña variable de la canalización.

• Ejemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Fecha de lanzamiento del parche 14 de Azure DevOps Server 2019.0.1: 8 de agosto de 2022

Hemos publicado una revisión para Azure DevOps Server 2019.0.1 que corrige lo siguiente.

• CVE-2023-36869: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.

Fecha de lanzamiento de la revisión 13 de Azure DevOps Server 2019.0.1: 17 de mayo de 2022

Hemos publicado una revisión para Azure DevOps Server 2019.0.1 que corrige lo siguiente.

• Revoque todos los tokens de acceso personal después de deshabilitar la cuenta de Active Directory de un usuario.

Fecha de lanzamiento de la revisión 12 de Azure DevOps Server 2019.0.1: 26 de enero de 2022

Hemos publicado una revisión para Azure DevOps Server 2019.0.1 que corrige lo siguiente.

• Se ha solucionado la vulnerabilidad de Elasticsearch mediante la eliminación de la clase jndilookup de los archivos binarios de log4j.

Pasos de instalación

1. Actualice el servidor con el parche 12.
2. Compruebe el valor del Registro en HKLM:\Software\Elasticsearch\Version. Si el valor del Registro no está ahí, agregue un valor de cadena y establezca la versión en 5.4.1 (Nombre = Version, Valor = 5.4.1).
3. Ejecute el comando de actualización PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update, tal como se proporciona en el archivo léame. Puede devolver una advertencia como la siguiente: No se puede conectar al servidor remoto. No cierre la ventana, ya que el proceso de actualización realiza reintentos hasta que se completa.

Nota:

Si Azure DevOps Server y Elasticsearch están instalados en diferentes máquinas, siga los pasos que se describen a continuación.

1. Actualice el servidor con el parche 12.
2. Compruebe el valor del Registro en HKLM:\Software\Elasticsearch\Version. Si el valor del Registro no está ahí, agregue un valor de cadena y establezca la versión en 5.4.1 (Nombre = Version, Valor = 5.4.1).
3. Copie el contenido de la carpeta denominada zip, que se encuentra en C:\Program Files\{TFS Version Folder}\Search\zip, en la carpeta de archivos remotos de Elasticsearch.
4. Ejecute Configure-TFSSearch.ps1 -Operation update en la máquina del servidor de Elasticsearch.

HASH SHA-256: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 Revisión 11 Fecha de lanzamiento: 10 de agosto de 2021

Hemos publicado una revisión para Azure DevOps Server 2019.0.1 que corrige lo siguiente.

• Se ha corregido el error en la interfaz de usuario de la definición de la compilación.

Fecha de lanzamiento de la revisión 10 de Azure DevOps Server 2019.0.1: 13 de abril de 2021

Hemos publicado una revisión para Azure DevOps Server 2019.0.1 que corrige lo siguiente.

• CVE-2021-27067: Divulgación de información

Para aplicar el parche 10, tendrá que instalar la AzureResourceGroupDeploymentV2 tarea.

Instalación de tareas AzureResourceGroupDeploymentV2

Nota:

Todos los pasos mencionados a continuación deben realizarse en una máquina Windows.

Instalar

1. Extraiga el paquete AzureResourceGroupDeploymentV2.zip en una nueva carpeta del equipo. Por ejemplo: AzureResourceGroupDeploymentV2.

2. Descargue e instale Node.js 14.15.1 y npm (incluidos con la descarga de Node.js) según su máquina.

3. Abra una ventana de comandos en modo administrador y ejecute el siguiente comando para instalar tfx-cli.

npm install -g tfx-cli

4. Cree un token de acceso personal con privilegios de acceso completo y cópielo. Este token de acceso personal se usará al ejecutar el comando tfx login.

5. Desde el símbolo del sistema, ejecute el siguiente comando. Cuando se le solicite, escriba la dirección URL del servicio y el token de acceso personal.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Ejecute el siguiente comando para cargar la tarea en el servidor. Use la ruta de acceso del archivo .zip extraído en el paso 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Fecha de lanzamiento de la revisión 9 de Azure DevOps Server 2019.0.1: 8 de diciembre de 2020

Hemos publicado una revisión para Azure DevOps Server 2019.0.1 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• CVE-2020-1325: Vulnerabilidad de suplantación de identidad de Azure DevOps Server
• CVE-2020-17135: Vulnerabilidad de suplantación de identidad de Azure DevOps Server
• CVE-2020-17145: Vulnerabilidad de suplantación de identidad de Azure DevOps Server y Team Foundation Server
• Corrección de un problema con TFVC que no procesa todos los resultados

Importante

Lea las instrucciones completas que se proporcionan a continuación antes de instalar este parche.

Instalación general de parches

Si tiene Azure DevOps Server 2019.0.1, debe instalar La revisión 9 de Azure DevOps Server 2019.0.1.

Comprobación de la instalación

• Opción 1: Ejecutar devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.exe es el archivo que se descarga del vínculo anterior. La salida del comando indicará que se ha instalado el parche o que no lo está.

• Opción 2: Compruebe la versión del archivo siguiente: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 está instalado en c:\Program Files\Azure DevOps Server 2019 de forma predeterminada. Después de instalar Azure DevOps Server 2019.0.1 Patch 9, la versión será 17.143.30723.4 .

Instalación de tareas de AzurePowerShellV4

Nota:

Todos los pasos mencionados a continuación deben realizarse en una máquina Windows.

Requisitos previos

1. Instale el módulo Az de Azure PowerShell en la máquina del agente privado.

2. Cree una canalización con la tarea AzurePowerShellV4. Solo verá una falla en el error estándar en la tarea.

Instalar

1. Extraiga el paquete AzurePowerShellV4.zip en una carpeta denominada AzurePowerShellV4.

2. Descargue e instale Node.js 14.15.1 y npm (incluidos con la descarga de Node.js) según su máquina.

3. Abra una consola de comandos en modo administrador y ejecute el siguiente comando para instalar tfx-cli.

npm install -g tfx-cli

4. Cree un token de acceso personal con privilegios de acceso completo y cópielo. Este token de acceso personal se usará al ejecutar el comando tfx login.

5. Ejecuta lo siguiente desde la línea de comandos. Cuando se le solicite, escriba la dirección URL del servicio y el token de acceso personal.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Ejecute el siguiente comando para cargar la tarea en el servidor. La ruta de acceso del paquete extraído será D:\tasks (1)\AzurePowerShellv4.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Fecha de lanzamiento de la revisión 8 de Azure DevOps Server 2019.0.1: 8 de septiembre de 2020

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• DTS 1713492: comportamiento inesperado al agregar grupos de AD a permisos de seguridad.

Fecha de lanzamiento de la revisión 7 de Azure DevOps Server 2019.0.1: 14 de julio de 2020

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• CVE-2020-1326: Vulnerabilidad de Cross-site Scripting
• La canalización de compilación muestra una conexión incorrecta para usuarios no autorizados al seleccionar Otro origen de Git.
• Se ha corregido el error al cambiar la configuración de Herencia a Activado o Desactivado en la definición de compilación XAML.

Fecha de lanzamiento del Parche 6 de Azure DevOps Server 2019.0.1: 10 de junio de 2020

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• CVE-2020-1327: Asegúrese de que Azure DevOps Server sane las entradas del usuario
• Adición de compatibilidad con SHA2 en SSH en Azure DevOps

Fecha de lanzamiento de la revisión 5 de Azure DevOps Server 2019.0.1: 10 de marzo de 2020

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige lo siguiente. Consulte la entrada de blog para obtener más información.

• CVE-2020-0700: Vulnerabilidad de scripting entre sitios
• CVE-2020-0758: Vulnerabilidad de elevación de privilegios
• CVE 2020-0815: Vulnerabilidad de elevación de privilegios

Fecha de lanzamiento de la revisión 3 de Azure DevOps Server 2019.0.1: 10 de septiembre de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige los siguientes errores. Consulte la entrada de blog para obtener más información.

• CVE-2019-1305: Vulnerabilidad de scripting entre sitios (XSS) en Repos
• CVE-2019-1306: Vulnerabilidad de ejecución remota de código en Wiki

---

Fecha de lanzamiento del parche 2 para Azure DevOps Server 2019.0.1: 13 de agosto de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige el siguiente error. Consulte la entrada de blog para obtener más información.

• Hemos agregado información a las conexiones de servicio para aclarar que, de forma predeterminada, están autorizadas para todas las canalizaciones.

---

Fecha de lanzamiento de la revisión 1 de Azure DevOps Server 2019.0.1: 9 de julio de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019.0.1 que corrige los siguientes errores. Consulte la entrada de blog para obtener más información.

• CVE-2019-1072: Vulnerabilidad de ejecución remota en el seguimiento de elemento de trabajo
• CVE-2019-1076: Vulnerabilidad de scripting entre sitios (XSS) en solicitudes de extracción

---

Fecha de lanzamiento de Azure DevOps Server 2019.0.1: 21 de mayo de 2019

Azure DevOps Server 2019.0.1 es un conjunto de soluciones de errores. Incluye todas las correcciones de las revisiones de Azure DevOps Server 2019 publicadas anteriormente. Puede instalar directamente Azure DevOps Server 2019.0.1 o actualizar desde Azure DevOps Server 2019 o Team Foundation Server 2012 o versiones posteriores.

Nota:

La herramienta de migración de datos estará disponible para Azure DevOps Server 2019.0.1 aproximadamente tres semanas después de esta versión. Puede ver la lista de versiones actualmente admitidas para la importación en esta página.

En esta versión se incluyen las correcciones de los siguientes errores:

Azure Boards

• "Los criterios de campo para este plan tienen un error" al configurar un plan. Se notifica a través de la Comunidad de desarrolladores.
• apiwitcontroller.executequery produce una excepción cuando una consulta tiene la misma columna varias veces.
• En el modelo de objetos de cliente, utilizando el ámbito oauth vso.work_full, falla la función WorkItemServer.DownloadFile().
• Copiar una imagen incrustada desde un campo de elemento de trabajo a otro campo de elemento de trabajo en un proyecto diferente puede crear una imagen rota.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• La pestaña Test Analytics Tab tiene una estrella (*) que indica vista previa, aunque esta característica no está en vista previa.
• En la pestaña Versiones, la acción para administrar la seguridad ahora se muestra a todos los usuarios independientemente de si pueden cambiar los permisos o no.
• En las páginas de versiones, la acción iniciar borrador de lanzamiento estaba creando una nueva versión, pero ahora inicia el borrador.

Azure Test Plans (planes de prueba)

• El filtro de 1 hora en TestRuns y TestResults CompletedDate son demasiado granulares.
• En el tipo de elemento de trabajo Test Case, no se debe localizar el tipo "Test Case".
• Los casos de prueba no aparecen en MTM ni en un explorador.
• Etapa de validación: no tiene permiso para iniciar implementaciones en la canalización de publicación asociada al ejecutar pruebas automatizadas desde un plan de pruebas. Se notifica a través de la Comunidad de desarrolladores.
• Con la API de eliminación de casos de prueba, los casos de prueba se pueden eliminar de otros proyectos. Se notifica a través de la Comunidad de desarrolladores.
• Al hacer clic en un vínculo de elemento de trabajo en Ejecutor de pruebas, se abre la dirección URL del elemento de trabajo dentro del ejecutor de pruebas en lugar del explorador predeterminado.
• El estado del caso de prueba no se actualiza para los usuarios que cierran la sesión del ejecutor de pruebas.
• El nombre de usuario y la dirección de correo electrónico no se muestran en la lista desplegable del usuario en Ejecutor de pruebas.

Azure Artifacts

• Mover hacia arriba y Mover hacia abajo no se localizan en Upstreams.

Análisis

• Los informes de análisis pueden mostrar datos incompletos porque el modelo está marcado como "listo" antes de completarse realmente.
• Los widgets de velocidad, retroceso y acumulación muestran diferentes trabajos planeados para los usuarios en distintas zonas horarias.
• Se puede aplicar una suspensión en el procesamiento de datos de Analytics durante el mantenimiento, lo que puede generar informes desactualizados.

General

• Los elementos de navegación laterales izquierdos se comprimen en IE cuando no hay suficiente espacio.

Administración

• Registro adicional agregado a la actualización de recopilación para ayudar a depurar problemas.
• Cuando se produce un error en TfsConfig offlineDetach, el mensaje de error no es accionable.
• Se interrumpe el servicio TfsJobAgent.
• La extensión Search no se instala una vez completada la configuración.
• La consola de administración deja de responder cuando la base de datos de configuración está dañada.
• Es posible que los enlaces de servicio no procesen correctamente las notificaciones.
• La indexación de código no se inicia después de configurar la búsqueda.
• Hay cadenas no localizadas en los resultados de las páginas de búsqueda.

Esta versión incluye la siguiente actualización:

Compatibilidad con Visual Studio 2019 (VS2019) en la tarea de prueba de Visual Studio

Hemos agregado compatibilidad con Visual Studio 2019 a la tarea de prueba de Visual Studio en las canalizaciones. Para ejecutar pruebas mediante la plataforma de pruebas para Visual Studio 2019, seleccione las opciones Más recientes o Visual Studio 2019 en la lista desplegable Versión de la plataforma de pruebas.

---

Fecha de lanzamiento de la revisión 2 de Azure DevOps Server 2019: 14 de mayo de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019 que corrige los errores siguientes. Consulte la entrada de blog para obtener más información.

• CVE-2019-0872: Vulnerabilidad de scripting entre sitios (XSS) en los Planes de Prueba
• CVE-2019-0971: Vulnerabilidad de divulgación de información en la API de Repos
• CVE-2019-0979: Vulnerabilidad de scripting entre sitios (XSS) en el centro de usuarios

---

Fecha de lanzamiento de la revisión 1 de Azure DevOps Server 2019: 9 de abril de 2019

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019 que corrige los errores siguientes. Consulte la entrada de blog para obtener más información.

• CVE-2019-0857: Vulnerabilidad de suplantación de identidad en la Wiki
• CVE-2019-0866: Vulnerabilidad de ejecución remota de código en Pipelines
• CVE-2019-0867: Vulnerabilidad de scripting entre sitios (XSS) en Pipelines
• CVE-2019-0868: Vulnerabilidad de secuencias de comandos en sitios cruzados (XSS) en canalizaciones
• CVE-2019-0869: vulnerabilidad de inyección de HTML en canalizaciones
• CVE-2019-0870: Vulnerabilidad de secuencias de comandos entre sitios (XSS) en Pipelines
• CVE-2019-0871: Vulnerabilidad de cross site scripting (XSS) en Pipelines
• CVE-2019-0874: Vulnerabilidad de scripting entre sitios (XSS) en canalizaciones
• CVE-2019-0875: Vulnerabilidad de elevación de privilegios en paneles

---

Fecha de lanzamiento de Azure DevOps Server 2019: 5 de marzo de 2019

Nota:

La herramienta de migración de datos estará disponible para Azure DevOps Server 2019 aproximadamente tres semanas después de esta versión. Puede ver la lista de versiones actualmente admitidas para la importación en esta página.

---

Fecha de lanzamiento de RC2: 22 de enero de 2019

Resumen de las novedades de Azure DevOps Server 2019 RC2

Hemos agregado las siguientes características a RC2:

• Vinculación de solicitudes de incorporación de cambios y confirmaciones de GitHub Enterprise a elementos de trabajo de Azure Boards
• Configuración de compilaciones mediante YAML
• Las anotaciones de las tarjetas incluyen fallos y tipos de elementos de trabajo personalizados
• Selector de ramas mejorado
• Cambios en los artefactos y licencias del pipeline de implementación de la Gestión de Versiones

---

Fecha de lanzamiento de RC1: 19 de noviembre de 2018

Resumen de las novedades de Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 presenta una nueva experiencia de navegación y muchas características nuevas. Entre los aspectos destacados se incluyen:

• Nueva experiencia de navegación
• La extensión de Marketplace de Analytics para informes ya está disponible.
• Compatibilidad con Azure SQL Database
• Herencia de procesos en nuevas colecciones
• Nuevo centro de elementos de trabajo
• Nuevos paneles, trabajos pendientes y centros de Sprints
• Nuevo centro de consultas
• Estandarización de las descripciones de solicitudes de incorporación de cambios mediante plantillas
• Cambiar la rama de destino de una solicitud de incorporación de cambios
• Gestiona las canalizaciones de compilación usando la nueva página Compilaciones
• Gestiona las canalizaciones de las versiones mediante la nueva página de versiones
• Visualizar el progreso de la versión
• Actualiza localmente tu agente
• Exponer y gestionar progresivamente las implementaciones utilizando puertas de control de lanzamientos
• Orígenes ascendentes
• Crear tabla de contenido para páginas wiki

También puede ir a secciones individuales para ver las nuevas características:

• General
• Tableros
• Repos
• Canalizaciones
• Test Plans
• Artefactos
• Wiki
• Informes

---

General

Anuncio de Azure DevOps Server

El 10 de septiembre, anunciamos Azure DevOps como la evolución de Visual Studio Team Services y Team Foundation Server. Azure DevOps Server 2019 es nuestra primera versión local con esta nueva marca. Puede encontrar más información en nuestra entrada de blog.

Nueva experiencia de navegación

Presentamos una nueva navegación para modernizar la experiencia del usuario. Esta nueva navegación se ha implementado en el servicio Azure DevOps y ahora está disponible en Azure DevOps Server 2019. Consulte nuestro blog para obtener más información.

Cambios en artefactos y licencias del pipeline de implementación de Release Management

En función de los comentarios de los usuarios, estamos realizando dos cambios clave en nuestras licencias con Azure DevOps Server 2019. En primer lugar, los clientes ya no tendrán que comprar la extensión Artifact para usar Artifacts. Ahora se incluirá una licencia de uso de artefactos en la licencia básica. Todos los usuarios que tengan asignada una licencia básica ahora podrán usar Artefactos. En segundo lugar, los clientes ya no tendrán que comprar las canalizaciones de implementación de Release Management. Al igual que las canalizaciones de compilación, las canalizaciones de implementación de Release Management ahora se incluyen con Azure DevOps Server 2019.

Compatibilidad con Azure SQL Database

Para simplificar la experiencia de ejecución de Azure DevOps 2019 en Azure, hemos habilitado la compatibilidad con Azure SQL Database (uso general S3 y versiones posteriores). Esto le permitirá aprovechar amplias características de copia de seguridad y opciones de escalado para satisfacer sus necesidades, a la vez que reduce la sobrecarga administrativa de ejecutar el servicio. Tenga en cuenta que la máquina virtual host debe encontrarse en la misma región de Azure que la base de datos para mantener la latencia baja. Consulta la documentación para obtener más información.

APIs SOAP del modelo de objetos de cliente para elementos de trabajo y pruebas en versiones futuras

Azure DevOps Server 2019 sigue admitiendo la API SOAP de seguimiento de elementos de trabajo y el modelo de objetos de cliente. Sin embargo, se marcará como en desuso en futuras versiones de Azure DevOps Server. Puede encontrar más información en nuestra documentación.

Herencia de procesos en colecciones nuevas

La herencia de procesos ya está disponible en las nuevas colecciones. Los usuarios tendrán que tomar una decisión de conciencia sobre el modelo de proceso al crear una nueva colección. Consulte nuestra documentación sobre lo que es el modelo de herencia y cómo es diferente de XML.

Cuadro de búsqueda ampliado

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.

Este es el cuadro de búsqueda predeterminado:

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

Mi desplegable de trabajo

Una nueva característica que estamos muy contentos de presentar es el menú desplegable de mi trabajo. Hemos escuchado comentarios de que cuando estáis en una parte del producto y queréis información de otra parte, no queréis perder vuestro contexto. Con esta nueva funcionalidad, puedes acceder a este menú desplegable desde cualquier parte del producto, lo que te proporcionará un vistazo rápido a la información crucial, incluidos tus elementos de trabajo, pull requests y todos tus favoritos. Con este nuevo menú desplegable, si está concentrado en su código en Repos, pero luego quiere comprobar rápidamente en qué elemento de trabajo debe trabajar a continuación, simplemente puede hacer clic en el menú y ver los elementos de trabajo asignados a usted y elegir el siguiente elemento.

A continuación, puedes ver la ventana emergente mi trabajo que muestra los elementos de trabajo asignados a mí:

Aquí puede ver la segunda tabla dinámica que muestra las solicitudes de extracción (PRs) que me han sido asignadas. En el panel desplegable, también tiene acceso con un solo clic para ver más pull requests.

Aquí puedes ver el último elemento clave, con todo lo que has marcado como favorito. Esto incluye tus equipos favoritos, tableros, paneles, trabajos pendientes, consultas y repositorios:

Tableros

Vinculación de solicitudes de incorporación de cambios y confirmaciones de GitHub Enterprise a elementos de trabajo de Azure Boards

Los equipos que usan GitHub Enterprise para el código y quieren funcionalidades enriquecidas de administración de proyectos ahora pueden integrar sus repositorios con Azure Boards. Al conectar GitHub y Azure Boards, puede obtener todas las características, como trabajos pendientes, paneles, herramientas de planeamiento de sprint, varios tipos de elementos de trabajo y aún tener un flujo de trabajo que se integre con flujos de trabajo de desarrollador en GitHub.

Es fácil vincular commits y pull requests a elementos de trabajo. Mencione el elemento de trabajo mediante la sintaxis siguiente:

AB#{work item ID}

Mencione un elemento de trabajo en un mensaje de confirmación, el título de la solicitud de incorporación de cambios o la descripción de la solicitud de incorporación de cambios, y Azure Boards creará un vínculo a ese artefacto. Por ejemplo, considere un mensaje de confirmación similar al siguiente:

Adds support for deleting connections. Fixes AB#20.

Esto creará un vínculo desde el elemento de trabajo n.º 20 a la confirmación en GitHub, que aparecerá en la sección Desarrollo del elemento de trabajo. ​

Si las palabras "fix", "fixes" o "fixed" preceden a la mención del elemento de trabajo (como se muestra anteriormente), el elemento de trabajo se moverá al estado completado cuando la confirmación se combine con la rama predeterminada.

Los equipos que usan Azure Pipelines para compilar código en GitHub también verán los elementos de trabajo vinculados a sus confirmaciones de GitHub en el resumen de compilación.

Nuevo centro de elementos de trabajo

El Centro de elementos de trabajo es nuestro nuevo centro que servirá como el hogar de sus elementos de trabajo. Aquí tiene muchas vistas de lista diferentes de los elementos de trabajo que están adaptadas para usted. Puede ver Asignado a mí para obtener rápidamente un vistazo al trabajo asignado a usted o Actualizado recientemente, que muestra todos los elementos de trabajo del proyecto que se han actualizado más recientemente. Todas las opciones de lista se pueden ver a continuación:

Si quiere reducir el ámbito de las listas aún más, puede filtrar por tipo, asignado a, estado, área, etiquetas y palabra clave. Una vez que tenga la vista de lista deseada, puede ordenar los elementos de trabajo simplemente haciendo clic en el encabezado de la columna. Si una columna es demasiado estrecha para ver el contenido completo de la columna, puede cambiar fácilmente el tamaño de la columna en el área de encabezado. Estas experiencias se pueden ver a continuación:

Nuevos paneles, trabajos pendientes y centros de Sprints

El centro de trabajos pendientes se ha dividido en tres centros distintos para mejorar la experiencia del usuario. Aunque potente, el antiguo centro de acumulaciones mantenía demasiadas funciones. Esto a menudo dificultaba encontrar la característica o funcionalidad que los usuarios buscaban. Para solucionar este problema, hemos dividido el centro de trabajos pendientes en:

• El centro de trabajos pendientes es ahora exclusivamente para los trabajos pendientes de un proyecto. Un trabajo pendiente es una lista prioritaria de trabajo para el equipo. Los trabajos pendientes proporcionan herramientas de planificación como la jerarquía de elementos de trabajo, la previsión y la nueva experiencia de planificación de sprint.
• El nuevo centro es el hogar de todos los tableros Kanban para un proyecto. Los paneles se usan para comunicar el estado y el flujo. Las tarjetas (elementos de trabajo) se mueven de izquierda a derecha a través de las columnas definidas por el equipo.
• El nuevo centro de Sprints es el centro de las funciones utilizadas para planificar y ejecutar un incremento de trabajo. Cada sprint contiene un trabajo pendiente de sprint, un panel de tareas y una vista para administrar y establecer la capacidad para el equipo.

Nuevo centro de consultas

El nuevo centro de consultas simplifica muchas de las características de consultas existentes del centro antiguo con una apariencia más moderna, así como proporciona nuevas funcionalidades para facilitar el acceso a las consultas que son importantes para usted. Algunos aspectos destacados de la nueva experiencia incluyen:

• Páginas de directorio con información sobre la última modificación por y la capacidad de realizar búsquedas
• Ruta de navegación con direcciones URL únicas para carpetas para guardar como favorito grupos de consultas importantes.
• Acceso rápido a sus consultas favoritas desde la página de resultados

Obtenga más información sobre estas actualizaciones emocionantes en nuestro blog de DevOps.

Mover elementos de trabajo a otro proyecto y cambiar un tipo de elemento de trabajo

Ahora puede cambiar el tipo de elemento de trabajo o mover elementos de trabajo a otro proyecto dentro de una colección de proyectos. Estas características requieren que el almacenamiento de datos esté deshabilitado. Con el almacenamiento de datos deshabilitado, el servicio Analytics le ayudará con los informes. Para más información sobre cómo deshabilitar el almacenamiento de datos, consulte Deshabilitación del almacenamiento de datos y el cubo.

Características de planificación de sprint

Las nuevas características de planeación de sprint ayudan a acelerar y mejorar la experiencia de planeamiento de sprints.

• Cree el siguiente sprint o suscríbase a una programación de sprint existente directamente desde el centro de Sprints .
• Usa el nuevo panel de Planificación en tu backlog para arrastrar y colocar elementos de trabajo en sprints futuros. El panel Planificación incluye fechas de sprint, recuentos de elementos de trabajo y esfuerzo planeado.
• Agregue requisitos a la parte superior del Panel de tareas o use la creación rápida para agregar a la parte superior, inferior o fila de su elección en el backlog de sprint.
• Use filtros para Assignee, Work Item Type, State y Tags para adaptar las vistas a sus necesidades.

Páginas de nuevo directorio

Todos los nuevos módulos, incluidos backlogs, paneles y sprints, ahora tienen nuevas páginas de directorio organizadas con las secciones siguientes:

• Continuar donde lo dejaste Esta nueva sección te proporciona un vínculo rápido directamente a la última vez en la que estabas (Panel | Trabajo pendiente | Sprint).
• Favoritos Todos sus paneles, sprints y trabajos pendientes favoritos en todos los equipos.
• Mis paneles, trabajos pendientes y sprints para los equipos de los que formas parte.
• Toda una lista completa de todos los paneles, trabajos pendientes y sprints.

Menú Nuevas opciones de vista

Los nuevos centros, incluidos trabajos pendientes, paneles y sprints, tienen un nuevo menú de Opciones de vista. Se trata de un nuevo hogar para todas las acciones para personalizar el diseño y el contenido de la página. Use Opciones de vista para habilitar vistas adicionales, como mostrar la jerarquía en trabajos pendientes o cambiar la opción Agrupar por en un panel de tareas, activar el panel lateral para asignar y planear sprints, o para explorar gráficos de detalles del trabajo.

Obtenga más información sobre estas actualizaciones emocionantes, el nuevo panel Perfil de equipo y Favoritos en nuestro blog de DevOps.

Las anotaciones de tarjeta incluyen errores y tipos de elementos de trabajo personalizados

Las anotaciones de tarjetas son apreciadas por su intuitiva vista de lista de comprobación y su interacción. Anteriormente, las anotaciones de tarjetas se limitaban a los tipos predeterminados de niveles de trabajos pendientes y no admitían Bugs (errores) ni tipos personalizados. Con la nueva versión, hemos quitado la restricción en los tipos de elementos de trabajo y hemos agregado la capacidad de mostrar errores y cualquier tipo de elemento de trabajo personalizado como anotación de tarjeta.

La configuración del panel para las anotaciones de tarjeta se expandió para incluir todos los tipos de elementos de trabajo disponibles para ese nivel de trabajo pendiente.

Cuando se habilitan las anotaciones para el elemento de trabajo, los recuentos de ese tipo de elemento de trabajo se incluyen en la tarjeta como una lista de comprobación independiente.

La creación rápida de tipos de elementos de trabajo habilitados también está disponible a través del menú contextual de la tarjeta.

Mover el trabajo utilizando áreas e iteraciones sugeridas

Puede ser habitual trabajar en la misma área o iteración y examinar repetidamente las jerarquías al mover elementos de trabajo. Los controles de área y controles de ruta de iteración ahora incluyen una lista de valores usados recientemente como sugerencias, proporcionándole acceso rápido para establecer y seguir.

Además, las fechas de iteración se incluyen a la derecha del nombre para que pueda juzgar rápidamente cuándo se debe entregar un elemento de trabajo.

Consultar a lo largo del calendario de iteración con +/- @CurrentIteration

La @CurrentIteration macro que ayuda a tu equipo a realizar un seguimiento del trabajo en función de tu calendario de iteración ahora admite la compensación de enteros. Mantenga fácilmente el control sobre el trabajo que no se completó con @CurrentIteration - 1, o consulte el trabajo planeado para futuras iteraciones con @CurrentIteration + 1. Consulte la entrada @CurrentIteration en el blog de Microsoft DevOps para obtener más información.

Aclarar las programaciones de iteración de consultas con el @CurrentIteration parámetro Team

Si ha estado usando la macro @CurrentIteration en consultas en el pasado, es posible que haya observado que los resultados pueden variar si el contexto del equipo cambia en equipos con diferentes itinerarios de iteración. Ahora, al crear o modificar una consulta con la @CurrentIteration macro, también se le pedirá que seleccione el equipo con la programación de iteración que es relevante para la consulta. Con el parámetro Team, puede usar la @CurrentIteration macro en la misma consulta, pero en todos los equipos. Un ejemplo puede ser una consulta para los elementos de trabajo en dos proyectos de equipo diferentes con nombres de iteración distintos y hasta cronogramas diferentes. Esto significa que ya no hay que actualizar las consultas a medida que cambian los sprints. Consulte la entrada @CurrentIteration en el blog de Microsoft DevOps para obtener más información.

Consulta de trabajo en las rutas de área de un equipo con la nueva macro @TeamAreas

En la configuración de un equipo, puede asociar una o varias rutas de acceso de área, lo que le ayuda a centrar los elementos pendientes, tableros, planes e incluso los paneles de control en el trabajo de ese equipo. Sin embargo, si quisiera escribir una consulta para un equipo, tenía que enumerar las rutas de área específicas para ese equipo en las cláusulas de consulta. Ahora, hay disponible una nueva macro de @TeamAreas para que pueda hacer referencia fácilmente a las rutas de área que posee el equipo especificado.

Consulta de campos de texto enriquecido vacíos

Busque elementos de trabajo que tengan un campo de texto enriquecido vacío, como Descripción, mediante el nuevo operador de consulta IsEmpty .

Buscar fácilmente elementos de trabajo existentes en experiencias de vinculación y mención

Cuando quiera vincular dos elementos de trabajo existentes juntos, ahora puede encontrar fácilmente el elemento que es importante para usted mediante nuestro nuevo control de búsqueda de elementos de trabajo. El selector de consultas se ha reemplazado por sugerencias insertadas en función de los elementos de trabajo a los que se ha accedido recientemente, así como un punto de entrada para buscar un elemento de trabajo específico por identificador o título.

Abra elementos de trabajo desde los resultados de búsqueda

Anteriormente, no se pudo abrir un elemento de trabajo desde la página de resultados de búsqueda si el panel de vista previa del elemento de trabajo estaba desactivado. Esto dificultaría profundizar en los resultados de la búsqueda. Ahora puede hacer clic en el título del elemento de trabajo para abrir los elementos de trabajo en una ventana modal.

Repos

Selector de ramas mejorado

La mayoría de las experiencias de Azure Repos requieren que seleccione un repositorio y, a continuación, una rama en ese repositorio. Para mejorar esta experiencia para las organizaciones con un gran número de ramas, estamos implementando un nuevo selector de ramas. El selector ahora le permite seleccionar sus ramas favoritas o buscar rápidamente una rama.

Recibir notificaciones cuando se omiten las políticas de pull request.

En el caso de los equipos que usan solicitudes de incorporación de cambios (PR) y directivas de rama, puede haber ocasiones en las que las personas necesiten invalidar y omitir esas directivas, por ejemplo, al desplegar una revisión rápida para un problema de producción en medio de la noche. Tiene sentido confiar en los desarrolladores para que hagan lo correcto y usar la capacidad de anulación con moderación. Al mismo tiempo, los equipos necesitan una manera de comprobar que esas excepciones de política se usan en las situaciones adecuadas. Para admitir esto, hemos agregado un nuevo filtro de notificación para permitir a los usuarios y equipos recibir alertas de correo electrónico cada vez que se omite una directiva. Comience con la plantilla Una solicitud de incorporación de cambios se crea o actualiza y seleccione Omitir directiva en la lista de filtros. Seleccione Directivas que se omiten como valor y se le notificará cada vez que se complete una solicitud de incorporación de cambios y se omitan las directivas.

Permitir la omisión de directivas de rama sin renunciar a la protección de inserción

Hay muchos escenarios en los que tiene la necesidad ocasional de omitir una directiva de rama: revertir un cambio que provocó una interrupción de la compilación, aplicar una revisión a medianoche, etc. Anteriormente, se ofrecía un permiso ("Exento de la aplicación de directivas") para ayudar a los equipos a gestionar qué usuarios tienen la capacidad de omitir las directivas de rama al completar un pull request. Sin embargo, ese permiso también concedió la capacidad de hacer un push directamente en la rama, omitiendo completamente el proceso de pull request.

Para mejorar esta experiencia, hemos dividido el permiso anterior para ofrecer más control a los equipos que conceden permisos para pasar por alto. Hay dos nuevos permisos para reemplazar el anterior:

1. Omitir políticas al completar las solicitudes de incorporación de cambios. Los usuarios con este permiso podrán usar la experiencia "Sobrescribir" para las solicitudes de extracción.
2. Omitir las directivas al hacer un push. Los usuarios con este permiso podrán empujar directamente a las ramas que tengan políticas requeridas configuradas.

Al conceder el primer permiso y denegar el segundo, un usuario podrá usar la opción de omisión cuando sea necesario, pero seguirá teniendo la protección de hacer push accidentalmente a una rama con políticas.

Nota:

Este cambio no introduce ningún cambio de comportamiento. A los usuarios a los que anteriormente se les concedió Allow para "Excluir de la aplicación de directivas" se les concederá Allow para ambos permisos nuevos, por lo que podrán anular la finalización en los pull requests y hacer push directamente a las ramas con directivas.

Para obtener más información, consulte la documentación sobre cómo establecer permisos de ramas.

Describir rápidamente las solicitudes de incorporación de cambios mediante mensajes de confirmación

Escribir mensajes de confirmación descriptivos agrega valor al historial de cualquier repositorio de Git. Para fomentar mensajes de confirmación de calidad, las nuevas solicitudes de incorporación de cambios (PR) que tengan varias confirmaciones requerirán que los colaboradores escriban un título manualmente.

Las descripciones de la solicitud de incorporación de cambios seguirán estando vacías de forma predeterminada, pero una nueva característica facilitará la incorporación de los mensajes de confirmación de las confirmaciones de solicitud de incorporación de cambios en la descripción de la solicitud de incorporación de cambios. Para agregar los mensajes de confirmación, simplemente haga clic en Agregar mensajes de confirmación para anexar los mensajes de confirmación al final del texto de descripción de la solicitud de incorporación de cambios.

Crear solicitudes de incorporación de cambios sin un equipo predeterminado como revisor

Cuando lanzamos por primera vez la experiencia de PR, pensamos que tendría sentido asignar todos los PR al contexto del equipo que seleccionaste al crearlos. Este comportamiento ha sido un punto de frustración, ya que muchas personas no observaron la conexión entre el contexto del equipo y la asignación de pr.

Como parte de los nuevos cambios de navegación, aprovechamos la oportunidad de cambiar esta asociación predeterminada con los equipos. Observará dos cambios:

1. Al crear una solicitud de incorporación de cambios, no se agrega ningún revisor de forma predeterminada. La lista de revisores cuenta con una función que facilita la adición de usuarios y grupos que se agregaron recientemente a los pull requests. La política de revisores obligatorios también puede ayudar a los equipos que quieran asegurarse de que se agregan revisores específicos para revisar su código.
2. El centro de solicitudes de incorporación de cambios tiene una nueva sección personalizable. De forma predeterminada, en esta sección se muestran las solicitudes de extracción (PRs) "Asignadas a mis equipos", lo que proporciona una funcionalidad equivalente a la sección anterior. Sin embargo, si pertenece a varios equipos, esta sección mostrará PRs asignadas a cualquiera de sus equipos. La sección también es personalizable: simplemente haga clic en la acción "Personalizar esta vista" cerca del encabezado de sección.

Estandarización de las descripciones de solicitudes de incorporación de cambios mediante plantillas

Escribir buenas descripciones de solicitudes de extracción es una excelente manera de ayudar a los revisores a saber qué esperar al revisar el código. También son una excelente forma de ayudar a realizar un seguimiento de lo que debe realizarse para cada cambio, como las pruebas, la adición de pruebas unitarias y la actualización de la documentación. Muchos de ustedes han solicitado que agreguemos plantillas para solicitudes de cambios para facilitar que los equipos escriban descripciones excelentes, y ahora hemos agregado esa característica.

Además de admitir una plantilla de descripción de PR predeterminada, los equipos pueden agregar varias plantillas, que se presentan en un menú de la página de creación de PR. Simplemente haga clic en el botón Agregar una plantilla para seleccionar cualquier plantilla del repositorio y añadirla a la descripción del PR.

También se admiten plantillas específicas de rama si desea aplicar una plantilla diferente para una solicitud de incorporación de cambios en una rama específica o en una carpeta de rama. Por ejemplo, si desea tener una plantilla específica para todas las ramas que comiencen por "hotfix/", puede agregar una plantilla que se usará para todos los pull requests en esas ramas.

Consulte la documentación de plantillas de solicitud de incorporación de cambios para obtener más información sobre cómo crear y usar plantillas.

Cambia la rama de destino de un pull request

Para la mayoría de los equipos, casi todas las pull requests tienen como objetivo la misma rama, como main o develop. En caso de que necesite apuntar a una rama diferente, es fácil olvidarse de cambiar la rama de destino de la predeterminada. Con la nueva función para cambiar la rama de destino de una solicitud de incorporación de cambios activa, esto 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 la solicitud de incorporación de cambios.

Además de corregir los errores, la función para cambiar las ramas de destino también facilita la "reasignación" de un pull request cuando la rama de destino se ha fusionado o eliminado. Considera un escenario en el que tienes un pull request dirigido a una rama de funcionalidades que contiene algunas funciones de las que dependen tus 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. Los revisores pueden ver solo los cambios y dejar los comentarios adecuados.

Ahora, considere lo que sucedería si la rama de características también tuviera un PR activo y se fusionara en main antes de sus cambios. Anteriormente, tendría que abandonar los cambios y crear una nueva solicitud de incorporación de cambios en main, o fusionar su PR en features/new-feature, y luego crear otra solicitud de incorporación de cambios de features/new-feature a main. Con esta nueva acción para actualizar la rama de destino, simplemente puedes cambiar la rama de destino del PR de features/new-feature a main, conservando todo el contexto y los comentarios. Al cambiar la rama de destino, puede incluso crear una nueva actualización del PR, lo que facilita revisar las diferencias anteriores antes del cambio de la rama de destino.

Los creadores de extensiones pueden consultar el contexto del repositorio actual

Uno de los desafíos de un autor de una extensión de control de versiones es obtener el contexto del repositorio que se muestra al usuario, como el nombre, el identificador y la dirección URL. Para ayudar con esto, agregamos VersionControlRepositoryService como un servicio accesible para extensiones. Con esto, un autor de la extensión puede consultar información sobre el contexto actual del repositorio de Git dentro de la interfaz de usuario web. Actualmente tiene un método, getCurrentGitRepository().

• Si se selecciona un repositorio de Git, se devuelve un objeto GitRepository con datos básicos sobre el repositorio (nombre, identificador y dirección URL).
• Si se selecciona un repositorio TFVC o se accede al servicio fuera de las páginas de Azure Repos, se devolverá null.

Esta es una extensión de ejemplo que usa este servicio.

Tuberías

Administrar las canalizaciones de compilación en la nueva página de Compilaciones

Estamos realizando varias mejoras e implementando una nueva versión de la página Compilaciones . Esta nueva versión combina el directorio de todas las canalizaciones de compilación y la lista de compilaciones actuales para que pueda navegar rápidamente por las compilaciones del proyecto para ver su estado. También incluye una vista previa del análisis de pruebas para la canalización seleccionada.

Gestione de mejor manera los correos electrónicos de finalización de compilación e implementación con un formato mejorado.

Los correos electrónicos de finalización de compilación e implementación se han actualizado para que sean más fácilmente filtrables mediante las reglas de correo electrónico. Ahora la línea de asunto incluye información más relevante de forma rápida, el cuerpo del correo contiene más detalles y su estilo se ha actualizado con la imagen de marca más reciente.

Los elementos del nuevo formato son:

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Estos son algunos ejemplos:

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Siga la nueva terminología unificada de Azure Pipelines.

A lo largo de las compilaciones y versiones, se han usado términos diferentes históricamente para conceptos similares. En otros casos, los significados de los términos eran imprecisos. Por ejemplo, indicar la diferencia entre un grupo de agentes y una cola de agentes.

La terminología se ha unificado en Azure Pipelines para aclarar sus conceptos. Ahora verá los siguientes términos unificados:

Término anterior	Término unificado	Significado
Agente hospedado	Agente hospedado por Microsoft	Un agente de compilación o versión que se ejecuta en la infraestructura hospedada en la nube administrada por Microsoft.
Agente privado	Agente autohospedado	Un agente de compilación o versión que se ejecuta en una máquina proporcionada y administrada por usted.
Grupo de agentes	Grupo de agentes	Conjunto de máquinas de agente de nivel de organización que pueden ejecutar compilaciones o versiones.
Cola de agentes	Grupo de agentes	Conjunto de equipos de agente de nivel de proyecto que pueden ejecutar compilaciones o versiones. Está vinculado a un grupo de agentes de nivel de organización.
Definición de construcción	Proceso de compilación	Un conjunto completo de pasos de compilación para una aplicación.
Construir	Construir	Instancia de una canalización de compilación que se está ejecutando o que se ha ejecutado.
Fase	Trabajo	Una serie de tareas que se ejecutan secuencialmente o en paralelo en un agente. Una canalización de compilación o versión puede contener un trabajo o un gráfico de varios trabajos.
Definición de versión	Flujo de publicación	Un conjunto completo de pasos de versión para que una aplicación se implemente en varias fases.
Lanzamiento	Lanzamiento	Instancia de una canalización de versión que se está ejecutando o se ha ejecutado.
Entorno	Fase	Una entidad lógica e independiente que representa dónde quieres implementar un lanzamiento generado a partir de un flujo de lanzamiento.
Trabajos/pipeline concurrentes	Trabajo paralelo	Un trabajo paralelo le ofrece la posibilidad de ejecutar un único trabajo de compilación o versión a la vez en la organización. Con más trabajos paralelos disponibles, puede ejecutar más trabajos de compilación y versión al mismo tiempo.
Punto de conexión de servicio	Conexión de servicio	Un grupo de opciones de configuración, como las credenciales, que se usan para conectarse a servicios externos para ejecutar tareas en una compilación o versión.

Consulte la documentación de conceptos para obtener más información.

Administrar canalizaciones de lanzamientos mediante la nueva página de Lanzamientos

Está disponible una nueva experiencia de usuario completamente rediseñada para la página de lanzamiento. Consulte una lista de las canalizaciones de versiones que lanzas con frecuencia a la izquierda. También puede buscar en sus canalizaciones y marcarlas como favoritas.

Cambie a la vista de carpetas para crear carpetas para la organización y la seguridad. La seguridad se puede establecer en un nivel de carpeta.

Visualizar el progreso del lanzamiento

La nueva vista de progreso de la versión proporciona actualizaciones dinámicas del progreso de la implementación y acceso con un solo clic para obtener más detalles. La nueva vista visualiza el pipeline de lanzamiento, facilitando la comprensión de lo que sucede y exponiendo los detalles y acciones adecuados en las distintas fases del lanzamiento.

Flujo de trabajo, detalles de la versión y entornos

La vista de la canalización muestra los artefactos del lanzamiento y los entornos donde se implementarán. El área de Lanzamiento proporciona detalles del lanzamiento, como el desencadenador, las versiones de artefactos y las etiquetas.

Los entornos se modelan de forma que ayuden a comprender su estado, junto con el progreso detallado. En cualquier momento, puede acceder a los registros haciendo clic en el vínculo de estado dentro del entorno.

Implementación previa y posterior a la implementación

Si se han establecido condiciones previas o posteriores al despliegue para un entorno, esto se indica en el entorno con la presencia de las aprobaciones y los controles. El progreso de las aprobaciones y los hitos también se refleja en el estado del entorno. Para realizar acciones o ver más detalles, haga clic en el icono de condición del entorno colgando del lado derecho o izquierdo del entorno.

Confirmaciones y elementos de trabajo

Con cada nueva versión, puede ver la lista de confirmaciones y elementos de trabajo asociados para cada entorno por separado haciendo clic en el entorno. Si la lista es larga, use filtros para buscar el elemento de confirmación o de trabajo que le interese.

Progreso y registros de implementación

Los entornos muestran actualizaciones directas de las implementaciones en curso, incluido el número de fases y tareas completadas y el tiempo de ejecución. Al hacer clic en el estado del entorno, se abre una vista que contiene los registros, centrada en lo que está activo en ese momento.

Puede hacer clic dentro de los registros para entrar en una vista centrada.

Impacto de la actualización a Azure DevOps Server 2019 en tareas: Copia de archivos de máquina Windows y PoweShell en la máquina de destino

Los grupos de máquinas de Test Hub han quedado en desuso en TFS 2017 RTM. Con Azure DevOps Server 2019, el servicio Grupos de máquinas ya no está disponible. Esto afectará a los usuarios de la tarea "Copia de archivos de máquina Windows" versión 1.* y "PowerShell en máquinas de destino" versión 1.*. Para que las canalizaciones sigan funcionando,

• Tiene que cambiar a la tarea "Copia de archivos de máquina Windows" versión 2.* y proporcionar el fqdn completo para la máquina de destino en lugar de simplemente el nombre de la máquina.
• Y cambie a la tarea "Powershell en la máquina de destino" versión 2.* o posterior e ingrese el nombre de dominio completo (fqdn) del equipo o el nombre del equipo seguido de los puertos de Gestión Remota de Windows (http/https). Por ejemplo, targetMachine:5985 o targetMachine:5986

Resultados de pruebas y extensibilidad

Los resultados de la ejecución de pruebas también se muestran para cada entorno. Al hacer clic en los resultados de la prueba, se abre una vista que contiene los detalles de la prueba, incluidos los resultados de otras extensiones que contribuyen al proceso.

Las extensiones existentes funcionan en esta nueva vista. Además, hay nuevos puntos para la ampliación de funcionalidades que permiten a las extensiones mostrar aún más información dentro de un entorno. Consulte la documentación de contribuciones y extensiones para obtener más información.

Configuración de compilaciones mediante YAML

Las canalizaciones de compilación basadas en YAML están disponibles en Azure DevOps Server. Automatice su tubería de integración continua mediante un archivo YAML incorporado en su repositorio. Puede encontrar una referencia completa para el esquema YAML aquí.

Para admitir canalizaciones de compilación basadas en YAML de forma más fluida, hemos cambiado el comportamiento predeterminado de todos los recursos nuevos que se crean (por ejemplo, conexiones de servicio, grupos de variables, grupos de agentes y archivos seguros) que se pueden usar en toda la canalización de ese proyecto. Si desea un control más estricto sobre los recursos, puede deshabilitar el modelo de autorización predeterminado (consulte la figura siguiente). Al hacerlo, alguien con permisos para usar el recurso debe guardar explícitamente la canalización en el editor web después de agregar una referencia de recursos al archivo YAML.

Encadenar compilaciones relacionadas usando desencadenadores de finalización de compilación

Los productos grandes tienen varios componentes que dependen unos de otros. Estos componentes suelen compilarse de forma independiente. Cuando cambia un componente de nivel superior (por ejemplo, una biblioteca), las dependencias de nivel inferior deben volver a generarse y validarse. Los equipos normalmente administran estas dependencias manualmente.

Ahora puede desencadenar una compilación tras la finalización correcta de otra compilación. Los artefactos generados por una compilación ascendente se pueden descargar y usar en la compilación posterior, y también puede obtener datos de estas variables: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Consulte la documentación de compilación de desencadenadores para obtener más información.

Tenga en cuenta que, en algunos casos, una sola compilación de varias fases podría satisfacer sus necesidades. Sin embargo, un desencadenador de finalización de compilación es útil si los requisitos incluyen diferentes configuraciones, opciones o un equipo diferente para gestionar el proceso dependiente.

Actualiza localmente tu agente

Las tareas que instale desde la Galería a veces requieren una versión más reciente del agente de canalizaciones. Si azure DevOps Server puede conectarse a Internet, las versiones más recientes se descargan automáticamente. Si no es así, tendrás que actualizar manualmente cada agente. A partir de esta versión, puede configurar Azure DevOps Server para buscar los archivos de paquete del agente en su disco local en lugar de desde Internet. Esto le proporciona flexibilidad y control sobre qué versiones de agente pone a disposición, sin tener que exponer azure DevOps Server a Internet.

Nueva dirección URL del distintivo de estado de compilación

Las notificaciones de compilación insertadas en la página principal de un repositorio son una manera común de mostrar el estado del repositorio. Aunque teníamos insignias de construcción hasta ahora, había algunos problemas:

• La dirección URL no era intuitiva
• La insignia no era específica de una sucursal
• No había forma de que un usuario haga clic en el distintivo para llevar al usuario a la compilación más reciente de esa definición.

Ahora estamos implementando una nueva API para las notificaciones de compilación que resuelven estos problemas. La nueva API permite a los usuarios publicar un estado por rama y puede llevar a los usuarios a la compilación más reciente de la rama seleccionada. Puede obtener el Markdown para la nueva URL del distintivo de estado seleccionando la acción de menú Distintivo de estado en la nueva página de Compilaciones.

Por motivos de compatibilidad con versiones anteriores, seguiremos respetando también las direcciones URL de distintivo de compilación anteriores.

Agregue contadores de compilación personalizados a sus compilaciones

Los contadores de compilación ofrecen una manera de numerar de manera única y etiquetar compilaciones. Anteriormente, podría usar la variable especial $(rev:r) para lograr esto. Ahora puede definir sus propias variables de contador en la definición de compilación que se incrementan automáticamente cada vez que se ejecuta una compilación. Esto se hace en la pestaña variables de una definición. Esta nueva característica le ofrece más potencia de las siguientes maneras:

• Puede definir un contador personalizado y establecer su valor de inicialización. Por ejemplo, puede iniciar el contador en 100. $(rev:r) siempre comienza en 0.
• Puede usar su propia lógica personalizada para restablecer un contador. $(rev:r) está asociado a la generación de números de compilación y se restablece automáticamente siempre que haya un nuevo prefijo en el número de compilación.
• Puede definir varios contadores por definición.
• Puede consultar el valor de un contador fuera de una compilación. Por ejemplo, puede contar el número de compilaciones que se han ejecutado desde el último restablecimiento mediante un contador.

Consulte la documentación sobre variables definidas por el usuario para obtener más información sobre los contadores de compilación.

Validaciones de seguridad y cumplimiento normativo de Azure Policy en Pipelines

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. Cuando se usa 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.

Además, hemos agregado la plantilla de definición de lanzamiento de Azure Policy. 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.

Use las plataformas de compilación Linux/ARM y Windows de 32 bits

El agente de código abierto y multiplataforma de Azure Pipelines siempre ha sido compatible con Windows, macOS y Linux de 64 bits (x64). Con esta versión, presentamos dos nuevas plataformas compatibles: Linux/ARM y Windows/32 bits. Estas nuevas plataformas ofrecen la capacidad de compilar en plataformas menos comunes, pero no menos importantes, como Raspberry Pi, una máquina Linux/ARM.

Experiencias mejoradas para pruebas en canalizaciones

Pruebas ahora tiene una experiencia moderna que proporciona información de prueba enriquecida y contextual para Pipelines. La nueva experiencia proporciona una vista de prueba en curso, una experiencia de depuración a página completa, historial de pruebas en contexto, informe de la ejecución de pruebas abortadas y resumen del nivel de ejecución de prueba.

Visualización de la ejecución de pruebas en curso

Las pruebas, como las pruebas funcionales y de integración, se pueden ejecutar durante mucho tiempo, por lo que es importante ver la ejecución de pruebas en cualquier momento dado. Con la Vista de Pruebas en Progreso, ya no tendrá que esperar a que se complete la ejecución de la prueba para conocer el resultado. Los resultados están disponibles casi en tiempo real a medida que se ejecutan, lo que le ayuda a realizar acciones más rápido. Puede depurar una falla o abortar, reportar un error o abortar la canalización. La característica está disponible actualmente para la canalización de compilación y de lanzamiento, utilizando la tarea de prueba de VS Test Task en la fase de multiagente, mediante Publish Test Results Task o publicando resultados de pruebas mediante API(s). En el futuro, tenemos previsto ampliar esta experiencia para la ejecución de pruebas mediante el Agente único.

En la vista a continuación se muestra el resumen de las pruebas en curso dentro de la vista de progreso de la nueva versión, informando el recuento total de pruebas y el número de fallos en un momento dado.

Al hacer clic en el resumen de pruebas en curso de arriba, puede ver el resumen detallado de pruebas junto con la información de prueba con fallos o anuladas en Planes de prueba. El resumen de pruebas se actualiza a intervalos periódicos con la capacidad de actualizar la vista de detalles a petición, en función de la disponibilidad de los nuevos resultados.

Visualización de los detalles de depuración de la ejecución de pruebas en la página completa

Los mensajes de error y las trazas de pila son largos por naturaleza y necesitan suficiente espacio para ver los detalles durante la depuración. Para tener una experiencia de depuración inmersiva, ahora puede expandir la vista de prueba o de ejecución de prueba a la vista de página completa, a la vez que puede realizar las operaciones necesarias en contexto, como el registro de errores o la asociación de requisitos para el resultado de la prueba actual.

Visualización del historial de pruebas en contexto

Históricamente, los equipos tendrían que ir al centro de ejecuciones para ver el historial de un resultado de prueba. Con la nueva experiencia, traemos el historial de pruebas directamente en contexto en la pestaña Planes de prueba para la compilación y el despliegue. La información del historial de pruebas se proporciona de forma progresiva a partir de la definición de compilación actual o el entorno de la prueba seleccionada, seguido de otras ramas y entornos para la compilación y versión, respectivamente.

Visualización de pruebas anuladas

La ejecución de pruebas puede anularse debido a varios motivos, como código de prueba incorrecto, código fuente bajo prueba y problemas de entorno. Independientemente del motivo de la anulación, es importante que analice el comportamiento e identifique la causa raíz. Ahora puede ver las pruebas anuladas y las ejecuciones de pruebas, junto con las ejecuciones completadas en Planes de pruebas. La característica está disponible actualmente tanto para la canalización de compilación como para la de despliegue, usando VS Test Task en la fase de múltiples agentes o publicando resultados de pruebas mediante API(s). En el futuro, tenemos previsto ampliar esta experiencia para la ejecución de pruebas mediante el Agente único.

Compatibilidad con la rastreabilidad de pruebas y los entornos de lanzamiento en el historial de pruebas

Estamos agregando compatibilidad para ver el historial de una prueba automatizada agrupada por varios entornos de versión en los que se ejecuta la prueba. Si va a modelar entornos de versión como canalizaciones de versión o entornos de prueba, y va a ejecutar pruebas en dichos entornos, puede averiguar si una prueba está pasando en el entorno de desarrollo, pero falla en el entorno de integración. Podría averiguar si funciona en la localización en inglés, pero falla en un entorno con localización turca. Para cada entorno, encontrará el estado del resultado de la prueba más reciente y, si la prueba ha fallado en ese entorno, también encontrará la versión desde la que se ha producido un error en la prueba.

Revisión de los resultados de las pruebas resumidas

Durante la ejecución de pruebas, una podría generar varias instancias de pruebas que contribuyen al resultado general. Algunos ejemplos incluyen: pruebas que se vuelven a ejecutar debido a errores, pruebas compuestas de una combinación ordenada de otras pruebas (por ejemplo, pruebas ordenadas) o pruebas que tienen diferentes instancias basadas en el parámetro de entrada proporcionado (pruebas controladas por datos). Dado que estas pruebas están relacionadas, deben notificarse junto con el resultado general derivado en función de los resultados de las pruebas individuales. Con esta actualización, presentamos una versión mejorada de los resultados de las pruebas, presentados como una jerarquía en la pestaña Pruebas de un lanzamiento. Veamos un ejemplo.

Anteriormente, se introdujo la capacidad de volver a ejecutar pruebas con errores en la tarea de VS Test. Sin embargo, solo se informó sobre el último intento de una prueba, que limitaba algo la utilidad de esta característica. Ahora hemos ampliado esta característica para notificar cada instancia de la ejecución de la prueba como intento. Además, test Management API ahora admite la capacidad de publicar y consultar resultados de pruebas jerárquicos. Consulte la documentación de la API de resultados de pruebas para obtener más información.

Nota:

Las métricas de la sección de resumen de pruebas (por ejemplo, Pruebas totales, Superadas, etc.), se calculan mediante el nivel raíz de la jerarquía en lugar de cada iteración individual de las pruebas.

Ver análisis de pruebas en Pipelines

El seguimiento de la calidad de las pruebas a lo largo del tiempo y la mejora de la documentación de pruebas es fundamental para mantener un flujo de trabajo eficiente. La funcionalidad de análisis de pruebas proporciona acceso casi en tiempo real a los datos de prueba para compilaciones y canalizaciones de lanzamiento. Ayuda a mejorar la eficacia de su flujo de trabajo mediante la identificación de problemas repetitivos de calidad de alto impacto.

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

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

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

Simplificación de definiciones con varias tareas sin agente

Las tareas de una fase sin agente se orquestan y se ejecutan en el servidor. Las fases sin agente no requieren un agente ni ningún ordenador objetivo. A diferencia de las fases del agente, solo se podría agregar una tarea a cada fase sin agente en las definiciones. Esto significaba que se tenían que agregar varias fases cuando había más de una tarea sin agente en el proceso, lo que hace que la definición sea masiva. Hemos relajado esta restricción, lo que le permite mantener varias tareas en una fase sin agente. Las tareas de la misma fase se ejecutarían secuencialmente, igual que para las fases del agente. Consulte la documentación de las fases del servidor para obtener más información.

Exponer progresivamente los despliegues por fases usando puertas de liberación

Con las puertas de lanzamiento, puede especificar los criterios de mantenimiento de la aplicación que se deben cumplir antes de que se promueva una versión al siguiente entorno. Todas las puertas especificadas se evalúan periódicamente antes o después de cualquier implementación, hasta que todas se realicen correctamente. Hay cuatro tipos de puertas disponibles de fábrica y puede agregar más puertas desde Marketplace. Podrá auditar que se cumplen todos los criterios necesarios para una implementación. Vea la documentación de puertas de lanzamiento para obtener más información.

Detener las implementaciones hasta que las etapas se completen exitosamente de forma coherente

Las puertas de versión permiten la evaluación automática de los criterios de estado antes de que se promueva una versión al siguiente entorno. De forma predeterminada, el lanzamiento progresa después de recibir una muestra exitosa para todas las puertas. Incluso si una puerta es errática y la muestra exitosa recibida es ruido, el lanzamiento avanza. Para evitar este tipo de problemas, ahora puede configurar el lanzamiento para verificar la consistencia del estado de salud durante un tiempo mínimo antes de avanzar. En tiempo de ejecución, la versión garantizaría que las evaluaciones consecutivas de las puertas se realicen correctamente antes de permitir la promoción. El tiempo total de evaluación depende del "tiempo entre la reevaluación" y normalmente sería mayor que la duración mínima configurada. Consulte la documentación sobre el control de implementación de versiones mediante puertas para obtener más información.

Desplegar automáticamente en nuevos objetivos dentro de un grupo de implementación.

Anteriormente, cuando se agregaron nuevos destinos a un grupo de implementación, se requería una implementación manual para asegurarse de que todos los destinos tienen la misma versión. Ahora puede configurar el entorno para implementar automáticamente la última versión correcta en los nuevos destinos. Consulte la documentación de grupos de implementación para obtener más información.

Implementación continua de compilaciones etiquetadas mediante el procesamiento posterior a la compilación

Los desencadenadores de implementación continua crean una versión al finalizar la compilación. Sin embargo, a veces las compilaciones se someten a un postprocesamiento y solo deben publicarse después de que ese proceso se complete. Ahora puede utilizar las etiquetas de compilación, que se asignarían durante el procesamiento posterior, en los filtros de activación de la versión.

Establecimiento de una variable en tiempo de lanzamiento

En una definición de versión, ahora puede elegir las variables que desea establecer al crear la versión.

El valor proporcionado para la variable cuando se crea la versión solo se usa para esa versión. Esta característica le ayudará a evitar varios pasos para "Crear en borrador", actualizar las variables en borrador e iniciar la publicación con la variable.

Pasar variables de entorno a tareas

Los autores de tareas de CI/CD pueden establecer una nueva propiedad, showEnvironmentVariables, en el task.json para pasar variables de entorno a tareas. Al hacerlo, se añade un control adicional en la tarea en el editor de construcción. Esto está disponible para las tareas de PowerShell, Cmd y Bash .

Esto habilita dos escenarios:

• Una tarea requiere una variable de entorno con el caso preservado en el nombre de la variable. Por ejemplo, en el ejemplo anterior, la variable de entorno que se le pasa a la tarea sería "foo" y no "FOO".
• Permite que los valores de secretos se pasen de forma segura a los scripts. Esto es preferible a que pasar los secretos como argumentos a los scripts, ya que el sistema operativo del agente puede registrar la invocación de procesos, incluyendo sus argumentos.

Clonación de grupos de variables

Se ha agregado soporte para la clonación de grupos de variables. Siempre que quiera replicar un grupo de variables y solo actualizar algunas de las variables, no es necesario pasar por el proceso tedioso de agregar variables una por una. Ahora puede realizar rápidamente una copia del grupo de variables, actualizar los valores adecuadamente y guardarlos como un nuevo grupo de variables.

Nota:

Los valores de las variables secretas no se copian al clonar un grupo de variables. Debe actualizar las variables cifradas y, a continuación, guardar el grupo de variables clonado.

Omitir una puerta de versión para una implementación

Las compuertas de lanzamiento permiten la evaluación automática de los criterios de salud antes de que se promueva una versión al siguiente entorno. De forma predeterminada, el pipeline de despliegue solo progresa cuando todos los gates están en buen estado al mismo tiempo. En determinadas situaciones, como al acelerar una publicación o después de comprobar manualmente el estado, es posible que un aprobador quiera omitir un control de calidad y permitir que la publicación progrese incluso si ese control de calidad todavía tiene que evaluarse como saludable. La documentación de las puertas de lanzamiento para obtener más información.

Realización de pruebas adicionales mediante un disparador de lanzamiento de pull request

Has podido desencadenar una compilación basada en una solicitud de incorporación de cambios (PR) y obtener esos comentarios rápidos antes de una combinación por un tiempo. Ahora también puede configurar un desencadenador de pr para una versión. El estado de la versión se publicará de nuevo en el repositorio de código y se puede ver directamente en la página de PR. Esto resulta útil si desea realizar pruebas funcionales o manuales adicionales como parte del flujo de trabajo de la PR.

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

Ahora puede definir una conexión de servicio de Azure con una entidad de servicio y un certificado para la autenticación. Con la conexión de servicio de Azure que ahora admite la entidad de servicio que se autentica con un certificado, ahora puede realizar implementaciones 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.

Compatibilidad con “Run From Package” en implementaciones de Azure App Service

La tarea de implementación del servicio de aplicaciones de Azure (versión 4.*) ahora admite RunFromPackage (anteriormente llamado RunFromZip).

App Service admite varias técnicas diferentes para implementar los archivos, como msdeploy (también conocido como WebDeploy), git, ARM y mucho más. Pero todas estas técnicas tienen una limitación. Los archivos se implementan en la carpeta wwwroot (específicamente d:\home\site\wwwroot) y el tiempo de ejecución ejecuta los archivos desde allí.

Con la ejecución desde paquete, ya no se requiere un paso de implementación que copie los archivos individuales a wwwroot. En su lugar, simplemente apunte a un archivo ZIP y el archivo ZIP se monta en wwwroot como un sistema de archivos de solo lectura. Esto presenta varias ventajas:

• Se reduce el riesgo de problemas de bloqueo de copia de archivos.
• Se pueden implementar en una aplicación de producción (con reinicio).
• Puede estar seguro de los archivos que se ejecutan en la aplicación.
• Mejora el rendimiento de las implementaciones de App de Azure Service.
• Puede reducir los tiempos de arranque en frío, especialmente para las funciones de JavaScript con árboles de paquete de npm grandes.

Implemente contenedores Linux con la tarea de despliegue de servidor de aplicaciones

La versión 4.* de la tarea de implementación del servicio de aplicaciones de Azure ahora es compatible con la implementación de su propio contenedor personalizado en Azure Functions en Linux.

El modelo de hospedaje de Linux para Azure Functions se basa en contenedores de Docker que proporcionan mayor flexibilidad en cuanto al empaquetado y aprovechan las dependencias específicas de la aplicación. Funciones en el sistema Linux se pueden hospedar en dos modos diferentes:

1. Imagen de contenedor integrada: trae el código de la aplicación de funciones y Azure proporciona y administra el contenedor (modo de imagen integrado), por lo que no se requiere ningún conocimiento específico relacionado con Docker. Esto se admite en la versión existente de la tarea de implementación de App Service.
2. Imagen de contenedor personalizada: Hemos mejorado la tarea de implementación de App Service para admitir la implementación de imágenes de contenedor personalizadas en Azure Functions en Linux. Cuando las funciones necesitan una versión de lenguaje específica o requieren una dependencia o configuración específica que no se proporciona dentro de la imagen integrada, puede compilar e implementar una imagen personalizada en Azure Functions en Linux mediante Azure Pipelines.

La tarea Xcode admite la nueva versión Xcode 10

Coincidendo con la versión de Xcode 10 de Apple, ahora puede establecer los proyectos para compilar o probarse específicamente con Xcode 10. Tu 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.

Simplificación de la implementación en Kubernetes mediante Helm

Helm es una herramienta que simplifica la instalación y administración de aplicaciones de Kubernetes. También ha ganado mucha popularidad y apoyo comunitario en el último año. Una tarea de Helm en Release está ahora disponible para empaquetar e implementar charts de Helm en Azure Container Service (AKS) o en cualquier otro clúster de Kubernetes.

Con la adición de esta tarea de Helm, ahora puede configurar una canalización de CI/CD basada en Helm para entregar contenedores en un clúster de Kubernetes. Consulte la documentación Implementación con Kubernetes en Azure Container Service para más información.

Control de la versión de Helm usada en el lanzamiento

La tarea Instalador de Herramientas de Helm adquiere una versión específica de Helm desde Internet o la memoria caché de herramientas y la agrega al PATH del agente (hospedado o privado). Use esta tarea para cambiar la versión de Helm usada en tareas posteriores, como la tarea cli de .NET Core. Agregar esta tarea antes de la tarea de implementación de Helm en una definición de compilación o liberación garantiza que se empaqueta e implementa su aplicación con la versión correcta de Helm. Esta tarea también ayuda a instalar opcionalmente la herramienta kubectl , que es un requisito previo para que Helm funcione.

Implementación continua en Azure Database for MySQL

Ahora puede implementar continuamente en Azure Database for MySQL, la base de datos MySQL como servicio de Azure. Administre e implemente continuamente los archivos de script de MySQL en el control de versiones como parte de un flujo de trabajo de entrega mediante una tarea nativa en lugar de scripts de PowerShell.

Usar tareas remotas mejoradas basadas en PowerShell de Windows

Hay disponibles tareas nuevas y mejoradas basadas en PowerShell remoto de Windows. Estas mejoras incluyen varias correcciones de rendimiento y admiten registros en directo y comandos de salida de consola, como Write-Host y Write-Output.

PowerShell en la tarea objetivo (versión: 3.*): puede agregar script en línea, modificar las opciones de PSSession, controlar "ErrorActionPreference" y fallar en el caso de un error estándar.

Tarea de copia de archivos de Azure (versión: 2.*):se incluye con la versión más reciente de AzCopy (v7.1.0) que soluciona un problema de GitHub.

Filtrar ramas para artefactos de GitHub Enterprise o de artefactos de Git externos

Al publicar desde GitHub Enterprise o repositorios de Git externos, ahora puede configurar las ramas específicas que se publicarán. Por ejemplo, puede que quiera implementar solo compilaciones procedentes de una rama específica en producción.

Compilación de aplicaciones escritas en Go

Usa la tarea Instalador de Go Tool para instalar una o varias versiones de Go Tool dinámicamente. Esta tarea adquiere una versión específica de Go Tool que necesita tu proyecto y la agrega a la PATH del agente de compilación. Si la versión de Go Tool de destino ya está instalada en el agente, esta tarea omitirá el proceso de descarga e instalarlo de nuevo.

La tarea Go le ayuda a descargar dependencias, compilar o probar la aplicación. También puede usar esta tarea para ejecutar un comando personalizado de Go de su elección.

Ejecuta scripts de Python en línea o basados en archivos en tu canalización

Una nueva tarea de script de Python simplifica la ejecución de scripts de Python en tu flujo de trabajo. La tarea ejecutará un script desde un archivo de Python (.py) en el repositorio, o bien puede escribir manualmente un script en la configuración de la tarea para guardarlo como parte de la canalización. La tarea usará la versión de Python en la ruta de acceso o puede especificar una ruta de acceso absoluta a un intérprete de Python que se va a usar.

Aprovecha la mejora en la salida de compilación y prueba de Xcode de xcpretty

xcpretty mejora la legibilidad de la salida de xcodebuild y genera resultados de prueba en formato JUnit. La tarea de compilación de Xcode ahora usa automáticamente xcpretty cuando está disponible en el equipo del agente, ya que está en agentes macOS hospedados. Aunque la salida de xcpretty puede ser diferente y menos detallada que la salida de xcodebuild, hacemos que los registros de xcodebuild completos estén disponibles con cada compilación.

Planes de prueba

Cliente del ejecutor de pruebas (Azure Test Plans) para ejecutar pruebas manuales para aplicaciones de escritorio

Ahora puede usar el cliente del ejecutor de pruebas (Azure Test Plans) para ejecutar pruebas manuales para aplicaciones de escritorio. Esto le ayudará a pasar de Microsoft Test Manager a Azure Test Plans. Consulte nuestras instrucciones aquí. Con el cliente del ejecutor de pruebas, puede ejecutar las pruebas manuales y registrar los resultados de las pruebas para cada paso de prueba. También tiene funcionalidades de recopilación de datos, como captura de pantalla, registro de acciones de imagen y grabación de vídeo de audio. Si encuentra un problema al realizar pruebas, use El ejecutor de pruebas para crear un error con pasos de prueba, capturas de pantalla y comentarios incluidos automáticamente en el error.

El ejecutor de pruebas (planes de pruebas de Azure) requiere una descarga e instalación única del ejecutor. Seleccione Ejecutar para la aplicación de escritorio, como se muestra a continuación.

Artefactos

Orígenes de nivel superior

Azure DevOps Server 2019 proporciona actualizaciones sustanciales a las fuentes ascendentes disponibles en los alimentadores de Azure Artifacts.

• Puede agregar nuget.org fuentes ascendentes a las fuentes existentes creadas en versiones anteriores de TFS. Busque el banner encima de los paquetes del feed para obtener más información, incluidos los cambios de comportamiento de los que debe estar al tanto antes de actualizar.
• Puede agregar otros canales de Azure DevOps Server como orígenes ascendentes a su canal, lo que significa que puede usar paquetes NuGet y npm de esos orígenes a través de su canal.

También hemos introducido un nuevo rol en Azure Artifacts: "Colaborador". Un colaborador puede guardar paquetes de un origen ascendente, pero no puede publicar paquetes paquetes directamente en el feed (por ejemplo, mediante el uso del comando nuget publish). Esto le permite restringir la publicación de paquetes a un usuario de confianza o al sistema de compilación, a la vez que sus ingenieros pueden usar nuevos paquetes de las fuentes ascendentes.

Seguimiento de paquetes

Hemos facilitado aún más la configuración de notificaciones con un nuevo botón Seguir directamente en cada paquete. El botón Seguir también es compatible con las vistas de lanzamientos. Si sigue un paquete mientras lo examina a través de una vista, solo obtendrá actualizaciones para las nuevas versiones que se promueven a esa vista.

Cambiar la configuración de la fuente sin tener que guardar manualmente

Se han mejorado algunas de las interacciones en la página de configuración del feed. Ahora, los cambios que realice, como agregar un repositorio principal o un permiso, se guardan inmediatamente. Esto significa que no tiene que preocuparse por perder los cambios al cambiar entre pivotes de configuración.

Simplifica la autenticación con el nuevo proveedor de credenciales para distintas plataformas de NuGet

La interacción con fuentes NuGet autenticadas acaba de mejorar mucho. El nuevo proveedor de credenciales de Azure Artifacts basado en .NET Core funciona con msbuild, dotnet y nuget(.exe) en Windows, macOS y Linux. Cada vez que quiera usar paquetes de una fuente de Azure Artifacts, el proveedor de credenciales adquirirá y almacenará automáticamente un token en nombre del cliente nuGet que está usando. Ya no es necesario almacenar y administrar manualmente un token en un archivo de configuración.

Para obtener el nuevo proveedor, dirígete a GitHub y sigue las instrucciones para tu cliente y plataforma.

Comprime símbolos cuando publica en un archivo compartido

Hemos actualizado la tarea Index & Publish Symbols para admitir la compresión de símbolos al publicarlos en una compartición de archivos.

Wiki

Publicación de archivos markdown desde un repositorio de Git como wiki

Los desarrolladores crean documentación para "APIs", "SDKs" y "documentos de ayuda que explican el código" en repositorios de código. A continuación, los lectores deben examinar el código para encontrar la documentación correcta. Ahora puede simplemente publicar archivos markdown desde repositorios de código y hospedarlos en Wiki.

En Wiki, empiece haciendo clic en Publicar código como wiki. A continuación, puede especificar una carpeta en un repositorio de Git que se debe promover.

Una vez que haga clic en Publicar, todos los archivos markdown de la carpeta seleccionada se publicarán como wiki. Esto también asignará el encabezado de la rama a la wiki para que los cambios realizados en el repositorio de Git se reflejen inmediatamente.

Consulte la entrada de blog sobre la documentación del producto para más información.

Vínculo a encabezados dentro de una página

Ahora puede hacer clic en el icono de vínculo situado junto a cualquier encabezado de sección de una página wiki para generar una dirección URL directamente en esa sección. Después, puede copiar esa dirección URL y compartirla con los miembros del equipo para vincularlas directamente a esa sección.

Adjuntar archivos e imágenes en carpetas

Al editar páginas wiki sin conexión, puede ser más fácil agregar datos adjuntos e imágenes de archivo en el mismo directorio que la página wiki. Ahora, puede agregar datos adjuntos o una imagen en cualquier carpeta de la wiki y vincularla a la página.

Inserta un video en la wiki

Ahora puede insertar vídeos en una página wiki desde servicios en línea como Microsoft Stream y YouTube. Puede agregar la dirección URL de vídeo insertada mediante la sintaxis siguiente:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Cambiar el nombre de una wiki

Ahora puede cambiar el nombre de la wiki en la interfaz de usuario wiki y usar las API REST. En el menú Más , haga clic en Cambiar nombre wiki para asignarle un nombre memorable a la wiki.

Abrir página en nueva pestaña

Ahora puede hacer clic con el botón derecho en una página wiki y abrirla en una nueva pestaña o simplemente presionar CTRL + clic izquierdo en una página wiki para abrirla en una nueva pestaña.

Conservar caracteres especiales en títulos de página Wiki

Ahora puede crear páginas wiki con caracteres especiales, como : < > * ? | -. Ahora, páginas con títulos como "FAQ?" o "Guía de configuración" se puede crear en Wiki. Los caracteres siguientes se traducen a sus cadenas codificadas UTF-8:

Carácter	Cadena codificada
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

Ver vínculos rotos

Todos los vínculos de una wiki que no están vinculados correctamente aparecerán en un color rojo distinto y un icono de vínculo roto, lo que le proporcionará una pista visual de todos los vínculos rotos en una página wiki.

Corregir vínculos rotos al mover páginas

Los vínculos de página rotos son una de las principales causas de mala calidad de página en cualquier solución de documentación. Anteriormente en Wiki, cuando movió una página dentro de la estructura de árbol o cambió el nombre de una página, podría interrumpir los vínculos a la página de otras páginas y elementos de trabajo. Ahora, puede buscar y corregir vínculos para asegurarse de que no se rompan.

Importante

Recuerde usar la []() sintaxis de Markdown para vínculos en páginas y el tipo de vínculo de página Wiki en elementos de trabajo para permitir que Wiki encuentre y corrija estos vínculos potencialmente rotos. Esta función no detectará las URLs y los hipervínculos en texto plano dentro de los elementos de trabajo.

Al cambiar el nombre o mover una página, se le pedirá que compruebe si hay vínculos absolutos o relativos afectados.

A continuación, se mostrará una lista de los enlaces de página y elementos de trabajo afectados antes de proceder.

Crear tabla de contenido para páginas wiki

A veces, las páginas wiki pueden ser largas, con contenido organizado en varios encabezados. Ahora puede agregar una tabla de contenido a cualquier página que tenga al menos un encabezado mediante la [[_TOC_]] sintaxis .

También puede insertar la tabla de contenido haciendo clic en el botón adecuado en el panel de formato al editar página.

Consulte la documentación de la guía de Markdown para más información sobre el uso de Markdown en Azure DevOps.

Metadatos de Surface para páginas wiki y vista previa de código mediante etiquetas YAML

Agregar metadatos a la documentación puede ayudar a los lectores y a los índices de búsqueda a captar y exponer contenido significativo. En esta actualización, cualquier archivo que contenga un bloque YAML al principio del archivo se transformará en una tabla de metadatos de un encabezado y una fila. El bloque YAML debe tener la forma de conjunto DE YAML válido entre líneas triples discontinuas. Admite todos los tipos de datos básicos, lista, objeto como valor. La sintaxis se admite en Wiki y en la vista previa de archivos de código.

Ejemplo de etiquetas YAML:

---
tag: post
title: Hello world
---

Ejemplo de etiquetas YAML con lista:

---
tags:
- post
- code
- web
title: Hello world
---

Publique el código como wiki con permisos de contribución

Anteriormente, solo los usuarios que tenían permiso Crear repositorio en un repositorio git podían publicar código como wiki. Esto hizo que los administradores o creadores del repositorio crearan un cuello de botella para las solicitudes de publicación de archivos markdown alojados en repositorios git como wikis. Ahora, puede publicar código como wiki si solo tiene permiso De colaboración en el repositorio de código.

Generación de informes

La extensión Marketplace de Analytics para informes ya está disponible.

La extensión de Marketplace de Analytics ya está disponible para Azure DevOps Server. Analytics es el futuro de los informes de Azure DevOps y Azure DevOps Server. La instalación de la extensión Analytics proporciona widgets avanzados, integración de Power BI y acceso a OData.

Para obtener más información, consulte What is Analytics and the Reporting Roadmap (Qué es Analytics y la hoja de ruta de informes). Analytics está en versión preliminar pública. Actualmente contiene datos para paneles y resultados de pruebas automatizadas a través de canalizaciones. Consulte Datos disponibles en Analytics Service.

Investigar el historial de compilación a través de un nuevo widget de panel de compilación

Tenemos un widget nuevo y mejorado de historial de versiones que puedes agregar a tus paneles. Con este widget ahora puede ver un historial de compilaciones desde una rama específica en el panel y configurarla en un proyecto público para visitantes anónimos.

Importante

Si busca información sobre las compilaciones XAML, siga usando el widget anterior y lea sobre la migración de compilaciones XAML a nuevas compilaciones. De lo contrario, se recomienda pasar al widget más reciente.

---

Comentarios

Nos encantaría que nos diera su opinión. Puede notificar un problema o proporcionar una idea y realizar un seguimiento a través de la Comunidad de desarrolladores y obtener consejos sobre Stack Overflow.

---

Principio de página