Notas de la versión de Azure DevOps Server 2022

---

| Developer Community Configuración del sistema | ytérminos | de licencia de compatibilidad | DevOps Blog | SHA-256 Hashes |

---

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

Para obtener más información sobre cómo instalar o actualizar una implementación de Azure DevOps Server, consulte .

Para descargar Azure DevOps Server productos, visite la página descargas de Azure DevOps Server.

La actualización directa a Azure DevOps Server 2022 es compatible con Azure DevOps Server 2019 o Team Foundation Server 2015 o versiones posteriores. Si la implementación de TFS está en TFS 2013 o versiones anteriores, debe realizar algunos pasos provisionales antes de actualizar a Azure DevOps Server 2022. Consulte la página Instalar para obtener más información.

---

Azure DevOps Server 2022 Update 0.1 Patch 5 Release Date: 14 de noviembre de 2023

Nota

Azure DevOps Server revisiones son acumulativas, si no instaló la revisión 3, esta revisión incluye actualizaciones del agente de Azure Pipelines. La nueva versión del agente después de instalar Patch 5 será 3.225.0.

Archivo	Hash SHA-256
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

Hemos publicado una revisión para Azure DevOps Server 2022 Update 0.1 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.
• Se ha corregido un problema que provocaba que las modificaciones de las conexiones de servicio fuesen persistentes después de hacer clic en el botón Cancelar.

Azure DevOps Server 2022 Update 0.1 Patch 4 Release Date: 10 de octubre de 2023

Nota

Azure DevOps Server revisiones son acumulativas, si no instaló la revisión 3, esta revisión incluye actualizaciones del agente de Azure Pipelines. La nueva versión del agente después de instalar Patch 5 será 3.225.0.

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

• Se ha corregido un error que provocaba que las canalizaciones se bloqueara mediante la actualización del modelo de ejecución de canalización.
• Se ha corregido un error por el que la identidad "Propietario del análisis" mostraba como Identidad inactiva en las máquinas de actualización de revisiones.
• El trabajo de limpieza de compilación contiene muchas tareas, cada una de las cuales elimina un artefacto de una compilación. Si se produjo un error en alguna de estas tareas, ninguna de las tareas posteriores se ejecutó. Hemos cambiado este comportamiento para omitir los errores de tareas y limpiar tantos artefactos como podamos.

Azure DevOps Server 2022 Update 0.1 Patch 3 Release Date: 12 de septiembre de 2023

Nota

Esta revisión incluye actualizaciones del agente de Azure Pipelines. La nueva versión del agente después de instalar Patch 3 será 3.225.0.

Hemos publicado una revisión para Azure DevOps Server 2022 Update 0.1 que incluye correcciones para 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.

Azure DevOps Server 2022 Update 0.1 Patch 2 Release Date: 8 de agosto de 2023

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

• CVE-2023-36869: Azure DevOps Server vulnerabilidad de suplantación de identidad.
• Se ha corregido un error en las llamadas SOAP en las que se puede generar ArithmeticException para la respuesta XML de metadatos grandes.
• Se implementaron cambios en el editor de conexiones de servicio para que el estado del punto de conexión se vacía al descartar el componente.
• Se ha corregido un problema con vínculos relativos que no funcionaban en archivos markdown.
• Se ha corregido un problema de rendimiento relacionado con el nivel de aplicación que tardaba más de lo normal en iniciarse cuando hay un gran número de etiquetas definidas.
• Se han corregido TF400367 errores en la página Grupos de agentes.
• Se ha corregido un error por el que la identidad del propietario del análisis se mostraba como Identidad inactiva.
• Se ha corregido un error de bucle infinito en CronScheduleJobExtension.

Azure DevOps Server 2022 Update 0.1 Patch 1 Release Date: 13 de junio de 2023

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

• CVE-2023-21565: Azure DevOps Server vulnerabilidad de suplantación de identidad.
• CVE-2023-21569: Azure DevOps Server vulnerabilidad de suplantación de identidad.
• Se ha corregido un error con el editor de conexiones de servicio. Ahora, el estado del punto de conexión de borrador se vacía al descartar el componente.
• Se ha corregido un error en el que la recopilación de desasociación o asociación generaba el siguiente error: "TF246018: la operación de base de datos superó el límite de tiempo de espera y se ha cancelado.

Azure DevOps Server fecha de lanzamiento de la actualización 0.1 de Azure DevOps Server 2022: 9 de mayo de 2023

Azure DevOps Server 2022.0.1 es un resumen de correcciones de errores. Incluye todas las correcciones del Azure DevOps Server 2022.0.1 RC publicadas anteriormente. Puede instalar directamente Azure DevOps Server 2022.0.1 o actualizar desde Azure DevOps Server 2022 o Team Foundation Server 2015 o posterior.

Azure DevOps Server 2022 Update 0.1 RC Fecha de lanzamiento: 11 de abril de 2023

Azure DevOps Server 2022.0.1 RC es una acumulación de correcciones de errores. Incluye todas las correcciones de las revisiones de Azure DevOps Server 2022 publicadas anteriormente. Puede instalar directamente Azure DevOps Server 2022.0.1 o actualizar desde Azure DevOps Server 2022 o Team Foundation Server 2015 o posterior.

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

