Notas de la versión de Azure DevOps Server 2019

| Developer CommunityConfiguración de los términos | de licencia de requisitos del sistema | Hashes sha-1 del blog | deDevOps

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 de descargas de Azure DevOps Server.

La actualización directa a Azure DevOps Server 2020 se admite desde 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 forma diferente, en función de las directivas de retención de nivel de canalización. Algunas configuraciones de directiva provocan que las ejecuciones de canalización se eliminen después de la actualización. Las ejecuciones de canalización que se han retenido manualmente o que se conservan mediante una versión no se eliminarán después de la actualización.

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

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 16: 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 la revisión 15 publicada 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 la revisión 15 será la 3.225.0.

Configuración de TFX

1. Siga los pasos descritos en la documentación de carga de 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 usar el nuevo comportamiento, se debe establecer una variable AZP_75787_ENABLE_NEW_LOGIC = true en canalizaciones que usen las tareas afectadas.

• En el 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 

Azure DevOps Server 2019.0.1 Patch 15 Release Date: 12 de septiembre de 2023

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

• CVE-2023-33136: Azure DevOps Server vulnerabilidad de ejecución remota de código.
• 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 Azure DevOps Server 2019.0.1 Patch 15.

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 autohospedado para implementar el agente.  

Nota

El AZP_AGENT_DOWNGRADE_DISABLED debe establecerse en "true" para evitar que el agente se cambie a una versión anterior. En Windows, el siguiente comando se puede usar en un símbolo del sistema administrativo, seguido de un reinicio. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configuración de TFX

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

Actualización de tareas mediante TFX

1. Descargue y extraiga 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 usar el nuevo comportamiento, se debe establecer una variable AZP_75787_ENABLE_NEW_LOGIC = true en canalizaciones que usen las tareas afectadas.

• En el 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 

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 14: 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 Azure DevOps Server.

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

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

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

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 12: 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 la revisión 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 la 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 la revisión 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 de interfaz de usuario de definición de compilación.

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 10: 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 la revisión 10, tendrá que instalar la AzureResourceGroupDeploymentV2 tarea.

Instalación de la tarea 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 carpeta nueva 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 un símbolo del sistema en modo de 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. En 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>*

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 9: 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 Azure DevOps Server
• CVE-2020-17135: vulnerabilidad de suplantación de identidad Azure DevOps Server
• CVE-2020-17145 : Vulnerabilidad de suplantación de identidad de Azure DevOps Server y Team Foundation Server
• Se ha corregido un problema con TFVC que no procesaba todos los resultados.

Importante

Lea las instrucciones completas que se proporcionan a continuación antes de instalar esta revisión.

Instalación de revisiones generales

Si tiene Azure DevOps Server 2019.0.1, debe instalar Azure DevOps Server 2019.0.1 Patch 9.

Comprobación de la instalación

• Opción 1: Ejecute 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 la revisión se ha instalado o que no está instalada.

• 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 se instala 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 Azure PowerShell módulo Az de Azure Powershell en la máquina del agente privado.

2. Cree una canalización con la tarea AzurePowerShellV4 . Solo verá un error 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 un símbolo del sistema en modo de 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. En 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. La ruta de acceso del paquete extraído será D:\tasks (1)\AzurePowerShellv4.

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

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 8: 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.

Azure DevOps Server 2019.0.1 Patch 7 Fecha de lanzamiento: 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 scripting entre sitios
• 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 herencia a Activada o Desactivada en la definición de compilación XAML.

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 6: 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

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 5: 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

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 3: 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

---

Azure DevOps Server 2019.0.1 Fecha de lanzamiento de la revisión 2: 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 están autorizadas para todas las canalizaciones de forma predeterminada.

---

Azure DevOps Server 2019.0.1 Patch 1 Release Date: 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 incorporación de cambios

---

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

Azure DevOps Server 2019.0.1 es un resumen de correcciones 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 Developer Community.
• apiwitcontroller.executequery produce una excepción cuando una consulta tiene la misma columna varias veces.
• En el modelo de objetos de cliente que usa el ámbito de vso.work_full oauth, se produce un error en WorkItemServer.DownloadFile().
• Copiar una imagen incrustada de 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 Análisis de pruebas tiene un star (*) que indica la versión preliminar, aunque esta característica no está en versión preliminar.
• 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 aterrizaje Versiones, la acción iniciar borrador de versión estaba creando una nueva versión, pero ahora inicia la versión de borrador.

