Partager via


Groupes de déploiement et déclencheur d’achèvement de build – Mise à jour VSTS Sprint 132

La mise à jour sprint 132 de Visual Studio Team Services (VSTS) apporte quelques fonctionnalités clés pour vous aider à mettre à l’échelle votre pipeline de build et de mise en production. Dans Générer, utilisez le nouveau déclencheur d’achèvement de build pour chaîner des builds associées qui peuvent appartenir à différentes équipes. Dans la version, nous annonçons la disponibilité générale des groupes de déploiement, que vous pouvez utiliser pour mettre à l’échelle les déploiements sur plusieurs machines virtuelles à haute disponibilité, y compris les environnements de production.

Parmi les autres points clés :

Nouveautés de VSTS

Fonctionnalités

Code

Build et mise en production

Package

Wiki

Rapports

Code

Décrire rapidement les demandes de tirage à l’aide de messages de validation

L’écriture de messages de validation descriptifs ajoute de la valeur à l’historique de tout dépôt Git. Pour encourager les messages de validation de qualité, les nouvelles demandes de tirage (TIRAGE) qui ont plusieurs validations obligent les contributeurs à entrer un titre manuellement.

Les descriptions des demandes de tirage continuent d’être vides par défaut, mais une nouvelle fonctionnalité facilite l’intégration des messages de validation des validations de tirage dans la description de la demande de tirage. Pour ajouter les messages de validation, cliquez simplement sur Ajouter des messages de validation pour ajouter les messages de validation à la fin du texte de description de la demande de tirage.

Action Ajouter des messages de validation

Exécuter des commandes TFVC directement à partir de l’Explorateur Windows

L’extension windows shell TFVC, qui offre une expérience de contrôle de version légère intégrée à Windows Explorateur de fichiers, prend désormais en charge VSTS et TFS 2018. Cet outil fournit un accès pratique à de nombreuses commandes TFVC directement depuis le menu contextuel de l’Explorateur Windows.

Intégré auparavant à Team Foundation Server Power Tools, l’outil a été publié en tant qu’outil autonome sur Visual Studio Marketplace.

Extension de l’interpréteur de commande

Build et mise en production

Les produits volumineux contiennent plusieurs composants qui dépendent les uns des autres. Ces composants sont souvent générés indépendamment. Lorsqu’un composant amont (une bibliothèque, par exemple) change, les dépendances en aval doivent être générées et validées à nouveau. Teams gère généralement ces dépendances manuellement.

Vous pouvez maintenant déclencher une build après l’achèvement d’une autre build. Les artefacts produits par une build amont peuvent être téléchargés et utilisés dans la build ultérieure, et vous pouvez également obtenir des données à partir de ces variables : Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Pour plus d’informations, consultez la documentation sur les déclencheurs de génération.

Cette fonctionnalité a été hiérarchisée en fonction de ce qui est actuellement la 2 meilleure suggestion avec 1 129 votes.

Configurer le chaînage de build

N’oubliez pas que dans certains cas, une seule build en plusieurs phases peut répondre à vos besoins. Toutefois, un déclencheur d’achèvement de build est utile si vos besoins incluent des paramètres de configuration différents, des options ou une autre équipe pour posséder le processus dépendant.

Mettre à l’échelle les déploiements sur des machines virtuelles à l’aide de groupes de déploiement

Groupes de déploiement, une solution robuste et prête à l’emploi de déploiement sur plusieurs machines, est désormais mise à la disposition générale. Avec Groupes de déploiement, vous pouvez orchestrer des déploiements sur plusieurs serveurs et effectuer des mises à jour propagées, tout en assurant la haute disponibilité de votre application tout au long du processus. Vous pouvez également effectuer un déploiement sur des serveurs locaux ou des machines virtuelles sur Azure ou n’importe quel cloud, tout en bénéficiant de la traçabilité de bout en bout des versions d’artefacts déployées jusqu’au niveau serveur.

