Partager via


Azure Pipelines - Mise à jour sprint 187

Fonctionnalités

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

Nous modifions les versions du Kit de développement logiciel (SDK) .NET qui sont préinstallées sur les agents Ubuntu 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). 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 Ubuntu le 14 juin. Cette modification a un impact sur toutes les versions d’Ubuntu sur les agents hébergés par Microsoft.

Date cible

Le déploiement des images mises à jour commencera le 14 juin 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 propriété et la version du rollForward: disable 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 la version exacte du Kit de développement logiciel (SDK) .NET qui n’est pas le dernier correctif, utilisez UseDotNet la tâche pour l’installer dans le cadre de la build :

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

Autorisations et vérifications sur les groupes de variables et les fichiers sécurisés

Vous pouvez utiliser différents types de ressources partagées dans des pipelines YAML. Les connexions de service, les groupes de variables, les fichiers sécurisés, les pools d’agents, les environnements ou les dépôts en sont des exemples. Pour empêcher un pipeline d’accéder à une ressource, le propriétaire de la ressource peut configurer des autorisations et des vérifications sur cette ressource. Chaque fois qu’un pipeline tente d’accéder à la ressource, toutes les autorisations et vérifications configurées sont évaluées. Ces protections sont disponibles depuis un certain temps sur les connexions de service, les environnements et les pools d’agents. Ils ont été récemment ajoutés aux dépôts. Avec cette version, nous ajoutons les mêmes protections aux groupes de variables et aux fichiers sécurisés.

Pour restreindre l’accès à un groupe de variables ou à un fichier sécurisé à un petit ensemble de pipelines, utilisez la fonctionnalité Autorisations de pipelines .

Mes variables secrètes

Pour configurer des vérifications ou des approbations qui doivent être évaluées chaque fois qu’un pipeline s’exécute, utilisez la fonctionnalité Approbations et vérifications pour la bibliothèque .

Ajouter l’approbation des vérifications

Préversion de la prise en charge des modèles dans l’éditeur YAML

Les modèles sont une fonctionnalité couramment utilisée au sein des pipelines YAML. Il s’agit d’un moyen simple de partager des extraits de code de pipeline. Ils constituent également un mécanisme puissant pour vérifier ou appliquer la sécurité et la gouvernance via votre pipeline.

Azure Pipelines prend en charge un éditeur YAML qui peut être utile lors de la modification de votre pipeline. Auparavant, l’éditeur ne prenait pas en charge les modèles. Les auteurs de pipelines YAML n’ont pas pu obtenir d’aide IntelliSense lors de l’utilisation d’un modèle. Avec cette version, nous proposons un aperçu de la prise en charge des modèles dans l’éditeur YAML. Pour activer cette préversion, accédez à l’aperçu des fonctionnalités dans votre organization Azure DevOps, puis activez l’éditeur de modèles YAML.

Activer l’éditeur de modèles YAML dans les fonctionnalités en préversion

Lorsque vous modifiez votre fichier principal YAML Azure Pipelines, vous pouvez inclure ou étendre un modèle. Lorsque vous tapez le nom de votre modèle, vous êtes invité à valider votre modèle. Une fois validé, l’éditeur YAML comprend le schéma du modèle, y compris les paramètres d’entrée.

Modèle YAML

Après validation, vous pouvez choisir d’accéder au modèle. Vous serez en mesure d’apporter des modifications au modèle à l’aide de toutes les fonctionnalités de l’éditeur YAML.

Veuillez noter que cette fonctionnalité est en préversion. Il existe des limitations connues, dont certaines que nous travaillons à résoudre. Si le modèle a des paramètres requis qui ne sont pas fournis en tant qu’entrées dans le fichier YAML principal, la validation échoue et vous invite à fournir ces entrées. Dans une expérience idéale, la validation ne doit pas être bloquée et vous devez être en mesure de renseigner les paramètres d’entrée à l’aide d’intellisense. En outre, vous ne pouvez pas créer de modèle à partir de l’éditeur. Vous pouvez uniquement utiliser ou modifier des modèles existants.

Ubuntu-16.04 sera supprimé des pools hébergés par Microsoft en septembre 2021

La prise en charge traditionnelle de 5 ans d’Ubuntu 16.04 par Canonical prend fin en avril 2021. Pour maintenir notre environnement à jour et sécurisé, nous allons supprimer Ubuntu 16.04 le 20 septembre 2021.

Vous devez migrer les workflows ubuntu-16.04 vers ubuntu-18.04 ou ubuntu-latest qui s’exécuteront sur Ubuntu 20.04 LTS.

Pour nous assurer que tout le monde est au courant de ce changement, nous avons planifié deux courts brownouts. Toutes les builds Ubuntu 16.04 échouent pendant la période d’abandon. Par conséquent, il est recommandé de migrer vos pipelines avant le 6 septembre 2021.

Les brownouts sont provisoirement planifiés pour les dates et heures suivantes. Nous allons mettre à jour ces heures à mesure que nous nous rapprocherons de cette période.

6 septembre 2021 17:00 UTC – 22:00 UTC

14 septembre 2021 17h00 UTC – 22h00 UTC

É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.

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.