Notas de la versión de Azure DevOps Server 2022

---

| Requisitos del sistema de la Comunidad | de desarrolladores y té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 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 Server, 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:

Las revisiones de Azure DevOps Server son acumulativas, si no ha instalado 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 ediciones de las conexiones de servicio sean 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:

Las revisiones de Azure DevOps Server son acumulativas, si no ha instalado 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 canalizaciones.
• Se ha corregido un error en el que la identidad "Propietario del análisis" se 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 tarea 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: Vulnerabilidad de ejecución remota de código de Azure DevOps Server.
• CVE-2023-38155: Vulnerabilidad de elevación de privilegios de Azure DevOps Server y Team Foundation Server.

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: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.
• Se ha corregido un error en las llamadas SOAP en las que se puede generar AritmeticException 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 en el descarte del 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 solucionado TF400367 errores en la página Grupos de agentes.
• Se ha corregido un error en el que la identidad del propietario del análisis se mostraba como Identidad inactiva.
• Se ha corregido un error de bucle infinito en CronScheduleJobExtension.

Fecha de lanzamiento de la actualización 0.1 de Azure DevOps Server 2022: 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: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.
• CVE-2023-21569: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.
• 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 en el descarte del 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.

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 una acumulación de correcciones de errores. Incluye todas las correcciones de 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 versiones posteriores.

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

Azure DevOps Server 2022.0.1 RC es una acumulación de correcciones de errores. Incluye todas las correcciones en 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 versiones posteriores.

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

• Se ha actualizado el sistema de archivos virtuales de Git (GVFS) de a v2.39.1.1-micorosoft.2 para solucionar una vulnerabilidad de seguridad.
• 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.
• Las actualizaciones de AnalyticsCleanupJob, el estado del trabajo se detuvo y ahora se informa de correcto.
• Se ha corregido el error de comando "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.
• CVE-2023-21564: Vulnerabilidad de scripting entre sitios de Azure DevOps Server
• CVE-2023-21553: Vulnerabilidad de ejecución remota de código de 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.
• El proxy de Azure DevOps Server 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 el grupo de aplicaciones de Azure DevOps Server 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 PAT siete días antes de la fecha de expiración.

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

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

• CVE-2023-21565: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.
• CVE-2023-21569: Vulnerabilidad de suplantación de identidad de Azure DevOps Server.
• 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 en el descarte del 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.

Fecha de lanzamiento de la revisión 3 de Azure DevOps Server 2022: 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 el grupo de aplicaciones de Azure DevOps Server 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, hemos corregido en el SDK de notificación 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 ampliar aún más las identidades del equipo para comprobar las preferencias de los miembros.

Fecha de lanzamiento de la revisión 2 de Azure DevOps Server 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 de 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.
• El proxy de Azure DevOps Server 2022 notifica el siguiente error: VS800069: este servicio solo está disponible en Azure DevOps local.

Fecha de lanzamiento de la revisión 1 de Azure DevOps Server 2022: 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.
• Las actualizaciones de AnalyticsCleanupJob, el estado del trabajo se detuvo y ahora se informa de correcto.
• Se ha corregido el error de comando "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.

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

Azure DevOps Server 2022 es una acumulación de correcciones de errores. Incluye todas las características de Azure DevOps Server 2022 RC2 y RC1 publicadas anteriormente.

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

Azure DevOps Server 2022 RC2 es una acumulación de correcciones de errores. Incluye todas las características de Azure DevOps Server 2022 RC1 publicadas anteriormente.

Nota:

Nuevos algoritmos RSA ssh habilitados

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

Ahora los tipos de clave pública admitidos 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 PubkeyAcceptedTypesmodificarla para usar RSA-SHA2-256 o RSA-SHA2-512 o ambas. Puede encontrar detalles sobre qué hacer si todavía se le pide su contraseña y GIT_SSH_COMMAND="ssh -v" git fetch no muestra ningún algoritmo de firma mutua en la documentación aquí.

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

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

Resumen de las novedades de Azure DevOps Server 2022

Importante

Warehouse y Analysis Service han quedado en desuso en la versión anterior de Azure DevOps Server (2020). En Azure DevOps Server 2022, el servicio de almacenamiento y análisis se ha 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 el rol correcto en los vínculos de confirmación
• Nuevos controles para variables de entorno en canalizaciones
• Generación de tokens sin restricciones para compilaciones de bifurcación
• 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:

• Vista de escala de tiempo del plan
• Progreso del trabajo
• Seguimiento de dependencias

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 prioridad es las fechas de inicio y 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 en el 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 tarjeta. Esta vista es útil para una vista general del trabajo en el plan. Para contraer los campos de la tarjeta, haga clic en el icono de tarjeta situado junto a los iconos de aumento 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. El progreso actual viene determinado por el recuento de elementos de trabajo.

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

  