• Se ha actualizado el sistema de archivos virtual de Git (GVFS) de a v2.39.1.1-micorosoft.2 para solucionar una vulnerabilidad de seguridad.
• Los datos de prueba no se eliminaron, lo que hace que la base de datos crezca. Con esta corrección, hemos actualizado la retención de compilación para evitar la creación de nuevos datos de prueba huérfanos.
• Novedades a AnalyticsCleanupJob, el estado del trabajo se detuvo y ahora notificamos Correcto.
• Se ha corregido el error de comando "tfx extension publish" con el error "The given key was not present in the dictionary" (La clave especificada no estaba presente en el diccionario).
• Implementó una solución alternativa para solucionar y errores al acceder a la extensión Calendario de equipo.
• CVE-2023-21564: vulnerabilidad de scripting entre sitios Azure DevOps Server
• CVE-2023-21553: vulnerabilidad de ejecución remota de código Azure DevOps Server
• Se han actualizado las tareas de MSBuild y VSBuild para admitir Visual Studio 2022.
• Metodología de actualización de la reautenticación de carga para evitar el vector de ataque XSS.
• Azure DevOps Server proxy de 2022 notifica el siguiente error: VS800069: este servicio solo está disponible en Azure DevOps local.
• Se ha corregido el problema de accesibilidad de los conjuntos de estantes a través de la interfaz de usuario web.
• Se ha corregido un problema que requería reiniciar el servicio tfsjobagent y Azure DevOps Server grupo de aplicaciones después de actualizar la configuración relacionada con SMTP en la consola de administración de Azure DevOps Server.
• Las notificaciones no se enviaron durante el PAT siete días antes de la fecha de expiración.

Azure DevOps Server 2022, revisión 4 Fecha de lanzamiento: 13 de junio de 2023

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

• CVE-2023-21565: Azure DevOps Server vulnerabilidad de suplantación de identidad.
• CVE-2023-21569: Azure DevOps Server vulnerabilidad de suplantación de identidad.
• Se ha corregido un error con el editor de conexiones de servicio. Ahora, el estado del punto de conexión de borrador se vacía al descartar el componente.
• Se ha corregido un error en el que la recopilación de desasociación o asociación generaba el siguiente error: "TF246018: la operación de base de datos superó el límite de tiempo de espera y se ha cancelado.

Azure DevOps Server 2022 Patch 3 Fecha de lanzamiento: 21 de marzo de 2023

Hemos publicado una revisión (19.205.33506.1) para Azure DevOps Server 2022 que incluye correcciones para lo siguiente.

• Se ha corregido un problema que requería reiniciar el servicio tfsjobagent y Azure DevOps Server grupo de aplicaciones después de actualizar la configuración relacionada con SMTP en la consola de administración de Azure DevOps Server.
• Copie el estado del punto de conexión en el panel de edición del punto de conexión de servicio en lugar de pasarlo por referencia.
• Anteriormente, al editar conexiones de servicio, las modificaciones se conservaban en la interfaz de usuario después de seleccionar el botón Cancelar. Con esta revisión, se ha corregido en el SDK de notificaciones para cuando un equipo tiene la entrega de notificaciones establecida en No entregar. En este escenario, si la suscripción de notificación está configurada con la opción entrega de preferencias de equipo, los miembros del equipo no recibirán las notificaciones. No es necesario expandir las identidades en el equipo para comprobar las preferencias de los miembros.

Azure DevOps Server fecha de lanzamiento de la revisión 2 de 2022: 14 de febrero de 2023

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

• CVE-2023-21564: vulnerabilidad de scripting entre sitios Azure DevOps Server
• Se han actualizado las tareas de MSBuild y VSBuild para admitir Visual Studio 2022.
• Metodología de actualización de la reautenticación de carga para evitar posibles vectores de ataque XSS.
• Azure DevOps Server proxy de 2022 notifica el siguiente error: VS800069: este servicio solo está disponible en Azure DevOps local.

Azure DevOps Server 2022 Patch 1 Release Date: 24 de enero de 2023

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

• Los datos de prueba no se han eliminado, lo que hace que la base de datos crezca. Con esta corrección, se ha actualizado la retención de compilación para evitar la creación de nuevos datos de prueba huérfanos.
• Novedades al AnalyticsCleanupJob, el estado del trabajo se detuvo y ahora se informa de Correcto.
• Se ha corregido el error "tfx extension publish" con el error "La clave especificada no estaba presente en el diccionario".
• Implementó una solución alternativa para solucionar y errores al acceder a la extensión Calendario de equipo.

Azure DevOps Server fecha de lanzamiento de 2022: 6 de diciembre de 2022

Azure DevOps Server 2022 es un resumen de correcciones de errores. Incluye todas las características del Azure DevOps Server 2022 RC2 y RC1 publicados anteriormente.

Azure DevOps Server 2022 RC2 Fecha de lanzamiento: 25 de octubre de 2022

Azure DevOps Server 2022 RC2 es un resumen de correcciones de errores. Incluye todas las características de la Azure DevOps Server 2022 RC1 publicadas anteriormente.

Nota

Nuevos algoritmos RSA SSH habilitados

Se ha mejorado la compatibilidad con la clave pública RSA para admitir tipos de clave pública SHA2, además de SHA1 SSH-RSA que se admitieron anteriormente.

Los tipos de clave pública admitidos ahora incluyen:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Acción necesaria

Si implementó la solución alternativa para habilitar SSH-RSA especificando explícitamente en el .ssh/config1 archivo, deberá quitar o PubkeyAcceptedTypesmodificarlo para usar RSA-SHA2-256 o RSA-SHA2-512, o ambos. Puede encontrar detalles sobre qué hacer si todavía se le pide la contraseña y GIT_SSH_COMMAND="ssh -v" git fetch no muestra ningún algoritmo de firma mutua en la documentación aquí.

