Partager via

Prise en charge des déploiements séquentiels lors de l’utilisation de vérifications de verrous exclusifs

  • Article

Dans ce sprint, nous avons étendu la fonctionnalité de vérifications de verrous exclusifs dans Azure Pipelines pour prendre en charge les déploiements séquentiels. Vous pouvez maintenant mettre en file d’attente plusieurs exécutions sur un environnement pour ne laisser qu’une seule d’entre elles s’exécuter à la fois.

Pour plus d’informations, consultez les descriptions des fonctionnalités suivantes.

Azure Boards

Azure Pipelines

Azure Boards

La section développement d’un élément de travail affiche la liste des validations et des demandes de tirage pertinentes. Vous pouvez afficher l’auteur de la validation ou de la demande de tirage ainsi que l’heure associée. Avec cette mise à jour, nous avons résolu un problème d’affichage incorrect de l’avatar de l’auteur dans la vue.

Azure Pipelines

Prise en charge des déploiements séquentiels plutôt que de la dernière version uniquement lors de l’utilisation de vérifications de verrous exclusifs

Dans les pipelines YAML, les vérifications sont utilisées pour contrôler l’exécution des phases sur les ressources protégées. L’un des contrôles courants que vous pouvez utiliser est un verrou exclusif case activée. Cette case activée permet à une seule exécution à partir du pipeline de continuer. Lorsque plusieurs exécutions tentent de déployer dans un environnement en même temps, le case activée annule toutes les anciennes exécutions et autorise le déploiement de la dernière exécution.

L’annulation des anciennes exécutions est une bonne approche lorsque vos mises en production sont cumulatives et contiennent toutes les modifications de code des exécutions précédentes. Toutefois, il existe certains pipelines dans lesquels les modifications de code ne sont pas cumulatives. Avec cette nouvelle fonctionnalité, vous pouvez choisir d’autoriser toutes les exécutions à se poursuivre et de les déployer de manière séquentielle dans un environnement, ou de conserver le comportement précédent qui consiste à annuler les anciennes exécutions et à autoriser uniquement les dernières exécutions. Vous pouvez spécifier ce comportement à l’aide d’une nouvelle propriété appelée lockBehavior dans le fichier YAML du pipeline. La valeur de sequential implique que toutes les exécutions acquièrent le verrou séquentiellement sur la ressource protégée. La valeur de runLatest implique que seule la dernière exécution acquiert le verrou de la ressource.

Pour utiliser la vérification Verrou exclusif avec des déploiements sequential ou runLatest, suivez ces étapes :

  1. Activez la vérification Verrou exclusif sur l’environnement (ou une autre ressource protégée).
  2. Dans le fichier YAML du pipeline, spécifiez une nouvelle propriété appelée lockBehavior. Celle-ci peut être spécifiée pour l’ensemble du pipeline ou pour un index donné :

Définie sur un index :

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

Définie sur le pipeline :

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

Si vous ne spécifiez pas de lockBehavior, il est supposé être runLatest.

Prise en charge de la version québécoise de ServiceNow

Azure Pipelines a une intégration existante à ServiceNow. L’intégration s’appuie sur une application dans ServiceNow et une extension dans Azure DevOps. Nous avons maintenant mis à jour l’application pour qu’elle fonctionne avec la version québécoise de ServiceNow. Les pipelines classiques et YAML fonctionnent maintenant avec le Québec. Pour vous assurer que cette intégration fonctionne, effectuez une mise à niveau vers la nouvelle version de l’application (4.188.0) à partir du magasin Service Now. Pour plus d’informations, consultez Intégrer à ServiceNow Change Management.

Modification de la stratégie de préinstallation du SDK .NET sur les agents Windows et macOS hébergés par Microsoft

Récemment, nous avons annoncé une modification de la stratégie de préinstallation du Kit de développement logiciel (SDK) .NET sur les agents Ubuntu hébergés par Microsoft. Nous effectuons maintenant la même modification pour les agents Windows et macOS hébergés par Microsoft.

Actuellement, nous installons toutes les versions disponibles et prises en charge du SDK .NET (2.1.x, 3.1.x, 5.0.x) sur les agents Windows et macOS hébergés par Microsoft. Cette approche sera modifiée en faveur de l’installation de la dernière version du correctif pour chaque version de fonctionnalité. Cette modification est apportée pour vous fournir plus d’espace libre et pour les nouvelles demandes d’outils.