Azure Test Plans

• El filtro de 1 hora en TestRuns y TestResults CompletedDate son demasiado granulares.
• En el tipo de elemento de trabajo Caso de prueba , no se debe localizar el tipo "Caso de prueba".
• Los casos de prueba no aparecen en MTM ni en un explorador.
• "Fase de validación: no tiene permiso para desencadenar versiones en la canalización de versión asociada" al ejecutar pruebas automatizadas desde un plan de pruebas. Se notifica a través de Developer Community.
• 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 Developer Community.
• 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 El ejecutor de pruebas.

Azure Artifacts

• Subir y Bajar no se localizan en Ascendentes.

Análisis

• Los informes de análisis pueden mostrar datos incompletos porque el modelo está marcado como "listo" antes de que se complete realmente.
• Los widgets de velocidad, quemar y quemar muestran diferentes trabajos planeados para los usuarios en diferentes zonas horarias.
• Una suspensión se puede colocar en la ingesta de datos de Analytics mientras se realiza un mantenimiento que puede provocar informes obsoletos.

General

• Los elementos de navegación izquierdo se exprimen en IE cuando no hay suficiente espacio.

Administración

• Se ha agregado un registro adicional a la actualización de la colección para ayudar a depurar problemas.
• Cuando Se produce un error en TfsConfig offlineDetach, el mensaje de error no es accionable.
• El servicio TfsJobAgent se bloquea.
• 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 Búsqueda 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 Prueba de Visual Studio

Se ha agregado compatibilidad con Visual Studio 2019 a la tarea Prueba de Visual Studio en canalizaciones. Para ejecutar pruebas con la plataforma de prueba para Visual Studio 2019, seleccione las opciones Más recientes o Visual Studio 2019 en el menú desplegable Versión de la plataforma de prueba.

---

Azure DevOps Server 2019 Patch 2 Fecha de lanzamiento: 14 de mayo de 2019

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

• CVE-2019-0872 : Vulnerabilidad de scripting entre sitios (XSS) en Test Plans
• CVE-2019-0971 : Vulnerabilidad de divulgación de información en Repos API
• CVE-2019-0979 : Vulnerabilidad de scripting entre sitios (XSS) en el centro Usuario

---

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