Aún no se ha agregado compatibilidad con claves elípticas y sigue siendo una característica muy solicitada en nuestro trabajo pendiente.

Azure DevOps Server fecha de lanzamiento de RC1 de 2022: 9 de agosto de 2022

Resumen de las novedades de Azure DevOps Server 2022

Importante

El almacén y el servicio de análisis han quedado en desuso en la versión anterior de Azure DevOps Server (2020). En Azure DevOps Server 2022, el almacén y el servicio de análisis se han quitado del producto. Analytics ahora proporciona la experiencia de informes en el producto.

Azure DevOps Server 2022 presenta muchas características nuevas. Entre los aspectos destacados se incluyen:

• Planes de entrega
• Mostrar un rol correcto en los vínculos de confirmación
• Nuevos controles para variables de entorno en canalizaciones
• Generación de compilaciones de bifurcación de tokens sin restricciones
• Nuevas páginas de TFVC
• Agrupar por etiquetas disponibles en widgets de gráfico

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

• Boards
• Repos
• Canalizaciones
• Informes

---

Boards

Planes de entrega

Nos complace anunciar que los planes de entrega ahora están incluidos en Azure DevOps Server. Los planes de entrega ofrecen tres escenarios clave:

• Una vista de escala de tiempo del plan
• Progreso del trabajo
• Seguimiento de dependencia

A continuación se muestran las características principales. El filtrado, los marcadores y los criterios de campo también forman parte de los planes de entrega.

Hay dos vistas principales: condensadas y expandidas

Los planes de entrega 2.0 permiten ver todos los elementos de trabajo del plan en una escala de tiempo, mediante fechas de inicio y destino o fechas de iteración. El orden de precedencia se inicia & fechas de destino seguidas de la iteración. Esto le permite agregar elementos de trabajo de nivel de cartera comoEpic, que a menudo no se definen en una iteración.

Hay dos vistas principales, la vista condensada y la vista expandida. También puede acercar y alejar el plan haciendo clic en la lupa del lado de la mano del plan.

Hay dos vistas principales, la vista condensada y la vista expandida. También puede acercar y alejar el plan haciendo clic en la lupa en el lado derecho del plan.

• Vista condensada

  La vista condensada muestra todas las tarjetas de elemento de trabajo contraídas , lo que significa que no se muestra toda la información de la tarjeta. Esta vista es útil para una vista general del trabajo en el plan. Para contraer los campos de tarjeta, haga clic en el icono de tarjeta situado junto a los iconos de lupa en el lado derecho del plan.

  Este es un ejemplo de un plan que alterna entre las vistas condensadas y expandidas.

  

• Vista expandida

  La vista expandida muestra el progreso de un elemento de trabajo contando el número de elementos secundarios y vinculados y mostrando el porcentaje completado. Actualmente, el progreso viene determinado por el recuento de elementos de trabajo.

  Este es un ejemplo de un plan mediante una vista expandida. Observe las barras de progreso y el porcentaje completados.

  

Seguimiento de dependencia

El seguimiento de dependencias se basa en los vínculos predecesores y sucesores que se definen en los elementos de trabajo. Si esos vínculos no están definidos, no se mostrará ninguna línea de dependencia. Cuando hay un problema de dependencia con un elemento de trabajo, el icono del vínculo de dependencia se colorea de color rojo.

• Visualización de dependencias

  Las dependencias específicas se ven a través del panel de dependencias que muestra todas las dependencias de ese elemento de trabajo, incluida la dirección. Una marca de exclamación roja indica un problema de dependencia. Para abrir el panel, basta con hacer clic en el icono del vínculo de dependencia en la esquina superior derecha de la tarjeta. Estos son ejemplos de dependencias.

  

  

• Líneas de dependencia

  Las dependencias entre los elementos de trabajo se visualizan con líneas de flecha direccional entre los elementos de trabajo respectivos. Varias dependencias se mostrarán como varias líneas. Una línea de color rojo indica un problema.

  Estos son algunos ejemplos.

  

  Este es un ejemplo de un elemento de trabajo con varias dependencias y funciona también con la vista condensada.

  

  Cuando hay un problema, el color de línea es rojo, por lo que es el icono de dependencia.

  Este es un ejemplo.

  

Estilo de tarjeta

Ahora se puede aplicar estilo a las tarjetas mediante reglas, como los paneles Kanban. Abra la configuración del plan y haga clic en Estilos. En el panel Estilos, haga clic en + Agregar regla de estilo para agregar la regla y, a continuación, haga clic en Guardar. Puede haber hasta 10 reglas y cada regla puede tener hasta 5 cláusulas.

• Antes

• Después

Para obtener más información sobre planes de entrega, consulte la documentación aquí.

Elementos quitados en el Centro de elementos de trabajo

El Centro de elementos de trabajo es el lugar para ver una lista de elementos que ha creado o que se le asignan. Proporciona varias funciones dinámicas y de filtro personalizadas para simplificar la enumeración de elementos de trabajo. Una de las principales quejas de la tabla dinámica Asignada a mí es que muestra elementos de trabajo quitados. Estamos de acuerdo en que los elementos de trabajo eliminados ya no son de valor y no deben estar en el trabajo pendiente. En este sprint, ocultamos todos los elementos quitados de las vistas Asignadas a mí en el Centro de elementos de trabajo.

Mostrar el rol correcto en los vínculos de confirmación

