API de préversion YAML améliorée & configurer amont source pour les packages universels
Dans ce sprint, nous déployons un nouveau point de terminaison d’API qui vous permet de récupérer le corps YAML finalisé. Nous sommes également heureux d’annoncer que nous ajoutons la possibilité de configurer votre source de amont pour les packages universels avec cette version.
Pour plus d’informations, consultez la liste des fonctionnalités ci-dessous.
Fonctionnalités
Azure Boards
- Types d’éléments de travail système sur des backlogs et des tableaux
- Événement de journal d’audit
- Limite du référentiel de l’application Azure Boards GitHub atteinte (préversion privée)
- Personnaliser l’état de l’élément de travail lorsque la demande de tirage est fusionnée (préversion privée)
Azure Pipelines
- Annonces d’images Pipelines
- Améliorations des téléchargements du journal de l’agent
- Vous pouvez également monter des volumes de conteneur en lecture seule
- Contrôle affiné sur le démarrage/l’arrêt d’un conteneur
- Décompression des groupes de tâches pour chaque étape
- Amélioration de la sécurité des versions en limitant l’étendue des jetons d’accès
- Améliorations de la version préliminaire de l’API YAML
Azure Artifacts
- Configuration de sources en amont pour Universal Packages
- Mise à jour de l’API REST de version Package maintenant disponible pour les packages Maven
Azure Boards
Types d’éléments de travail système sur des backlogs et des tableaux
Nous avons démarré une préversion privée d’une fonctionnalité qui vous permet d’ajouter un type d’élément de travail système au niveau de backlog de votre choix. Historiquement, ces types d’éléments de travail n’ont été disponibles qu’à partir de requêtes.
| Processus | Type d’élément de travail |
|---|---|
| Agile | Problème |
| Scrum | Obstacle |
| CMMI | Demande de modification |
| Problème | |
| Révision | |
| Risque |
Nous sommes heureux d’annoncer que la fonctionnalité n’est plus disponible en préversion et généralement disponible pour toutes les organisations. L’ajout d’un type d’élément de travail système à un niveau de backlog est simple. Accédez simplement à votre processus personnalisé et cliquez sur l’onglet Niveaux du backlog. Sélectionnez le niveau de votre backlog de choix (exemple : Backlog des exigences) et choisissez l’option de modification. Ajoutez ensuite le type d’élément de travail.
Événement de journal d’audit
Nous avons ajouté un nouvel événement aux journaux d’audit pour aider les clients à mieux suivre les modifications liées au processus. Un événement est enregistré chaque fois que les valeurs d’une liste de sélection sont modifiées. Les modifications apportées aux champs de liste de sélection sont généralement les modifications les plus courantes apportées à un processus. Avec ce nouvel événement, les administrateurs de l’organisation peuvent mieux suivre quand et qui a apporté des modifications à ces champs.
Limite du référentiel de l’application Azure Boards GitHub atteinte (préversion privée)
Si vous utilisez l’application Azure Boards à partir de la Place de marché GitHub, il existe une limite de 100 dépôts GitHub auxquels vous pouvez vous connecter. Cela devient un bloqueur pour les grandes organisations qui peuvent avoir bien plus de 100 dépôts. Dans ce sprint, nous avons modifié la façon dont Azure Boards se connecte à vos dépôts GitHub pour prendre en charge plus de 100. Si vous atteignez actuellement la limite de 100 référentiels, faites-nous savoir et nous pouvons permettre à la fonctionnalité d’augmenter cette limite et de vous débloquer. Veuillez nous envoyer un e-mail directement avec le nom de votre organisation (dev.azure.com/{organisation}).
Personnaliser l’état de l’élément de travail lorsque la demande de tirage est fusionnée (préversion privée)
Tous les flux de travail ne sont pas identiques. Certains clients souhaitent fermer leurs éléments de travail associés lorsqu’une demande de tirage est terminée. D’autres souhaitent définir les éléments de travail sur un autre état à valider avant de fermer. Nous devrions autoriser les deux.
À compter du sprint 174, nous avons une nouvelle fonctionnalité qui vous permet de définir les éléments de travail à l’état souhaité lorsque la demande de tirage est fusionnée et terminée. Pour ce faire, nous scannons la description de la demande de tirage et recherchons la valeur d’état suivie de la #mention des éléments de travail. Dans cet exemple, nous définissons deux récits utilisateur sur Résolu et fermant deux tâches.
Cette fonctionnalité a été un long moment à venir et nous sommes heureux de voir ce que vous pensez. Pour commencer, nous analysons simplement la description de la demande de tirage et n’incluons aucune modification de l’interface utilisateur. Nous voulions d’abord faire part de vos commentaires avant d’investir davantage.
Si vous souhaitez participer à la préversion privée, veuillez nous envoyer un e-mail directement. N’oubliez pas d’inclure votre organisation (dev.azure.com/{organisation}).
Azure Pipelines
Annonces d’images Pipelines
Remarque
Les images Azure Pipelines sont mises à jour en permanence dans le but de fournir aux utilisateurs la meilleure expérience possible. Ces mises à jour de routine sont principalement destinées à résoudre les bogues ou les logiciels obsolètes. Ils n’auront souvent aucun impact sur vos pipelines, mais ce n’est pas toujours le cas. Votre pipeline peut être affecté s’il prend une dépendance sur un logiciel qui a été supprimé ou mis à jour sur l’image.
Pour en savoir plus sur les mises à jour à venir sur nos images Windows, Linux et macOS, consultez les annonces suivantes :
Pour afficher les notes de publication à venir (préversion) et les modifications déployées, veuillez vous abonner aux notes de publication suivantes :
Améliorations des téléchargements du journal de l’agent
Lorsqu’un agent cesse de communiquer avec le serveur Azure Pipelines, le travail en cours d’exécution devient abandonné. Si vous examinez les journaux de la console de diffusion en continu, vous avez peut-être obtenu des indices sur ce que l’agent était à droite avant qu’il ne réponde. Mais si vous n’étiez pas, ou si vous avez actualisé la page, ces journaux de console ont disparu. Avec cette version, si l’agent cesse de répondre avant qu’il n’envoie ses journaux complets, nous allons conserver les journaux de la console comme meilleure chose. Les journaux de console sont limités à 1 000 caractères par ligne et peuvent parfois être incomplets, mais ils sont beaucoup plus utiles que de ne rien montrer ! L’examen de ces journaux peut vous aider à dépanner vos propres pipelines, et cela aidera certainement nos ingénieurs de support lorsqu’ils vous aident à résoudre les problèmes.
Vous pouvez également monter des volumes de conteneur en lecture seule
Lorsque vous exécutez un travail de conteneur dans Azure Pipelines, plusieurs volumes contenant l’espace de travail, les tâches et d’autres matériaux sont mappés en tant que volumes. Ces volumes sont par défaut accessibles en lecture/écriture. Pour renforcer la sécurité, vous pouvez monter les volumes en lecture seule en modifiant la spécification de votre conteneur dans YAML. Chaque clé sous mountReadOnly peut être définie true pour la lecture seule (la valeur par défaut est false).
resources:
containers:
- container: example
image: ubuntu:18.04
mountReadOnly:
externals: true
tasks: true
tools: true
work: false
Contrôle affiné sur le démarrage/l’arrêt d’un conteneur
En général, nous vous recommandons d’autoriser Azure Pipelines à gérer le cycle de vie de vos conteneurs de travail et de service. Toutefois, dans certains scénarios rares, vous pouvez commencer et les arrêter vous-même. Avec cette version, nous avons intégré cette fonctionnalité à la tâche Docker.
Voici un exemple de pipeline utilisant la nouvelle fonctionnalité :
resources:
containers:
- container: builder
image: ubuntu:18.04
steps:
- script: echo "I can run inside the container (it starts by default)"
target:
container: builder
- task: Docker@2
inputs:
command: stop
container: builder
# if any step tried to run in the container here, it would fail
En outre, nous incluons la liste des conteneurs dans une variable de pipeline. Agent.ContainerMapping Vous pouvez l’utiliser si vous souhaitez inspecter la liste des conteneurs dans un script, par exemple. Il contient un objet JSON stringifié mappant le nom de la ressource (« générateur » à partir de l’exemple ci-dessus) à l’ID de conteneur que l’agent gère.
Décompression des groupes de tâches pour chaque étape
Lorsque l’agent exécute un travail, il télécharge tout d’abord tous les ensembles de tâches requis par les étapes du travail. Normalement, pour les performances, il décompresse les tâches une fois par travail même si la tâche est utilisée en plusieurs étapes. Si vous avez des préoccupations concernant le code non approuvé modifiant le contenu décompressé, vous pouvez supprimer un peu de performances en faisant décompresser la tâche sur chaque utilisation. Pour activer ce mode, passez --alwaysextracttask lors de la configuration de l’agent.
Amélioration de la sécurité des versions en limitant l’étendue des jetons d’accès
En s’appuyant sur notre initiative visant à améliorer les paramètres de sécurité pour Azure Pipelines, nous prenons désormais en charge la restriction de l’étendue des jetons d’accès pour les versions.
Chaque travail qui s’exécute dans les versions obtient un jeton d’accès. Le jeton d’accès est utilisé par les tâches et par vos scripts pour rappeler dans Azure DevOps. Par exemple, nous utilisons le jeton d’accès pour obtenir du code source, télécharger des artefacts, charger des journaux, des résultats de test ou effectuer des appels REST dans Azure DevOps. Un nouveau jeton d’accès est généré pour chaque travail et expire une fois le travail terminé.
Avec cette mise à jour, nous nous appuyons sur l’amélioration de la sécurité du pipeline en limitant l’étendue des jetons d’accès et en étendant la même chose aux versions classiques.
Cette fonctionnalité sera activée par défaut pour les nouveaux projets et organisations. Pour les organisations existantes, vous devez l’activer dans organization Paramètres > Pipelines > Paramètres. > Limitez l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production. En savoir plus ici.
Améliorations de la version préliminaire de l’API YAML
Il y a quelques sprints, nous avons introduit la possibilité d’afficher un aperçu du YAML complet d’un pipeline sans l’exécuter. Avec cette mise à jour, nous avons créé une nouvelle URL dédiée pour la fonctionnalité d’aperçu. Vous pouvez maintenant publier pour https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview récupérer le corps YAML finalisé. Cette nouvelle API prend les mêmes paramètres que la mise en file d’attente d’une exécution, mais ne nécessite plus l’autorisation « Files d’attente ».
Azure Artifacts
Configuration de sources en amont pour Universal Packages
Vous pouvez maintenant configurer vos flux Azure Artifacts pour télécharger automatiquement des packages universels à partir de amont sources à la demande.
Auparavant, vous pouvez configurer amont sources sur votre flux pour les packages NuGet, Python, Maven et npm, mais pas pour les packages universels. Cela a été dû à une différence dans la technologie de stockage utilisée pour les packages universels, qui prennent en charge des packages beaucoup plus volumineux que d’autres types de packages pris en charge.
Vous pouvez maintenant configurer amont sources pour les packages universels de la même façon que pour d’autres types de packages ; ouvrez vos paramètres de flux, cliquez sur Sources en amont ->Ajouter amont source -> et choisissez le type de source qui vous convient. Vous verrez les packages universels (UPack) comme une nouvelle option dans la vue suivante (voir l’image ci-dessous). Pour plus d’informations, consultez la documentation de configuration amont sources.
Notez que les packages universels dans amont sources sont uniquement pris en charge entre les flux de la même organisation DevOps.
Mise à jour de l’API REST de version Package maintenant disponible pour les packages Maven
Vous pouvez maintenant utiliser l’API REST « Update Package Version » d’Azure Artifacts pour mettre à jour les versions du package Maven. Auparavant, vous pouvez utiliser l’API REST pour mettre à jour les versions des packages NuGet, Maven, npm et Universal, mais pas les packages Maven.
Pour mettre à jour les packages Maven, utilisez la commande HTTP PATCH comme suit.
PATCH
https://pkgs.dev.azure.com/{organization}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1
Vous pouvez définir les éléments suivants :
Paramètres d’URI
| Nom | Dans | Obligatoire | Type | Description |
|---|---|---|---|---|
| artifactId | path | VRAI | string | ID d’artefact du package |
| feed | path | VRAI | string | Nom ou ID du flux |
| groupId | path | VRAI | string | ID de groupe du package |
| organisation | path | VRAI | string | Nom de l’organisation Azure DevOps |
| version | path | VRAI | string | Version du package |
| projet | path | string | ID de projet ou nom du projet | |
| api-version | query | VRAI | string | Version de l’API à utiliser. Cette valeur doit être définie sur « 5.1-preview.1 » pour utiliser cette version de l’API |
Corps de la demande
| Nom | Type | Description |
|---|---|---|
| views | JsonPatchOperation | Vue à laquelle la version du package sera ajoutée |
Pour plus d’informations, reportez-vous à la documentation de l’API REST à mesure qu’elle est mise à jour.
É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.
Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.
Merci,
Aaron Hallberg