Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Fonctionnalités
- 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
- Autorisations et vérifications sur les groupes de variables et les fichiers sécurisés
- Aperçu de la prise en charge des modèles dans l'éditeur YAML
- Ubuntu-16.04 sera supprimé des pools hébergés par Microsoft en septembre 2021
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 préinstallées sur les agents Ubuntu hébergés par Microsoft. Actuellement, nous installons toutes les versions disponibles et prises en charge du Kit de développement logiciel (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 de 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) est composée des parties suivantes : 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 est la version corrective. Selon la nouvelle approche, nous allons installer uniquement la dernière version de correctif pour chaque version de fonctionnalité, c’est-à-dire que seules 2.1.302 seront installées 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 d’images mises à jour démarre le 14 juin et prendra 3 à 4 jours.
Impact potentiel
Si vous utilisez un fichierglobal.json, votre build est affectée dans les cas suivants :
Votre build échoue, si le fichier global.json contient la propriété et la rollForward: disable 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 est automatiquement remplacée par 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 la dernière version du 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>
Permissions 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. Par exemple, citons les connexions de service, les groupes de variables, les fichiers sécurisés, les pools d’agents, les environnements ou les référentiels. Pour protéger un pipeline contre l’accès à 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 sur les connexions de service, les environnements et les pools d’agents depuis quelque temps. Ils ont été récemment ajoutés aux référentiels. 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é d’autorisations Pipelines .
Pour configurer des contrôles ou des approbations qui doivent être évalués chaque fois qu’un pipeline s’exécute, utilisez la fonctionnalité Approbations et contrôles pour Bibliothèque.
Aperçu du support 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 sont é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 pratique 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’assistance IntelliSense lors de l’utilisation d’un modèle. Avec cette version, nous prévisualisons la prise en charge des modèles dans l’éditeur YAML. Pour activer cette préversion, accédez à la préversion des fonctionnalités de votre organisation Azure DevOps et activez l’éditeur de modèles YAML.
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.
Après validation, vous pouvez choisir d’accéder au modèle. Vous pourrez apporter des modifications au modèle à l’aide de toutes les fonctionnalités de l’éditeur YAML.
Notez que cette fonctionnalité est en préversion. Il existe des limitations connues, dont certaines 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
Le support traditionnel de 5 ans d’Ubuntu 16.04 par Canonical se termine en avril 2021. Pour maintenir notre environnement mis à jour et sécurisé, nous allons supprimer Ubuntu 16.04 le 20 septembre 2021.
Vous devez migrer des flux de travail ubuntu-16.04 vers ubuntu-18.04 ou ubuntu-latest qui s’exécuteront sur Ubuntu 20.04 LTS.
Pour vous assurer que tout le monde est au courant de ce changement, nous avons planifié deux brownouts courts. Toutes les builds Ubuntu 16.04 échouent pendant la période de brunout. Par conséquent, il est recommandé de migrer vos pipelines avant le 6 septembre 2021.
Les coupures de courant sont provisoirement programmées pour les dates et heures suivantes. Nous allons mettre à jour ces moments à mesure que nous nous rapprocherons de cette période.
6 septembre 2021 19h00 UTC – 10:00 UTC
14 septembre 2021 19h00 UTC – 10h00 UTC
Étapes suivantes
Note
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 entendre ce que vous pensez de ces fonctionnalités. Utilisez le menu d’aide pour signaler un problème ou fournir une suggestion.
Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.