La sección de desarrollo de un elemento de trabajo muestra la lista de confirmaciones y solicitudes de incorporación de cambios pertinentes. Puede ver el autor de la solicitud de confirmación o de incorporación de cambios junto con el tiempo asociado. Con esta actualización, se ha corregido un problema que provocaba que el avatar del autor se mostrara incorrectamente en la vista.

Quitar la capacidad de descargar datos adjuntos eliminados del historial de elementos de trabajo

Se ha corregido un pequeño problema por el que los usuarios podían descargar datos adjuntos del historial de elementos de trabajo, incluso después de quitar los datos adjuntos del formulario. Ahora, una vez quitados los datos adjuntos, no se puede descargar del historial, ni la dirección URL de descarga estará disponible en la respuesta de la API rest.

Se ha agregado el valor "Will not Fix" (No corregirá) al campo Error reason (Motivo del error).

Al igual que con todos los demás tipos de elementos de trabajo, el tipo de elemento de trabajo Error tiene un flujo de trabajo bien definido. Cada flujo de trabajo consta de tres o más estados y un motivo. Los motivos especifican por qué el elemento ha pasado de un estado a otro. Con esta actualización, hemos agregado un valor de motivo Will not fix reason for the Bug work item types in the Agile process.we added a Will not fix reason for the Bug work item types in the Agile process. El valor estará disponible como un motivo para mover errores de Nuevo o Activo a Resuelto. Puede obtener más información sobre cómo definir, capturar, evaluar y administrar errores de software en Azure Boards documentación.

Pipelines

Eliminación de directivas de retención por canalización en compilaciones clásicas

Ahora puede configurar directivas de retención para compilaciones clásicas y canalizaciones YAML en la configuración del proyecto de Azure DevOps. Las reglas de retención por canalización para canalizaciones de compilación clásicas ya no se admiten. Aunque esta es la única manera de configurar la retención para las canalizaciones de YAML, también puede configurar la retención para canalizaciones de compilación clásicas por canalización. Hemos quitado todas las reglas de retención por canalización para las canalizaciones de compilación clásicas en una próxima versión.

Lo que esto significa para usted: cualquier canalización de compilación clásica que se use para tener reglas de retención por canalización se regirá por las reglas de retención de nivel de proyecto.

Para asegurarse de que no pierde ninguna compilación al actualizar, se creará una concesión para todas las compilaciones existentes en el momento de la actualización que no tienen una concesión.

Se recomienda comprobar la configuración de retención de nivel de proyecto después de la actualización. Si la canalización requiere específicamente reglas personalizadas, puede usar una tarea personalizada en la canalización. Para obtener información sobre cómo agregar concesiones de retención a través de una tarea, consulte la documentación de establecimiento de directivas de retención para compilaciones, versiones y pruebas.

Nuevos controles para variables de entorno en canalizaciones

El agente de Azure Pipelines examina la salida estándar de los comandos de registro especiales y las ejecuta. El setVariablecomando se puede usar para establecer una variable o modificar una variable definida previamente. Esto puede ser potencialmente aprovechado por un actor fuera del sistema. Por ejemplo, si la canalización tiene un paso que imprime la lista de archivos en un servidor ftp, una persona con acceso al servidor ftp puede agregar un nuevo archivo, cuyo nombre contiene el setVariable comando y hacer que la canalización cambie su comportamiento.

Tenemos muchos usuarios que se basan en la configuración de variables mediante el comando de registro en su canalización. Con esta versión se realizan los siguientes cambios para reducir el riesgo de usos no deseados del setVariable comando.

• Hemos agregado una nueva construcción para los autores de tareas. Al incluir un fragmento de código como el siguiente en task.json, un autor de tareas puede controlar si su tarea establece alguna variable.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Además, estamos actualizando una serie de tareas integradas, como ssh, para que no se puedan aprovechar.

• Por último, ahora puede usar construcciones YAML para controlar si un paso puede establecer variables.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Generación de tokens sin restricciones para compilaciones de bifurcación

Los usuarios de GitHub Enterprise suelen usar bifurcaciones para contribuir a un repositorio ascendente. Cuando Azure Pipelines crea contribuciones a partir de una bifurcación de un repositorio de GitHub Enterprise, restringe los permisos concedidos al token de acceso del trabajo y no permite el acceso a los secretos de canalización mediante dichos trabajos. Puede encontrar más información sobre la seguridad de la creación de bifurcaciones en nuestra documentación.

Esto puede ser más restrictivo que el deseado en estos entornos cerrados, donde los usuarios pueden seguir beneficie de un modelo de colaboración de origen interno. Aunque puede configurar una opción en una canalización para que los secretos estén disponibles para bifurcaciones, no hay ninguna opción para controlar el ámbito del token de acceso del trabajo. Con esta versión, le proporcionamos control para generar un token de acceso de trabajo normal incluso para compilaciones de bifurcaciones.

Puede cambiar esta configuración de Desencadenadores en el editor de canalizaciones . Antes de cambiar esta configuración, asegúrese de comprender completamente las implicaciones de seguridad de habilitar esta configuración.

Repositorios como un recurso protegido en canalizaciones de YAML

Puede organizar el proyecto de Azure DevOps para hospedar muchos subproyectos, cada uno con su propio repositorio de Git de Azure DevOps y una o varias canalizaciones. En esta estructura, puede que desee controlar qué canalizaciones pueden acceder a qué repositorios. Por ejemplo, supongamos que tiene dos repositorios A y B en el mismo proyecto y dos canalizaciones X e Y que normalmente compilan estos repositorios. Es posible que quiera impedir que la canalización Y acceda al repositorio A. En general, quiere que los colaboradores de A controlen las canalizaciones a las que quieren proporcionar acceso.