La fonctionnalité de déploiement basée sur un agent s’appuie sur les mêmes agents de build et de déploiement généralement disponibles. Vous pouvez utiliser le catalogue complet des tâches sur vos machines cibles lors de la phase Groupe de déploiement. Du point de vue de l’extensibilité, vous pouvez également utiliser les API REST pour les groupes de déploiement et les cibles dans le cadre d’un accès par programme.

Cibles de déploiement partagé

Si vous utilisez le même serveur pour héberger plusieurs applications, vous pouvez partager le serveur (également appelé cible de déploiement) entre des projets d’équipe à l’aide de pools de déploiement.

Liste des cibles des groupes de déploiement

Nouveaux modèles

Le déploiement sur plusieurs cibles est désormais un jeu d’enfant avec les nouveaux modèles de définition de version. Plusieurs modèles pour le site web IIS, le site web IIS avec base de données et plusieurs modèles de déploiement pour SQL DB sont disponibles prêtes à l’emploi.

Modèles de version pour les groupes de déploiement

Provisionnement de machines virtuelles

Utilisez la tâche de groupe de ressources Azure améliorée pour démarrer dynamiquement les agents sur les Machines Virtuelles nouvellement provisionnés ou préexistants sur Azure.

Tâche de groupe de ressources Azure

Lorsque nous avons lancé des groupes de déploiement en mai dernier, nous avons livré une interface utilisateur simple ciblant quelques scénarios clés. Vous trouverez maintenant une interface plus cohérente qui ressemble au reste du produit.

Pour plus d’informations sur la prise en main, consultez la documentation relative aux groupes de déploiement.

Créer des applications écrites en Go

Vous pouvez maintenant créer vos applications Go dans VSTS !

Utilisez la tâche Go Tool Installer pour installer une ou plusieurs versions de Go Tool à la volée. Cette tâche acquiert une version spécifique de Go Tool nécessaire à votre projet et l’ajoute au CHEMIN d’accès de l’agent de build. Si la version de Go Tool ciblée est déjà installée sur l’agent, cette tâche ignore le processus de téléchargement et d’installation.

La tâche Go vous aide à télécharger des dépendances, à générer ou à tester votre application. Vous pouvez également utiliser cette tâche pour exécuter une commande Go personnalisée de votre choix.

Étendre les portes de mise en production avec des extensions de tâche

Les portes de mise en production apportent des informations sur les signaux d’intégrité directement dans votre pipeline de mise en production. Une porte collecte un ensemble de signaux d’intégrité à plusieurs reprises, avant ou après un déploiement, pour déterminer si la mise en production doit passer à l’étape suivante ou non. Un ensemble de portes intégrées est fourni, et l’option Appeler une fonction Azure a été recommandée pour l’intégration d’autres services jusqu’à présent.

Désormais, les portes peuvent se présenter sous la forme d’une extension, ce qui vous permet, ou pour les auteurs d’extensions, d’intégrer plus facilement des services nouveaux ou personnalisés et de configurer la porte.

Pour plus d’informations, consultez la documentation relative aux tâches de la porte de création.

Package

Utiliser amont packages npm d’ailleurs dans VSTS

Nous continuons d’investir dans amont sources, qui vous permettent de centraliser toutes vos dépendances de package dans un flux unique et de conserver des copies enregistrées de tous les packages que vous utilisez. Si vous avez plusieurs flux VSTS avec des packages npm, vous pouvez désormais en ajouter un en tant que source amont de l’autre dans le même compte VSTS. Étant donné que npm vous limite principalement à un flux/registre unique dans la configuration de votre projet, amont sources vous offre la flexibilité dont vous avez besoin pour utiliser plusieurs flux npm, tels qu’un pour chaque équipe ou produit.

Nous travaillons également à activer bientôt amont sources pour les flux NuGet VSTS. Pour plus d’informations, consultez la documentation sur les sources amont.

Liste des sources en amont

Maintenir la vitesse des requêtes de flux avec des stratégies de rétention

Au fil du temps, le nombre de versions de package peut devenir important, les versions antérieures étant inutilisées. Pour les éditeurs de packages récurrents, cela pouvait se traduire par un ralentissement des requêtes de flux dans le Gestionnaire de package NuGet et d’autres clients tant que certaines versions n’étaient pas supprimées manuellement.

