Mejoras de YAML en Azure Pipelines: actualización de Sprint 142
En la actualización sprint 142 de Azure DevOps, se han realizado varias mejoras en YAML, como agregar contadores personalizados a las compilaciones, especificar ramas para compilar para solicitudes de incorporación de cambios y usar plantillas insertadas. También hemos activado la nueva navegación para todos los usuarios, hemos introducido un tema oscuro y hemos mejorado las experiencias de vinculación y datos adjuntos en Azure Boards.
Consulte la lista de características siguiente para obtener más información.
Características
General:
Azure Boards:
- Organización de materiales de referencia con datos adjuntos de elementos de trabajo más completos
- Administración de dependencias mediante la vinculación de elementos de trabajo en todas las organizaciones
- Apertura de elementos de trabajo desde la búsqueda
Azure Repos:
Azure Pipelines:
- Adición de contadores de compilación personalizados a las compilaciones
- Uso de YAML para especificar ramas que se van a compilar para solicitudes de incorporación de cambios
- Uso de expresiones de plantilla YAML insertadas
- Mejora de la solución de problemas con el registro de inicialización de canalización
- Retención predeterminada para canalizaciones DE YAML
- Compilación en plataformas Linux/ARM y Windows de 32 bits
- Clonación de grupos de variables
- Consulte confirmaciones y elementos de trabajo para todos los orígenes vinculados.
- Ejecutar desde el paquete admitido en implementaciones de Azure App Service
- Implementación de contenedores de Linux con la tarea De implementación de App Server
Azure Test Plans:
Azure Artifacts:
Wiki:
Administración:
General
La nueva navegación está activada para todos los usuarios
Hemos activado nuestra nueva navegación para todos los usuarios. Este es un hito importante en la implementación de nuestro nuevo diseño de producto. Aunque estamos moviendo a todos al nuevo modelo de navegación con esta versión, los usuarios podrán optar por no participar y usar la navegación anterior hasta el 16 de enero de 2019. Puede optar por no participar seleccionando Características de vista previa en el menú debajo de su avatar en la parte superior derecha de cada página.
Consulte la entrada de blog Actualización de navegación para obtener más información.
Tema oscuro
Una de nuestras solicitudes de características de larga duración ha sido ofrecer un tema oscuro. Nos complace informarle de que esto ya está disponible como parte de la nueva navegación. Puedes activar el tema oscuro seleccionando Tema en el menú debajo de tu avatar en la parte superior derecha de cada página.
Azure Boards
Organización de materiales de referencia con datos adjuntos de elementos de trabajo más completos
Adjuntar archivos a elementos de trabajo le permite a usted y a su equipo centralizar los materiales de referencia para que estén siempre cerca cuando los necesite. Ahora es más fácil agregar un nuevo archivo adjunto arrastrando y colocando el archivo en cualquier parte del formulario de elemento de trabajo. Puede seguir viendo los datos adjuntos como una lista o cambiar a una vista de cuadrícula para mostrar una vista previa en miniatura. Haga doble clic en el archivo para abrir una vista previa y recorrerlos para encontrar rápidamente la información que necesita.
Administración de dependencias mediante la vinculación de elementos de trabajo en todas las organizaciones
La vinculación de trabajo relacionado o dependiente proporciona un contexto más amplio en el trabajo que está realizando el seguimiento y le ayuda a administrar las dependencias con otros equipos. Con vínculos para el trabajo remoto, ahora puede realizar un seguimiento del trabajo en todas las organizaciones de su empresa. Simplemente copie la dirección URL de un elemento de trabajo existente, vaya a otro elemento de trabajo y cree un vínculo con uno de los tres nuevos tipos de vínculo: Consumes From, Produce para y Remote Related. Consulte la documentación de vinculación de elementos de trabajo para obtener más información sobre la rastreabilidad en Azure Boards.
Nota
Los permisos se respetan en ambas organizaciones de Azure DevOps, que deben estar respaldadas por el mismo inquilino de Azure AD.
A medida que empiece a administrar varias dependencias, use el nuevo campo Recuento de vínculos remotos en Consultas para enumerar los elementos de trabajo que tienen dependencias remotas en el proyecto o considere la posibilidad de instalar la extensión Dependency Tracker . Esta extensión, creada por el grupo de Windows en Microsoft para satisfacer sus necesidades de escala, se basa en vínculos remotos para mostrar una jerarquía enriquecida y una representación gráfica de las dependencias.
Apertura de elementos de trabajo desde la búsqueda
Anteriormente, no se podía abrir un elemento de trabajo desde la página de resultados de búsqueda si el panel de vista previa del elemento de trabajo estaba desactivado. Esto dificultaría profundizar en los resultados de búsqueda. Ahora puede hacer clic en el título del elemento de trabajo para abrir los elementos de trabajo en una ventana modal. Esta característica se priorizó de UserVoice.
Azure Repos
Los autores de extensiones pueden consultar el contexto sobre el repositorio actual
Uno de los desafíos de un autor de una extensión de control de versiones es obtener el contexto del repositorio que se muestra al usuario, como el nombre, el identificador y la dirección URL. Para ayudar con esto, agregamos VersionControlRepositoryService como un servicio accesible para extensiones. Con esto, un autor de extensión puede consultar información sobre el contexto actual del repositorio de Git dentro de la interfaz de usuario web. Actualmente tiene un método, getCurrentGitRepository().
- Si se selecciona un repositorio de Git, se devuelve un objeto GitRepository con datos básicos sobre el repositorio (nombre, identificador y dirección URL).
- Si se selecciona un repositorio TFVC o se accede al servicio fuera de las páginas de Azure Repos, se devolverá null.
Esta es una extensión de ejemplo que usa este servicio.
Azure Pipelines
Adición de contadores de compilación personalizados a las compilaciones
Los contadores de compilación proporcionan una manera de numerar y etiquetar compilaciones de forma única. Anteriormente, podría usar la variable especial $(rev:r) para hacerlo. Ahora puede definir sus propias variables de contador en la definición de compilación que se incrementan automáticamente cada vez que se ejecuta una compilación. Esto se hace en la pestaña variables de una definición. Esta nueva característica ofrece más potencia de las siguientes maneras:
- Puede definir un contador personalizado y establecer su valor de inicialización. Por ejemplo, puede iniciar el contador en 100. $(rev:r) siempre comienza en 0.
- Puede usar su propia lógica personalizada para restablecer un contador. $(rev:r) está asociado a la generación de números de compilación y se restablece automáticamente cada vez que hay un nuevo prefijo en el número de compilación.
- Puede definir varios contadores por definición.
- Puede consultar el valor de un contador fuera de una compilación. Por ejemplo, puede contar el número de compilaciones que se han ejecutado desde el último restablecimiento mediante un contador.
Consulte la documentación sobre variables definidas por el usuario para obtener más información sobre los contadores de compilación.
Uso de YAML para especificar ramas que se van a compilar para solicitudes de incorporación de cambios
Las canalizaciones de YAML pueden especificar qué ramas se van a compilar para solicitudes de incorporación de cambios (solicitudes de incorporación de cambios). Puede elegir ramas para incluir y excluir. Esta capacidad estaba disponible anteriormente en la interfaz de usuario web. Al moverlo al archivo YAML, se convierte en parte del flujo de trabajo config-as-code.
Un ejemplo de uso de desencadenadores de solicitud de incorporación de cambios podría ser similar al siguiente:
pr:
branches:
include:
- features/*
exclude:
- features/experimental/*
paths:
include:
- **/*.cs
steps:
- script: echo My PR build!
Uso de expresiones de plantilla YAML insertadas
Las plantillas de YAML son una manera eficaz de reutilizar partes de canalizaciones. Además de factorizar código común, las expresiones de plantilla permiten cambiar los valores y controlar qué yaML se incluye. Hasta ahora, una expresión de plantilla tenía que ocupar todo el valor en una expresión YAML. Este ejemplo funcionaría porque la expresión es el valor completo de la propiedad de la solución .
- task: msbuild@1
inputs:
solution: ${{ parameters.solution }}
Ahora hemos relajado la restricción y se permiten plantillas insertadas como se muestra en el ejemplo siguiente.
- script: echo The solution file is ${{ parameters.solution }}
Mejora de la solución de problemas con el registro de inicialización de canalización
Cuando se ejecuta una canalización, Azure Pipelines tiene que asegurarse de que la definición de la canalización es correcta, decidir qué trabajos programar, solicitar agentes para ejecutar los trabajos, etc. Hasta ahora, este proceso era completamente opaco, por lo que cuando las cosas se equivocaron, era casi imposible que un cliente solucionara el problema. Estamos introduciendo un nuevo tipo de registro, denominado registro de inicialización de canalización, que hace que estos detalles sean visibles. Para acceder al registro de inicialización de canalización, elija la opción Descargar todos los registros en una compilación completada.
Retención predeterminada para canalizaciones DE YAML
Estamos trabajando para que los usuarios configuren directivas de retención para canalizaciones yaML. Hasta que esta nueva característica esté disponible, hemos aumentado la retención predeterminada de todas las compilaciones de YAML a 30 días, ya que muchos usuarios quieren mantener sus compilaciones durante más tiempo que la retención predeterminada de 10 días anterior. Se ha quitado la pestaña de retención en el editor de canalizaciones YAML hasta que el nuevo modelo esté en su lugar.
Compilación en plataformas Linux/ARM y Windows de 32 bits
El agente multiplataforma de Azure Pipelines código abierto siempre se admite en Windows, macOS y Linux de 64 bits (x64). Este sprint, presentamos dos nuevas plataformas compatibles: Linux/ARM y Windows/32 bits. Estas nuevas plataformas le ofrecen la posibilidad de basarse en plataformas menos comunes, pero no menos importantes, como Raspberry Pi, una máquina Linux/ARM.
Clonación de grupos de variables
Se ha agregado compatibilidad con la clonación de grupos de variables. Siempre que quiera replicar un grupo de variables y actualizar solo algunas de las variables, no es necesario pasar por el proceso tedioso de agregar variables una por una. Ahora puede realizar rápidamente una copia del grupo de variables, actualizar los valores de forma adecuada y guardarlos como un nuevo grupo de variables.
Nota:
Los valores de la variable secreta no se copian al clonar un grupo de variables. Debe actualizar las variables cifradas y, a continuación, guardar el grupo de variables clonado.
Consulte confirmaciones y elementos de trabajo para todos los orígenes vinculados.
Continuando nuestro compromiso con la rastreabilidad mejorada, nos complace anunciar que los clientes ahora pueden ver los detalles de confirmación y de trabajo de todos los artefactos vinculados a la canalización. De forma predeterminada, la confirmación y el elemento de trabajo se comparan con la última implementación en la misma fase. Sin embargo, puede comparar con cualquier otra implementación anterior si es necesario.
Ejecutar desde el paquete admitido en implementaciones de Azure App Service
La versión de Azure App Service Deploy (4.*) ahora admite RunFromPackage (anteriormente denominada RunFromZip).
App Service admite varias técnicas diferentes para implementar los archivos, como msdeploy (también conocido como WebDeploy), git, ARM y mucho más. Pero todas estas técnicas tienen una limitación. Los archivos se implementan en la carpeta wwwroot (específicamente d:\home\site\wwwroot) y el runtime ejecuta los archivos desde allí.
Con Ejecutar desde paquete, ya no hay un paso de implementación que copia los archivos individuales en wwwroot. En su lugar, simplemente apunte a un archivo ZIP y el archivo ZIP se monta en wwwroot como un sistema de archivos de solo lectura. Esto presenta varias ventajas:
- Se reduce el riesgo de problemas de bloqueo de copia de archivos.
- Se pueden implementar en una aplicación de producción (con reinicio).
- Puede estar seguro de los archivos que se ejecutan en la aplicación.
- Mejora el rendimiento de las implementaciones de Azure App Service.
- Puede reducir los tiempos de arranque en frío, especialmente para las funciones de JavaScript con árboles de paquete de npm grandes.
Implementación de contenedores de Linux con la tarea De implementación de App Server
La versión 4.* de la tarea de implementación de Azure App Service ahora admite la implementación de su propio contenedor personalizado en Azure Functions en Linux.
El modelo de hospedaje de Linux para Azure Functions se basa en contenedores de Docker que proporcionan mayor flexibilidad en términos de empaquetado y aprovechamiento de dependencias específicas de la aplicación. Las funciones en Linux se pueden hospedar en dos modos diferentes:
- Imagen de contenedor integrada: El código de Function App y Azure proporciona y administra el contenedor (modo de imagen integrado), por lo que no se requiere ningún conocimiento específico relacionado con Docker. Esto se admite en la versión existente de App Service tarea Implementar.
- Imagen de contenedor personalizada: Hemos mejorado la tarea implementar App Service para admitir la implementación de imágenes de contenedor personalizadas en Azure Functions en Linux. Cuando las funciones necesitan una versión de lenguaje específica o requieren una dependencia o configuración específica que no se proporciona en la imagen integrada, puede compilar e implementar una imagen personalizada en Azure Functions en Linux mediante Azure Pipelines.
Azure Test Plans
Cliente de Azure Test Runner para ejecutar pruebas manuales para aplicaciones de escritorio
Ahora puede usar el cliente de Azure Test Runner (ATR) para ejecutar pruebas manuales para aplicaciones de escritorio. Esto le ayudará a pasar de Microsoft Test Manager a Azure Test Plans. Por favor, consulte nuestra guía aquí. Con el cliente ATR, puede ejecutar las pruebas manuales y registrar los resultados de las pruebas para cada paso de prueba. También tiene funcionalidades de recopilación de datos, como captura de pantalla, registro de acciones de imagen y grabación de vídeo de audio. Si encuentra un problema al realizar pruebas, use El ejecutor de pruebas para crear un error con pasos de prueba, capturas de pantalla y comentarios incluidos automáticamente en el error.
ATR requiere una descarga e instalación única del ejecutor. Seleccione Ejecutar para la aplicación de escritorio , como se muestra a continuación.
Azure Artifacts
Versión preliminar pública de los artefactos de canalización
Estamos publicando una versión preliminar pública de Pipeline Artifacts, un nuevo tipo de artefacto altamente escalable diseñado para su uso con Azure Pipelines. Los artefactos de canalización se basan en la misma tecnología que usa la característica paquetes universales anunciados recientemente y pueden reducir drásticamente el tiempo necesario para almacenar salidas de compilación para compilaciones de clase empresarial de gran tamaño.
Wiki
Publicación de código como wiki con permisos de contribución
Anteriormente, solo los usuarios que tenían el permiso Crear repositorio en un repositorio git podían publicar código como wiki. Esto hizo que los administradores del repositorio o creadores de un cuello de botella para cualquier solicitud publicar archivos markdown hospedados en repositorios git como wikis. Ahora, puede publicar código como wiki si solo tiene permiso Contribuir en el repositorio de código.
Administración
LOS PAT aplican cap
En febrero de 2017, anunciamos la compatibilidad con la directiva de acceso condicional (CAP) de Azure Active Directory, pero había una limitación que hacía que los mecanismos de autenticación alternativos, como los tokens de acceso personal, no aplicaran CAP. Nos complace anunciar que hemos rellenado esta brecha y Azure DevOps ahora respetará las directivas de barrera de IP de CAP al usar PAT, claves SSH, credenciales de autenticación alternativas y OAuth. Los administradores no necesitan hacer nada para aprovechar esta característica. Se aplicará automáticamente para todas las directivas existentes.
Pasos siguientes
Nota:
Estas características se implementarán en las próximas dos a tres semanas.
Obtenga información sobre las nuevas características siguientes y diríjase a Azure DevOps para probarlas usted mismo.
Cómo enviar sus comentarios
Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de comentarios para notificar un problema o proporcionar una sugerencia.
También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.
Gracias,
Aaron Bjork