Aunque esto era parcialmente posible con los repositorios y canalizaciones de Git de Azure, no había experiencia para administrarlo. Esta característica soluciona esa brecha. Los repositorios de Git de Azure ahora se pueden tratar como recursos protegidos en canalizaciones YAML, al igual que las conexiones de servicio y los grupos de agentes.

Como colaborador del repositorio A, puede agregar comprobaciones y permisos de canalización al repositorio. Para ello, vaya a la configuración del proyecto, seleccione Repositorios y, después, el repositorio. Observará un nuevo menú denominado "Comprobaciones", donde puede configurar cualquiera de las comprobaciones en el cuadro o personalizadas en forma de funciones de Azure.

En la pestaña "Seguridad", puede administrar la lista de canalizaciones que pueden acceder al repositorio.

Cada vez que una canalización YAML usa un repositorio, la infraestructura de Azure Pipelines comprueba y garantiza que se cumplan todas las comprobaciones y permisos.

Nota

Estos permisos y comprobaciones solo son aplicables a las canalizaciones de YAML. Las canalizaciones clásicas no reconocen estas nuevas características.

Permisos y comprobaciones en grupos de variables y archivos seguros

Puede usar diferentes tipos de recursos compartidos en canalizaciones de YAML. Algunos ejemplos son las conexiones de servicio, los grupos de variables, los archivos seguros, los grupos de agentes, los entornos o los repositorios. Para proteger una canalización de acceso a un recurso, el propietario del recurso puede configurar permisos y comprobaciones en ese recurso. Cada vez que una canalización intenta acceder al recurso, se evalúan todos los permisos y comprobaciones configurados. Estas protecciones están disponibles en conexiones de servicio, entornos y grupos de agentes durante un tiempo. Se agregaron recientemente a los repositorios. Con esta versión, se agregan las mismas protecciones a grupos de variables y archivos seguros.

Para restringir el acceso a un grupo de variables o a un archivo seguro a un pequeño conjunto de canalizaciones, use la característica De permisos de canalizaciones .

Para configurar comprobaciones o aprobaciones que se deben evaluar cada vez que se ejecuta una canalización, use la característica Aprobaciones y comprobaciones de biblioteca .

Cambios en la creación automática de entornos

Al crear una canalización YAML y hacer referencia a un entorno que no existe, Azure Pipelines crea automáticamente el entorno. Esta creación automática puede producirse en el contexto del usuario o en el contexto del sistema. En los siguientes flujos, Azure Pipelines sabe sobre el usuario que realiza la operación:

• Utilizas el asistente de creación de canalizaciones YAML en la experiencia web de Azure Pipelines y haces referencia a un entorno que aún no se ha creado.
• Actualizas el archivo YAML con el editor web de Azure Pipelines y guardas la canalización después de agregar una referencia a un entorno que no existe. En cada uno de los casos anteriores, Azure Pipelines tiene una comprensión clara del usuario que realiza la operación. Por lo tanto, crea el entorno y agrega el usuario al rol de administrador para el entorno. Este usuario tiene todos los permisos para administrar el entorno o para incluir a otros usuarios en varios roles para administrar el entorno.

En los siguientes flujos, Azure Pipelines no tiene información sobre el usuario que crea el entorno: actualiza el archivo YAML mediante otro editor de código externo, agrega una referencia a un entorno que no existe y, a continuación, hace que se desencadene una canalización de integración continua. En este caso, Azure Pipelines no conoce al usuario. Anteriormente, se ha controlado este caso agregando todos los colaboradores del proyecto al rol de administrador del entorno. Cualquier miembro del proyecto podría cambiar estos permisos e impedir que otros usuarios accedan al entorno.

Hemos recibido sus comentarios sobre cómo conceder permisos de administrador en un entorno a todos los miembros de un proyecto. Al escuchar sus comentarios, hemos oído que no deberíamos crear automáticamente un entorno si no está claro para quién realiza la operación el usuario. Con esta versión, hemos realizado cambios en cómo se crearán automáticamente los entornos:

• En el futuro, las ejecuciones de canalización no crearán automáticamente un entorno si no existe y si no se conoce el contexto del usuario. En tales casos, se producirá un error en la canalización con un error de entorno no encontrado. Debe crear previamente los entornos con la seguridad adecuada y comprobar la configuración antes de usarlo en una canalización.
• Las canalizaciones con contexto de usuario conocido seguirán siendo los entornos de creación automática como lo hicieron en el pasado.
• Por último, debe tenerse en cuenta que la característica para crear automáticamente un entorno solo se agregó para simplificar el proceso de introducción a Azure Pipelines. Estaba pensado para escenarios de prueba y no para escenarios de producción. Siempre debe crear previamente entornos de producción con los permisos y comprobaciones adecuados y, a continuación, usarlos en canalizaciones.

Cuadro de diálogo Quitar conclusiones de la canalización de compilación

En función de los comentarios, se ha quitado el cuadro de diálogo Información de la tarea o canalización que se muestra al navegar por la canalización de compilación para mejorar el flujo de trabajo. El análisis de canalización sigue estando disponible para que tenga la información que necesita.

Compatibilidad con implementaciones secuenciales en lugar de más reciente solo cuando se usan comprobaciones de bloqueo exclusivas

En las canalizaciones de YAML, las comprobaciones se usan para controlar la ejecución de fases en recursos protegidos. Una de las comprobaciones comunes que puede usar es una comprobación de bloqueo exclusiva. Esta comprobación solo permite realizar una sola ejecución desde la canalización. Cuando varias ejecuciones intentan implementar en un entorno al mismo tiempo, la comprobación cancela todas las ejecuciones anteriores y permite implementar la última ejecución.