Hemos publicado una revisión de seguridad para Azure DevOps Server 2019 que corrige los siguientes errores. 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 scripting entre sitios (XSS) en Pipelines
• CVE-2019-0869: vulnerabilidad de inyección de HTML en canalizaciones
• CVE-2019-0870 : vulnerabilidad de scripting entre sitios (XSS) en Pipelines
• CVE-2019-0871 : vulnerabilidad de scripting entre sitios (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 Azure Boards elementos de trabajo
• Configuración de compilaciones mediante YAML
• Las anotaciones de tarjeta incluyen errores y tipos de elementos de trabajo personalizados
• Selector de rama mejorado
• Cambios en artefactos y licencias de canalización de implementación de Release Management

---

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
• Proceso de herencia en colecciones nuevas
• Nuevo centro de elementos de trabajo
• Nuevos paneles, trabajos pendientes y centros sprints
• Nuevo centro de consultas
• Estandarización de descripciones de solicitudes de incorporación de cambios mediante plantillas
• Cambio de la rama de destino de una solicitud de incorporación de cambios
• Administración de canalizaciones de compilación mediante la nueva página Compilaciones
• Administración de canalizaciones de versión mediante la nueva página Versiones
• Visualización del progreso de la versión
• Actualización local del agente
• Exponer progresivamente las implementaciones de fases mediante puertas de versión
• 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
• Boards
• 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 de canalización 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á un uso de licencia de Artifacts 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 Release Management canalizaciones de implementación. Al igual que las canalizaciones de compilación, Release Management las canalizaciones de implementación 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 (De 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. Consulte la documentación para más información.

Elemento de trabajo & probar las API SOAP del modelo de objetos de cliente 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 versiones futuras de Azure DevOps Server. Puede encontrar más información en nuestra documentación.

Proceso de herencia en colecciones nuevas

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

Cuadro de búsqueda expandido

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 control flotante de trabajo

Una nueva característica que estamos muy contentos de presentar es el control flotante de mi trabajo . Hemos oído comentarios que, cuando se encuentra en una parte del producto y desea alguna información de otra parte, no desea perder su contexto. Con esta nueva característica, puede acceder a este control flotante desde cualquier lugar del producto y le proporcionará un vistazo rápido a información crucial, incluidos los elementos de trabajo, las solicitudes de incorporación de cambios y todos los favoritos. Con este nuevo control flotante, si está en Repositorios en el código, pero desea comprobar rápidamente qué elemento de trabajo debe trabajar a continuación, simplemente puede hacer clic en el control flotante y ver los elementos de trabajo asignados y recoger el siguiente elemento.

A continuación, puede ver el control flotante mi trabajo que muestra los elementos de trabajo asignados a mí:

Aquí puede ver el segundo pivote que muestra las solicitudes de incorporación de cambios asignadas. En el control flotante, también tiene acceso de un clic para ver más solicitudes de incorporación de cambios:

Aquí puede ver la última tabla dinámica, que es todo lo que ha favorito. Esto incluye sus equipos favoritos, paneles, paneles, trabajos pendientes, consultas y repositorios:

Boards

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

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 seguir teniendo un flujo de trabajo que se integra con los flujos de trabajo de desarrollador en GitHub.

La vinculación de confirmaciones y solicitudes de incorporación de cambios a elementos de trabajo es fácil. 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 cuyo ámbito está fuera de servicio. 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. A continuación se muestran todas las opciones de la lista:

Si quiere reducir aún más el ámbito de las listas, 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 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 sprints

El centro de trabajos pendientes se dividió en tres concentradores distintos para mejorar la experiencia del usuario. Aunque potente, el antiguo centro de trabajos pendientes era el hogar de demasiadas características. 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 ahora es el hogar de solo los trabajos pendientes de un proyecto. Un trabajo pendiente es una lista prioritaria de trabajo para el equipo. Los trabajos pendientes proporcionan herramientas de planeación como la jerarquía de elementos de trabajo, la previsión y la nueva experiencia de planeamiento de sprint.
• El nuevo concentrador boards es el hogar de todos los paneles 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 sprints es el hogar de las características usadas para planear 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 la última modificación por información y la capacidad de buscar consultas
• Ruta de navegación con direcciones URL únicas para carpetas para marcar grupos importantes de consultas
• Acceso rápido a sus consultas favoritas desde la página de resultados

Obtenga más información sobre estas emocionantes actualizaciones 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 planeamiento de sprint

Las nuevas características de planeamiento 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 .
• Use el nuevo panel Planificación del trabajo pendiente 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 los requisitos a la parte superior del Panel de tareas o use la creación rápida para agregarlos a la parte superior, inferior o fila que prefiera en el trabajo pendiente de sprint.
• Use filtros para Assignee, Work Item Type, State y Tags para adaptar las vistas a sus necesidades.

Nuevas páginas de directorio

Todos los nuevos centros, incluidos trabajos pendientes, paneles y sprints, ahora tienen nuevas páginas de directorio organizadas con las secciones siguientes:

• Continue where you left off (Continuar donde se dejó) En esta nueva sección se proporciona un vínculo rápido directamente al último (Panel | Trabajo pendiente | Sprint) estabas encendido.
• Favoritos Todos sus paneles favoritos, sprints y trabajos pendientes en todos los equipos.
• Mi Todos los paneles, trabajos pendientes y sprints de los equipos a los que pertenece.
• Todo 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ú Opciones de vista . Se trata de una nueva página principal 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, para 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

A las anotaciones de tarjetas les encanta su intuitiva vista de lista de comprobación e interacción. Anteriormente, las anotaciones de tarjeta se limitaban a los tipos de nivel de trabajo pendiente predeterminados y no admitían 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.

Traslado del trabajo mediante á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 ruta de acceso Área e Iteración ahora incluyen una lista de valores usados recientemente como Sugerencias, lo que le proporciona acceso rápido para establecer y continuar.

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.

Trabajo de consulta en la programación de iteración con +/- @CurrentIteration

La @CurrentIteration macro que ayuda a su equipo a realizar un seguimiento del trabajo en función de la programación de iteración ahora admite el desplazamiento entero. Mantenga fácilmente las pestañas en el trabajo que no se cerró con @CurrentIteration - 1, o examine 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 @CurrentIteration macro en las consultas anteriores, es posible que haya observado que los resultados pueden variar si el contexto del equipo cambia en Teams con diferentes programaciones de iteración. Ahora, al crear o modificar una consulta con la @CurrentIteration macro, también tendrá que seleccionar el equipo con la programación de iteración que sea 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 de elementos de trabajo en dos proyectos de equipo diferentes con nombres de iteración diferentes e incluso programaciones. Esto significa que ya no es necesario 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.

Trabajo de consulta en las rutas de acceso de área de un equipo con la nueva @TeamAreas macro

En la configuración de un equipo, puede asociar una o varias rutas de acceso de área, lo que le ayuda a centrar trabajos pendientes, paneles, planes, incluso paneles para el trabajo de ese equipo. Sin embargo, si desea escribir una consulta para un equipo, tenía que enumerar las rutas de acceso de área específicas para ese equipo en las cláusulas de consulta. Ahora, hay disponible una nueva macro @TeamAreas para que pueda hacer referencia fácilmente a las rutas de acceso de área que pertenecen al 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 basadas en 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.

Apertura de elementos de trabajo desde la búsqueda

Anteriormente, no se podía 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 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 rama 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 directivas de solicitud de incorporación de cambios

En el caso de los equipos que usan solicitudes de incorporación de cambios (RP) y directivas de rama, puede haber ocasiones en las que los usuarios necesiten invalidar y omitir esas directivas, por ejemplo, al implementar una revisión en un problema de producción en medio de la noche. Tiene sentido confiar en que los desarrolladores hagan lo correcto y usen la funcionalidad de invalidación con moderación. Al mismo tiempo, los equipos necesitan una manera de comprobar que esas invalidaciones de directiva se usan en las situaciones adecuadas. Para admitir esto, hemos agregado un nuevo filtro de notificación para permitir que los usuarios y los equipos reciban alertas por 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 selecciona Omisión de directiva en la lista de filtros. Seleccione Directivas omitidas 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ó un salto de compilación, aplicar una revisión en medio de la noche, etc. Anteriormente, ofrecimos un permiso ("Exento de la aplicación de directivas") para ayudar a los equipos a administrar qué usuarios se les concedió la capacidad de omitir las directivas de rama al completar una solicitud de incorporación de cambios. Sin embargo, ese permiso también concedió la capacidad de insertar directamente en la rama, pasando por completo el proceso de solicitud de incorporación de cambios.

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

1. Omitir las directivas cuando finalicen las solicitudes de incorporación de cambios. Los usuarios con este permiso podrán usar la experiencia "Invalidar" para las PR.
2. Omitir las directivas al insertar. Los usuarios con este permiso podrán insertar directamente en ramas que tengan configuradas directivas necesarias.

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 contra la inserción accidental en una rama con directivas.

Nota:

Este cambio no introduce ningún cambio de comportamiento. A los usuarios a los que anteriormente se les concedió permiso para "Excluir de la aplicación de directivas" se les concederá Permiso para ambos permisos nuevos, por lo que podrán invalidar la finalización en solicitudes de incorporación de cambios e insertar directamente en ramas con directivas.

Consulte la documentación establecer permisos de rama para obtener más información.

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 manualmente un título.

Las descripciones de solicitudes 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.

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

Cuando iniciamos por primera vez la experiencia de solicitud de incorporación de cambios (PR), pensamos que tendría sentido asignar todas las solicitudes de incorporación de cambios al contexto del equipo que había seleccionado al crear la solicitud de incorporación de cambios. 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, hemos tomado 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 agregan revisores de forma predeterminada. La lista de revisores tiene una característica para facilitar la adición de usuarios y grupos que se agregaron recientemente a las solicitudes de incorporación de cambios. La directiva de revisores necesarios 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 solicitudes de incorporación de cambios "Asignadas a mis equipos", lo que proporciona una funcionalidad equivalente como la sección anterior. Sin embargo, si pertenece a varios equipos, en esta sección se mostrarán las solicitudes de incorporación de cambios asignadas a cualquiera de los 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 descripciones de solicitudes de incorporación de cambios mediante plantillas

Escribir buenas descripciones de PR 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 de solicitud de incorporación de cambios para facilitar a los equipos escribir excelentes descripciones y ahora hemos agregado esa característica.

Además de admitir una plantilla de descripción de solicitud de incorporación de cambios predeterminada, los equipos pueden agregar varias plantillas, que se le presentan en un menú de la página crear solicitud de incorporación de cambios. Simplemente haga clic en el botón Agregar una plantilla para elegir entre cualquier plantilla del repositorio para anexarla a la descripción de la solicitud de incorporación de cambios.

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 carpeta de rama. Por ejemplo, si desea tener una plantilla específica para todas las ramas que comiencen por "revisión/", puede agregar una plantilla que se usará para todas las solicitudes de incorporación de cambios 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.

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

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

Además de corregir errores, la característica para cambiar las ramas de destino también facilita la "retar" una solicitud de incorporación de cambios cuando la rama de destino se ha combinado o eliminado. Considere un escenario en el que tiene una solicitud de incorporación de cambios dirigida a una rama de características que contiene algunas características en las que dependen los cambios. Quiere revisar los cambios dependientes de forma aislada de otros cambios en la rama de características, por lo que inicialmente tiene como destino features/new-feature. 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 una solicitud de incorporación de cambios activa y se combinara main antes de los cambios. Anteriormente, tendría que abandonar los cambios y crear una nueva solicitud de incorporación de cambios en main, o combinarla en features/new-featurey, a continuación, 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 puede cambiar la rama de destino de la solicitud de incorporación de cambios de features/new-feature a main, conservando todo el contexto y los comentarios. Al cambiar la rama de destino, incluso se crea una nueva actualización de la solicitud de incorporación de cambios, lo que facilita la búsqueda de diferencias anteriores antes del cambio de rama de destino.

Los autores de extensiones pueden consultar el contexto sobre el 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 extensiones 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.

Pipelines

Administración de canalizaciones de compilación mediante la nueva página 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.

Administrar los correos electrónicos de finalización de compilación e implementación mejor con el formato mejorado

Los correos electrónicos de finalización de compilación e implementación se han actualizado para que las reglas de correo electrónico sean más filtrables. Ahora la línea de asunto incluye información más relevante de un vistazo, el cuerpo contiene más detalles y su estilo se ha actualizado con la 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 del agente	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 compilación	Canalización de compilación	Un conjunto completo de pasos de compilación para una aplicación.
Build	Build	Instancia de una canalización de compilación que se está ejecutando o que se ha ejecutado.
Fase	Trabajo	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	Canalización de versión	Un conjunto completo de pasos de versión para que una aplicación se implemente en varias fases.
Release	Release	Instancia de una canalización de versión que se está ejecutando o que se ha ejecutado.
Entorno	Fase	Una entidad lógica e independiente que representa dónde desea implementar una versión generada a partir de una canalización de versión.
Trabajo o canalización simultáneos	Trabajo paralelo	Un trabajo paralelo le ofrece la posibilidad de ejecutar un único trabajo de compilación o versión a la vez en su 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 configuraciones, como las credenciales, usadas para conectarse a servicios externos para ejecutar tareas en una compilación o versión.

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

Administración de canalizaciones de versión mediante la nueva página Versiones

Hay disponible una experiencia de usuario nueva y totalmente rediseñada para la página de aterrizaje de la versión. Vea una lista de las canalizaciones de versión que publica a menudo a la izquierda. También puede buscar en las canalizaciones y favoritos.

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.

Visualización del progreso de la versión

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 la canalización de versión, lo que facilita la comprensión de lo que sucede y expone los detalles y las acciones adecuados en diferentes fases de la versión.

Canalización, detalles de la versión y entornos

La vista Canalización muestra los artefactos de la versión y los entornos donde se implementarán. El área Versión proporciona detalles de la versión, como el desencadenador de versión, 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 a la implementación, se indica en el entorno con la presencia de las aprobaciones y las puertas. El progreso de las aprobaciones y las puertas también se muestra 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 en los registros para escribir 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 en el centro de pruebas 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 las 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 solo el nombre de la máquina.
• Y cambie a la tarea "Powershell en la máquina de destino" versión 2.* o posterior y proporcione el fqdn completo del equipo o el nombre de la máquina seguido de los puertos de administració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 de que hay nuevos puntos de extensibilidad para permitir que las extensiones se desarrolle para exponer aún más información para 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 la Azure DevOps Server. Automatice la canalización de integración continua mediante un archivo YAML protegido en el 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 cree (por ejemplo, conexiones de servicio, grupos de variables, grupos de agentes y archivos seguros) para que se puedan usar en toda la canalización de ese proyecto. Si desea un control más estricto de 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 con el uso de 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 sobre desencadenadores de compilación para obtener más información.

Tenga en cuenta que, en algunos casos, una única 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 opciones de configuración, opciones o un equipo diferente para poseer el proceso dependiente.

Actualización local del agente

Las tareas que instale desde la Galería a veces requieren una versión más reciente del agente de canalizaciones. Si el Azure DevOps Server puede conectarse a Internet, las versiones más recientes se descargan automáticamente. Si no es así, debe actualizar manualmente cada agente. A partir de esta versión, puede configurar el 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 las versiones de agente que pone a disposición, sin tener que exponer sus 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 distintivos de compilación hasta ahora, había algunos problemas:

• La dirección URL no era intuitiva
• El distintivo no era específico de una rama
• 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 pueden llevar a los usuarios a la compilación más reciente de la rama seleccionada. Puede obtener el Markdown para la nueva dirección URL del distintivo de estado seleccionando la acción de menú Distintivo de estado en la nueva página Compilaciones.

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

Adición de contadores de compilación personalizados a las compilaciones

Los contadores de compilación proporcionan una manera de numerar y etiquetar compilaciones de forma única. Anteriormente, podría usar la variable especial $(rev:r) para lograrlo. 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 proporciona 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á vinculado 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.

Azure Policy las validaciones de cumplimiento y seguridad en canalizaciones

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

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

Para cumplir con las directrices de cumplimiento y seguridad como parte del proceso de lanzamiento, 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 durante la implementación de plantillas de ARM.

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

Compilación en plataformas linux/ARM y Windows de 32 bits

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

Experiencias mejoradas para pruebas en canalizaciones

La pestaña Pruebas ahora tiene una experiencia moderna que proporciona información enriquecida de pruebas en contexto para canalizaciones. La nueva experiencia proporciona una vista de prueba en curso, una experiencia de depuración de página completa, en el historial de pruebas de contexto, la generación de informes de ejecución de pruebas anuladas y el resumen de nivel de ejecución.

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

Las pruebas, como la integración y las pruebas funcionales, se pueden ejecutar durante mucho tiempo, por lo que es importante ver la ejecución de pruebas en un momento dado. Con el In-Progress Vista de pruebas, ya no tiene que esperar a que se complete la ejecución de la prueba para conocer el resultado de la prueba. 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 un error o anular, archivar un error o anular la canalización. La característica está disponible actualmente para la canalización de compilación y versión mediante la tarea de prueba de VS en la fase multiagente, mediante la tarea Publicar resultados de pruebas o publicar resultados de pruebas mediante API. En el futuro, tenemos previsto ampliar esta experiencia para la ejecución de pruebas mediante el Agente único.

En la vista siguiente se muestra el resumen de In-Progress prueba en la nueva vista de progreso de la versión, el recuento total de pruebas y el número de errores de prueba en un momento dado.

Al hacer clic en el resumen de In-Progress prueba anterior, puede ver el resumen detallado de la prueba junto con información de prueba errónea o anulada en Test Plans. 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 los seguimientos de pila son largos por naturaleza y necesitan suficiente espacio real para ver los detalles durante la depuración. Para tener una experiencia de depuración inmersiva, ahora puede expandir la vista de ejecución de pruebas o pruebas a la vista de página completa, a la vez que puede realizar las operaciones necesarias en operaciones de contexto, como la creación 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, llevamos el historial de pruebas directamente en contexto dentro de Test Plans pestaña para la compilación y la versión. La información del historial de pruebas se proporciona de forma progresiva a partir de la definición de compilación o el entorno de compilación actual para la prueba seleccionada, seguida 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 el código de prueba incorrecto, el origen en pruebas y los problemas del entorno. Independientemente del motivo de la anulación, es importante diagnosticar el comportamiento e identificar la causa principal. Ahora puede ver las pruebas anuladas y las ejecuciones de pruebas, junto con las ejecuciones completadas en Test Plans. La característica está disponible actualmente para la canalización de compilación y versión mediante la tarea de prueba de VS en la fase multiagente o la publicación de resultados de pruebas mediante API. En el futuro, tenemos previsto ampliar esta experiencia para la ejecución de pruebas mediante el Agente único.

Compatibilidad con entornos de seguimiento y versión de prueba 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 está modelando entornos de versión como canalizaciones de versión o entornos de prueba, y ejecuta pruebas en estos entornos, puede averiguar si una prueba pasa el entorno de desarrollo, pero produce un error en el entorno de integración. Puede averiguar si pasa la configuración regional en inglés, pero se produce un error en un entorno que tiene configuración regional 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 son: 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 pruebas que se presentan como una jerarquía en la pestaña Pruebas de una versión. Veamos un ejemplo.

Anteriormente, se introdujo la capacidad de volver a ejecutar pruebas con errores en la tarea De prueba de VS . Sin embargo, solo hemos informado sobre el último intento de una prueba, lo que limitaba ligeramente 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.

Visualización del análisis de pruebas en Canalizaciones

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

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

Vea el 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 organizan mediante y se ejecutan en el servidor. Las fases sin agente no requieren un agente ni ningún equipo de destino. 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 fases sin agente. Las tareas de la misma fase se ejecutarían secuencialmente, igual que para las fases del agente. Consulte la documentación de fases del servidor para obtener más información.

Exposición progresiva de implementaciones y fases mediante puertas de lanzamiento

Con las puertas de lanzamiento, puede especificar los criterios de mantenimiento de la aplicación que deben cumplirse antes de que se promueva una versión al entorno siguiente. 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 sobre validaciones de versión para obtener más información.

Mantener las implementaciones hasta que las puertas se realicen correctamente de forma coherente

Las puertas de lanzamiento permiten la evaluación automática de los criterios de mantenimiento antes de promover una versión al entorno siguiente. De forma predeterminada, la versión progresa después de que se haya recibido un ejemplo correcto para todas las puertas. Incluso si una puerta es errática y la muestra correcta recibida es ruido, la versión progresa. Para evitar estos tipos de problemas, ahora puede configurar la versión para comprobar la coherencia del estado 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 Control de implementación de versiones mediante puertas para obtener más información.

Implementación automática en nuevos destinos 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 procesan después del procesamiento y la compilación solo se debe liberar una vez completado el procesamiento. Ahora puede aprovechar las etiquetas de compilación, que se asignarían durante el posprocesamiento, en los filtros de desencadenador de la versión.

Establecer 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 y desencadenar la versión con la variable .

Pasar variables de entorno a tareas

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

Esto habilita dos escenarios:

• Una tarea requiere una variable de entorno con mayúsculas y minúsculas en el nombre de la variable. Por ejemplo, en el ejemplo anterior, la variable de entorno que se pasa a la tarea sería "foo" y no "FOO".
• Permite pasar valores de secretos de forma segura a los scripts. Se prefiere pasar los secretos como argumentos a los scripts, ya que el sistema operativo del agente puede registrar la invocación de procesos, incluidos sus argumentos.

Clonación de grupos de variables

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

Nota

Los valores de la variable secreta 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 puertas de lanzamiento permiten la evaluación automática de los criterios de mantenimiento antes de promover una versión al entorno siguiente. De forma predeterminada, la canalización de versión solo progresa cuando todas las puertas están en buen estado al mismo tiempo. En determinadas situaciones, como cuando se acelera una versión o después de comprobar manualmente el estado, es posible que un aprobador quiera omitir una puerta y permitir que la liberación avance incluso si esa puerta todavía se ha evaluado como correcto. La documentación de puertas de lanzamiento para obtener más información.

Realización de pruebas adicionales mediante un desencadenador de versión de solicitud de incorporación de cambios

Ha 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 durante un tiempo. Ahora también puede configurar un desencadenador de solicitud de incorporación de cambios para una versión. El estado de la versión se devolverá al repositorio de código y se puede ver directamente en la página de solicitud de incorporación de cambios. Esto resulta útil si desea realizar pruebas funcionales o manuales adicionales como parte del flujo de trabajo de solicitud de incorporación de cambios.

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

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

Ejecución desde el paquete admitido en implementaciones de Azure App Service

La versión de Azure App Service Deploy task (4.*) ahora admite RunFromPackage (anteriormente denominado 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 Ejecutar desde paquete, ya no hay un paso de implementación que copie los archivos individuales en 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 Azure App Service.
• Puede reducir los tiempos de arranque en frío, especialmente para las funciones de JavaScript con árboles de paquete de npm grandes.

Implementación de contenedores de Linux con la tarea De implementación de App Server

La versión 4.* de la tarea de implementación de Azure App Service ahora admite 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 términos de empaquetado y aprovechamiento de dependencias específicas de la aplicación. Functions en Linux se puede hospedar en dos modos diferentes:

1. Imagen de contenedor integrada: El código de Function App 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 App Service tarea Implementar.
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 Xcode 10 recién publicada

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

Optimizació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. Ahora hay disponible una tarea de Helm en versión para empaquetar e implementar gráficos 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 mediante Kubernetes en Azure Container Service para más información.

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

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 a la ruta de acceso del agente (hospedada o privada). 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 versión garantiza que va a empaquetar e implementar la 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: base de datos MySQL de Azure como servicio. Administre los archivos de script de MySQL en el control de versiones e implemente continuamente como parte de una canalización de versión mediante una tarea nativa en lugar de scripts de PowerShell.

Uso de tareas mejoradas basadas en PowerShell remoto de Windows

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

Tarea de PowerShell en destino (versión: 3.*): puede agregar un script insertado, modificar las opciones de PSSession, controlar "ErrorActionPreference" y producir 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 GitHub Enterprise o 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

Use la tarea Instalador de herramientas de Go para instalar una o varias versiones de Go Tool sobre la marcha. Esta tarea adquiere una versión específica de go Tool que necesita el proyecto y la agrega a la ruta de acceso 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 instalación 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 de Go personalizado de su elección.

Ejecución de scripts de Python insertados o basados en archivos en la canalización

Una nueva tarea script de Python simplifica la ejecución de scripts de Python en la canalización. 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.

Aproveche la salida mejorada 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 de macOS hospedados. Aunque la salida de xcpretty puede ser diferente y menos detallada que la salida de xcodebuild, hacemos que los registros completos de xcodebuild estén disponibles con cada compilación.

Test Plans

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 nuestra guía 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 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 (Azure Test Plans) requiere una descarga e instalación única del ejecutor. Seleccione Ejecutar para la aplicación de escritorio , como se muestra a continuación.

Artifacts

Orígenes de nivel superior

Azure DevOps Server 2019 aporta actualizaciones sustanciales a los orígenes ascendentes disponibles en las fuentes de Azure Artifacts:

• Puede agregar nuget.org orígenes ascendentes a fuentes existentes creadas en versiones anteriores de TFS. Busque el banner encima de los paquetes de la fuente para obtener más información, incluidos los cambios de comportamiento que debe tener en cuenta antes de actualizar.
• Puede agregar otras fuentes de Azure DevOps Server como orígenes ascendentes a la fuente, lo que significa que puede usar paquetes NuGet y npm de esas fuentes a través de la fuente.

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 directamente en la fuente (por ejemplo, mediante nuget publish). Esto le permite restringir la publicación de paquetes a un usuario de confianza o al sistema de compilación, al tiempo que permite a los ingenieros usar nuevos paquetes de los orígenes ascendentes.

Seguir 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 versión. 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 de fuente. Ahora, los cambios que realice, como agregar un permiso ascendente o un permiso, se guardan inmediatamente. Esto significa que no tiene que preocuparse por perder los cambios al cambiar entre los valores dinámicos.

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, vaya a GitHub y siga las instrucciones para el cliente y la plataforma.

Comprime símbolos cuando publica en un archivo compartido

Hemos actualizado la tarea Index & Publicar símbolos para admitir la compresión de símbolos cuando se publican en un recurso compartido de archivos.

Wiki

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

Los desarrolladores crean documentación para "API", "SDK" y "ayudan a explicar el código" en los 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.

Desde Wiki, comience 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 que realice en el repositorio de Git se reflejen inmediatamente.

Consulte la entrada de blog de documentación del producto para obtener 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 archivos adjuntos e imágenes 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 asignar 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 "P+F?" 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 proporciona 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, al mover una página dentro de la estructura de árbol o cambiar 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 comprobar y corregir los vínculos antes de que se rompa.

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 busque y corrija estos vínculos potencialmente rotos. Esta característica no recogerá las direcciones URL y los hipervínculos de texto sin formato en 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 vínculos Página y Elementos de trabajo afectados antes de realizar una acción.

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 la 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 del código mediante etiquetas YAML

Agregar metadatos a la documentación puede ayudar a los lectores y a buscar índices a recoger 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 adoptar la forma de conjunto 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 la vista previa del archivo wiki y del archivo 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
---

Publicación de código como wiki con permisos de contribución

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

Notificación

La extensión de 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 ¿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 el servicio Analytics.

Investigar el historial de compilación mediante un nuevo widget de panel de compilación

Tenemos un widget de historial de compilación nuevo y mejorado que puede agregar a los paneles. Con este widget ahora puede ver un historial de compilaciones de 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 Developer Community y obtener consejos sobre Stack Overflow.

---

Principio de página