Vous pouvez maintenant activer les stratégies de rétention sur les flux. Les stratégies de rétention suppriment automatiquement la version la plus ancienne d’un package, une fois que le seuil de rétention est atteint. Les packages promus en vues sont conservés indéfiniment, ce qui vous permet de protéger les versions utilisées en production ou largement utilisées dans votre organisation.

Pour activer les stratégies de rétention, modifiez votre flux et entrez une valeur dans la zone Nombre maximal de versions par package de la section Stratégies de rétention.

paramètre de stratégies de rétention

Wiki

Publier des fichiers Markdown à partir d’un dépôt Git en tant que Wiki

Les développeurs créent une documentation pour les « API », les « SDK » et les « documents d’aide expliquant le code » dans les référentiels de code. Les lecteurs doivent ensuite parcourir le code pour trouver la documentation appropriée. Maintenant, vous pouvez simplement publier des fichiers Markdown à partir de dépôts de code et les héberger dans Wiki.

code public en tant qu’action wiki

Dans Wiki, commencez par cliquer sur Publier le code en tant que wiki. Ensuite, vous pouvez spécifier un dossier dans un dépôt Git qui doit être promu.

Boîte de dialogue publier des pages

Une fois que vous cliquez sur Publier, tous les fichiers Markdown sous le dossier sélectionné sont publiés sous la forme d’un wiki. Cela mappe également le chef de la branche au wiki afin que toutes les modifications que vous apportez au dépôt Git soient immédiatement reflétées.

Si vous avez plusieurs versions de votre produit et que vous souhaitez parcourir facilement la documentation de ces versions, vous pouvez également publier une nouvelle version de la documentation sur le wiki à l’aide de différentes branches.

Action publier une nouvelle version

Une fois les fichiers Markdown publiés, les pages peuvent également faire l’objet d’une recherche dans le hub de recherche Wiki.

résultats de recherche pour Azure CLI

Si vous avez publié le mauvais dépôt, annulez simplement la publication du wiki, ce qui laisse le dépôt sous-jacent inchangé.

Vous pouvez également modifier l’ordre des pages à partir du dépôt ou même transformer un dossier pour qu’il ressemble à une page wiki.

Pour plus d’informations, consultez le billet de blog de la documentation produit . Cette fonctionnalité a été rendue prioritaire à la suite d’une suggestion.

Conserver des caractères spéciaux dans les titres des pages Wiki

Vous pouvez maintenant créer des pages wiki avec des caractères spéciaux tels que : < > * ? | -. Désormais, des pages avec des titres tels que « FAQ ? » ou « Guide de configuration » peuvent être créées dans Wiki. Les caractères suivants sont traduits en chaînes encodées en UTF-8 :

Caractère Chaîne encodée
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D

Cette fonctionnalité a été rendue prioritaire à la suite d’une suggestion.

Étendre Wiki à l’aide d’API REST

Les API REST Wiki sont désormais publiques. Pour plus d’informations, consultez les fonctions Wiki et la documentation de recherche Wiki .

Rapports

Intégrer Power BI à VSTS Analytics à l’aide de vues

Les vues d’analyse fonctionnent avec notre connecteur de données Power BI VSTS. Ensemble, ils offrent un moyen simple d’obtenir vos données VSTS dans Power BI afin que vous puissiez commencer à créer des rapports personnalisés.

Lorsque vous installez l’extension VSTS Analytics, nous créons un ensemble de vues Analytics par défaut que vous pouvez commencer à utiliser dans Power BI. Vous pouvez maintenant modifier vos vues par défaut et créer de nouvelles vues pour affiner les enregistrements, les champs et l’historique retournés à Power BI.

Étapes suivantes et commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Signalez un problème ou fournissez une suggestion si vous avez des idées sur les éléments que vous souhaitez nous voir hiérarchiser, via le menu de commentaires.

Menu Commentaires

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

Merci,

Gopinath Chigakkagari