La cancelación de ejecuciones antiguas es un buen enfoque cuando las versiones son acumulativas y contienen todos los cambios de código de las ejecuciones anteriores. Sin embargo, hay algunas canalizaciones en las que los cambios de código no son acumulativos. Con esta nueva característica, puede optar por permitir que todas las ejecuciones continúen e implementen secuencialmente en un entorno, o conservar el comportamiento anterior de cancelar las ejecuciones antiguas y permitir solo la versión más reciente. Puede especificar este comportamiento mediante una nueva propiedad denominada lockBehavior en el archivo YAML de canalización. Un valor de sequential implica que todas las ejecuciones adquieren el bloqueo secuencialmente al recurso protegido. Un valor de runLatest implica que solo la ejecución más reciente adquiere el bloqueo en el recurso.

Para usar la comprobación de bloqueo exclusiva con implementaciones sequential o runLatest, siga estos pasos:

1. Habilite la comprobación de bloqueo exclusiva en el entorno (o en otro recurso protegido).
2. En el archivo YAML de la canalización, especifique una nueva propiedad denominada lockBehavior. Esto se puede especificar para toda la canalización o para una fase determinada:

Se establece en una fase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Se establece en la canalización:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Si no especifica un lockBehavior, se supone que es runLatest.

Compatibilidad con la versión de Quebec de ServiceNow

Azure Pipelines tiene una integración existente con ServiceNow. La integración se basa en una aplicación de ServiceNow y una extensión en Azure DevOps. Ahora hemos actualizado la aplicación para que funcione con la versión de Quebec de ServiceNow. Las canalizaciones clásicas y YAML ahora funcionan con Quebec. Para asegurarse de que esta integración funciona, actualice a la nueva versión de la aplicación (4.188.0) desde el almacén Service Now. Para obtener más información, consulte Integración con La administración de cambios de ServiceNow.

Nuevas expresiones condicionales de YAML

Escribir expresiones condicionales en archivos YAML acaba de ser más fácil con el uso de ${{ else }} expresiones y ${{ elseif }} . A continuación se muestran ejemplos de cómo usar estas expresiones en los archivos de canalizaciones de YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Compatibilidad con caracteres comodín en filtros de ruta de acceso

Los caracteres comodín se pueden usar al especificar ramas de inclusión y exclusión para desencadenadores de CI o PR en un archivo YAML de canalización. Sin embargo, no se pueden usar al especificar filtros de ruta de acceso. Por ejemplo, no puede incluir todas las rutas de acceso que coincidan con src/app/**/myapp*. Esto ha sido señalado como un inconveniente por varios clientes. Esta actualización llena esta brecha. Ahora, puede usar caracteres comodín (**, *o ?) al especificar filtros de ruta de acceso.

La especificación predeterminada del agente para las canalizaciones será Windows-2022.

La windows-2022 imagen está lista para ser la versión predeterminada de la windows-latest etiqueta en agentes hospedados por Microsoft en Azure Pipelines. Hasta ahora, esta etiqueta apuntaba a agentes de Windows-2019. Este cambio se implementará durante un período de varias semanas a partir del 17 de enero. Tenemos previsto completar la migración en marzo.

Azure Pipelines se admite windows-2022 desde septiembre de 2021. Hemos supervisado sus comentarios para mejorar la estabilidad de la windows-2022 imagen y ahora estamos listos para establecerla como la más reciente.

La windows-2022 imagen incluye Visual Studio 2022. Para obtener una lista completa de las diferencias entre windows-2022 y windows-2019, visite el problema de GitHub. Para obtener una lista completa del software instalado en la imagen, consulte aquí.

El cambio de nombre de la carpeta de canalización valida los permisos

Se puede cambiar el nombre de las carpetas que contienen canalizaciones. Cambiar el nombre de una carpeta ahora solo se realizará correctamente si el usuario tiene permisos de edición en al menos una canalización contenida en la carpeta .

Planeación de la actualización en tiempo de ejecución del agente de canalizaciones

¿Qué es el agente de canalización?

El agente de canalización de Azure DevOps es el producto de software que se ejecuta en un host de canalización para ejecutar trabajos de canalización. Se ejecuta en agentes hospedados por Microsoft, agentes de conjunto de escalado y agentes autohospedados. En este último caso, lo instala usted mismo. El agente de canalización consta de un agente de escucha y un trabajo (implementados en .NET), las tareas de trabajo que se implementan en Node o PowerShell y, por tanto, hospedan esos entornos de ejecución para ellos.

Próxima actualización a .NET 6 & desuso de Red Hat 6

Con el lanzamiento de .NET 6 , podemos aprovechar sus nuevas funcionalidades multiplataforma. En concreto, podremos proporcionar compatibilidad nativa para Apple Silicon y Windows Arm64. Por lo tanto, tenemos previsto pasar a .NET 6 para el agente de canalización (agente de escucha y trabajo) en los próximos meses.

Debido a una serie de restricciones que esto impone, se elimina la compatibilidad con Red Hat Enterprise Linux 6 del agente el 30 de abril de 2022.

Novedades a la tarea Copia de archivos de Azure

Estamos implementando una nueva versión de la tarea Copia de archivos de Azure. Esta tarea se usa para copiar archivos en blobs o máquinas virtuales (VM) de Microsoft Azure Storage. La nueva versión tiene varias actualizaciones solicitadas a menudo por la comunidad:

