Utiliser le modèle par défaut pour un processus de build
Le modèle par défaut (.png "TFVC icon")
TfvcTemplate.12.xaml ou .png "Git icon")
GitTemplate.12.xaml) vous permet de définir rapidement un processus de base pour générer et tester votre code. Vous avez la possibilité de contrôler la manière dont Team Foundation Build (TFBuild) génère votre code, exécute vos tests et exécute d'autres processus tels que les scripts.
Prise en main
(Facultatif) Avant de créer une définition de build, à partir de la page d'accueil de Team Explorer (raccourci clavier : Ctrl+0, H), ouvrez la solution que vous souhaitez générer pour qu'elle soit automatiquement spécifiée dans la zone Projets.
Dans Team Explorer, vérifiez que vous êtes connecté au projet d'équipe (raccourci clavier : Ctrl + 0, C), puis ouvrez la page Builds (raccourci clavier : Ctrl + 0, B).
Cliquez sur le lien Nouvelle définition de build ou sélectionnez une build, ouvrez son menu contextuel, puis choisissez Modifier la définition de build.
Conseil
Si un message d'erreur TF225001 s'affiche, configurez un contrôleur de build.
Sous l'onglet Processus , sous Modèle de processus de génération, le modèle par défaut est sélectionné par défaut.
.png "Default Template build process")
Avertissement
Êtes-vous connecté à un projet d'équipe Git
hébergé sur Visual Studio Online ?Les paramètres Substitution de l'extraction et Projets sont-ils absents ?.png "Parameters from the wrong Git default template")
Consultez Comment puis-je être sûr que j'utilise le modèle de processus de génération Git par défaut approprié sur Visual Studio Online ?
Utilisez les informations ultérieures de cette rubrique pour renseigner les champs qui fournissent les fonctionnalités que vous souhaitez placer dans cette définition de build.
Après avoir rempli les champs de l'onglet Processus, spécifiez les options de processus de génération sur les autres onglets.
Pour plus d'informations, consultez Créer ou modifier une définition de build.
Que voulez-vous faire ensuite ?
Obtenir votre code
Générer votre code
Spécifier les projets à générer
Spécifier les plateformes et configurations à générer
Spécifier les options de build
Exécuter d'autres processus pendant la build
Exécuter l'analyse du code pendant la build
Contrôler comment les serveurs exécutent votre build
Spécifier les agents de build qui traitent votre build
Spécifier des limites temporelles pour l'agent de build
Contrôler le résultat de la build
Spécifier l'emplacement de sortie de la build
Rendre les noms des builds terminées simples à comprendre pour votre équipe
Publier les symboles de la build
Associer et créer les éléments de travail
Créer un élément de travail en cas d'échec
Étiqueter votre code source
Obtenir des réponses à des questions courantes
Obtenir votre code
Vous pouvez définir des options décrivant comment l'agent de build obtient le code source que vous avez spécifié sous l'onglet Paramètres de la source.
Pour… |
Définissez ce paramètre… |
En suivant ces recommandations... |
|---|---|---|
Spécifier si et comment nettoyer l'espace de travail ou le référentiel Git de l'agent de build avant qu'il ne traite la build |
|
Sélectionnez True pour supprimer toutes les sorties et tous les fichiers de code source existants avant que la build ne soit traitée. Utilisez cette option si vous souhaitez que votre processus de compilation expose de la manière la plus complète possible les problèmes présents dans votre processus de génération. Conseil Si votre processus de génération ne requiert pas un espace de travail ni un référentiel nettoyé, vous pouvez réduire considérablement le temps d'exécution de la build en affectant à ce paramètre la valeur False. Ce paramètre n'a aucun effet si vous utilisez le contrôleur de build hébergé. Dans ce cas, vous obtenez un nouveau répertoire de travail avec chaque build. |
Générer une version spécifique de votre code source |
|
TFVC : spécifiez versionspec qui identifie la version que vous souhaitez générer. Git : spécifiez la branche ou validez l'ID à extraire. |
Générer votre code
Vous pouvez utiliser MSBuild pour compiler votre code.
Spécifier les projets à générer
Dans la zone Projets, sous Générer dans la table Paramètres du processus de génération, vous pouvez spécifier une ou plusieurs solutions ou projets de code à générer. Vous devez spécifier au moins une solution ou un projet.
Si vous générez plusieurs projets connexes, vous devrez généralement les ajouter à une solution unique et indiquer cette solution dans la zone Projets au lieu de répertorier chaque projet séparément.
Dans la zone Projets, vous pouvez cliquer sur le bouton de sélection (...) pour ouvrir et utiliser la boîte de dialogue Solutions/Projets afin de spécifier les solutions ou les projets à générer.
Pour remplir manuellement la zone Projets d'un projet d'équipe TFVC, spécifiez le chemin d'accès complet au contrôle de version de chaque projet ou solution que vous souhaitez générer. Vous délimitez chaque valeur par une virgule, comme l'illustre l'exemple suivant :
$/Features/FeatureA/Server/All Server Projects.sln, $/Features/FeatureA/Client/All Client Projects.sln
Important
Si vous utilisez TFVC, assurez-vous que le chemin d'accès de chaque projet ou solution est un enfant de l'une des valeurs Dossier du contrôle de code source répertoriées sous l'onglet Paramètres de la source de la définition de build.Si vous utilisez Git, assurez-vous que le projet ou la solution est dans votre référentiel Git, dans une branche que vous générez.
Spécifier les plateformes et configurations à générer
Dans la zone Configurations, vous pouvez spécifier les plateformes et les configurations que vous souhaitez générer. Par exemple, vous pouvez spécifier que cette build doit générer uniquement la configuration Release de la version 32 bits de votre projet C++ en incluant Version finale|x86 dans cette zone.
Conseil
Si vous possédez un grand code base, vous pouvez augmenter considérablement la vitesse de traitement de la build en générant uniquement les configurations et plateformes dont vous avez besoin.
Si vous ne remplissez pas la zone Configurations, la configuration et la plateforme par défaut définies dans chaque solution ou projet seront générées.
Dans la zone Configurations, vous pouvez cliquer sur le bouton de sélection (...) pour ouvrir et utiliser la boîte de dialogue Configurations et spécifier les éléments à générer. Vous pouvez également les spécifier manuellement.
Chaque configuration de la zone Configurations doit se présenter sous la forme suivante :
Configuration|Plateforme
Vous devez remplacer les espaces réservés suivants :
Configuration est une valeur telle que Débogage, Version finale ou Toutes les configurations.
Plateforme est une valeur telle que Win32, x86, x64 ou Any CPU.
Les configurations de la liste doivent être séparées par des virgules.
Par exemple, pour générer simultanément les configurations Débogage et Version finale de votre projet C#, vous devez spécifier Débogage|Any CPU, Version finale|Any CPU dans la zone Configurations.
Les jetons que vous utilisez pour la configuration et la plateforme doivent correspondre aux jetons configurés dans vos propriétés de solution ou de projet de code. Si ces éléments ne correspondent pas, vous risquez d'obtenir des résultats inattendus une fois la build terminée.
Notes
Si vous générez des projets de code distincts au lieu d'un fichier solution et que vous souhaitez spécifier Any CPU en guise de plateforme, vous devez la spécifier sous la forme AnyCPU au lieu de Any CPU.
Spécifier les options de build
Vous pouvez contrôler plusieurs options de build.
Pour… |
Définissez ce paramètre… |
En suivant ces recommandations... |
|---|---|---|
Contrôler si la régénération est nécessaire |
Générer, Build propre |
Affectez la valeur True si vous souhaitez régénérer tout le code dans les projets de code. Cela équivaut à MSBuild /target:clean. Cette option n'a aucun effet pratique à moins que ne vous définissiez également Nettoyer le référentiel sur False. Conseil Vous pouvez réduire considérablement le temps nécessaire à la build de codes base volumineux en définissant cette option sur False. |
Valider du code par rapport à des diagrammes de couche |
Générer, Avancé, Arguments MSBuild |
Incluez la chaîne suivante dans cette valeur de paramètre : /p:ValidateArchitecture=true. Pour plus d'informations, consultez Valider du code avec des diagrammes de couche. |
Spécifier des arguments de ligne de commande à passer à MS Build |
Générer, Avancé, Arguments MSBuild |
Si votre processus de génération nécessite que vous passiez des arguments à MSBuild, entrez-les dans le paramètre Arguments MSBuild. Pour plus d'informations, consultez Référence de la ligne de commande MSBuild. |
Spécifier le nombre de bits de la version MSBuild utilisée pour traiter votre build |
Générer, Avancé, Plateforme MSBuild |
Spécifiez l'une des valeurs suivantes :
Si vous spécifiez cette valeur, vous devez vous assurer (par exemple, en utilisant une balise comme expliqué précédemment dans cette rubrique) que votre build est traitée par un agent de build hébergé par un ordinateur de build 64 bits. Sinon, votre build échoue. |
Exécuter d'autres processus
Vous pouvez exécuter d'autres processus pendant la build.
Effectuer l'analyse du code
Vous pouvez analyser votre code pour y rechercher des erreurs courantes pendant la build. Définissez le paramètre Effectuer l'analyse du code dans les paramètres de build avancés.
Sélectionnez Comme configuré pour analyser chaque projet de code dans lequel cette fonctionnalité est activée.
Sélectionnez Toujours pour analyser chaque projet de code, que cette fonctionnalité soit activée ou non dans les projets de code.
Sélectionnez Jamais pour ignorer l'analyse du code.
Pour plus d'informations, consultez l'une des rubriques suivantes :
Comment : définir les propriétés d'analyse du code pour les projets C/C++
Comment : configurer l'analyse du code pour un projet de code managé
Comment : configurer l'analyse du code pour une application Web ASP.NET
Contrôler comment les serveurs exécutent votre build
Vous pouvez contrôler la manière dont les serveurs de builds exécutent votre build.
Spécifier les agents de build qui traitent votre build
Pour spécifier quels agents de build sont utilisés pour traiter votre build, développez le nœud Avancé, puis le nœud Paramètres d'agent, et spécifiez enfin les valeurs des paramètres suivants :
Filtre de nom : vous pouvez filtrer les agents de build utilisés pour traiter cette définition de build en tapant le nom d'un agent dans ce champ. Vous pouvez également spécifier un ensemble de noms à l'aide des caractères génériques * et ?. Par exemple, vous pouvez indiquer CI* pour spécifier tous les agents dont le nom commence par les caractères CI. Les agents correspondant à ce critère incluent CI, CI1 ou CI_Agent2.
Filtre de balises : spécifiez une ou plusieurs balises pour vous assurer que seuls les agents de build comportant les balises correspondantes exécuteront cette build. En général, vous appliquez des balises à certains agents de build pour les réserver à des fins spéciales. Par exemple, vous configurez un agent de build sur un ordinateur de build conçu pour traiter vos builds d'archivage contrôlé. Vous appliquez la balise de contrôle à cet agent de build. Enfin, vous appliquez la balise de contrôle à la définition de build afin qu'elle soit traitée uniquement par l'agent également référencé par cette balise. Pour spécifier des balises, cliquez sur le bouton de sélection (…).
Notes
Le pool des agents de build disponibles pour traiter cette build est déterminé par le contrôleur de build que vous avez spécifié pour cette définition de build.Pour modifier le contrôleur de build, cliquez sur l'onglet Valeurs par défaut des builds, ouvrez le menu Contrôleur de build, puis sélectionnez un contrôleur de build.
Opérateur de comparaison de balises : dans le menu, choisissez l'une des valeurs suivantes :
MatchExactly : sélectionnez cette valeur si vous souhaitez que cette définition de build soit traitée uniquement par les agents de build dont le jeu de balises correspond exactement aux balises spécifiées dans la zone Filtre de balises. Si vous ne spécifiez pas de balise, n'importe quel agent peut traiter cette définition de build.
Conseil
En sélectionnant MatchExactly, vous limitez les agents disponibles pour cette définition de build à ceux dont le jeu de balises correspond exactement à celles spécifiées dans le champ Filtre de balises.
MatchAtLeast : sélectionnez cette valeur si vous souhaitez que cette définition de build soit traitée par n'importe quel agent de build qui possède au moins le même jeu de balises que vous avez spécifié dans le champ Filtre de balises. Si vous ne spécifiez pas de balise, seuls les agents qui n'ont aucune balise peuvent traiter cette définition de build.
Spécifier des limites temporelles pour l'agent de build
Pour spécifier des limites de temps, développez le nœud Avancé puis le nœud Paramètres d'agent, et spécifiez les paramètres du tableau suivant.
Pour… |
Définissez ce paramètre… |
En suivant ces recommandations... |
|---|---|---|
Spécifier le temps maximum accordé à l'agent de build pour traiter la build |
Durée d'exécution maximale |
Entrez une valeur d'intervalle de temps au format hh:mm:ss. Par exemple, la build échoue avec une erreur de délai d'expiration si vous spécifiez une valeur de 04:30:15 et que l'agent de build n'a pas terminé son travail après 4 heures, 30 minutes et 15 secondes. Si vous souhaitez accorder à l'agent de build un temps illimité pour traiter la build, spécifiez une valeur de 00:00:00. |
Spécifier le temps maximum accordé pour assigner la demande de build à un agent de build |
Durée d'attente maximale |
Entrez une valeur d'intervalle de temps au format hh:mm:ss. Par exemple, la build échoue avec une erreur de délai d'expiration si vous spécifiez une valeur de 01:30:45 et que la build n'a pas été assignée à un agent de build après 1 heure, 30 minutes et 45 secondes. Si vous souhaitez accorder au contrôleur de build un temps illimité pour rechercher un agent de build pour traiter cette définition de build, spécifiez une valeur de 00:00:00. |
Contrôler le résultat de la build
Spécifier l'emplacement de sortie de la build
Pour contrôler l'emplacement où TFBuild insère les sorties de la build, sélectionnez :
SingleFolder pour placer tous les fichiers de sortie de la build ensemble dans le dossier cible.
PerProject pour regrouper les sorties de la build dans des sous-dossiers du dossier cible pour chaque solution ou projet de code que vous avez spécifié dans la zone Projets.
AsConfigured pour laisser les fichiers binaires dans le dossier des sources d'agent de build, organisé selon la même structure de sous-dossiers que lorsque vous générez votre code sur votre ordinateur de développement avec Visual Studio. Cette structure est définie dans vos projets de code.
Si vous utilisez cette option, TFBuild ne copiera pas la sortie dans le dossier cible. Au lieu de cela, vous pouvez programmer vos scripts pour copier les sorties dans l'emplacement spécifié par TF_BUILD_BINARIESDIRECTORY afin qu'elles soient déplacées vers l'emplacement intermédiaire. Voir les scripts de post-génération ou de post-test.
Rendre les noms des builds terminées simples à comprendre pour votre équipe
Votre équipe et vous-même pouvez utiliser Avancé, Format du numéro de build pour charger des données utiles dans le nom de chaque build terminée. Pour connaître les valeurs valides de ce paramètre, consultez Utiliser des numéros de build pour attribuer des noms pertinents aux builds terminées.
Publier les symboles de la build
Spécifiez le paramètre Chemin d'accès pour publier les symboles pour indexer et publier les données de symboles afin d'activer des fonctionnalités telles que le débogage d'historique. Consultez Indexer et publier des données symboles.
Associer des ensembles de modifications, des validations et des éléments de travail
Le processus de génération lie automatiquement chaque build terminée à tous les ensembles de modifications ou validations apportés au code, ainsi qu'à tous les éléments de travail associés. Vous ne pouvez pas désactiver ce comportement, mais sous Avancé, vous pouvez décider si vous souhaitez ou non Mettre à jour les éléments de travail avec le numéro de build en sélectionnant True ou False.
Comment le processus de génération détermine-t-il quand associer des ensembles de modifications, des validations et des éléments de travail ?
Créer un élément de travail en cas d'échec
Pour le paramètre Avancé, Créer un élément de travail en cas d'échec, sélectionnez True si, en cas d'échec de la build, vous souhaitez que le processus de génération crée un bogue et l'assigne à la personne qui a archivé l'ensemble de modifications TFVC ou a effectué la validation de Git.
Étiqueter votre code source
Pour Contrôle de version TF, Etiqueter les sources, sélectionnez True si vous souhaitez marquer automatiquement chaque fichier de code source avec une étiquette pour permettre à votre équipe d'identifier facilement quelle version de chaque fichier est incluse dans la build terminée. Ce paramètre ne s'applique pas aux projets d'équipe Git.
Pour plus d'informations sur la manière dont TFBuild détermine la version à étiqueter, consultez le blog How good was that build?
Q et R
Comment puis-je être sûr que j'utilise le modèle de processus de génération Git par défaut approprié sur Visual Studio Online ?
Êtes-vous connecté à un projet d'équipe Git hébergé sur Visual Studio Online ? Les paramètres Substitution de l'extraction et Projets sont-ils absents ?
Lorsque vous affichez les détails, Modèle par défaut (GitTemplate.xaml) apparaît-il ?
.png "The wrong Git default template")
Dans ce cas, sélectionnez GitTemplate.12.xaml. Après cela, le paramètre Substitution de l'extraction et le bouton Parcourir dans le paramètre Projets apparaissent.
.png "The correct Git default template")
Q : Comment le processus de génération détermine-t-il quand associer des ensembles de modifications, des validations et des éléments de travail ?
R : Chaque définition de build gère son propre registre des ensembles de modifications (TFVC), des validations (Git), et des éléments de travail qui attendent d'être associés avec la build terminée suivante.
Par exemple, l'ensemble de modifications 382 est généré à la fois par la Build A et la Build B. La Build A est mise en file d'attente et terminée avec succès. La Build B est mise en file d'attente et échoue. L'ensemble de modifications 382 est à présent lié à la build terminée avec succès de la Build A et la build terminée ayant échoué de la Build B. L'ensemble de modifications 382 ne sera pas lié à la build terminée suivante de la Build A, mais à la build terminée suivante de la Build B.
Pour plus d'informations sur la manière dont TFBuild détermine la version à associer, consultez le blog How good was that build?