Compatibilidad con implementaciones secuenciales al usar comprobaciones de bloqueo exclusivas

  • Artículo

En este sprint, se ha ampliado la funcionalidad de las comprobaciones de bloqueo exclusivas en Azure Pipelines para admitir implementaciones secuenciales. Ahora puede poner en cola varias ejecuciones en un entorno para permitir que solo una de ellas se ejecute a la vez.

Consulte las siguientes descripciones de características para obtener más información.

Azure Boards

Azure Pipelines

Azure Boards

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.

Azure Pipelines

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.

Cambio en la directiva de preinstalación del SDK de .NET en agentes de Windows y macOS hospedados por Microsoft

Recientemente, anunciamos un cambio en la directiva de preinstalación del SDK de .NET en los agentes de Ubuntu hospedados por Microsoft. Ahora estamos realizando el mismo cambio para los agentes de Windows y macOS hospedados por Microsoft.

Actualmente, instalamos todas las versiones disponibles y compatibles del SDK de .NET (2.1.x, 3.1.x, 5.0.x) en agentes de Windows y macOS hospedados por Microsoft. Este enfoque se cambiará en favor de instalar la versión de revisión más reciente para cada versión de característica. Este cambio se realiza para proporcionarle más espacio libre y para las nuevas solicitudes de herramientas.

¿Qué significa?

La versión del SDK se compone de las siguientes partes: x.y.znn. z es la versión de la característica y nn es la versión de revisión. Por ejemplo, para la versión 2.1.302, la versión de la característica es 3 y 02 es la versión de revisión. Según el nuevo enfoque, solo instalaremos la versión de revisión más reciente para cada versión de característica, es decir, solo 2.1.302 se instalará para 2.1.3x, solo 2.1.403 para 2.1.4x, etc. Todas las versiones del SDK de .NET que no son las versiones de revisión más recientes se quitarán de las imágenes de Windows y macOS el 6 de septiembre. Este cambio afecta a todas las versiones de Windows y macOS en agentes hospedados por Microsoft.

Fecha de destino

La implementación de imágenes actualizadas comenzará el 6 de septiembre y tardará entre 3 y 4 días.

Posible impacto

Si usa un archivo global.json, la compilación se verá afectada en los casos siguientes:

Se producirá un error en la compilación si el archivo global.json contiene la rollForward: disable propiedad y una versión del SDK que no es la versión de revisión más reciente. Por ejemplo:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

La versión del SDK de .NET se cambiará automáticamente a la revisión más reciente si el archivo global.json contiene la rollForward: patch propiedad . Por ejemplo:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

Si el campo no se especifica en el rollForward archivo global.json, no habrá ningún cambio. Se usa el nivel de revisión instalado más reciente.

Si necesita usar una versión exacta del SDK de .NET que no sea la revisión más reciente, use la UseDotNet tarea para instalarla como parte de la compilación:

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

Cambios en las tareas PublishBuildArtifacts y DownloadBuildArtifacts

Azure Pipelines admite dos conjuntos de tareas para publicar o descargar artefactos. PublishPipelineArtifact y DownloadPipelineArtifact son las tareas más recientes y recomendadas para realizar estos pasos.

PublishBuildArtifacts y DownloadBuildArtifacts son las tareas anteriores y no tienen las mismas optimizaciones de rendimiento y almacenamiento que están presentes en las tareas PipelineArtifact correspondientes. Estas tareas anteriores también tenían limitaciones de escala en términos de cómo se implementaron. Algunos de nuestros clientes más grandes han estado teniendo estos límites.

Aunque queremos que todos los clientes se muevan a las tareas PipelineArtifact, también tuvimos que realizar algunos pasos para abordar la escalabilidad de las tareas anteriores de BuildArtifact. Como parte de una actualización reciente para mejorar su escalabilidad, los agentes de Azure Pipelines ahora interactuarán directamente con los artefactos de compilación a través de dominios de blobstore (en lugar de enrutar a través de dominios tfs). Estas canalizaciones comenzarán a acceder a direcciones IP y dominios que han estado mucho tiempo en la lista de permitidos de Azure DevOps, pero que es posible que no se hayan usado antes por canalizaciones específicas.

La implementación actualizada de las tareas BuildArtifact requiere una actualización del agente, que debe producirse automáticamente a menos que las actualizaciones automáticas se hayan deshabilitado específicamente o los firewalls estén configurados incorrectamente.

Si los agentes se ejecutan en entornos con firewall que no han seguido las instrucciones vinculadas, pueden ver errores al actualizar el agente o en las tareas PublishBuildArtifacts o DownloadBuildArtifacts hasta que se corrija la configuración del firewall.

Un síntoma común de este problema es errores repentinos relacionados con protocolos de enlace ssl o errores de descarga de artefactos, generalmente en grupos de implementación dirigidos por definiciones de Release Management. Como alternativa, si se han bloqueado las actualizaciones del agente, es posible que observe que las versiones están esperando un agente del grupo que nunca llega o que los agentes se desconectan a mitad de su actualización (este último está relacionado con entornos que bloquean erróneamente la red CDN del agente).

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Vaya a Azure DevOps.

Cómo enviar sus comentarios

Nos encantaría saber lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

Hacer una sugerencia

También puede recibir consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

Gracias,

Aaron Hallberg