• La versión de la herramienta AzCopy se ha actualizado a la versión 10.12.2, que admite tipos de contenido de archivo. Como resultado, al copiar PDF, Excel, PPT o uno de los tipos mime admitidos, el tipo de contenido del archivo se establece correctamente.

• Con la nueva versión de AzCopy, también puede configurar un valor para limpiar el destino cuando el tipo de destino es Azure Blob. Al establecer esta opción, se eliminarán todas las carpetas o archivos de ese contenedor. O bien, si se proporciona un prefijo de blob, se eliminarán todas las carpetas o archivos de ese prefijo.

• La nueva versión de la tarea se basa en los módulos Az que están instalados en el agente en lugar de en los módulos de AzureRM. Esto quitará una advertencia innecesaria en algunos casos al usar la tarea.

Los cambios forman parte de una actualización de versión principal para esta tarea. Tendría que actualizar explícitamente las canalizaciones para usar la nueva versión. Hemos elegido actualizar la versión principal para asegurarnos de que no se interrumpen las canalizaciones que todavía dependen de los módulos de AzureRM.

Nuevos puntos de extensión para la vista de detalles de canalizaciones

Hemos agregado dos nuevos puntos de extensibilidad que puede tener como destino en las extensiones. Estos puntos de extensibilidad permiten agregar un botón personalizado en el encabezado de canalización y un menú personalizado en una carpeta de canalización:

• Botón personalizado en el encabezado de canalización: ms.vss-build-web.pipelines-header-menu
• Menú personalizado en una carpeta de canalización: ms.vss-build-web.pipelines-folder-menu

Para usar estos nuevos puntos de extensibilidad, basta con agregar una nueva contribución destinada a ellos en el archivo de manifiesto de la vss-extension.json extensión de Azure DevOps.

Por ejemplo:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

El resultado será:

• Botón personalizado en el encabezado de canalización

  

• Menú personalizado en una carpeta de canalización

  

Migración mejorada a Azure DevOps Services

Al ejecutar una importación desde Azure DevOps Server a Azure DevOps Services, debe tener en cuenta que Azure DevOps ya no admite reglas de retención por canalización. Con esta actualización, se quitaron estas directivas al migrar a Azure DevOps Services desde la Azure DevOps Server local. Para más información sobre la configuración de directivas de retención, consulte nuestra documentación sobre cómo establecer directivas de retención para compilaciones, versiones y pruebas.

Mejora de la API REST de ejecuciones de canalizaciones

Anteriormente, la API REST Pipelines Runs solo devolvía el self repositorio. Con esta actualización, la API REST Pipelines Runs devuelve todos los recursos del repositorio de una compilación.

Las plantillas de canalizaciones de YAML extendidas ahora se pueden pasar información de contexto para las fases, los trabajos y las implementaciones.

Con esta actualización, vamos a agregar una nueva templateContext propiedad para joblos componentes de canalización de , deploymenty stage YAML destinados a usarse junto con las plantillas.

Este es un escenario para usar templateContext:

• Las plantillas se usan para reducir la duplicación de código o para mejorar la seguridad de las canalizaciones.

• La plantilla toma como parámetro una lista de stages, jobso deployments

• La plantilla procesa la lista de entrada y realiza algunas transformaciones en cada una de las fases, trabajos o implementaciones. Por ejemplo, establece el entorno en el que se ejecuta cada trabajo o agrega pasos adicionales para aplicar el cumplimiento.

• El procesamiento requiere que el autor de la canalización pase información adicional a la plantilla para cada fase, trabajo o implementación en la lista.

Veamos un ejemplo. Supongamos que está creando una canalización que ejecuta pruebas de un extremo a otro para la validación de solicitudes de incorporación de cambios. El objetivo es probar solo un componente del sistema, pero, dado que tiene previsto ejecutar pruebas de un extremo a otro, necesita un entorno en el que haya más componentes del sistema disponibles y debe especificar su comportamiento.

Se da cuenta de que otros equipos tendrán necesidades similares, por lo que decide extraer los pasos para configurar el entorno en una plantilla. Su código es similar al siguiente:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Lo que hace la plantilla es, para cada trabajo del testSet parámetro , establece la respuesta de los componentes del sistema especificados por ${{ testJob.templateContext.requiredComponents }} para devolver ${{ testJob.templateContext.expectedHTTPResponseCode }}.

A continuación, puede crear su propia canalización que se extienda testing-template.yml como en el ejemplo siguiente.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Esta canalización ejecuta dos pruebas, positivas y negativas. Ambas pruebas requieren que el dimensionsapi componente esté disponible. El positive_test trabajo espera el dimensionsapi código HTTP devuelto 200, mientras negative_test que espera que devuelva el código HTTP 500.

Compatibilidad con cuentas de servicio administradas de grupo como cuenta de servicio del agente

El agente de Azure Pipelines ahora admite cuentas de servicio administradas de grupo en agentes autohospedados en Windows.

Las cuentas de servicio administradas de grupo proporcionan administración centralizada de contraseñas para las cuentas de dominio que actúan como cuentas de servicio. El agente de Azure Pipelines puede reconocer este tipo de cuenta, por lo que no se requiere una contraseña durante la configuración:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Ejecuciones informativas

Una ejecución informativa indica que Azure DevOps no pudo recuperar el código fuente de una canalización YAML. Esta ejecución es similar a la siguiente.