Seguimiento de dependencias

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 signo de exclamación roja indica un problema de dependencia. Para abrir el panel, simplemente haga 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 direccionales entre los elementos de trabajo respectivos. Varias dependencias se mostrarán como varias líneas. Una línea de color rojo indica un problema.

  Aquí hay 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 y, por tanto, es el icono de dependencia.

  A continuación se muestra 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 más información sobre los 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 han asignado. 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 eliminados. 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, se ocultan todos los elementos eliminados 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 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 incorporación de cambios junto con el tiempo asociado. Con esta actualización, se ha corregido un problema con el avatar del autor que se mostraba incorrectamente en la vista.

Eliminación de 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 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 will not fix reason for the Bug work item types in the Agile process. El valor estará disponible como motivo al 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 la documentación de Azure Boards.

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 canalizaciones 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 canalizaciones de compilación clásicas en una próxima versión.

Esto significa que 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, crearemos una concesión para todas las compilaciones existentes en el momento de la actualización que no tengan 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 setVariable comando se puede usar para establecer una variable o modificar una variable definida previamente. Esto puede ser 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 dependen de establecer 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 sus tareas establecen variables.

{
    "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 compila contribuciones desde una bifurcación de un repositorio de GitHub Enterprise, restringe los permisos concedidos al token de acceso del trabajo y no permite que dichos trabajos accedan a secretos de canalización. 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 todavía pueden beneficiarse de un modelo de colaboración de origen interno. Aunque puede configurar un valor 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 desde Desencadenadores en el editor de canalizaciones. Antes de cambiar esta configuración, asegúrese de que comprende completamente las implicaciones de seguridad de habilitar esta configuración.

Repositorios como un recurso protegido en canalizaciones YAML

Puede organizar el proyecto de Azure DevOps para hospedar muchos subproyectos, cada uno con su propio repositorio git de Azure DevOps y una o varias canalizaciones. En esta estructura, es posible que quiera 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 aborda 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 integradas 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 cumplen 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 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 han estado 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 Permisos de canalizaciones.

Para configurar comprobaciones o aprobaciones que se deben evaluar cada vez que se ejecuta una canalización, use las aprobaciones y comprobaciones de la característica 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 flujos siguientes, 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. Como escuchamos sus comentarios, oímos que no deberíamos crear automáticamente un entorno si no está claro sobre quién es el usuario que realiza la operación. 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 usarla en una canalización.
• Las canalizaciones con contexto de usuario conocidos seguirán creando automáticamente entornos 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 permite que solo se ejecute 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 antiguas y permite implementar la ejecución más reciente.

Cancelar 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 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 trabajar 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 más información, consulte Integración con ServiceNow Change Management.

Nuevas expresiones condicionales de YAML

Escribir expresiones condicionales en archivos YAML es 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 comodines en los filtros de ruta de acceso

Las tarjetas 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 para varios clientes. Esta actualización rellena este hueco. Ahora, puede usar caracteres comodín (**, *o ?) al especificar filtros de ruta de acceso.

La especificación predeterminada del agente para 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 ha admitido 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. El cambio de 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 de 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), el trabajo ejecuta tareas que se implementan en Node o PowerShell y, por tanto, hospeda esos entornos de ejecución para ellos.

Próxima actualización a desuso de .NET 6 y 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, estamos quitando la compatibilidad con Red Hat Enterprise Linux 6 del agente el 30 de abril de 2022.

Actualizaciones de la tarea De copia de archivos de Azure

Estamos implementando una nueva versión de la tarea De copia de archivos de Azure. Esta tarea se usa para copiar archivos en blobs o máquinas virtuales (VM) de Almacenamiento de Microsoft Azure. 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 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 interrumpamos ninguna canalización que todavía dependa 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 le 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 azure DevOps Server local. Para más información sobre cómo configurar 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 fases, trabajos e implementaciones.

Con esta actualización, vamos a agregar una nueva templateContext propiedad para joblos componentes de canalización de , deploymenty stage YAML diseñados para 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, una positiva y una negativa. 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 para que no se requiera 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 tiene un aspecto similar al 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 las ejecuciones informativas.

La propiedad de LA API retentionRules REST de definición de compilación está obsoleta

En el tipo de respuesta de la API REST de definición de compilación, la retentionRules propiedad ahora está marcada como obsoleta, ya que esta propiedad siempre devuelve BuildDefinition 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.

Deshabilitar 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 quiera hacerlo cuando:

• Encontró 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:

• 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 los creadores de ramas para que no obtengan "permisos de administración" en sus ramas

Al crear una nueva rama, obtendrá "Administrar permisos" en esa rama. Este permiso le 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 desactivarlo si desea usar esta nueva característica de seguridad.

Impedir que los usuarios de bifurcaciones voten sobre las solicitudes de incorporación de cambios de niveles superiores

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 la cadena ascendente, 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 este patrón aún más, 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.

Generación de informes

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 agotamiento

Anteriormente, no podía ver los tipos de elementos de trabajo personalizados configurados en el widget de grabación y sumados o contados 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 recuperació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 la Comunidad de desarrolladores y obtener consejos sobre Stack Overflow.

---

Principio de página