Qu’est-ce que cela signifie ?

La version du Kit de développement logiciel (SDK) se compose des éléments suivants : x.y.znn. z est la version de fonctionnalité et nn est la version corrective. Par exemple, pour la version 2.1.302, la version de fonctionnalité est 3 et 02 la version du correctif. Selon la nouvelle approche, nous installerons uniquement la dernière version du correctif pour chaque version de fonctionnalité, c’est-à-dire que seule 2.1.302 sera installée pour 2.1.3x, seulement 2.1.403 pour 2.1.4x et ainsi de suite. Toutes les versions du Kit de développement logiciel (SDK) .NET qui ne sont pas les dernières versions correctives seront supprimées des images Windows et macOS le 6 septembre. Ce changement a un impact sur toutes les versions de Windows et macOS sur les agents hébergés par Microsoft.

Date cible

Le déploiement des images mises à jour commencera le 6 septembre et prendra 3 à 4 jours.

Impact possible

Si vous utilisez un fichier global.json, votre build sera affectée dans les cas suivants :

Votre build échouera si le fichier global.json contient la rollForward: disable propriété et une version du Kit de développement logiciel (SDK) qui n’est pas la dernière version du correctif. Par exemple :

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

La version du Kit de développement logiciel (SDK) .NET sera automatiquement modifiée vers le dernier correctif si le fichier global.json contient la rollForward: patch propriété . Par exemple :

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

Si le rollForward champ n’est pas spécifié dans votre fichier global.json, il n’y aura aucune modification pour vous. Le dernier niveau de correctif installé est utilisé.

Si vous devez utiliser une version exacte du SDK .NET qui n’est pas le dernier correctif, utilisez la tâche pour l’installer UseDotNet dans le cadre de la build :

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

Modifications apportées aux tâches PublishBuildArtifacts et DownloadBuildArtifacts

Azure Pipelines prend en charge deux ensembles de tâches pour la publication/le téléchargement d’artefacts. PublishPipelineArtifact et DownloadPipelineArtifact sont les tâches les plus récentes et recommandées pour effectuer ces étapes.

PublishBuildArtifacts et DownloadBuildArtifacts sont les tâches plus anciennes et n’ont pas les mêmes optimisations de performances et de stockage que celles présentes dans les tâches PipelineArtifact correspondantes. Ces tâches plus anciennes présentaient également des limitations d’échelle en termes de mise en œuvre. Certains de nos clients de plus grande taille ont dû se trouver dans ces limites.

Bien que nous souhaitions que tous les clients passent aux tâches PipelineArtifact, nous avons également dû prendre certaines mesures pour résoudre la scalabilité des anciennes tâches BuildArtifact. Dans le cadre d’une mise à jour récente visant à améliorer leur scalabilité, les agents Azure Pipelines interagissent désormais directement avec les artefacts de build via des domaines blobstore (au lieu d’un routage via des domaines tfs). Ces pipelines commencent à accéder aux adresses IP et aux domaines qui sont depuis longtemps dans la liste verte Azure DevOps, mais qui n’ont peut-être pas été utilisés auparavant par des pipelines spécifiques.

L’implémentation mise à jour des tâches BuildArtifact nécessite une mise à niveau de l’agent, qui doit se produire automatiquement, sauf si les mises à niveau automatiques ont été spécifiquement désactivées ou si les pare-feu sont mal configurés.

Si vos agents s’exécutent dans des environnements pare-feu qui n’ont pas suivi les instructions liées, ils peuvent voir des échecs lors de la mise à jour de l’agent ou dans les tâches PublishBuildArtifacts ou DownloadBuildArtifacts jusqu’à ce que la configuration du pare-feu soit corrigée.

Un symptôme courant de ce problème est des erreurs soudaines liées aux liaisons ssl ou aux échecs de téléchargement d’artefacts, généralement sur les pools de déploiement ciblés par Release Management définitions. Sinon, si les mises à niveau de l’agent ont été bloquées, vous pouvez observer que les mises en production attendent un agent dans le pool qui n’arrive jamais, ou que les agents passent hors connexion à la moitié de leur mise à jour (cette dernière est liée aux environnements qui bloquent par erreur le CDN de l’agent).

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

Accédez à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu Aide pour signaler un problème ou faire une suggestion.

Faire une suggestion

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Aaron Hallberg