Azure DevOps recupera el código fuente de una canalización YAML en respuesta a eventos externos, por ejemplo, una confirmación insertada o en respuesta a desencadenadores internos, por ejemplo, para comprobar si hay cambios de código e iniciar una ejecución programada o no. Cuando se produce un error en este paso, el sistema crea una ejecución informativa. Estas ejecuciones solo se crean si el código de la canalización está en un repositorio de GitHub o BitBucket.

Se puede producir un error al recuperar el código YAML de una canalización debido a:

• El proveedor del repositorio experimenta una interrupción
• Regulación de solicitudes
• Problemas de autenticación.
• No se puede recuperar el contenido del archivo .yml de la canalización

Obtenga más información sobre ejecuciones informativas.

La propiedad de la API retentionRules rest de definición de compilación está obsoleta

En el tipo de respuesta de BuildDefinition la API REST de definición de compilación, la retentionRules propiedad ahora está marcada como obsoleta, ya que esta propiedad siempre devuelve un conjunto vacío.

Repos

Nuevas páginas de TFVC

Hemos actualizado varias páginas de Azure DevOps para usar una nueva plataforma web con el objetivo de hacer que la experiencia sea más coherente y accesible en los distintos servicios. Las páginas de TFVC se han actualizado para usar la nueva plataforma web. Con esta versión, estamos haciendo que las nuevas páginas de TFVC estén disponibles con carácter general.

Deshabilitación de un repositorio

A menudo, los clientes han solicitado una manera de deshabilitar un repositorio y evitar que los usuarios accedan a su contenido. Por ejemplo, puede que desee hacerlo cuando:

• Ha encontrado un secreto en el repositorio.
• Una herramienta de análisis de terceros encontró que un repositorio no cumple los requisitos.

En tales casos, es posible que desee deshabilitar temporalmente el repositorio mientras trabaja para resolver el problema. Con esta actualización, puede deshabilitar un repositorio si tiene permisos de eliminación del repositorio . Al deshabilitar un repositorio, puede hacer lo siguiente:

• Puede enumerar el repositorio en la lista de repositorios.
• No se puede leer el contenido del repositorio
• No se puede actualizar el contenido del repositorio
• Vea un mensaje que indica que el repositorio se ha deshabilitado cuando intentan acceder al repositorio en la interfaz de usuario de Azure Repos

Una vez realizados los pasos de mitigación necesarios, los usuarios con el permiso Eliminar repositorio pueden volver a habilitar el repositorio. Para deshabilitar o habilitar un repositorio, vaya a Configuración del proyecto, seleccione Repositorios y, a continuación, el repositorio específico.

Configuración de creadores de ramas para que no obtengan "Administrar permisos" en sus ramas

Al crear una rama, obtendrá "Administrar permisos" en esa rama. Este permiso permite cambiar los permisos de otros usuarios o admitir usuarios adicionales para contribuir a esa rama. Por ejemplo, un creador de rama puede usar este permiso para permitir que otro usuario externo realice cambios en el código. O bien, pueden permitir que una canalización (identidad del servicio de compilación) cambie el código de esa rama. En determinados proyectos con requisitos de cumplimiento más altos, los usuarios no deben poder realizar estos cambios.

Con esta actualización, puede configurar todos y todos los repositorios del proyecto de equipo y restringir a los creadores de ramas para que obtengan el permiso "Administrar permisos". Para ello, vaya a la configuración del proyecto, seleccione Repositorios y, después, Configuración para todos los repositorios o un repositorio específico.

Esta configuración está activada de forma predeterminada para imitar el comportamiento existente. Sin embargo, puede desactivarla si desea usar esta nueva característica de seguridad.

Impedir que los usuarios de bifurcación voten en sus solicitudes de incorporación de cambios ascendentes

Con Azure Repos, los usuarios con permiso de "lectura" en un repositorio pueden bifurcar el repositorio y realizar cambios en su bifurcación. Para enviar una solicitud de incorporación de cambios con sus cambios en el nivel superior, los usuarios necesitan el permiso "contribuir a las solicitudes de incorporación de cambios" en la cadena ascendente. Sin embargo, este permiso también rige quién puede votar sobre las solicitudes de incorporación de cambios en el repositorio ascendente. Como resultado, puede terminar en situaciones en las que un usuario, que no es colaborador del repositorio, puede enviar una solicitud de incorporación de cambios y hacer que se combine en función de cómo configure las directivas de rama.

En los proyectos que promueven un modelo de origen interno, bifurcación y contribución es un patrón común. Para proteger y promover aún más este patrón, estamos cambiando el permiso para votar en una solicitud de incorporación de cambios de "contribuir a las solicitudes de incorporación de cambios" para "contribuir". Sin embargo, este cambio no se realiza de forma predeterminada en todos los proyectos. Tiene que participar y seleccionar una nueva directiva en el repositorio, denominada "Modo de voto estricto" para cambiar este permiso. Se recomienda hacerlo si confía en bifurcaciones en Azure Repos.

Notificación

Agrupar por etiquetas disponibles en widgets de gráfico

El widget de gráfico Agrupar por etiquetas ahora está disponible de forma predeterminada para todos los clientes. Al usar el widget de gráfico, ahora hay una opción disponible para las etiquetas. Los usuarios pueden visualizar su información seleccionando todas las etiquetas o un conjunto de etiquetas en el widget.

Mostrar tipos de elementos de trabajo personalizados en el widget de evolución

Anteriormente, no podía ver los tipos de elementos de trabajo personalizados configurados en el widget de quemación y sumar o contar por un campo personalizado. Con esta actualización, se ha corregido este problema y ahora puede ver los tipos de elementos de trabajo personalizados en el widget de evolución.

---

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